Log file Viewer
#python2.8 logs for Tuesday the 7th of January, 2014
[01:12:08] <ctismer> aclark: I read that this channel is publically logged. Where, please? I'd like to catch up...
[02:22:22] <ctismer> tos9: well, compared to yesterday's discussions, the activity here is - hum - moderate? ;-)
[02:24:08] <ctismer> but actually, this is really about a possible python 2.8, and not stackless (ugh, relief)
[02:27:01] <ctismer> ok, I will stay until after we made stackless 2.8 public. Maybe that is constructive, too.
[08:57:06] <ztane> having read the logs, the major 3 reasons for not adopting python 3 seem to be: bytes does not have encode, unicode does not have decode...; print is not a statement, and 3 / 2 == 1.5
[09:55:55] <ctismer> ztane: I am happily using python 3 in all but one project, and I think the bytes/unicode distinction is a very good thing that removes lots of errors.
[09:59:15] <ctismer> but the real problem is that repr is not active on a one-liner, like in an interactive shell.
[10:10:51] <peke> ztane: this is a bit ot, but i happen to like 3/2 == 1.5. i find it annoying to use x/float(y) in py2. at least in my typical use cases i need true division more often would rather use x//y when floor division is needed.
[10:13:20] <peke> i know i could `from __future__ import division`, but i don't like that i cannot look at a diff containing `x/y` w/o knowing what it actually does. one of the reasons i agree with mitsuhiko that `from __future__ import unicode_literals` is a bad idea.
[10:14:15] <mitsuhiko> for instance os.path.join(os.getcwd(), '..', 'foo') with unicode literals breaks in subtle ways
[10:29:57] <peke> mitsuhiko: agreed. thanks for making an issue about getting u'' back in py3.3! i doubt i would even consider porting my projects to py3 without it.
[14:14:34] <Unode> The topic mentions "channel is publicly logged", can someone add the URL somewhere? I'd like to read what has been discussed already. Thanks
[15:03:06] <faassen> I've been asking some questions on the stackless mailing list about 2.8; I see ctismer is now also on the channel, welcome!
[15:04:07] <faassen> mainly I'm wondering how much room there would be in stackless 2.8 for facilities to help people upgrade their code to Python 3, i.e. something like what python-future has, and here's how I theorize it works: https://groups.google.com/d/msg/comp.lang.python/CvtQVzZWcUE/bvt3Cg0FhSoJ
[15:04:50] <faassen> it'd be nice if someone dug into the 'future' module codebase to verify whether my speculation in that post is correct.
[15:26:35] <Unode> Upon reading the backlog of the channel, and apologies for stating anyting already obvious, I get the impression that the primary reason why python 3 hasn't been adopted is that an effort (time, money,...) is required to port the code between 2 and 3 (proportional to the size of the codebase).
[15:28:41] <dstufft> Unode: mostly, also things are being ported (where things == libraries/tools) and it's often times means if you use py3 you'll hit something that isn't ported yet
[15:28:49] <tomprince> That would be less of an issue if things were easier to port, and could be ported incrementally.
[15:28:50] <dstufft> so it's a combination of requiring effort to port your own code, and dependencies not all being updated yet
[15:28:53] <faassen> I think porting incrementally is more important for applications than for libraries.
[15:29:38] <faassen> so your boss will ask: well, so you ask me to give you X amount of time to port this code, and there's no benefit except a "slightly cleaner programming language", and there's a chance we'll end up with new bugs?
[15:29:52] <Unode> With that said, I so far fail to understand why python2.8 would help this aspect. Meaning any python2 would allow execution of the code but could not include any of the "backwards-incompatible" changes, or existing code would fail if unchanged.
[15:30:10] <faassen> well, I think a Python 2.8 could help because then you can tell your boss: this is the obvious upgrade path.
[15:30:23] <faassen> python 2.8 *could* add facilities for incremental upgrading of unicode, I suspect looking at the 'future' module.
[15:30:47] <Unode> faassen, I understand the incremental value when you need to justify to your boss, but I fail in terms of the accumulated effort required to do so.
[15:31:48] <dstufft> faassen: I think it makes more sense to add facilities to 3.x to make it easier to port than to release a 2.x line
[15:32:03] <faassen> dstufft: sure, that was brought up here yesterday.. but what would that require?
[15:32:21] <dstufft> faassen: I don't know :) I don't have any problems porting my stuff to python 3
[15:32:23] <Unode> faassen, taking any app/library as is now. The effort required to port to python 3 is smaller than any other path with additional steps.
[15:32:58] <faassen> Unode: well, I think collective effort versus individual effort should be distinguished.
[15:33:02] <dstufft> I know some folks (Mercurial and Twisted?) have expressed that losing % and .format() on bytes is a hard thing for them
[15:33:43] <faassen> Unode: we could make individual porting efforts more incremental while this takes more work by others to make it so.
[15:34:00] <tos9> there's a few other bugs that also are important for them that will come up again as more work is done porting
[15:34:08] <faassen> my argument is that those who have the least motivation to port are the ones with the money, and should therefore be valuable to our community.
[15:34:26] <tos9> there's a bug with buffer() behavior in py3 that's also fairly important last I heard
[15:34:37] <faassen> case in point is stackless; I saw a rant by Christian Tismer where he said he prefers Python 3, he ported all his stuff over to it, but his customers don't want it, and want a stackless 2.8.
[15:34:56] <Unode> faassen, I think a lot of different aspects are being thrown to the same basket. And note I'm not dismissing any of them. It simply makes defining the target harder.
[15:35:01] <tos9> dstufft: (I know, sorry, my point was tangentially "there are a class of bugs that are important in py3 to fix", which was probably the same as yours)
[15:35:21] <faassen> Unode: sure. So far given the discussions on this irc channel I'm not optimistic anything can be figured out to actually do.
[15:35:34] <faassen> Unode: but I think it's valuable to have the discussion, and who knows.. I'm learning *some* things.
[15:36:12] <faassen> but I do think the community has a bit of a blind spot concerning who pays for us coding this stuff, and where THEIR interests are.
[15:36:19] <dstufft> I think making Py3 easier to port to from 2.x is a better solution than a 2.8, especially a 2.8 that backports actual features (because a 2.8 that backports features will just drag out this split longer because people will stick to it instead of 2.7 with less motivation to move to 3)
[15:36:51] <faassen> well, if a 2.8 that backports actual features is created.. there's apparently a demand for it.. and that should tell the community something important.
[15:37:10] <faassen> you can argue morally against it that it would drag out this split, but the people driving that backporting may not be susceptible to this moral argument.
[15:38:06] <faassen> making incremental upgrades possible for Python 3 in the unicode might involve something like from __past__ import unicode, str :) but I need to think about how that is supposed to interact with proper unicode/bytes and what that all entails.
[15:38:56] <dstufft> I mean fundamentally you have a backwards incompatible change which if you mix str/bytes together in Python 2.x you'll have to solve and there's not much that can be done about that
[15:39:11] <Unode> From the backlog I got a mix of things including "I don't like feature X and/or consider Y worse than existing", "It's too expensive (time, money) to do the port", "I want a python2.8 so I can run my code with minimal changes without much effort"
[15:39:31] <faassen> dstufft: well, that's the question. *is* there nothing that Python can do to help with this?
[15:39:53] <faassen> Unode: yeah, I think the "I don't like feature X" is really irrelevant to what can be done in a Python 2.8 (or potentially in Python 3.x)
[15:40:04] <Unode> For the last point I blame backwards incompatibility and don't see any way around it other that doing the changes.
[15:40:38] <faassen> well, incremental upgrades versus whole upgrades, making it blindingly obvious to in-house app projects what the upgrade path is, small steps..
[15:40:57] <faassen> I do think that incremental bytes/str upgrades should be possible, see my earlier link.
[15:41:32] <Unode> dstufft, how can you make py3 easier to port to without removing the backwards incompatible changes (which are largely the reason behind the 3 series)?
[15:41:53] <dstufft> Unode: in many cases it's exactly that, removing some backwards incompatible changes
[15:42:56] <tomprince> Or, hiding backwards incompatible changes behind a __future__ that you can turn off and on.
[15:43:27] <faassen> tomprince: well, a __past__ in py3, otherwise it'd be backwards incompatible with itself?
[15:43:27] <dstufft> tomprince: that only works for changes that fundamentally can work at the module level
[15:43:55] <tomprince> For things that don't work at a module level, one option would be a command line switch, so you can change *just* that behavior.
[15:44:07] <Unode> dstufft, if you take that road for too long you end up removing all of the backwards incompatible ones. which makes me think if python 3 is a valid name at all.
[15:45:08] <dstufft> Unode: Core incompatible changes wouldn't get backed out, like the removal of implicit conversion between bytes and str
[15:45:50] <Unode> Personally I'm not fond of the __past__ strategy. I would love to have python 2 inside python 3 but am kinda scared of what that will do to the interpreter (i.e. mess at all levels including performance)
[15:47:01] <tomprince> An option to turn on bytes/string-incompatiability and an option to force new-style classes would be two big things that would help.
[15:47:26] <dstufft> tomprince: I'm not sure if a cli switch is all that useful TBH, I could be wrong of course. but I don't think i'd actually be able to use it very often because it would rely on all of my dependencies having updated themselves to wahtever switch I happen to be switching on. I think the likelygood of them all having that one particular switch on is pretty low (but IDK maybe it would help :D)
[15:48:48] <tomprince> There is actually talk of doing the later in twisted, since chaning that is potentially backwards-incompatible. (Although probably not in practice, for most people).
[15:48:49] <dstufft> tomprince: I suppose so, though mostly if they theymelves didn't have dependencies
[15:49:28] <tomprince> But we want to provide a smooth path for people to test that there code actually works with the new way, before forcing it on them.
[15:49:41] <dstufft> otoh if it's just a porting aid to allow developers to turn things on one at a time it wouldn't even really need to be an official full out Python 2.x release
[15:50:12] <dstufft> unless you'd expect people to run with some of the flags turned on in production
[15:51:49] <tomprince> If I was going through the trouble of porting to 3.x incrementally, I would definitely want to run with things turned on in production.
[16:42:59] <ctismer> cwillu_borken: yes, I would too like it better if floats would be generated only when necessary. But this is nothing serious against python3
[16:50:11] <ctismer> and I have to confess that my real motivation is to make people use stackless. That's the one time wehe I want to be mean ;-)
[16:52:55] <faassen> well, hey, the core developers gave you the opportunity, I think it'd be weird if they actually blamed you for taking it.
[16:53:07] <faassen> if people are willing to pay you for it, then well, that's something people should learn from.
[16:53:43] <faassen> ctismer: I just replied to the from __future__ import nonlocal issue by the way. I would *really* like to be able to write polyglot code that works on both stackless and python 3.x
[16:53:50] <faassen> ctismer: if you care about smooth upgrades, it should be from __stackless__ or some other thing that's not __future__.
[16:58:34] <faassen> ctismer: nothing, but if you want to promote stackless 2.8 as a smoother upgrade to Python 3.x
[16:58:40] <faassen> ctismer: then it should be possible to write code that works on stackless 2.8 *and* python 3.x
[16:59:49] <faassen> it'd just make it harder for me to recommend it as a smoother upgrade path to python 3.
[17:00:26] <faassen> once you go stackless and use the upgrade smoothening features, you can't write polyglot code anymore.
[17:00:53] <ctismer> well, this is all in the air, ans sure we can provide a smooth transition, just playing with ideas.
[17:01:36] <tomprince> I would be suprised if python-dev was opposed to adding stuff to __future__ as no-ops, to make transition easier.
[17:02:18] <faassen> tomprince: and I'd not be surprised if python-dev *was* opposed to adding it as no-ops, unfortunately. :(
[17:33:26] <zzzeek> well looks like scombinator making friends on the reddit thread as well, -9 points for http://www.reddit.com/r/Python/comments/1ukqav/eli5_why_is_there_a_seemingly_larger_push_to/cejfmra
[18:26:09] <stackless> there is a "stackless 2.8" being built, which is python 2.7.6 plus some backports, undefined how much we will backport.
[18:27:17] <stackless> right now it has support for VS2010 on Windows, because usin VS2008 for Python 2 _and_ VS2010 for Python 3 is a PITA
[18:28:38] <stackless> and you get the stackless features as well, but only if you "import stackless". Otherwise it is plain vanilla Python.
[18:30:14] <stackless> we never wanted to fork, but now it happens, and the reason is python-dev's behavior when I asked about 2.8 ...
[18:36:18] <stackless> aclark: yeah, actually a good thing for our project. Since 1998 stackless struggled to be used as a drop-in replacement of CPython, with little success.
[18:37:41] <stackless> The name change of the executable makes it easy to install them both and see that things are compatible.
[18:38:42] <ionelmc> excuse my ignorance, wouldn't it be better to just have a py3.5 with some unsafe a-la-2.7 string for reckless sort of people?
[18:38:43] <stackless> in a sense, the 2.8 debacle is becoming a better chance for wider adoption of stackless.
[18:40:20] <stackless> ionelmc: you mean you want to throw in a string type as inconsistent as it was in 2.7?
[18:41:46] <stackless> that move was one of the best changes to Python! All projects which are converted have to struggle with that, and afterwards the projects are _much_ cleaner.
[18:41:56] <ionelmc> i'm just asking, seems an obvious way to have ends meet - it doesn't need to be a `type` ... it can be just a C extension providing all that unsafe methods that are missing now
[18:43:18] <stackless> ok, but then I'm asking: why don't the people who think they need that sit together and build such a C module?
[18:46:38] <stackless> I think the biggest push towards python 3.x will come from PyPy, when the port is ready.
[18:47:37] <stackless> If I were PSF, I would collect money for making PyPy 3.x faster than PyPy 2.x. Then this is going from alone.
[18:48:36] <stackless> tomprince: nobody is talking about what it is written in. Actually it is written in RPython, which is a 2.7 subset. But please forget about that.
[18:49:06] <stackless> We are talking of the language that PyPy implements, not what it is written in.
[18:49:20] <dstufft> For the couple days of data I have, PyPy is a smaller set of users than Python 3 (going from PyPI downloads where pip 1.4+ was used), Not enough stuff is written in CFFI for a lot of projects to use PyPy I think
[18:50:00] <tos9> pypy's problems are mostly bad marketing :P, which are simultaneously easier and harder to fix than py3's
[18:50:27] <tomprince> stackless: Sure. But I suspect that pypy will always have a bit of a 2.x bias because of that.
[18:51:39] <stackless> tomprince: I don't think so. We decided once that there is no need to have a second compiler language.
[18:52:27] <dstufft> tos9: Hilarously like Python3 in that there's a big corpus of C stuff that's alreadywritten and will take time to wait for people to port it to cffi
[18:53:05] <dstufft> Although in this case there's a bigger payoff in the massive performance increases
[18:54:31] <stackless> dstufft: my dream is: making a C module PyPy-ready == rewrite the module in Python
[19:01:35] <stackless> tomprince: I must correct me: if people really want to write RPython extensions, then it might make sense to consider a Python 3 based RPython 3.
[19:01:44] <tos9> dstufft: Agreed, although also there's probably a smaller domain certainly that I care about that's unported, because in many places the C was written for performance"