[Python-Dev] A proposal has surfaced oncomp.lang.pythontoredefine
"is"
Tim Peters
tim.one at comcast.net
Wed Mar 17 21:05:19 EST 2004
[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".
System code like cPickle relies on it to faithfully recreate isomorphic
object graphs, and to optimize pickle size by planting cheap indirections to
already-pickled subobjects. There aren't many memory analyzers for Python,
but such as exist rely on being able to determine when distinct bindings are
to the same object (if they are, it's vital not to "double count" the memory
consumed by the subobjects). Stuff like that, "substitutable" generally
doesn't make any sense for low-level analysis of what the implementation is
actually doing, and that kind of analysis is also an important application
for Python.
I think all those things *can* be done via manipulating id()s instead.
Indeed, I think they usually *are* done that way in most system code today,
but "is" was part of Python long before id() was added.
I don't know what alternative meaning has been suggested, but I don't have
to in order to know I won't like it -- the meaning of "is" now is dead
simple, and useful in system-level spelunking code.
Someday Guido has to figure out a way to convice Python programmers that
they really are allowed to write their own functions when they find a
describable behavior that isn't built in <wink>.
More information about the Python-Dev
mailing list