Sasha wrote: >On 6/8/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > > >>... >>__array_struct__ (perhaps we could call this __array_interface__ but >>I'm happy keeping the name the same too.) >> >> > >+0 on the name change and consider making it a method rather than an attribute. > > I'm not thrilled with either name, nor do I have a better one, so put me down as undecided on name.
I marginally prefer an attribute to a name here. I'm +1 on narrowing the interface though. >>If __array_struct__ is a CObject then it behaves as it does now. >> >>If __array_struct__ is a tuple then each entry in the tuple is one of >>the items currently obtained by an additional attribute access (except >>the first item is always an integer indicating the version of the >>protocol --- unused entries are None). >> >> >> > >-1 > >This will complicate the use of array interface. > I concur. >I would propose >creating a subtype of CObject that has the necessary attributes so >that one can do a.__array_interface__.shape, for example. I did not >check if CObject is subclassable in 2.5, but if not, we can propose to >make it subclassable for 2.6. > > Alternatively, if this proves to be a hassle, a function, unpack_interface or some such, could be provided that takes an __array_interface__ object and spits out the appropriate tuple or, perhaps better, and object with the appropriate field. > > >>... >> >>I would like to eliminate all the other array protocol attributes before >>NumPy 1.0 (and re-label those such as __array_data__ that are useful in >>other contexts --- like ctypes). >> >> >+1 > > +1. -tim _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
