Identity inconsistency and unification of types and classes

[Moshe Zadka]

rimbalaya at yahoo.com (Rim) writes:
 
> With the great unification of types and classes, what will happen to the
> following identity inconsistency?
> 
> >>> class myint(int): pass
> ... 
> >>> a=int(1); b=int(1)
> >>> a is b
> 1
> >>> a=myint(1); b=myint(1)
> >>> a is b 
> 0

On Mon, 14 Jul 2003, Michael Hudson <mwh at python.net> wrote:

> Nothing, as is.  You can always dick about in myint.__new__ if you
> really want to manage that, but as others keep saying, you shouldn't
> worry about it too much.

Of course, the inconsistency has always been present:

>>> int(1) is int(1)
1
>>> int(5000) is int(2500*2)
0

Not so much with the consistency, huh?
Here's the deal: if a,b are immutable builtin objects, and a==b, it is
undefined if "a is b" is true. Do not rely on it. Assume patch releases
of Python will change it to be randomly true or false. Assume flags
to Python's compilation will randomly change it to true or false. Assume
the fluttering of the wings of a butterfly in Tibet will create a storm...
err, sorry, got carried away there.

Exercise: Determine for yourself where exactly I got carried away. Discuss.
-- 
Moshe Zadka -- http://moshez.org/
Buffy: I don't like you hanging out with someone that... short.
Riley: Yeah, a lot of young people nowadays are experimenting with shortness.
Agile Programming Language -- http://www.python.org/