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

[Nathaniel Smith]

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.

-n