[Python-3000] PEP 3106: Revamping dict.keys(), .values() and .items() (original) (raw)
Guido van Rossum guido at python.org
Sat Dec 23 06:49:08 CET 2006
- Previous message: [Python-3000] PEP 3106: Revamping dict.keys(), .values() and .items()
- Next message: [Python-3000] PEP 3106: Revamping dict.keys(), .values() and .items()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 12/19/06, Guido van Rossum <guido at python.org> wrote:
I've written a quick version of PEP 3106, which expresses my ideas about how the dict methods to access keys, values and items should be redone.
Thanks for all the comments. The new version is in svn: http://svn.python.org/view/peps/trunk/pep-3106.txt?view=markup
At some point it will appear on python.org: http://python.org/dev/peps/pep-3106/
Most issues brought up are either resolved or clarified in the new PEP, or explicitly added as open issues. I have strawman answers for most open issues except for the class names, which I'll leave up to whoever wants to implement this (except I don't like Neal's suggestion to name them dict.Keys etc.; that's a rather Javaesque use of a class as a namespace that feels unpythonic to me. OTOH the collections module seems a fine resting place.)
Some specific answers to issues brought up that you may not easily find back in the new PEP, and some new (perhaps off-topic) thoughts:
Adding list.discard() is a separate issue and doesn't have to wait for Py3k. I think it's a reasonable suggestion.
I am beginning to wonder if copy() methods should be discouraged in general in favor of explicitly naming the result type you want; e.g. to copy a set x you would write set(x) instead of x.copy(). This makes "generic" copying a bit harder, e.g. suppose you have an x that could be either a set or a frozenset and you want a copy that has the same type as x; but I'm not actually convinced that there are a lot of use cases for that outside the copy module. But this is also off-topic. I believe Alex Martelli may have some ideas on this, since I believe he dislikes using x[:] to copy a list and prefers list(x).
OTOH, d_items.copy() could easily be implemented as self.__d.copy().items(). (I forgot to add this to the PEP.) I wouldn't want to do something like this for copying keys or values, but for items it seems to be fast and space-efficient, since the dict copy doesn't use actual tuples for its items.
I expect that some refinements to this PEP will become apparent once we have a solid proposal for ABCs (which I fully intend to support).
Talin asked for values to be list-like rather than set-like, and proposes bags. Well, I thought bags and multisets are the same thing (unordered lists that may contain duplicates). I really don't want them to be list-like since that implies an ordering (albeit arbitrary) and an O(1) indexing (v[i]) operation. I believe the Java Collections Framework calls this a Collection -- it is a little bit more than an iterable since it has a length and a membership test, but it doesn't promise that these are efficient. That's pretty close to what d_values does in the new PEP, except I also added an implementation of equality (albeit an inefficient one due to the potential unhashability of values).
Again off-topic: Java's add() method returns true if the collection was changed; its remove() method acts like our discard() but again returns true if the collection was changed. Would it be worth to copy this API style?
If I left your specific suggestion or question unaddressed or unanswered, please send it again (after re-reading the PEP, of course).
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
- Previous message: [Python-3000] PEP 3106: Revamping dict.keys(), .values() and .items()
- Next message: [Python-3000] PEP 3106: Revamping dict.keys(), .values() and .items()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]