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