On Tue, Apr 1, 2008 at 7:37 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
