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 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion