On Thu, Apr 26, 2012 at 9:42 PM, Adam Skutt <ask...@gmail.com> wrote: > 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.
It's an address. You can cast it back to pointer and then dereference it. But you're talking about C, which is portable assembly language. When I write C code, I expect to be able to shoot myself in the foot in numerous ways. With Python, you have to actually work at it a bit, like: len = str Okay, that wasn't very hard, but still, it's not like dereferencing an uninitialized pointer! But all this is predicated on a few things: 1) The CPU addresses memory by numbers of a certain size. 2) The C declaration "int *ptr" represents an address 3) The C declaration "(int)ptr" turns that address into an integer that's big enough to store it Assuming #3 to be correct is a major cause of trouble, but let's suppose for the moment that it is. What we have is a direct 1:1 relationship between pointers, integers, and object identities. The fact is, though, that Python does not ever guarantee this. Side point: In Python 2, id() returns an int, not a long. Is it possible to be running Python on a 64-bit machine with a 32-bit int type? And if so, what does CPython do? Return the address modulo 4G? Because that could result in collisions. ChrisA -- http://mail.python.org/mailman/listinfo/python-list