> So unless I am misinterpreting this, it sounds like the burden of > proof now falls on the option to keep the status quo. The thing is > that it seems to me that if that an outside observer were to look at > this situation, then they might ask why the names are being changed > when the current behavior is functional and no one is clamoring for > the change.
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?). Applications that take a snapshot of the .keys() are rare (right?). Even more uncommon are applications that take a snapshot of .keys(), and then continue changing the dictionary. And yet more uncommon are cases where you save a snapshot of .keys(), change the dictionary, and then break (i.e. fail to function correctly) if the snapshot gets "silently" updated. > If you disagree, then I still don't understand the motivation on the > PEP, and the current motivation, "being able to do set operations on > keys and items without having to copy them" does not appear to pertain > to the issue of which names should correspond to which behavior. The most direct name should be used in the most common scenario, which is the for loop. I.e. people who don't think about this issue at all should likely do the right thing. For 2.x, this is not the case. Regards, Martin _______________________________________________ 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
