On Sat, Apr 4, 2015 at 9:54 AM, Nathaniel Smith
On Sat, Apr 4, 2015 at 12:17 AM, Ralf Gommers
wrote:
On Sat, Apr 4, 2015 at 1:54 AM, Nathaniel Smith
wrote:
So I'd be very happy to see worked out proposals for any or all of these approaches. It strikes me as really premature to be issuing proclamations about what changes might be considered. There is really no danger to *considering* a proposal;
Sorry, I have to disagree. Numpy is already seen by some as having a poor track record on backwards compatibility. Having core developers say "propose some backcompat break to how indexing works and we'll consider it" makes our stance on that look even worse. Of course everyone is free to make any technical proposal they deem fit and we'll consider the merits of it. However I'd like us to be clear that we do care strongly about backwards compatibility and that the fundamentals of the core of Numpy (things like indexing, broadcasting, dtypes and ufuncs) will not be changed in backwards-incompatible ways.
Ralf
P.S. also not for a possible numpy 2.0 (or have we learned nothing from Python3?).
I agree 100% that we should and do care strongly about backwards compatibility. But you're saying in one sentence that we should tell people that we won't consider backcompat breaks, and then in the next sentence that of course we actually will consider them (even if we almost always reject them). Basically, I think saying one thing and doing another is not a good way to build people's trust.
There is a difference between politely considering what proposals people send us uninvited and inviting people to work on specific proposals. That is what Ralf was getting at. -- Robert Kern