[Python-Dev] redefining is

[Samuele Pedroni]

At 17:09 19.03.2004 -0500, Andrew Koenig wrote:
> > >It certainly doesn't *require* a builtin operator.  I do think, however,
> > >that the proposed comparison is more useful than "is" in most contexts in
> > >which programmers use "is" today.  In particular, programs that use "is"
> > >caneasily contain bugs that testing on a particular implementation can
> > >never reveal, and using the proposed comparison instead makes such bugs
> > much less likely (and perhaps even impossible).
>
>
> > maybe, OTOH I suspect that people most puzzled by
>
> >  >>> a = 1
> >  >>> b = 1
> >  >>> a is b
> > True
> >  >>> a = 99
> >  >>> b = 99
> >  >>> a is b
> > True
> >  >>> a = 101
> >  >>> b = 101
> >  >>> a is b
> > False
> >
> > really simply expect there to be just one 1 and 99 and 101, not an
> > half-a-page definition of 'is' or some such involving the notion of
> > (im)mutability.
>
>I think we are agreeing with each other.

nope, my point is that the friendly "fit everybody brain" solution would be 
to keep
the definition of 'is' as is, but force some classes of value objects to 
force singletons for each value, but this cannot be made to work. So we 
cannot win.

So we remain with the gain of killing potential bugs related to naive usage 
of 'is', but I don't think that's worth the spec complexity.


>Because if "is" were redefined in
>the way that was proposed, we would have the following behavior on every
>implementation:
>
>         >>> a = 1
>         >>> b = 1
>         >>> a is b
>         True
>         >>> a = 99
>         >>> b = 99
>         >>> a is b
>         True
>         >>> a = 101
>         >>> b = 101
>         >>> a is b
>         True

yes, but through a far more complex model, and still I don't know then 
whether they expect there to be just e.g. one (1,1) or many.