<p dir="ltr"><br>
On 19 Apr 2014 10:53, "Guido van Rossum" <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
><br>
> 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)).<br>

><br>
> 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<br>
><br>
>   for x in d:<br>
>     y = d[x]<br>
>     <blah><br>
><br>
> 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.<br>
><br>
> I get the social aspect of the PEP, but I think it's too high a price to pay.</p>
<p dir="ltr">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:</p>

<p dir="ltr">* for loops<br>
* comprehensions and generator expressions<br>
* iterator object<br>
* bound methods<br>
* unbound methods</p>
<p dir="ltr">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.</p>

<p dir="ltr">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.</p>

<p dir="ltr">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.</p>

<p dir="ltr">Regards,<br>
Nick.</p>
<p dir="ltr">><br>
> -- <br>
> --Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)</p>