[Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

[Nick Coghlan]

On 19 Apr 2014 00:27, "Steven D'Aprano" <steve at pearwood.info> wrote:
>
> On Fri, Apr 18, 2014 at 10:31:29PM -0400, Nick Coghlan 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.
>
> It would also considerable add to the cruft of Python 3. One motive for
> going through the pain of Python 2 to 3 migration was to remove cruft.
> Adding it back in again is not just an aid to porting but actively
> making Python 3 a worse (well, "less better") experience.

The cruft is unavoidable in this case. The decision we face is *where the
cruft lives*, and *how much work is involved* in creating that cruft.

Status quo: we preserve the "purity" of the Python 3 mapping API, and
require every developer making the transition from Python 2 to Python 3
replace every occurrence of these methods with a helper function that is
not idiomatic code in either language.

My proposal: we add three trivial helper methods to the Python 3 mapping
API. For the cost of 3 additional methods that are easily explained in
terms of combining a builtin with other existing methods, a whole pile of
work just evaporates for affected segments of the community.

>
> So while I'm sympathetic to wanting to ease the 2/3 transition, even at
> the expense of re-introducing some cruft when unavoidable, I don't think
> that the difficulty of dealing with dict items|iteritems|viewitems etc.
> justifies re-adding cruft.

The cruft will be there regardless, the only question is whether it exists
in the definition of Python 3 or is distributed across all of the single
source projects supporting both 2 & 3.

> [...]
> > Rationale
> > =========
> >
> > Similar in spirit to PEP 414 (which restored explicit Unicode literal
> > support in Python 3.3), this PEP is aimed primarily at helping users
> > that currently feel punished for making use of a feature that needed to
be
> > requested explicitly in Python 2, but was effectively made the default
> > behaviour in Python 3.
>
> "Feel punished"? That's awfully strong language. It may even be true, in
> the sense that some people *feel* that they are being punished, but I
> think the barrier to doing something about that needs to be a bit
> higher, namely that they *actually are* being punished.

Yes, they are *actually* being punished for using the memory efficient APIs
that were being added in Python 2.2. That's why the PEP covers how the
transition to Python 3 is harder for them than if they just hadn't cared
about memory efficiency in the first place.

They're Pythonistas too - they care about readability, and they *don't
like* having to add crufty helper functions to all their mapping
manipulation code. They also legitimately don't want to put up with all the
code churn that results from doing so, requiring additional reviews and
retesting of currently working code.

I spend a fair bit of time talking to users that have put a lot of work
into supporting a language transition that doesn't really help them
personally. A non-trivial number of them are deeply, viscerally angry about
what they see as pointlessly changing the spelling of a core language
feature for no real technical gain.

So let me be clear: this is *not* a proposal driven primarily by technical
considerations. Rather, it is a social one, where we do something simple
and easy and low cost for us to send a clear message to a set of users that
feel justifiably angry about the amount of work we imposed on other members
of the community by putting Python 2 into maintenance mode that we do value
their time and energy, and are willing to show some flexibility in adding
"not harmful" changes to Python 3 that don't significantly increase the
complexity of the language, while making it easier to write single source
code that looks like idiomatic Python code.

> I think that if "write a helper function" is punishment, then nearly
> every programmer is being punished *all the time*.

No, the punishment is "replace every usage of the memory efficient iterator
based APIs that have existed since Python 2.2 with a helper function
because we think that is a reasonable burden to place on you just so we can
avoid adding three trivial helper methods in Python 3".

Regards,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140419/d1a21805/attachment.html>