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
--
https://mail.python.org/mailman/listinfo/python-list
