On 6/8/06, David M. Cooke <[EMAIL PROTECTED]> 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 __array_descr__, as the C struct doesn't provide all the info > that this does. > What do you have in mind? _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
