[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