[Python-Dev] (Looking for) A Retrospective on the Move to Python 3 (original) (raw)
Victor Stinner vstinner at redhat.com
Mon Apr 30 03:38:45 EDT 2018
- Previous message (by thread): [Python-Dev] (Looking for) A Retrospective on the Move to Python 3
- Next message (by thread): [Python-Dev] (Looking for) A Retrospective on the Move to Python 3
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
2018-04-28 3:33 GMT+02:00 Greg Ewing <greg.ewing at canterbury.ac.nz>:
Victor Stinner wrote:
In my opinion, the largest failure of Python 3 is that we failed to provide a smooth and slow transition from Python 2 and Python 3. Although for some things, such as handling of non-ascii text, it's hard to see how a smooth transition could have been achieved. Is it a failure if we don't succeed in doing the impossible?
Technically, it is easy to add an option to Python 2 to raise an exception on str+unicode and str < unicode.
You can imagine the same option or a different one to really get the bytes type of Python 3 (b'abc'[0] returns 97).
Such option would ease a lot to port code to Python 3, since you only have to care of bytes vs Unicode issue. You don't have to worry about the looooong list of other Python 3 changes (like the new stdlib names...).
Note: Python 3 Unicode is stricter in other ways, like UTF-8 reject lone surrogates. But I don't think that it matters for most users, and technically it would also be possible to add an option to Python 2 to get the new behaviour.
Moreover, Python 2 already has an option to switch to the new division mode:
$ python2 -Q new -c 'print(1/2)' 0.5
I'm proposing that a backward incompatible change must always be prepared in the previous release.
Victor
- Previous message (by thread): [Python-Dev] (Looking for) A Retrospective on the Move to Python 3
- Next message (by thread): [Python-Dev] (Looking for) A Retrospective on the Move to Python 3
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]