Antoon Pardon wrote:
Op 2004-12-16, Jeff Shannon schreef <[EMAIL PROTECTED]>:
nevermind the fact that I can't think of a case where I'm likely to "retrieve" a key from a dict, modify it, and then put it back. (I can think of endless cases where I'd want to do that with *values*, but not with keys...)
Well neither can I, but yet the fact that lists are mutable and tuples
are not, is frequently presented as reason why tuples are allowed as
keys and tuples are not.
True -- in much the same way that the inability to see is why sighted people are allowed to get driver's licenses and blind people are not. The fact of mutability makes an object very poorly suited for use as a dict key, and therefore allowing them to be used as dict keys would be a dangerous thing. I'm sure that, with careful guidance and supervision, a blind person could manage to operate a motor vehicle, but no matter how high my regard for that blind person was I'd be a bit hesitant to give them my car keys for a quick trip to the corner store...
(And if dicts were somehow changed so that keys were copied when added to a dict, just so that every once in a while someone might be able to avoid a few conversions to/from tuple, then you're adding the overhead of an object copy to *every* dict insertion, thus slowing down (possibly by a significant amount) a large proportion of Python operations. How is that a gain?)
Well will look at two scenario's. In each we will work with mutable objects that we would like to use a keys. In the first we transform them into an immutable object, in the second we just allow mutables to be inserted as keys, but insert a copy of the key instead of the key itself in order to protect the programmer somewhat from mutating dictionary keys.
Now in scenario one we will have a lot more copies then in scenario two, because each time we want to use an object as a key we will first have to transform it into an immutable. That means every addition to the dictionary as well as every key access and each such transform means a copy.
In scenario two we will only make a copy when a key is added to the dictionary, we don't need to make copies with key accesses.
I think scenario two is a performance gain over scenario one.
Except that Python uses dicts internally, quite heavily. Much of the speed gains of recent versions of Python have reportedly come specifically due to extensive and impressive optimization of dictionaries. Forcing an (extra) object copy every time a variable name is bound (or rebound) would be hell on Python's performance across the board, not just in those rare cases where someone thinks that they'd benefit from using a mutable object as a key.
(And I have to reiterate, here, that I have *never* felt it a hardship to be unable to use lists as dictionary keys; it's just never come up that the data that I had in a list was something that I wanted to use as-is for a dict key, and I can't think of a situation where it *would* happen. What you're saying, essentially, is that for the sake of one form of aesthetic purity with no significant practical benefits, we should break another form of aesthetic purity with massive practical benefits.)
Jeff Shannon Technician/Programmer Credit International
-- http://mail.python.org/mailman/listinfo/python-list
