From: Travis O. <oli...@ie...> - 2006-06-16 21:44:38
|
Thomas Heller wrote: > Robert Kern wrote: > >> Francesc Altet wrote: >> >>> A Divendres 09 Juny 2006 11:54, Albert Strasheim va escriure: >>> >>> >>>> Just out of curiosity: >>>> >>>> In [1]: x = N.array([]) >>>> >>>> In [2]: x.__array_data__ >>>> Out[2]: ('0x01C23EE0', False) >>>> >>>> Is there a reason why the __array_data__ tuple stores the address as a hex >>>> string? I would guess that this representation of the address isn't the >>>> most useful one for most applications. >>>> >>> Good point. I hit this before and forgot to send a message about this. I agree >>> that a integer would be better. Although, now that I think about this, I >>> suppose that the issue should be the difference of representation of longs in >>> 32-bit and 64-bit platforms, isn't it? >>> >> Like how Win64 uses 32-bit longs and 64-bit pointers. And then there's >> signedness. Please don't use Python ints to encode pointers. Holding arbitrary >> pointers is the job of CObjects. >> >> > > (Sorry, I'm late in reading this thread. I didn't know there were so many > numeric groups) > > Python has functions to convert pointers to int/long and vice versa: PyInt_FromVoidPtr() > and PyInt_AsVoidPtr(). ctypes uses them, ctypes also represents addresses as ints/longs. > The function calls are PyLong_FromVoidPtr() and PyLong_AsVoidPtr() though, right? I'm happy representing pointers as Python integers (Python long integers on curious platforms like Win64). -Travis |