[Python-ideas] Providing a guarantee that instances of user-defined classes have distinct identities

Max Moroz maxmoroz at gmail.com
Wed Apr 18 03:23:10 CEST 2012


Suppose I model a game of cards, where suits don't matter. I might find the
integer representation of cards (14 for "Ace", 13 for "King", ..., 2 for
"2") to be convenient.

The deck has 4 copies of each card, which I need to distinguish.

I was thinking to model a card as follows:

class Card(int):
__hash__ = int.__hash__
def __eq__(self, other):
return self is other

This works precisely as I want (at least in CPython 3.2):

x = Card(14)
y = Card(14)
assert x != y # x and y are two different Aces
z = x
assert x == z # x and z are bound to the same Ace

But this behavior is implementation dependent, so the above code may one
day break (very painfully for whoever happens to maintain it at the time).

Is it possible to add a guarantee to the language that would make the above
code safe to use? Currently the language promises:

"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."

Nowhere in the documentation is it clearly defined which objects are
considered "immutable" for the purpose of this promise. As a result, a
Python implementation, now or in the future, may decide that it's ok to
return a reference to an existing object when a Card instance is created -
since arguably, class Card is immutable (since it derives from an immutable
base class, and doesn't add any new attributes).

Perhaps a change like this would be fine (it obviously won't break any
existing code):

"For certain types, operations that compute new values may actually return
a reference to an existing object with the same type and value. The only
types for which this may happen are:

- built-in immutable types
- user-defined classes that explicitly override __new__ to return a
reference to an existing object

Note that a user-defined class that inherits from a built-in immutable
types, without overriding __new__, will not exhibit this behavior."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20120417/50d540ff/attachment.html>


More information about the Python-ideas mailing list