Rustom Mody <rustompm...@gmail.com> writes:
> On Wednesday, March 5, 2014 11:50:46 AM UTC+5:30, Ben Finney wrote:
> > So, what machine represenatation is leaked?
>
> > I'll re-iterate that "memory location of the object" isn't a valid
> > response. There is no necessary relation between the memory location of
> > the object referenced by "foo" and the return value of 'id(foo)'.
>
> ... however you are both disagreeing with me and also saying Ive not
> given the answer and further disagreeing with the python standard,
> which I quote:
>
> Every object has an identity, a type and a value. An object's identity
> never changes once it has been created; you may think of it as the
> object's address in memory. The 'is' operator compares the identity of
> two objects; the id() function returns an integer representing its
> identity (currently implemented as its address).
>
> from http://docs.python.org/2/reference/datamodel.html
Right. None of which constitutes a leaking abstraction. I'll repeat the
point: the abstraction does not leak if the user of that abstraction has
no need to deal with what lies beneath it.
In other words: A helpful “you may think of it as the object's address
in memory” does not constitute a leaky abstraction, because it would be
just as correct to say “you may think of it as a snowflake”.
There is no need for the user of the abstraction “object identity” to
know anything about the object's location in memory (nor of snowflakes),
nor ever to think about it when using the abstraction. You may, as the
documentation suggests, think of it that way; but you may also think of
it as anything else which agrees with the abstraction.
The clause about “object's location in memory” is not normative, does
not matter for using the abstraction, and is not part of the definition.
It literally does not matter for the purpose of using the abstraction,
so there's no leak.
In fact, in the current Python documentation the description has changed:
Every object has an identity, a type and a value. An object’s
identity never changes once it has been created; you may think of it
as the object’s address in memory. The ‘is‘ operator compares the
identity of two objects; the id() function returns an integer
representing its identity.
CPython implementation detail: For CPython, id(x) is the memory
address where x is stored.
<URL:http://docs.python.org/3/reference/datamodel.html>
So it's now even clearer that “memory address where the object is
stored” is *not* part of the abstraction, is *not* guaranteed to be what
‘id(foo)’ returns, and is an implementation detail of one particular
implementation, that can be ignored.
The abstraction “object identity” behaves exactly as the documentation
says it does, in the absence of any “object address in memory” concept,
and this is not undermined by suggestions that the reader may already
have a concept in mind which can help them to imagine the abstraction.
> So when you say
> > I'll re-iterate that "memory location of the object" isn't a valid
> > response.
>
> well... all I can say is I dont know what to say :-)
I'd encourage you to read the documentation for comprehension. Not every
word in a discussion of a concept must be normative.
I'd also encourage you to report a bug, suggesting a documentation
improvement if you have been misled by (the latest version of) the
language reference.
--
\ “Of course, everybody says they're for peace. Hitler was for |
`\ peace. Everybody is for peace. The question is: what kind of |
_o__) peace?” —Noam Chomsky, 1984-05-14 |
Ben Finney
--
https://mail.python.org/mailman/listinfo/python-list
