<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 14, 2013 at 1:22 PM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Jun 12, 2013 at 7:43 PM, Eric Firing <<a href="mailto:efiring@hawaii.edu">efiring@hawaii.edu</a>> wrote:<br>
> On 2013/06/12 2:10 AM, Nathaniel Smith wrote:<br>
</div><div class="im">>> Personally I think that overloading np.empty is horribly ugly, will<br>
>> continue confusing newbies and everyone else indefinitely, and I'm<br>
>> 100% convinced that we'll regret implementing such a warty interface<br>
>> for something that should be so idiomatic. (Unfortunately I got busy<br>
>> and didn't actually say this in the previous thread though.) So I<br>
>> think we should just merge the PR as is. The only downside is the<br>
>> <a href="http://np.ma" target="_blank">np.ma</a> inconsistency, but, <a href="http://np.ma" target="_blank">np.ma</a> is already inconsistent (cf.<br>
>> masked_array.fill versus masked_array.filled!), somewhat deprecated,<br>
><br>
> "somewhat deprecated"? Really? Since when? By whom? Replaced by what?<br>
<br>
</div>Sorry, not trying to start a fight, just trying to summarize the<br>
situation. As far as I can tell:<br>
<br></blockquote><div><br></div><div>Oh... (puts away iron knuckles)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Despite heroic efforts on the part of its authors, <a href="http://numpy.ma" target="_blank">numpy.ma</a> has a<br>
number of weird quirks (masked data can still trigger invalid value<br>
errors), misfeatures (hard versus soft masks), and just plain old pain<br>
points (ongoing issues with whether any given operation will respect<br>
or preserve the mask).<br></blockquote><div><br></div><div>Actually, now that we have a context manager for warning capture, we could actually fix that.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It's been in deep maintenance mode for some time; we merge the<br>
occasional bug fix that people send in, and that's it. (To be fair,<br>
numpy as a whole is fairly slow-moving, but <a href="http://numpy.ma" target="_blank">numpy.ma</a> still gets much<br>
less attention.)<br>
<br>
Even if there were active maintainers, no-one really has any idea how<br>
to fix any of the problems above; they're not so much bugs as<br>
intrinsic limitations of the design.<br>
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Therefore, my impression is that a majority (not all, but a majority)<br>
of numpy developers strongly recommend against the use of <a href="http://numpy.ma" target="_blank">numpy.ma</a> in<br>
new projects.<br>
<br></blockquote><div><br></div><div>Such a recommendation should be in writing in the documentation and elsewhere. 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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I could be wrong! And I know there's nothing to really replace it. I'd<br>
like to fix that. But I think "semi-deprecated" is not an unfair<br>
shorthand for the above.<br>
<br></blockquote><div><br></div><div>You will have to pry <a href="http://np.ma">np.ma</a> from my cold, dead hands! (or distract me with a sufficiently shiny alternative)<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(I'll even admit that I'd *like* to actually deprecate it. But what I<br>
mean by that is, I don't think it's possible to fix it to the point<br>
where it's actually a solid/clean/robust library, so I'd like to reach<br>
a point where everyone who's currently using it is happier switching<br>
to something else and is happy to sign off on deprecating it.)<br></blockquote><div><br></div><div>As far as many people are concerned, it is a solid, clean, robust library.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
>> and AFAICT there are far more people who will benefit from a clean<br>
>> np.filled idiom than who actually use <a href="http://np.ma" target="_blank">np.ma</a> (and in particular its<br>
>> fill-value functionality). So there would be two<br>
><br>
> I think there are more <a href="http://np.ma" target="_blank">np.ma</a> users than you realize. Everyone who uses<br>
> matplotlib is using <a href="http://np.ma" target="_blank">np.ma</a> at least implicitly, if not explicitly. Many<br>
> of the matplotlib examples put <a href="http://np.ma" target="_blank">np.ma</a> to good use. np.ma.filled is an<br>
> essential long-standing part of the <a href="http://np.ma" target="_blank">np.ma</a> API. I don't see any good<br>
> rationale for generating a conflict with it, when an adequate<br>
> non-conflicting alternative ('np.initialized', maybe others) exists.<br>
<br>
</div>I'm aware of that. If I didn't care about the opinions of <a href="http://numpy.ma" target="_blank">numpy.ma</a><br>
users, I wouldn't go starting long and annoying mailing list threads<br>
about features that are only problematic because of their affect on<br>
<a href="http://numpy.ma" target="_blank">numpy.ma</a> :-).<br>
<br>
But, IMHO given the issues with <a href="http://numpy.ma" target="_blank">numpy.ma</a>, our number #1 priority ought<br>
to be making numpy proper as clean and beautiful as possible; my<br>
position that started this thread is basically just that we shouldn't<br>
make numpy proper worse just for <a href="http://numpy.ma" target="_blank">numpy.ma</a>'s sake. That's the tail<br>
wagging the dog. And this 'conflict' seems a bit overstated given that<br>
(1) np.ma.filled already has multiple names (and 3/4 of the uses in<br>
matplotlib use the method version, not the function version), (2) even<br>
if we give it a non-conflicting name, <a href="http://np.ma" target="_blank">np.ma</a>'s lack of maintenance<br>
means that it'd probably be years before someone got around to<br>
actually adding a parallel function to <a href="http://np.ma" target="_blank">np.ma</a>. [Unless this thread<br>
spurs someone into submitting one just to prove me wrong ;-).]<br>
<br></blockquote><div><br></div><div>Actually, IIRC, <a href="http://np.ma">np.ma</a> does some sort of auto-wrapping of numpy functions. This is why adding np.filled() would cause a namespace clobbering, I think.<br></div>
<div><br></div><div>Cheers!<br></div><div>Ben Root<br></div><br></div></div></div>