<html><body>

        
            

I would disagree here. For libraries like Dask, XArray, pydata/sparse, XND, etc., it would be bad for them if there was continued use of “weird” indexing behaviour (no warnings means more code written that’s… well… not exactly the best design). Of course, we could just choose to not support it. But that means a lot of code won’t support us, or support us later than we desire.<div><br></div><div>I agree with your design of “let’s limit the number of warnings/deprecations to cases that make very little sense” but there should be warnings.</div><div><div><br></div><div>Specifically, I recommend warnings for mixed slices and fancy indexes, and warnings followed by errors for cases where the transposing behaviour occurs.<br>
<br>


<div class=""><div>Best Regards,</div><div>Hameer Abbasi</div>

        

        

        
            Sent from <a href="https://www.helloastro.com">Astro</a> for Mac
        

    

</div><br><blockquote class="hm_quoted_text" style="padding-left:8px;margin:0;border-left:1px solid rgb(185,185,185);color:rgb(100,100,100)">
    <div>On 26. Jun 2018 at 10:33, Robert Kern <<a href="mailto:robert.kern@gmail.com">robert.kern@gmail.com</a>> wrote:</div><p>

    

    
    <br></p><div dir="ltr"><div class="gmail_quote"><div><div dir="ltr">On Tue, Jun 26, 2018 at 1:26 AM Travis Oliphant <<a href="mailto:teoliphant@gmail.com">teoliphant@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I like the proposal generally.  NumPy could use a good orthogonal indexing method and a vectorized-indexing method is fine too. <div><br></div><div>Robert Kern is spot on with his concerns as well.  Please do not change what arr[idx] does except to provide warnings and perhaps point people to new .oix and .vix methods.  What indexing does is documented (if hard to understand and surprising in a particular sub-case). <div><br></div><div>There is one specific place in the code where I would make a change to raise an error rather than change the order of the axes of the output to provide a consistent subspace.  Even then, it should be done as a deprecation warning and then raise the error. </div><div><br></div><div>Otherwise, just add the new methods and don't make any other changes until a major release.  </div></div></div></blockquote><div><br></div></div><div>I'd suggest that the NEP explicitly disclaim deprecating current behavior. Let the NEP just be about putting the new features out there. Once we have some experience with them for a year or three, then let's talk about deprecating parts of the current behavior and make a new NEP then if we want to go that route. We're only contemplating *long* deprecation cycles anyways; we're not in a race. The success of these new features doesn't really rely on the deprecation of current indexing, so let's separate those issues.</div><div> </div></div><div>-- <br><div dir="ltr" class="gmail_signature">Robert Kern</div></div></div>
<br><span style="white-space:pre-wrap" class="hm_plaintext"><div>_______________________________________________<br>NumPy-Discussion mailing list<br><a href="mailto:NumPy-Discussion@python.org">NumPy-Discussion@python.org</a><br><a href="https://mail.python.org/mailman/listinfo/numpy-discussion">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br></div></span>
    

</blockquote>



        

        

        

    

</div></div></body></html>