On Tue, Jan 7, 2014 at 6:26 AM, Mark Lawrence <breamore...@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 -- https://mail.python.org/mailman/listinfo/python-list
