[Numpy-discussion] Do we want scalar casting to behave as it does at the moment?

[Matthew Brett]

Hi,

On Sat, Jan 5, 2013 at 4:16 PM, Nathaniel Smith <njs at pobox.com> wrote:
> On 5 Jan 2013 15:59, "Matthew Brett" <matthew.brett at gmail.com> wrote:
>>
>> Hi,
>>
>> On Sat, Jan 5, 2013 at 2:38 PM, Nathaniel Smith <njs at pobox.com> wrote:
>> > On Sat, Jan 5, 2013 at 12:32 PM, Matthew Brett <matthew.brett at gmail.com>
>> > wrote:
>> >> Hi,
>> >>
>> >> On Fri, Jan 4, 2013 at 4:54 PM, Matthew Brett <matthew.brett at gmail.com>
>> >> wrote:
>> >>> Hi,
>> >>>
>> >>> On Fri, Jan 4, 2013 at 4:01 PM, Andrew Collette
>> >>> <andrew.collette at 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.
>
> It's not just the time to make the change, it's the time to make sure that
> we haven't created any new unexpected problems in the process. 1.7's already
> gone through many weeks of stabilization and testing. Really at this point
> the criterion isn't really even bug fixes only, but release critical bugs
> and doc fixes only (and the only RC bugs left should be ones discovered
> through the beta/rc cycle).

OK, I understand.

This must influence the decision on what to do about the scalar
casting.  Further from 1.5.x makes reverting to 1.5.x less attractive.
 The longer the 1.6.x changes have been in the wild, the stronger the
argument for leaving things as they are.

Best,

Matthew