[Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?

Joseph Martinot-Lagarde joseph.martinot-lagarde at m4x.org
Thu Aug 21 02:27:10 CEST 2014


Le 18/08/2014 03:02, Guido van Rossum a écrit :
> On Sun, Aug 17, 2014 at 6:29 AM, Barry Warsaw <barry at python.org
> <mailto:barry at python.org>> wrote:
>
>     On Aug 16, 2014, at 07:43 PM, Guido van Rossum wrote:
>
>      >(Don't understand this to mean that we should never deprecate things.
>      >Deprecations will happen, they are necessary for the evolution of any
>      >programming language. But they won't ever hurt in the way that
>     Python 3
>      >hurt.)
>
>     It would be useful to explore what causes the most pain in the 2->3
>     transition?  IMHO, it's not the deprecations or changes such as print ->
>     print().  It's the bytes/str split - a fundamental change to core
>     and common
>     data types.  The question then is whether you foresee any similar
>     looming
>     pervasive change? [*]
>
>
> 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).

The pain was even bigger because in addition to the change in underlying 
types, the names of the types were not compatible between the python 
versions. I often try to write compatible code between python2 and 3, 
and I can't use "str" because it has not the same meaning in both 
versions, I can not use "unicode" because it disappeared in python3, and 
I can't use "byte" because it doesn't exist in python2. Add __str__ and 
__unicode__ to the mix and then you get the real pain.

Actually "str" is still usefull in the cases where a library is 
byte-only in python2 and unicode-only in python3 (hello, 
locale.setlocale()).

Joseph



More information about the Python-Dev mailing list