[Numpy-discussion] Subclassing ndarray with concatenate
Fri Feb 1 08:13:35 CST 2013
On Wed, Jan 30, 2013 at 11:20 AM, Sebastian Berg <firstname.lastname@example.org
> > > In my particular case at least, there are clear ways to
> > handle corner
> > > cases (like being passed a class that lacks these
> > attributes), so in
> > > principle there no problem handling concatenate in a general
> > way,
> > > assuming I can get access to the attributes.
> > >
> > >
> > > So is there any way to subclass ndarray in such a way that
> > concatenate
> > > can be handled properly?
> > >
> > Quite simply, no. If you compare masked arrays, they also
> > provide their
> > own concatenate for this reason.
> > I hope that helps a bit...
> > Is this something that should be available? For instance a method
> > that provides both the new array and the arrays that were used to
> > construct it. This would seem to be an extremely common use-case for
> > array subclasses, so letting them gracefully handle this would seem to
> > be very important.
> In any case, yes, it calls __array_finalize__, but as you noticed, it
> calls it without the original array. Now it would be very easy and
> harmless to change that, however I am not sure if giving only the parent
> array is very useful (ie. you only get the one with highest array
> Another way to get around it would be maybe to call __array_wrap__ like
> ufuncs do (with a context, so you get all inputs, but then the non-array
> axis argument may not be reasonably placed into the context).
> In any case, if you think it would be helpful to at least get the single
> parent array, that would be a very simple change, but I feel the whole
> subclassing could use a bit thinking and quite a bit of work probably,
> since I am not quite convinced that calling __array_wrap__ with a
> complicated context from as many functions as possible is the right
> approach for allowing more complex subclasses.
I was more thinking of a new method that is called when more than one input
array is used, maybe something like __multi_array_finalize__. This would
allow more fine-grained handling of such cases and would not break
backwards compatibility with any existing subclasses (if they don't
override the method the current behavior will remain).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion