I am posting again this. I am new to mailing lists and I've realised
I've sent it only to Nick Coghlan four hours ago.
----
2014/1/8 Nick Coghlan
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 [...] 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...
Ok, thanks. I see this has been a recurring topic and a lot of care has been given. I am looking at a different issue, though. I am thinking in existing projects, python 2 code in use, not even third party libraries but end products. I fear that if existing projects remain python 2 for too long because the benefit of expending resources on the migration are not worth the return, when the time finally comes for the upgrade another language might be chosen. At that point the divergence between that ancient py2 code and the latest py3 version would probably be greater than now, and other languages may offer features like GIL-less multithreading. If this happens in a large scale the whole python community may shrink and lose momentum. I do not know whether this is a real risk or not, and it is really up to you to assess it. I think a convenient way to run old python 2 modules along with new python 3 ones may be a good idea despite the cost. Even embedding a complete python 2.7 interpreter that executes .py2 modules and somehow shares the state with the main python 3 environment. I don't know whether that "monstrosity" is feasible without changing python 3 core too much, but it should help many people and nullify the risk of losing them. A large community is desirable in this context.
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
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
The idea is that exceptions that end up showing tracebacks should be, uhmm, exceptional (the tool should work 99.9% of the time and we are talking about working py2 code). When something happens, the problem of a different source in the traceback could be handled by the translation tool by adding annotations (even comments). Cheers, Alejandro
On Thu, Jan 9, 2014 at 10:14 AM, Alejandro López Correa
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
The idea is that exceptions that end up showing tracebacks should be, uhmm, exceptional (the tool should work 99.9% of the time and we are talking about working py2 code). When something happens, the problem of a different source in the traceback could be handled by the translation tool by adding annotations (even comments).
That's a sort-of-viable option (C preprocessors have used #line directives for decades), but not really ideal. For it to work with current Python, it would have to actually _be_ comments, so every line would have to have something appended: # "file.py" 213 How would that behave on arbitrary code? What if there's backslash continuation? Will people know to go looking elsewhere? Exceptions DO happen. And when they do, the language should try to make it easy to figure out what's going on. I'm not sure how well that would be served by this, especially given that it's not supposed to be a normal workflow. If you build a new language that uses Python as its back-end, then manipulating the source code WOULD be the normal workflow, and in that case I'd wholeheartedly support editing the recorded line numbers (I think you can do that with AST manipulation??) so tracebacks show the original file and line. But this shouldn't be that normal. ChrisA
On 08/01/2014 23:14, Alejandro López Correa wrote:
I think a convenient way to run old python 2 modules along with new python 3 ones may be a good idea despite the cost.
One of the major costs, quoting Winston Churchill, will be blood, toil, tears and sweat. How much of this are you personally intending to put into this effort, or are you happy to try and force core developers into a situation that many of them don't want to be in? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
2014/1/9 Mark Lawrence
On 08/01/2014 23:14, Alejandro López Correa wrote:
I think a convenient way to run old python 2 modules along with new python 3 ones may be a good idea despite the cost.
One of the major costs, quoting Winston Churchill, will be blood, toil, tears and sweat. How much of this are you personally intending to put into this effort, or are you happy to try and force core developers into a situation that many of them don't want to be in?
I am not trying to force anything. I am offering my views and some ideas. Personally, I am not experiencing any problem with python 3 other than some missing third party libraries. I am sorry if my posts seem rude (I do not know whether that is the case). When writing in English, many times it is more like adjusting what I want to say to what I know how to say. That "despite the cost" was a poor choice of words. I agree that it is not reasonable to expect a change that means "blood, toil, tears and sweat" for the core developers when they are against it. However, there might be easy solutions not pretty but pragmatic and that might be implemented without polluting the main code base a lot. But again, I am not trying to force anything but convince people. I am starting to realise this debate has been going on for too long and it seems to have left some scars. I am sorry, it is brand new to me. Alejandro
participants (3)
-
Alejandro López Correa -
Chris Angelico -
Mark Lawrence