the Gravity of Python 2

[Devin Jeanpierre]

On Mon, Jan 6, 2014 at 4:19 PM, Chris Angelico <rosuav at gmail.com> 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?

Actually, this brings up something I'm unsure of. Is there any change
that can't, in theory, be put into __future__, so that if every module
in your project and its transitive dependencies imports everything
from __future__, it can run on Python 3 without changes, and where it
is realistically feasible to allow different modules to have different
things they import from __future__?

For example, I imagine that it is kind of _silly_ to have a
__future__.disable_str_autoencoding on a per-module basis, because
some modules' functions will fail when they are given the wrong type,
and some won't -- but in the context of making migration easier, that
silliness is probably OK. More fundamental is probably that it can't
actually be done easily or without serious performance penalties (e.g.
the relevant string method would have to look up the callstack to see
if its direct caller came from a module which enabled that future
feature).

I'm not sure there's anything that can't in principle be
sort-of-sanely encoded as a __future__ feature though.

-- Devin