[Python-3000] Spooky behavior of dict.items() and friends

[Guido van Rossum]

On Tue, Apr 1, 2008 at 11:00 PM, David Pokorny <dbpokorny at gmail.com> wrote:
> On Tue, Apr 1, 2008 at 7:37 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>  >  I think it's fairly obvious why the 2.x .keys() has to change. It's
>  >  just too wasteful to actually build the list of all keys of a dictionary
>  >  (or even of all values, as you have to create all the tuples as well),
>  >  if all you want to do is to iterate over it, and the most common
>  >  operation of .keys() is to iterate over it in a for look (right?).
>
>  I agree that the most common operation/scenario is the one you
>  describe, but I don't understand why the behavior of the most common
>  name should be the most efficient implementation of the most common
>  scenario. One could propose an alternate policy: the behavior of the
>  most common name should correspond to the most common (human)
>  interpretation of the name. According to this policy, I think there
>  are valid arguments to be made for .keys() to return either a list or
>  set (set if you had never used python 2 before, list if you had), but
>  I don't think a dict_keys object that is tied to the underlying dict
>  is a common interpretation of the meaning of .keys() (outside this
>  list). This is a good policy because it minimizes the mental
>  housekeeping required to understand a given piece of code; this is a
>  real benefit for the programmer. (And especially for the programmer
>  just coming to Python). With all due respect, the policy you
>  describe---a more efficient implementation in the common
>  case---optimizes the code of people who don't think about this issue
>  at all. In other words it facilitates premature optimization.

The problem is that if you make the slow and fool-proof implementation
the common name, you'll have to invent another name for the fast (but
sometimes less convenient) method. This is what we ended up doing in
Python 2.2 with iterkeys() and friends. Unfortunately, despite your
assertion, most people think their code should run as fast as
possible, and hence we see a great proliferation of iterkeys() calls.
So the fast-but-requiring-care implementation becomes more popular
than the slow-but-simple version, and now we have a duplication of
APIs.

I'd much rather have a single API that can be made to serve everyone
equally. I predict that list(x.keys()) will remain a rarity (except in
code converted by 2to3). However sorted(x.keys()) will become a
well-known idiom, and it's a much better one than the old idiom

  keys = x.keys()
  keys.sort()

which doesn't led itself easily to use in an expression.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)