Sasha wrote: >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. > Conceptually at least, couldn't there be a single __array_interface__ object associated with a given array? In that sense, it doesn't really feel like creating a new object.
> 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). > > I don't understand this. I'm don't see how bringing in metaclass is going to help a pure python type provide a sensible __array_struct__. That seems like a hopeless task. Shouldn't pure python implementations just provide __array__? 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 nightmare. -tim > >_______________________________________________ >Numpy-discussion mailing list >Numpy-discussion@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > > > _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
