[Numpy-discussion] Array Protocol change for Python 2.6 (original) (raw)
Sasha ndarray at mac.com
Thu Jun 8 22:52:53 EDT 2006
- Previous message (by thread): [Numpy-discussion] Array Protocol change for Python 2.6
- Next message (by thread): [Numpy-discussion] Array Protocol change for Python 2.6
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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. In addition, to me array_interface feels like a generalization of array method, so I personally expected it to be a method the first time I tried to use it.
... The idea behind the array interface was to have 0 external dependencies: any array-like object from any package could add the interface, without requiring a 3rd-party module. That's why the C version uses a CObject. Subclasses of CObject start getting into 3rd-party requirements.
Not necessarily. Different packages don't need to share the subclass, but subclassing CObject is probably a bad idea for the reasons I will explain below.
How about a dict instead of a tuple? With keys matching the attributes it's replacing: "shapes", "typestr", "descr", "data", "strides", "mask", and "offset". The problem with a tuple from my point of view is I can never remember which order things go (this is why in the standard library the result of os.stat() and time.localtime() are now "tuple-like" classes with attributes). My problem with array_struct returning either a tuple or a CObject is that array protocol sholuld really provide both. CObject is useless for interoperability at python level and a tuple (or dict) is inefficient at the C level. Thus a good array-like object should really provide both array_struct for use by C modules and array_tuple (or whatever) for use by python modules. On the other hand, making both required attributes/methods will put an extra burden on package writers. Moreover, a pure python implementation of an array-like object will not be able to provide array_struct at all. One possible solution would be an array protocol metaclass that adds array_struct to a class with array_tuple and array_tuple to a class with array_struct (yet another argument to make both methods).
We still need arraydescr, as the C struct doesn't provide all the info that this does. What do you have in mind?
- Previous message (by thread): [Numpy-discussion] Array Protocol change for Python 2.6
- Next message (by thread): [Numpy-discussion] Array Protocol change for Python 2.6
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]