On 18 August 2014 11:14, Donald Stufft <don...@stufft.io> wrote: > On Sun, Aug 17, 2014, at 09:02 PM, Guido van Rossum wrote: >> I'm unsure about what's the single biggest pain moving to Python 3. In the >> past I would have said that it's for sure the bytes/str split (which both >> the biggest pain and the biggest payoff). >> >> But if I look carefully into the soul of teams that are still on 2.7 (I know >> a few... :-), I think the real reason is that Python 3 changes so many >> different things, you have to actually understand your code to port it >> (unlike with minor version transitions, where the changes usually spike in >> one specific area, and you can leave the rest to normal attrition and >> periodic maintenance). >> > > In my experience bytes/str is the single biggest change that causes the > most problems. Most of the other changes can be mechanically transformed > and/or papered over using helpers like six. The bytes/str change is the > main one that requires understanding code and where it requires a > serious untangling of things in code bases where str/bytes are freely > used intechangingbly. Often times this requires making a decision about > what *should* be bytes or str as well which requires having some deep > knowledge about the APIs in question too.
It's certainly the one that has caused the most churn in CPython and the standard library - the ripples still haven't entirely settled on that front :) I think Guido's right that there's also a "death of a thousand cuts" aspect for large existing code bases, though, especially those that are lacking comprehensive test suites. By definition, existing large Python 2 applications are OK with the restrictions imposed by Python 2, and we're deliberately not forcing the issue by halting Python 2 maintenance. That's where Steve Dower's idea of being able to progressively declare a code base "Python 3 compatible" on a file by file basis and have some means of programmatically enforcing that is interesting - it opens the door to "opportunistic and incremental" porting, where modules are progressively updated to run on both, until an application reaches a point where it can switch to Python 3 and leave Python 2 behind. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
