From the Python Reference Manual [emphasis added]:
Types affect almost all aspects of object behavior. Even the importance of object IDENTITY is affected in some sense: for immutable types, operations that compute new values may actually return a reference to any existing object with the same type and value, while for mutable objects this is not allowed. This seems to be saying that two immutable objects are (in some sense) the same iff they have the same type and value, while two mutable objects are the same iff they have the same id(). I heartily agree, and I think that this notion of sameness is the single most useful variant of the "equals" relation. Indeed, I think it worthwhile to consider modifying the "is" operator to compute this notion of sameness. (This would break only exceedingly strange user code.) "is" would then be the natural comparator of dictionary keys, which could then be any object. The usefulness of this idea is limited by the absence of user-definable immutable instances. It might be nice to be able to declare a class -- eg, Point -- to be have immutable instances. This declaration would promise that: 1. When the expression Point(3.0,4.0) is evaluated, its reference count will be zero. 2. After Point(3.0,4.0) is evaluated, its attributes will not be changed. I sent the above thoughts to Guido, who graciously and politely responded that they struck him as somewhere between bad and poorly presented. (Which surprised me. I would have guessed that the ideas were already in his head.) Nevertheless, he mentioned passing them along to you, so I have. Regards, Greg
Greg Weeks wrote:
From the Python Reference Manual [emphasis added]:
Types affect almost all aspects of object behavior. Even the importance of object IDENTITY is affected in some sense: for immutable types, operations that compute new values may actually return a reference to any existing object with the same type and value, while for mutable objects this is not allowed.
This seems to be saying that two immutable objects are (in some sense) the same iff they have the same type and value, while two mutable objects are the same iff they have the same id(). I heartily agree, and I think that this notion of sameness is the single most useful variant of the "equals" relation.
Notice the "may" in the reference text.
88 + 11 is 98 + 1 1 100 + 3 is 101 + 2 0
Python goes to the effort of keeping singleton instances of the integers less than 100. In certain situations, a similar effort is invested in strings. But it is by no means the general case, and (unless you've got a solution) it would be expensive to make it so.
Indeed, I think it worthwhile to consider modifying the "is" operator to compute this notion of sameness. (This would break only exceedingly strange user code.) "is" would then be the natural comparator of dictionary keys, which could then be any object.
The implications don't follow. The restriction that dictionary keys be immutable is not because of the comparison method. It's the principle of "least surprise". Use a mutable object as a dict key. Now mutate the object. Now the key / value pair in the dictionary is inaccessible. That is, there is some pair (k,v) in dict.items() where dict[k] does not yield v.
The usefulness of this idea is limited by the absence of user-definable immutable instances. It might be nice to be able to declare a class -- eg, Point -- to be have immutable instances. This declaration would promise that:
1. When the expression Point(3.0,4.0) is evaluated, its reference count will be zero.
That's a big change from the way Python works:
sys.getrefcount(None) 167
2. After Point(3.0,4.0) is evaluated, its attributes will not be changed.
You can make an instance effectively immutable (by messing with __setattr__). You can override __hash__ to return something suitable (eg, hash(id(self))), and then use an instance as a dict key. You don't even need to do the first to do the latter. - Gordon
participants (2)
-
Gordon McMillan -
weeks＠golden.dtc.hp.com