Sasha wrote: >On 6/9/06, Tim Hochberg <[EMAIL PROTECTED]> wrote: > > >>Sasha wrote: >>... >> >> >>>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 my view, conceptually, __array_interface__ creates a adaptor to the >array-like object. What are the advantages of it being an attribute? >It is never settable, so the most common advantage of packing get/set >methods in a single attribute can be rulled out. Saving typing of >'()' cannot be taken seriousely when the name contains a pair of >double underscores :-). > >There was a similar issue discussed on the python-3000 mailing list >with respect to __hash__ method ><http://mail.python.org/pipermail/python-3000/2006-April/000362.html>. > > Isn't __array_interface__ always O(1)? By the criteria in that thread, that would make is good candidate for being an attribute.
[Stare at __array_interface__ spec...think..stare...] OK, I think I'm coming around to making it a function. Presumably, in: >>> a = arange(6) >>> ai1 = a.__array_interface__() >>> a.shape = [3, 2] >>> ai2 = a.__array_interface__() ai1 and ai2 will be different objects with different objects, pointing to structs with different shape and stride attributes. So, in that sense it's not conceptually constant and should be a function. What happens if I then delete or resize a? Hmmm. It looks like that's probably OK since CObject grabs a reference to a. FWIW, at this point, I marginally prefer array_struct to array_interface. > > >>.... >> >> >>>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__? >> >> >> > >My metaclass idea is very similar to your unpack_interface suggestion. > A metaclass can autonatically add > >def __array_tuple__(self): > return unpack_interface(self.__array_interface__()) > > >or > >def __array_interface__(self): > return pack_interface(self.__array_tuple__()) > >to a class that only implements only one of the two required methods. > > It seems like 99% of the people will never care about this at the Python level, so adding an extra attribute is mostly clutter. For those few who do care a function seems preferable. To be honest, I don't actually see a need for anything other than the basic __array_struct__. >>A single attribute seems pretty appealing to me, I'm don't see much use >>for anything else. >> >> > >I don't mind just having __array_struct__ that must return a CObject. >My main objection was against a method/attribute that may return >either CObject or something else. That felt like shifting the burden >from package writer to the package user. > > I concur. > >_______________________________________________ >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
