[Numpy-discussion] Array Protocol change for Python 2.6
oliphant at ee.byu.edu
Fri Jun 9 14:08:51 EDT 2006
Tim Hochberg wrote:
> Sasha wrote:
>> On 6/8/06, David M. Cooke <cookedm at physics.mcmaster.ca> wrote:
>>> +0 for name change; I'm happy with it as an attribute.
>> My rule of thumb for choosing between an attribute and a method is
>> that attribute access should not create new objects.
Interesting rule. In NumPy this is not quite the rule followed.
Bascially attributes are used when getting or setting intrinsinc
"properties" of the array. Attributes are used for properties that are
important in defining what an array *is*. The flags attribute, for
example, is an important intrinsinc property of the array but it returns
an flags object when it is accessed. The flat attribute also returns a
new object (it is arguable whether it should have been a method or an
attribute but it is enough of an intrinsic property --- setting the flat
attribute sets elements of the array -- that with historical precedence
it was left as an attribute).
By this meausure, the array interface should be an attribute.
>> My problem with __array_struct__ returning either a tuple or a CObject
>> is that array protocol sholuld really provide both.
This is a convincing argument. Yes, the array protocol should provide
both. Thus, we can't over-ride the usage of the same name unless that
name produces an object through which both interfaces can be obtained.
Is that Sasha's suggestion?
> A single attribute seems pretty appealing to me, I'm don't see much
> use for anything else.
>>> We still need __array_descr__, as the C struct doesn't provide all
>>> the info
>>> that this does.
>> What do you have in mind?
> Is there any prospect of merging this data into the C struct? It would
> be cleaner if all of the information could be embedded into the C
> struct, but I can see how that might be a backward compatibility
I do think it should be merged into the C struct. The simplest thing
to do is to have an additional PyObject * as part of the C struct which
could be NULL (or unassigned). The backward compatibility is a concern
but when thinking about what Python 2.6 should support we should not be
too crippled by it.
Perhaps we should just keep __array_struct__ and compress all the other
array_interface methods into the __array_interface__ attribute which
returns a dictionary from which the Python-side interface can be produced.
Keep in mind there are two different (but related) issues at play here.
1) What goes in to NumPy 1.0
2) What we propose should go into Python 2.6
I think for #1 we should compress the Python-side array protocol into a
single __array_interface__ attribute that returns a dictionary. We
should also expand the C-struct to contain what _array_descr_ currently
More information about the NumPy-Discussion