On Sun, Jan 19, 2014 at 12:14 PM, Neil Schemenauer firstname.lastname@example.org wrote:
That's basically the whole idea of this proposal, the bytes/str change in 3.x is the really disruptive one, separate it into separate interpreter versions to make porting easier.
It may be disruptive to a whole lot of code that's been happily oblivious to the whole issue, but it's also central to more and more of Py3's library. It's going to become increasingly difficult to backport stuff from Py3 to a system that doesn't have the same back-end string handling.
If you're prepared to make a whole bunch of incompatible changes to move to this hypothetical 2.8, why not make all the changes at once? Unless 2.x will be maintained forever (with a 2.9, a 2.10, and so on), the changes will have to be made. If it's so costly to make a full pass over your code to port it to 3.3/3.4/3.5, surely it would be twice as costly to make that exact same full pass to port it to 2.8, and then another just the same to port 2.8 to 3.6?
I still maintain that the biggest complaints about the jump from 2.x to 3.x are largely dealt with by 2.7 and 3.3/3.4. Yes, it's hard to jump from 2.5 to 3.1, but you don't have to. Just stick with 2.x until your users are all on 2.7, then strip out all the code that's supporting pre-2.7 versions. Once you have that, you can start in with some __future__ directives (division, print_function, unicode_literals), and start sorting out the bytes/unicode distinction *at your leisure*. (In some cases, that "sorting out" is simply a matter of naming. I have some code that reads from a socket, and it's divided into three parts: first pass works with "data" and handles TELNET codes, second pass works with "text" and handles ANSI codes, third pass works with "text" and handles newlines. It's obvious from the parameter names that the conversion from bytes to Unicode has to happen between the first and second passes.) Then, when you finally come to port it to 3.x (which mightn't be for another however-many years, when 2.7's python.org support finally ends, or it might be even later, when RHEL stops shipping patches, or it might not even be then - code doesn't stop working just because it's not supported), you make the jump to whichever version is most convenient. Currently, I'm seeing 3.3 as easier to jump to than 3.2 (eg the redundant compatibility notation u"str" is available), and 3.4 is getting some more on that front; maybe some features won't make it into 3.4 so they'll be in 3.5. And maybe it'll be 3.7 that you jump to. That's not a problem. Whatever version you port it to, you make *one* assault on your code, and there you are, taking advantage of exactly as much of 3.x as you feel like, and it's all working.