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

2012-04-28 Thread OKB (not okblacke)
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


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

2012-04-27 Thread Temia Eszteri
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


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

2012-04-27 Thread Adam Skutt
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


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

2012-04-27 Thread Chris Angelico
On Sat, Apr 28, 2012 at 3:51 AM, Adam Skutt ask...@gmail.com 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