the Gravity of Python 2
Martijn Faassen
faassen at startifact.com
Tue Jan 7 07:54:18 EST 2014
On 01/07/2014 01:19 AM, Chris Angelico wrote:
> Can we get a run-down of everything that actually must be broken in
> 2.7 -> 3.3, that can't be backported via __future__, so we can start
> cherry-picking which bits to break in 2.8? The biggest one is going to
> be Unicode strings, for a large number of people (the print statement
> and division operators can be __future__'d, lots of other stuff got
> backported into 2.7). I'd be prepared to bet money that that one will
> NOT be broken in 2.8, meaning that it achieves nothing on that score.
> So how much easier will the migration actually be?
That's a good question. I envision support for per-module upgrades,
though I'm not 100% sure that it would work. This way a large project
can incrementally start porting modules to the Python 3 unicode behavior.
The 'future' module (python-future.org) effectively backports the Python
3 str and bytes into Python 2.7. The question is then what happens when
they interact with Python 2 str and unicode.
I'm speculating about the behavior of the 'future' module here, but
here's what I could imagine.
First the Python 3 behavior:
py3str + py3str = py3str
py3bytes + py3bytes = py3bytes
py3str + py3bytes = error
Then the behavior of when Python 3 str/bytes are mixed with Python 2 str
and unicode:
py3str + py2unicode = py2unicode
py3str + py2str = py2unicode
py3bytes + py2str = py2str
Plus the regular old Python 2 behavior.
I'm quite sure I could be getting something wrong; it's only a few days
since I saw 'future' and started thinking along these lines.
Regards,
Martijn
More information about the Python-list
mailing list