[Python-ideas] from __history__ import ...

Nick Coghlan ncoghlan at gmail.com
Sat Apr 19 17:07:56 CEST 2014


On 19 Apr 2014 08:18, "Anthony Towns" <aj at erisian.com.au> wrote:
>
> There's already a "from __future__ ..." mechanism to help with
> backwards incompatible changes (creating new keywords and syntax in
> particular). But that only helps people stay on old versions of
> python.
>
> So why not create the opposite: "from __history__ import ..." that
> allows you to use obsoleted ways of programming with new versions of
> python? If you want to use iter* on dicts in py3.5, require a "from
> __history__ import dict_iter" statement at the top of the file.

There are two reasons for that, one technical, one more people oriented.

The technical reason is that *data type* behaviours can't be isolated to a
single module - calling functions and returning values means they escape
easily to other code and need to behave as that code expects. This is a big
reason why most of the thorny migration problems revolve around text,
binary data and mappings - the *object* interfaces changed, so its hard to
do module-at-a-time updates.

The other reason goes back to the fact that part of the rationale for
deprecating and removing legacy behaviours is so *new* users never need to
learn them. The deprecation process is designed to strongly encourage
incremental modernisation over time, minimising the amount of legacy cruft
that hangs around indefinitely in Python code bases. Python 3 originally
broke with that tradition of incremental modernisation, but the rise of
code that runs in the common subset of Python 2 & 3 means that a fair bit
of work is now going into enabling that model for the Python 3 transition
as well.

So when we add back a Python 2 feature to Python 3, it needs to be
justified as either being an improvement in its own right (e.g. binary
interpolation) or as being sufficiently easy to explain to new users that
it doesn't significantly hurt the readability and maintainability of Python
3 code (e.g. explicit Unicode literals, my proposal to restore the mapping
iter methods).

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140419/5902529c/attachment.html>


More information about the Python-ideas mailing list