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

[Nick Coghlan]

On 19 Apr 2014 10:53, "Guido van Rossum" <guido at python.org> wrote:
>
> Does everyone involved know that "for x in d.iterkeys()" is equivalent to
"for x in d" and works the same in Python 2 and 3? Similarly, "list(d)" is
a simple, fast way to spell the Python 2 semantics of "d.keys()"  that
works in both versions (but I doubt it is much needed -- usually the actual
code follows up with sorting, so you should use sorted(d)).
>
> This doesn't solve itervalues() and iteritems() but I expect those are
less common, and "for x, y in d.iteritems(): <blah>" is rewritten nicely as
>
>   for x in d:
>     y = d[x]
>     <blah>
>
> If there is a measurable slowdown in the latter I would be totally okay
with some kind of one-element cache for the most recent lookup.
>
> I get the social aspect of the PEP, but I think it's too high a price to
pay.

OK, I think the main thing I need to add to the PEP next is a clear
description of the current state of the art in translating these methods to
the common 2/3 subset across the following modes of interaction with the
existing Python 2 API:

* for loops
* comprehensions and generator expressions
* iterator object
* bound methods
* unbound methods

That may help clarify the tricky warts and edge cases that can arise when
moving from the current relatively straightforward and consistent method
based approach to a more complicated combination of dedicated syntax and
helper functions.

I also asked JP Calderone to trawl the Twisted code base for specific cases
where the status quo causes migration problems. Since my main argument is
that we should do this to save collective modification and review effort
for affected projects (i.e. I think it's a "death by 1000 cuts" situation
rather than a single gaping wound anyone can point to), it would be good if
those affected could help with quantifying the scale of the problem so we
can make a more informed trade-off between that work and future users of
Python 3 needing to learn about the existence of the proposed largely
redundant compatibility methods.

In several ways, I see my proposal as similar to what we did when PEP
8'ifying the threading.Thread API - the old camel case functions are still
there, but clearly marked as only existing for legacy compatibility reasons
(they may actually be completely undocumented in Py3 - I don't recall off
the top of my head). While I'm personally a big fan of cleaning up APIs and
strongly encouraging code modernisation, I've also become convinced that it
will be worth our while to start soliciting more quantitative feedback in
relation to various decisions to help make sure we're OK with the full
consequences of those design decisions.

Regards,
Nick.

>
> --
> --Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140419/d0344cb1/attachment.html>