Marko Rauhamaa <ma...@pacujo.net> writes: > Ben Finney <ben+pyt...@benfinney.id.au>: > > > A reference-compliant implementation can contradict your inference (by > > returning an object identity that is *not* the object's memory > > address). Any code you've written based on that false inference will > > break. > > > > The fault will be yours, for inferring an assertion that isn't implied > > by the definition. > > Show me a few lines of Python that demonstrate the error of the false > inference, please.
It need not be Python; it could be an extension library to which you pass the ‘id(foo)’ result, on the false assumption that it must be a memory location. Besides which, it is *you* that declares this abstraction to be leaky. If you're unable to show how that's the case, I rest on the null hypothesis: your assertion is untrue. > When I talk about an object's memory address, I'm not referring to > what might be revealed by gdb, for example. That is, I'm not talking > about the process's virtual address space, nor am I talking about the > physical address on the address bus. I can simply define that the > object's memory address is whatever id() returns. Then this does not count as a leaky abstraction. All you're saying is that the ‘id(foo)’ result is a representation of the object identity, which is entirely at the level of the abstraction. Nothing is leaked. -- \ “God forbid that any book should be banned. The practice is as | `\ indefensible as infanticide.” —Dame Rebecca West | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
