<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 24, 2018 at 8:07 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"><span class="">On Sun, Jul 22, 2018 at 12:28 PM, Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com">ralf.gommers@gmail.com</a>> wrote:<br>
> On Sat, Jul 21, 2018 at 7:15 PM, Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br>
</span><span class="">>> Speaking of examples: I hate to say this because in general I think<br>
>> using examples is a great idea. But... I think you should delete most<br>
>> of these examples. The problem is scope creep: the goal for this NEP<br>
>> (IMO) should be to lay out the principles we use to think about these<br>
>> issues in general, but right now it comes across as trying to lay down<br>
>> a final resolution on lots of specific issues (including several where<br>
>> there are ongoing conversations). It ends up like trying to squish<br>
>> multiple NEPs into one, which makes it hard to discuss, and also<br>
>> distracts from the core purpose.<br>
><br>
><br>
> I'm not sure this is the best thing to do. I can remove a couple, but aiming<br>
> to be "totally uncontroversial" is almost impossible given the topic of the<br>
> NEP.<br>
<br>
</span>Of course the NEP itself will have some things to discuss – but I<br>
think the discussion will be more productive if we can stay focused on<br>
the core part of the NEP, which is the general principles we use to<br>
evaluate each specific situation as it comes up. Look at how much of<br>
the discussion so far has gotten derailed onto topics like<br>
subclassing, submodules, etc.<br></blockquote><div><br></div><div>The subclassing discussion was actually illuminating and useful. Maybe it does deserve its own write-up somewhere though. Happy to remove that too. Would then like to put it somewhere else - in the docs, another NEP, ...?<br></div><div><br></div><div>The submodules one I'd really like to keep. <br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> The diag view example is important I think, it's the second most<br>
> discussed backwards compatibility issue next to histogram. I'm happy to<br>
> remove the statement on what should happen with it going forward though.<br>
<br>
</span>It's the most discussed issue because it was the test case where we<br>
developed all these policies in the first place :-). </blockquote><div><br></div><div>Pretty sure that's not true, we had policies long before that plus it was not advertised as a test case for backwards compat (it's just an improvement that someone wanted to implement). But well, I don't care enough about this particular one to argue about it - I'll remove it.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not sure it's<br>
particularly interesting aside from that, and that specific history<br>
("let's come up with a transition plan for this feature that no-one<br>
actually cares about, b/c no-one cares about it so it's a good thing<br>
to use as a test case") is unlikely to be repeated.<br>
<span class=""><br>
> Then, I think it's not unreasonable to draw a couple of hard lines. For<br>
> example, removing complete submodules like linalg or random has ended up on<br>
> some draft brainstorm roadmap list because someone (no idea who) put it<br>
> there after a single meeting. Clearly the cost-benefit of that is such that<br>
> there's no point even discussing that more, so I'd rather draw that line<br>
> here than every time someone open an issue. Very recent example:<br>
> <a href="https://github.com/numpy/numpy/issues/11457" rel="noreferrer" target="_blank">https://github.com/numpy/<wbr>numpy/issues/11457</a> (remove auto-import of<br>
> numpy.testing).<br>
<br>
</span>I can see an argument for splitting random and linalg into their own<br>
modules, which numpy depends on and imports so that existing code<br>
doesn't break. </blockquote><div><br></div><div>Me too, that could happen. But that's unrelated to backwards compatibility.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">E.g. this might let people install an old version of<br>
random if they needed to reproduce some old results, or help us merge<br>
numpy and scipy's linalg modules into a single package. I agree though<br>
that making 'np.linalg' start raising AttributeError is a total<br>
non-starter.<br></blockquote><div><br></div><div>It is, hence why I say above that I'd like to keep that example.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
>> Regarding the major version number thing: ugh do we really want to<br>
>> talk about this more. I'd probably leave it out of the NEP entirely.<br>
>> If it stays in, I think it needs a clearer description of what counts<br>
>> as a "major" change.<br>
><br>
><br>
> I think it has value to keep it, and that it's not really possible to come<br>
> up with a very clear description of "major". In particular, I'd like every<br>
> deprecation message to say "this deprecated feature will be removed by<br>
> release X.Y.0". At the moment we don't do that, so if users see a message<br>
> they don't know if a removal will happen next year, in the far future (2.0),<br>
> or never. The major version thing is quite useful to signal our intent.<br>
> Doesn't mean we need to exhaustively discuss when to do a 2.0 though, I<br>
> agree that that's not a very useful discussion right now.<br>
<br>
</span>The problem is that "2.0" means a lot of different things to different<br>
people, not just "some future date to be determined", so using it that<br>
way will confuse people. Also, it's hard to predict when a deprecation<br>
will actually happen... it's very common that we adjust the schedule<br>
as we go (e.g. when we try to remove it and then discover it breaks<br>
everyone so we have to put it back for a while).<br>
<br>
I feel like it would be better to do this based on time</blockquote><div><br></div><div>This does make sense to me.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> -- like say<br>
"this will be removed <today + 1 year>" or something, and then it<br>
might take longer but not shorter?<br></blockquote><div><br></div><div>You can't practically do "today", should be <version number of next release when PR is merged + at least N years>. But yes that is useful, the point is to give a clear indication and it's then easy for the user to figure out when the earliest date is that the removal could happen.</div><div><br></div><div>Given that this is clear and avoids the version number discussion, I'm happy to go with that and remove the major/minor version text.</div><div><br></div><div>Cheers,<br></div><div>Ralf<br></div><div><br></div><br></div></div></div>