On 12/19/06, Guido van Rossum <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
