Rustom Mody <rustompm...@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 -- https://mail.python.org/mailman/listinfo/python-list