On Tue, Jun 26, 2018 at 1:49 AM Hameer Abbasi <einstein.edi...@gmail.com> wrote: > > On 26. Jun 2018 at 10:33, Robert Kern <robert.k...@gmail.com> wrote: > > > 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. > > 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. > > 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.
I'm still in favor of warnings in these cases. I didn't mean to suggest excluding those from the NEP. I just don't think they should be deprecations; we shouldn't suggest that they will eventually turn into errors. At least until we get these features out there, get some experience with them, then have a new NEP at that time just proposing deprecation. P.S. Would you mind bottom-posting? It helps maintain the context of what you are commenting on and my reply to those comments. I tried writing this reply without it, and it felt like it was missing context. Thanks! -- Robert Kern
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
