[Numpy-discussion] Subclassing ndarray with concatenate

Todd toddrjen@gmail....
Fri Feb 1 08:13:35 CST 2013

On Wed, Jan 30, 2013 at 11:20 AM, Sebastian Berg <sebastian@sipsolutions.net
> wrote:

> >
> >
> >         > 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
> priority).
> 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...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20130201/f3f3c2d7/attachment.html 

More information about the NumPy-Discussion mailing list