<br><br>On Wednesday, May 9, 2012, Nathaniel Smith  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
My only objection to this proposal is that committing to this approach<br>
seems premature. The existing masked array objects act quite<br>
differently from <a href="http://numpy.ma" target="_blank">numpy.ma</a>, so why do you believe that they're a good<br>
foundation for <a href="http://numpy.ma" target="_blank">numpy.ma</a>, and why will users want to switch to their<br>
semantics over <a href="http://numpy.ma" target="_blank">numpy.ma</a>'s semantics? These aren't rhetorical<br>
questions, it seems like they must have concrete answers, but I don't<br>
know what they are.<br></blockquote><div style><span class="Apple-style-span" style><br></span></div>Based on the design decisions made in the original NEP, a re-made <a href="http://numpy.ma">numpy.ma</a> would have to lose _some_ features particularly, the ability to share masks. Save for that and some very obscure behaviors that are undocumented, it is possible to remake <a href="http://numpy.ma">numpy.ma</a> as a compatibility layer.<div>
<span class="Apple-style-span" style><br></span></div><div><span class="Apple-style-span" style>That being said, I think that there are some fundamental questions that has concerned. If I recall, there were unresolved questions about behaviors surrounding assignments to elements of a view.</span><div>
</div></div><div><span class="Apple-style-span" style><br></span></div><div><span class="Apple-style-span" style>I see the project as broken down like this:</span></div><div><span class="Apple-style-span" style>1.) internal architecture (largely abi issues)</span></div>
<div><span class="Apple-style-span" style>2.) external architecture (hooks throughout numpy to utilize the new features where possible such as where= argument)</span></div><div><span class="Apple-style-span" style>3.) getter/setter semantics</span></div>
<div><span class="Apple-style-span" style>4.) mathematical semantics</span></div><div><span class="Apple-style-span" style><br></span></div><div><span class="Apple-style-span" style>At this moment, I think we have pieces of 2 and they are fairly non-controversial. It is 1 that I see as being the immediate hold-up here. 3 & 4 are non-trivial, but because they are mostly about interfaces, I think we can be willing to accept some very basic, fundamental, barebones components here in order to lay the groundwork for a more complete API later.</span></div>
<div><span class="Apple-style-span" style><br></span></div><div><span class="Apple-style-span" style>To talk of Travis's proposal, doing nothing is no-go. Not moving forward would dishearten the community. Making a ndmasked type is very intriguing. I see it as a set towards eventually deprecating ndarray? Also, how would it behave with no.asarray() and no.asanyarray()? My other concern is a possible violation of DRY. How difficult would it be to maintain two ndarrays in parallel?  </span></div>
<div><span class="Apple-style-span" style><br></span></div><div><span class="Apple-style-span" style>As for the flag approach, this still doesn't solve the problem of legacy code (or did I misunderstand?)</span></div>
<div><span class="Apple-style-span" style><br></span></div><div><span class="Apple-style-span" style>Cheers!</span></div><div><span class="Apple-style-span" style>Ben Root<span></span></span></div><div></div>