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

[Nick Coghlan]

On 9 January 2014 02:22, Alejandro López Correa <alc at spika.net> wrote:
> 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_answers.html#but-uptake-is-so-slow-doesn-t-this-mean-python-3-is-failing-as-a-platform

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia