[Python-Dev] redefining is

[Neil Schemenauer]

On Fri, Mar 19, 2004 at 12:19:11PM -0500, Andrew Koenig wrote:
> Analogously, I think that the way Python defines "is" is hazardous.  I do
> not think it is nearly as big a hazard as C++'s treatment of virtual
> destructors, but I still think it's a hazard.  The reason is similar:  Using
> it makes it easy to write programs that appear to work by coincidence.

Making 'is' do something other than comparing object identity is not
going to help, IMHO.  If you don't understand Python's object model
then you are going to get into trouble anyhow.

> The "raise 'quit'" example is a good one, because it will always
> work on an implementation that interns string literals, so no
> amount of testing will reveal the problem.

Not a good example.  String exceptions are deprecated.

> By "object equivalence", I mean mutual substitutability--which is the same
> as identity for mutable objects, but not for immutable ones.

So what does it mean for immutable objects?

> The hazard comes about because there are objects that are equivalent but not
> identical, and there are contexts (such as the raise/except example above)
> in which it is logical to ask for object equivalence, but what you actually
> get is object identity.

Your raise/except example is bad.  Do you have another one in which
people could not just use '==' instead of 'is'?

  Neil