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

[Matthew Brett]

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.

Cheers,

Matthew