from __history__ import ...
Antoine Pitrou wrote (on python-dev):
On Fri, 18 Apr 2014 22:31:29 -0400 Nick Coghlan <ncoghlan at gmail.com> wrote:
After spending some time talking to the folks at the PyCon Twisted sprints, they persuaded me that adding back the iterkeys/values/items methods for mapping objects would be a nice way to eliminate a key porting hassle for them (and likely others), without significantly increasing the complexity of Python 3. I'm -1 on this. This is destroying the simplification effort of the dict API in Python 3.
I'm one of the masses who basically ignores py3 in favour of py2.7 (or
2.6 or even 2.4...) because the code I write has to run on old python.
And even if I /want/ to be compatible with py3, the only way I can do
that is by doing things that perform poorly in the version of python
I'll actually be using in production, or by having ugly special cases
and boiler plate all over the place. Things like this really are a
barrier to adoption for py3...
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.
For py2.7, there is no __history__ module, but it's easy to add one to
your project that just says "dict_iter = True" to let the import
statement succeed. In general (looking forward to py4?) you could (at
least in theory) have "from __history__ import FOO" be a noop if FOO
is unknown, add support for whatever historical practice if it's known
and a barrier to adoption, and have it be a syntax error when it's
finally no longer supported at all. That way you only need to actually
define a symbol via the __history__ module when you're actually
removing an obsolete idiom from the language.
Cheers,
aj
--
Anthony Towns
On 19 Apr 2014 08:18, "Anthony Towns"
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.
participants (2)
-
Anthony Towns
-
Nick Coghlan