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

Thinking about this more, I expect that an issue might be classes that
emulate dicts without being too formal about it (e.g. no ABCs) and then
porting code that works for both such class instances and dicts. Many
examples of such classes I've seen have a keys() method that returns a
list, and for various reasons these classes won't be rewritten to be more
like Python 3 as part of the port.

And then again, adding iterkeys() back to dict doesn't solve *that*
problem, and presumably such a class still has an __iter__() method, and
presumably the alternatives I proposed would still work.

I am also concerned about the dependency on Python 3.5 that we're building
here. I'd much rather be able to use Twisted sooner, with 3.3 or at least
3.4.


On Sat, Apr 19, 2014 at 9:17 AM, Nick Coghlan <ncog...@gmail.com> wrote:

>> On 19 Apr 2014 10:53, "Guido van Rossum" <gui...@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)>



-- 
--Guido van Rossum (python.org/~guido)