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

[David Pokorny]

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.

David