<br><br><div class="gmail_quote">On Wed, May 9, 2012 at 4:12 PM, Travis Oliphant <span dir="ltr"><<a href="mailto:travis@continuum.io" target="_blank">travis@continuum.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">On re-reading, I want to make a couple of things clear:   <div><br></div><div><span style="white-space:pre-wrap">     </span>1) This "wrap-up" discussion is *only* for what to do for NumPy 1.7 in such a way that we don't tie our hands in the future.    I do not believe we can figure out what to do for masked arrays in one short week.   What happens beyond NumPy 1.7 should be still discussed and explored.    My urgency is entirely about moving forward from where we are in master right now in a direction that we can all accept.      The tight timeline is so that we do *something* and move forward.    </div>
<div><br></div><div><span style="white-space:pre-wrap"> </span>2) I missed another possible proposal for NumPy 1.7 which is in the write-up that Mark and Nathaniel made:  remove the masked array additions entirely possibly moving them to another module like numpy-dtypes.</div>
<div><br></div><div>Again, these are only for NumPy 1.7.   What happens in any future NumPy and beyond will depend on who comes to the table for both discussion and code-development. </div><div><br></div></div></blockquote>
<div><br>Why don't we go with 2) then? Mark implies that it takes the least work and it kicks the decision down the road. It may well be that a better approach turns up after more discussion, or that we decide to just pull it out, but the first takes time to arrive at and the second takes effort that could be better spent (IMHO) on other things at the moment.<br>
<br>My sense is that the API is actually the major point of contention, although I may just be speaking for myself. And perhaps we should look for ways of adding support for masked array implementations rather than masked arrays themselves. It could be that easy to use infrastructure that enhanced others efforts might be a better way forward.<br>
<br><snip><br><br>Chuck<br></div></div>