the Gravity of Python 2

[Chris Angelico]

On Tue, Jan 7, 2014 at 6:26 AM, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
> http://blog.startifact.com/posts/python-2-gravity.html
>
> "A Way Forward - How to go forward then? I think it makes sense to work as
> hard as possible to lift those Python 2 codebases out of the gravity well."
>
> I think this is complete nonsense.  There's only been five years since the
> first release of Python 3.  Surely much more time should be made available
> for people using Python 2 to plan for a migration?

"""And to make it even more obvious, we need Python 2.x releases where
the deprecated stuff is removed, incrementally. Breaking code is
making it as obvious as you can get! But you don't want to break it
all at once, because then people will be inclined to give up before
they even start."""

Suppose there's a Python 2.8 that breaks just some of the things that
might break in 2.7->3.3 migration. What does it achieve?

1) Everything that has to be fixed before moving onto 3.3+ will still
need to be fixed.
2) Instead of ONE code-breaking shift with a major version number to
highlight it, there are now TWO code-breaking shifts.

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?

ChrisA