why () is () and [] is [] work in other way?

[Chris Angelico]

On Thu, Apr 26, 2012 at 9:42 PM, Adam Skutt <askutt at 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