[Numpy-discussion] numpy.filled, again

[Nathaniel Smith]

On Fri, Jun 14, 2013 at 6:40 PM, Benjamin Root <ben.root at ou.edu> wrote:
> On Fri, Jun 14, 2013 at 1:22 PM, Nathaniel Smith <njs at pobox.com> wrote:
>>
>> On Wed, Jun 12, 2013 at 7:43 PM, Eric Firing <efiring at hawaii.edu> wrote:
>> > On 2013/06/12 2:10 AM, Nathaniel Smith wrote:
>> Despite heroic efforts on the part of its authors, numpy.ma has a
>> number of weird quirks (masked data can still trigger invalid value
>> errors), misfeatures (hard versus soft masks), and just plain old pain
>> points (ongoing issues with whether any given operation will respect
>> or preserve the mask).
>
>
> Actually, now that we have a context manager for warning capture, we could
> actually fix that.

PRs welcome!

>> It's been in deep maintenance mode for some time; we merge the
>> occasional bug fix that people send in, and that's it. (To be fair,
>> numpy as a whole is fairly slow-moving, but numpy.ma still gets much
>> less attention.)
>>
>> Even if there were active maintainers, no-one really has any idea how
>> to fix any of the problems above; they're not so much bugs as
>> intrinsic limitations of the design.
>>
>>
>> Therefore, my impression is that a majority (not all, but a majority)
>> of numpy developers strongly recommend against the use of numpy.ma in
>> new projects.
>>
>
> Such a recommendation should be in writing in the documentation and
> elsewhere.

Maybe, but someone needs to write it, and in a way that gets past the
list. Feel free to try :-).

> Furthermore, a proper replacement would also be needed.  Just
> simiply deprecating it without some sort of decent alternative leaves
> everybody in a lurch.  I have high hopes for NA to be that replacement, and
> the sooner, the better.

Again, this would be great, just, someone needs to do it :-).

>> But, IMHO given the issues with numpy.ma, our number #1 priority ought
>> to be making numpy proper as clean and beautiful as possible; my
>> position that started this thread is basically just that we shouldn't
>> make numpy proper worse just for numpy.ma's sake. That's the tail
>> wagging the dog. And this 'conflict' seems a bit overstated given that
>> (1) np.ma.filled already has multiple names (and 3/4 of the uses in
>> matplotlib use the method version, not the function version), (2) even
>> if we give it a non-conflicting name, np.ma's lack of maintenance
>> means that it'd probably be years before someone got around to
>> actually adding a parallel function to np.ma. [Unless this thread
>> spurs someone into submitting one just to prove me wrong ;-).]
>>
>
> Actually, IIRC, np.ma does some sort of auto-wrapping of numpy functions.
> This is why adding np.filled() would cause a namespace clobbering, I think.

Nope. np.ma manually wraps and re-exports every object that it
exports. Generally speaking it has to, because there's no way to look
at an arbitrary numpy function and know what the np.ma equivalent
would be. But even in cases where auto-wrapping would be possible and
useful, it doesn't do it. (E.g., it's easy to get a list of all ufunc
objects in the np.* namespace and wrap them all automatically, but
np.ma doesn't, it just has a big and possibly out-of-date list of all
the ufuncs that it knows about.)

-n