[Python-Dev] indiscernible objects (was: A proposal has surfaced oncomp.lang.pythontoredefine "is")

[Casey Duncan]

On Wed, 17 Mar 2004 21:05:19 -0500
"Tim Peters" <tim.one at comcast.net> wrote:

> [Andrew Koenig]
> > ...
> > Indeed, it would be a change.  And I can go along with an argument
> > that an incompatible change of that magnitude should be rejected for
> > that reason alone.  But why would the change cause a problem?
> > Consider:
> >
> > 	a = []
> > 	b = []
> > 	x = (a, b)
> > 	y = (a, b)
> >
> > Can you think of a program that can make productive use of the value
> > of "x is y"?  It seems to me that x and y are mutually
> > substitutable.
> 
> It's the purpose of "is" to give Python code a handle on the actual
> object graph an implementation creates.  This is important in "system
> code" that needs to manipulate, analyze, or clone parts of the system
> object graph *for its own sake*.  For example, if your x and y above
> are both also bound to attributes of a class instance, the actual
> object graph is plain different depending on whether instance.x is
> instance.y.  Application-level code is free to rely on that
> distinction or not, as it likes; if it does rely on it, it's also free
> to arrange to make any conclusion it likes a consequence of"is" or "is
> not".

One interesting case I ran into where I had some indecision about
whether to use 'is' or '==' was implementing a generator function which
could accept an arbitrary sentinel object which when encountered would
yield an intermediate result (it was an implementation to find all paths
in a graph that lead to a specific end node).

Since the "target" could be an arbitrary object, it seemed logical to
use 'is', to identify the terminal node, except that in many cases the
node objects would be integers (or strings). So, I decided to use '=='
instead. This gave me a slightly uneasy feeling though because the
semantic meaning of '==' is only advisory. In fact any aplication object
can claim to be equal to any other object. IOW the system code needs to
trust the application code.

What I really wanted was a system-level assertion that "objectA is
indiscernible from objectB" (the same idea as mutually subsititutable I
think). In any case I wanted something more discerning than equals but
not as particular as 'is'.

Specifically, objects are indiscernible if they are the same type and
have the same state. Unlike 'is', they *do not* need to be the same
physical object. In the case of sequences they would need to be the same
type and have indiscernible members.

Another obvious invariant is that all objects are indiscernible from
themselves. Which means that if 'a is b' is true then a is also
indiscernible from b.

Yes, I could write my own function to implement this. But I doubt I
would get it right. A naive and general function to implement this might
serialize the objects to a string and compare the strings. If objects
serialize to the same representation they are indiscernible. Obviously
there are shortcuts one can take to optimize this for simple types
(simply compare type and binary value in memory directly for instance).
The first thing this function would probably do is an identity check
anyway since that is cheap and identical objects are always
indiscernible.

I could certainly envision an operator for this being useful, but even
just a function in the std lib would suffice (or a new builtin
function). I know I would find it very useful if it existed.

-Casey