Reference

[Ben Finney]

Rustom Mody <rustompmody at gmail.com> writes:

> * ... which summarizes my objection in this thread:

Your long post references many things. Which is the “which” to which you
refer? What is it you're referring to that summarises your position?

> Python's 'is' leaks the machine abstraction.

No, it does not. The ‘is’ operator compares object identity, which is
itself an abstraction. What is leaking?

Note that the “location of the object in memory” is not a guarantee made
by either Python's object identity nor the ‘id’ function. There's no
need to treat “object location in memory” as equal to “object identity”,
and code which makes that assumption is buggy. The documentation doesn't
promise they will be the same.

So, the fact that some Python implementations happen to present
‘id(foo)’ values that coincide with a representation of memory location,
does not constitute a leaky abstraction: there is no need for any Python
programmer to care about what the memory location is. So if that's the
basis of your objection, I don't consider that objection to be
legitimate.

> 'id' does it legitimately (somewhat), 'is' does it illegitimately

What would, in your view, be a legitimate way for Python to present
object identity to the programmer? How would it differ substantially
from Python's existing abstraction of object identity?

-- 
 \          “That's all very good in practice, but how does it work in |
  `\                                             *theory*?” —anonymous |
_o__)                                                                  |
Ben Finney