Hi, On Sat, Jan 5, 2013 at 2:38 PM, Nathaniel Smith <n...@pobox.com> wrote: > On Sat, Jan 5, 2013 at 12:32 PM, Matthew Brett <matthew.br...@gmail.com> > wrote: >> Hi, >> >> On Fri, Jan 4, 2013 at 4:54 PM, Matthew Brett <matthew.br...@gmail.com> >> wrote: >>> Hi, >>> >>> On Fri, Jan 4, 2013 at 4:01 PM, Andrew Collette >>> <andrew.colle...@gmail.com> wrote: >>>> >From a more basic perspective, I think that adding a number to an >>>> array should never raise an exception. I've not used any other >>>> language in which this behavior takes place. In C, you have rollover >>>> behavior, in IDL you roll over or clip, and in NumPy you either roll >>>> or upcast, depending on the version. IDL, etc. manage to handle >>>> things like max() or total() in a sensible (or at least defensible) >>>> fashion, and without raising an error. >>> >>> That's a reasonable point. >>> >>> Looks like we lost consensus. >>> >>> What about returning to the 1.5 behavior instead? >> >> If we do return to the 1.5 behavior, we would need to think about >> doing this in 1.7. >> >> If there are a large number of 1.5.x and previous users who would >> upgrade to 1.7, leaving the 1.6 behavior in 1.7 will mean that they >> will get double the confusion: >> >> 1) The behavior has changed to something they weren't expecting >> 2) The behavior is going to change back very soon > > I disagree. 1.7 is basically done, the 1.6 changes are out there > already, and we still have work to do just to get consensus on how we > want to handle this, plus implement the changes. > > Basically, the way I think about it in general is, you have the first > release that contains some bug, and then you have the first release > that doesn't contain it. Minimizing the amount of *time* between those > releases is important. Minimizing the *number of releases* in between > does not -- according to that logic, we shouldn't have released 1.6.1 > and 1.6.2 until we were confident that we'd fixed *all* the bugs, > because otherwise they might have misled people into upgrading too > soon. Holding 1.7 back for this isn't going to get this change done or > to users any faster; it's just going to hold back all the other > changes in 1.7. > > I do think we ought to aim to shorten our release cycle drastically. > Like release 1.8 within 2-3 months after 1.7. But let's talk about > that after 1.7 is out.
Yes, I was imagining that resolving this question would be rather quick, and therefore any delay to 1.7 would be very small, but if it takes more than a few days to come to a solution, it's possible there would not be net benefit. To Ralf - I think a 'bugfix only' metric doesn't help all that much in this case, because if we revert to 1.5 behavior, this could very reasonably be described as a bugfix. Cheers, Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
