Hi all, On Fri, Jul 8, 2011 at 12:04 PM, Cesare Di Mauro <cesare.di.ma...@gmail.com> wrote: > So, there must be care about using is. It's safe for some trivial objects > (None, False, True, Ellipsis) and, I think, with user-defined classes' > instances, but not for everything.
The problem is more acute with id(). Some standard library modules like copy.py *need* a working id() for any object, including immutable ones, because CPython has no identity dict. After some discussion with Carl Friedrich, here is the best we could think of. Say that "a is b" is redefined as being True for two equal immutable objects of the same type. Then we want the following property to always hold: "a is b" if and only if "id(a) == id(b)". We can do that by having id(x) return either a regular integer or a long. Let's call for the rest of this discussion an "immutable object" an object of type int, long or float. If 'x' is not an immutable object, then id(x) can return the same value as it does now. If 'x' is an immutable object, then we compute from it a long value that does *not* fit in 32- or 64-bit, and that includes some tagging to make sure that immutable objects of different types have different id's. For example, id(7) would be (2**32 + 7<<3 + 1). Such a solution should make two common use cases of id() work: 1. as keys in a dictionary, to implement an identity dict, like in copy.py: in this case we take the id() of random objects including immutable ones, but only expect the result to work as keys in the dictionary. Getting arbitrarily-sized longs is not a problem here. 2. more contrived examples involve taking the id() of some instance, sending it around as a (word-sized) integer, and when getting it back retrieving the original instance from some dict. I don't expect people to do that with immutable objects, only their own custom instances. That's why it should be enough if id(x) returns a regular, 32- or 64-bit integer for *non-immutable* objects. A bientôt, Armin. _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
