Pre-PEP: __hashable__
Chad Netzer
cnetzer at mail.arc.nasa.gov
Tue Dec 10 22:54:39 EST 2002
More information about the Python-list mailing list
Tue Dec 10 22:54:39 EST 2002
- Previous message (by thread): Pre-PEP: __hashable__
- Next message (by thread): Pre-PEP: __hashable__
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tuesday 10 December 2002 18:39, Delaney, Timothy wrote: > > From: Chad Netzer [mailto:cnetzer at mail.arc.nasa.gov] [stuff deleted] I'm understanding things a little better (thanks to your next message which clarified how hashable() is really intended to operate.) > > Well, perhaps I have a tuple that has all > > the same objects as a list. Should that allow me to retrieve > > the list key? > > No. Hence the introduction of the immutablelist class. This will > compare equal to a list with the same elements, and also equal to > anything which would compare equal to such a list. Exactly the > same semantics as using a tuple as the key (or an int, or > whatever). I always wished for a immutable dict type (ie. must be created fully populated), but not called dict (after all ISN'T a dict if you can't update() it, for example.) Similarly, while I understand your use of immutablelist as a demonstration, I always liked that tuple has a distinct name from lists. Because tuples aren't lists (ie. you can't pop() them, etc.) So it just feels completly strange to have a somethinglist that does support the list interface... But I see your point; I'd still prefer to be explicit: ie. given, a = {} b = [1,2,3] I do prefer: a[ tuple(b) ] = "spam" to: a[ b ] = "spam" And so, in general, I think I'd be partial to: class MyObject: <whatever> class MyImmutableObject: def __init__( self, my_object ): <whatever> and used as: a[ MyImmutableObject( some_my_object ) ] = "eggs" rather than: a[ some_mutable_my_object ] = "eggs" But I'm sure many would disagree. [other good points you made deleted] > There is already precedent for this (in 2.3) - this is what sets > do. Sets are mutable - but when you want to use them as (for > example) a dictionary key, a snapshot is taken (an immutable > set). You can then continue modifying the original set - the key > stays the same. If at some stage the set and the snapshot match > up, you could retrieve your value from the dictionary. Well, it is interesting. It seems to me to (ultimately) be a way to simply the syntax for using items as dictionary keys (since you could do these things through other methods), and having that ability is often nice. > Believe me - I've thought seriously about the ramifications of > this. It's quite possible I've missed something. Well, after more thought, and your clarification about hashable(), I'm not really opposed to such a thing (in a practical sense, my objections even struck even me as a bit off the mark, mainly because we already do have decent semantics for determining when dictionaries and other mutable built in types compare equal.) Fair enough, I'll look forward to the PEP. :) If equivalent lists and tuples compared equal, and you could then just return a tuple in list's __hashable__(), I'd probably prefer it, though. -- Bay Area Python Interest Group - http://www.baypiggies.net/ Chad Netzer cnetzer at mail.arc.nasa.gov
- Previous message (by thread): Pre-PEP: __hashable__
- Next message (by thread): Pre-PEP: __hashable__
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list