[Python-ideas] from __past__ import division, str, etc

[Alejandro López Correa]

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 <ncoghlan at gmail.com>

> 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_answers.html#but-uptake-is-so-slow-doesn-t-this-mean-python-3-is-failing-as-a-platform

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