<div dir="ltr"><div><div>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. 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.<br><br>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.<br><br>> My apologies, that was rather rude of me when you're offering to help<br></div><div>No worries.<br><br>
> The main challenge is thus getting people to stop asking the question<br>> "How do we bring back the Python 2 text model" (which is never going<br>> 
to happen - we changed the model for a reason), and instead ask "What<br>> 
changes can be made to Python 3, such as introducing additional<br>> 
purpose specific types, to make it a better language for wire protocol<br>> 
development?". There's nothing actually *saying* "thou shalt only use<br>> 
builtin types for manipulation of wire protocol data", but that's the<br>> 
way all porting efforts have been carried out to date.<br></div><div>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.<br>
<br>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.<br><br>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.<br></div><br></div>Cheers,<br>Alejandro<br></div>