[Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
barry at python.org
Mon Aug 18 16:12:59 CEST 2014
On Aug 17, 2014, at 06: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
The latter is a good point, and sometimes it's a huge challenge to understand
the code being ported. A good test suite (and dare I say, doctests :) help a
lot with this.
I've ported a ton of stuff, and failed at a few. I think all the little
changes are mostly tractable, and we've assembled a pretty good stack of
documents to help[*].
Sometimes a seemingly easy and mechanical port will produce odd failures,
where more domain expertise needs to be brought to bear to get just the right
bilingual invocation. But if the underlying code does not itself have a clear
bytes/str distinction, then you're doomed. One of my failures was a Python
binding for a large C++ project that deeply conflated data and text. Another
was a pure Python library that essentially did the same. In both cases, I
ended up in a situation where some core types could be neither str nor bytes
without some part of the test suite failing miserably. Those are the types of
projects that largely get left unported since it's much harder to justify the
costs vs. benefits.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the Python-Dev