Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info>:
> There is no metaphysical implication from Python's "is" operator. If the
> operator had precisely the same behaviour, but was called "same", as in:
>
> a same b
> => returns True if a and b are the same object
> => returns False if a and b are not the same object
>
> would you claim there was a metaphysical implication?
I would. You are not defining anything because you are not explaining
what "same object" means.
Set theory obeys the so-called extensionality principle: if two objects
are indistinguishable in every way, they are one and the same object.
Fermions in particle physics are the same way: if two fermions' quantum
states coincide, they are one and the same particle.
Now, that's not true for Pythons "bosonic" objects. You can have two
objects that are identical except they are not the same.
There are (at least) two ways to break the circularity between "is" and
"same-objectness:"
1. Give a real or hypothetical reference implementation and state that
any other implementation that produces same (or similar enough)
outcomes is valid. ("Each object is allocated with the malloc(3)
function call. The identity of an object is the value returned by
malloc(3).")
2. Give formal axioms that characterize any valid implementation.
("After x = y, x is y" plus a couple of dozen more formal
stipulations.)
As for teaching the concept in practice, both of the above approaches
are probably bad. Take abstract algebra. You don't start teaching a
first-grader about groups and rings and work your way down to
arithmetics. Rather, you start with counting, move on to arithmetics,
bring in vectors and maybe Rubik's Cube and finally try to get the
students to understand the general, abstract idea behind it all.
Analogously, it may be necessary to teach the "children" first the
theory of linear memory, then variables and arrays, then pointers and
singly-linked lists. Once these concrete ideas have been understood, the
principles behind Python and other higher-level programming languages
can be learned.
> How about if it were called "eq", like Lisp uses?
You are correct. Lisp suffers from the same problem. The underlying
reference machine is simpler to present, though, as there are no classes
or methods. There are only memory cells and a handful of data types
(number, cons, symbol, string or nil). You really get a feel of a
physical steam engine.
Ten years ago a whole generation of programmers was raised who knew
nothing of computing except Java. I wonder how difficult it was for them
to get objects, references and identity.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
