On 9 January 2014 02:22, Alejandro López Correa
Answering both Chris Angelico and you, I think I have not made my point clear. I am not really complaining about python 3. My opinion about the changes (at least those of which I am aware) is that they are sane. Unfortunately, many people are reluctant to change, and from what I've read that is actually a problem (not that I have actual data). I think large python 2 code bases won't change unless the benefits are larger than the costs.
This is mostly a communications problem on our part. I certainly thought "5 years for Python 3 to be the default choice for new projects" was fairly straightforward to interpret, but some overly optimistic folks with less experience of corporate adoption rates managed to misinterpret that as something more like "5 years until more people are writing Python 3 code than Python 2 code". If the latter was the goal, then we'd have a crisis, but it was never the goal - Python 2 has a massive installed base, and it's going to take a long time for new Python 3 projects and Python 2 to Python 3 migrations to overtake that.
In the costs we have to count the available developer time, for example, and in many cases that means [a lot of] money. The idea is to offer a solution to those programmers so they can trivially port their code base, write new code in python 3 and rewrite old python 2 code as soon as possible.
I am not suggesting offering back the whole python 2.7 by any means. Many changes can be safely performed by the 2to3 tool, probably. My suggestion is to offer a convenient way to bring everybody into python 3.
This is also largely an education problem. A couple of projects have legitimate gripes about binary protocol handling in Python 3, and since they have no pressing interest in migrating (and thus little motivation to build the missing pieces of infrastructure themselves), their response has been to tell the core team "we're not migrating until *you* provide a suitable replacement for this particular Python 2 feature". It's a reasonable request, but hasn't been at the top of the core teams priority list up to this point (that's now likely to change for Python 3.5).
My apologies, that was rather rude of me when you're offering to help No worries.
The main challenge is thus getting people to stop asking the question "How do we bring back the Python 2 text model" (which is never going to happen - we changed the model for a reason), and instead ask "What changes can be made to Python 3, such as introducing additional purpose specific types, to make it a better language for wire protocol development?". There's nothing actually *saying* "thou shalt only use builtin types for manipulation of wire protocol data", but that's the way all porting efforts have been carried out to date. Enabling old functionality when required is not the same as bringing back python 2, since python 3 is there by default and python 2 code won't work by default. It means just providing a good way to make old code work. The key part is the translation from 2 to 3. This does not mean that the code has to run unchanged but that the translation may be performed automatically, at least in 99.9% of cases. In practice this could involve a mixture of changes to python 3 itself to support the 2to3 tool, and improvements to the tool.
There's very little actually *missing* from Python 3 now, though, and it's far from clear that the key remaining missing piece (a type for manipulating ASCII compatible binary protocol data) can't be provided as a library on PyPI.
With a 2to3 tool that covers 99.99% of the cases, we could even have .py2 modules that would be translated transparently to .py when first used, in the same way compilation works, raising an exception in case something goes wrong.
I'm pretty sure someone already wrote one of those - they're a problem, because they mean the tracebacks for runtime exceptions don't match the source code (that's one of the major reasons single-source approaches came to dominate as the preferred migration mechanism for libraries and frameworks, leaving 2to3 as an option mainly considered by applications that can abandon Python 2 support when migrating to Python 3).
Anyway, I understand it is not a clean way to proceed, but something along these lines might be the only way to speed up the adoption of python 3, and minimise the risk of defection to other languages.
We're largely happy with the rate of adoption though - there were just some folks that didn't grasp the kinds of time scales we're talking about for a migration of this magnitude. See this for more details: http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_an... Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia