[Numpy-discussion] Array Protocol change for Python 2.6

Travis Oliphant oliphant.travis at ieee.org
Fri Jun 16 17:44:33 EDT 2006


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





More information about the NumPy-Discussion mailing list