Discussion about PEP 234: iterators

Jeff Petkau jpet at eskimo.com
Mon Feb 19 04:32:41 CET 2001

Aahz Maruch <aahz at panix.com> wrote in message
news:96ori0$mq$1 at panix3.panix.com...
> In article <96nst0$pe9 at gap.cco.caltech.edu>,
> Nathaniel Gray  <n8gray at caltech.edu.is.my.email.address> wrote:
> >
> >How about we make it:
> >if key in dict.keys():
> >if value in dict.values():
> >if (key, value) in dict.items():
> The problem with this is absolutely horrendous speed/memory performance
> with any large dictionary.  Your code generates a list AND THEN DOES A
> LINEAR SEARCH.  No, no, no, no, no, no, no.  We've already got

Instead of inventing new syntax for inefficent idioms, we
could just make the idioms more efficent, by having values(),
keys(), and items() return proxy objects with __contains__()
and sequential __getitem__() functions.

Alas, this isn't backwards compatible with old code that
expects a real list object.  Possible solutions, in descending
order of sanity:

- make new functions called xkeys(), xvalues(), etc. to
  return the proxies.  Pretty ugly, but consistent with
  xrange() and xreadlines().

- just live with it.

- make 'dict.keys' return the proxy object, which is
  callable.  Make proxy.__call__() return an actual
  list from the proxy so dict.keys() works as before.
  So cute I'm ashamed I even thought of it.

--Jeff Petkau (jpet at eskimo.com),
  currently specializing in poorly thought out solutions.

More information about the Python-list mailing list