Mailing List Archive: Python: Python

Python id() does not return an address [was Re: why () is () and [] is [] work in other way?]

Index | Next | Previous | View Threaded

steve+comp.lang.python at pearwood

Apr 27, 2012, 10:12 AM

Post #1 of 5 (286 views)
Permalink

Python id() does not return an address [was Re: why () is () and [] is [] work in other way?]

On Thu, 26 Apr 2012 04:42:36 -0700, Adam Skutt wrote:

> On Apr 26, 5:10Ā am, Steven D'Aprano <steve
> +comp.lang.pyt...@pearwood.info> wrote:

>> Solution to *what problem*?
>>
> This confusion that many people have over what 'is' does, including
> yourself.

I have no confusion over what "is" does. The "is" operator returns True
if and only if the two operands are the same object, otherwise it returns
False.

If you think that "is" does something different, you are wrong.

>> > An address is an identifier: a number that I can use to access a
>> > value[1].
>>
>> Then by your own definition, Python's id() does not return an address,
>> since you cannot use it to access a value.
>
> The fact Python lacks explicit dereferencing doesn't change the fact
> that id() returns an address. Replace 'can' with 'could' or 'could
> potentially' or the whole phrase with 'represents' if you wish. It's a
> rather pointless thing to quibble over.

You can't treat id() as an address. Did you miss my post when I
demonstrated that Jython returns IDs generated on demand, starting from
1? In general, there is *no way even in principle* to go from a Python ID
to the memory location (address) of the object with that ID, because in
general objects *may not even have a fixed address*. Objects in Jython
don't, because the Java virtual machine can move them in memory.

The fact that CPython happens to use the memory address of objects,
suitably converted to an int object, is a red-herring. It leads to
nothing but confusion.

> Would you call the result of casting a C pointer to an int an address?
> If so, you must call the result of id() an address as well-- you can't
> dereference either of them. If not, then you need to provide an
> alternate name for the result of casting a C pointer to an int.

I don't need to do anything of the sort. It was *your* definition, not
mine. Don't put the responsibility on me for your definition being broken.

(And for the record, in C you can cast an integer into a pointer,
although the results are implementation-specific. There's no equivalent
in Python.)

--
Steven
--
http://mail.python.org/mailman/listinfo/python-list

lamialily at cleverpun

Apr 27, 2012, 10:24 AM

Post #2 of 5 (263 views)
Permalink

Re: Python id() does not return an address [was Re: why () is () and [] is [] work in other way?] [In reply to]

Steven, your posts are leaking out of their respective thread(s). Is
this intentional?

~Temia
--
When on earth, do as the earthlings do.
--
http://mail.python.org/mailman/listinfo/python-list

askutt at gmail

Apr 27, 2012, 10:51 AM

Post #3 of 5 (265 views)
Permalink

Re: Python id() does not return an address [was Re: why () is () and [] is [] work in other way?] [In reply to]

On Apr 27, 1:12 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Thu, 26 Apr 2012 04:42:36 -0700, Adam Skutt wrote:
> > On Apr 26, 5:10 am, Steven D'Aprano <steve
> > +comp.lang.pyt...@pearwood.info> wrote:
> >> Solution to *what problem*?
>
> > This confusion that many people have over what 'is' does, including
> > yourself.
>
> I have no confusion over what "is" does.

False. If you did, then you would not have suggested the difference
in True/False result between "id([1,2]) == id([1, 2])" and "[1, 2] is
[1, 2]" matters. You would understand that the result of an identity
test with temporary objects is meaningless, since identity is only
meaningful while the objects are alive. That's a fundamental
mistake.

> >> > An address is an identifier: a number that I can use to access a
> >> > value[1].
>
> >> Then by your own definition, Python's id() does not return an address,
> >> since you cannot use it to access a value.
>
> > The fact Python lacks explicit dereferencing doesn't change the fact
> > that id() returns an address. Replace 'can' with 'could' or 'could
> > potentially' or the whole phrase with 'represents' if you wish. It's a
> > rather pointless thing to quibble over.
>
> You can't treat id() as an address. Did you miss my post when I
> demonstrated that Jython returns IDs generated on demand, starting from
> 1? In general, there is *no way even in principle* to go from a Python ID
> to the memory location (address) of the object with that ID, because in
> general objects *may not even have a fixed address*. Objects in Jython
> don't, because the Java virtual machine can move them in memory.

Yes, there is a way. You add a function deref() to the language. In
CPython, that simply treats the passed value as a memory address and
treats it as an object, perhaps with an optional check. In Jython,
it'd access a global table of numbers as keys with the corresponding
objects as values, and return them. The value of id() is absolutely
an address, even in Jython. The fact the values can move about is
irrelevant.

Again, if this wasn't possible, then you couldn't implement 'is'.
Implementing 'is' requires a mechanism for comparing objects that
doesn't involve ensuring the contents of the two operands in memory is
the same.

> > Would you call the result of casting a C pointer to an int an address?
> > If so, you must call the result of id() an address as well-- you can't
> > dereference either of them. If not, then you need to provide an
> > alternate name for the result of casting a C pointer to an int.
>
> I don't need to do anything of the sort.

Yes, you do, because you called such a thing an address when talking
about CPython. Even if my definition is wrong (it's not), your
definition is wrong too.

> (And for the record, in C you can cast an integer into a pointer,
> although the results are implementation-specific. There's no equivalent
> in Python.)

Yes, but the lack of that operation doesn't mean that id() doesn't
return an address.

Adam
--
http://mail.python.org/mailman/listinfo/python-list

rosuav at gmail

Apr 27, 2012, 11:24 AM

Post #4 of 5 (264 views)
Permalink

Re: Python id() does not return an address [was Re: why () is () and [] is [] work in other way?] [In reply to]

On Sat, Apr 28, 2012 at 3:51 AM, Adam Skutt <askutt [at] gmail> wrote:
> Yes, there is a way. You add a function deref() to the language. In
> CPython, that simply treats the passed value as a memory address and
> treats it as an object, perhaps with an optional check. In Jython,
> it'd access a global table of numbers as keys with the corresponding
> objects as values, and return them. The value of id() is absolutely
> an address, even in Jython. The fact the values can move about is
> irrelevant.

Python already as dereferenceable addresses. Look.

def address(obj,table=[]):
for i,o in enumerate(table):
if obj is o: return i
table.append(obj)
return len(table)-1

def deref(addr):
return address.__defaults__[0][addr]

You can take the address of an object (interning it, effectively), and
later dereference it. Proves nothing.

ChrisA
--
http://mail.python.org/mailman/listinfo/python-list

brenNOSPAMbarn at NObrenSPAMbarn

Apr 28, 2012, 11:04 AM

Post #5 of 5 (254 views)
Permalink

Re: Python id() does not return an address [was Re: why () is () and [] is [] work in other way?] [In reply to]

Adam Skutt wrote:

>> You can't treat id() as an address. Did you miss my post when I
>> demonstrated that Jython returns IDs generated on demand, starting
>> from 1? In general, there is *no way even in principle* to go from
>> a Python ID to the memory location (address) of the object with
>> that ID, because in general objects *may not even have a fixed
>> address*. Objects in Jython don't, because the Java virtual
>> machine can move them in memory.
>
> Yes, there is a way. You add a function deref() to the language.

This is getting pretty absurd. By that logic you could say "With
Python, you can end all life on earth! You just add a function to
the language called nuclear_winter() that remotely accesses warhead
launch sites in the US and Russia, enters the appropriate launch codes,
and launches the entire nuclear arsenal!"

--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown
--
http://mail.python.org/mailman/listinfo/python-list

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads