[Numpy-discussion] Do we want scalar casting to behave as it does at the moment?
Sat Jan 5 09:59:25 CST 2013
On Sat, Jan 5, 2013 at 2:38 PM, Nathaniel Smith <email@example.com> wrote:
> On Sat, Jan 5, 2013 at 12:32 PM, Matthew Brett <firstname.lastname@example.org> wrote:
>> On Fri, Jan 4, 2013 at 4:54 PM, Matthew Brett <email@example.com> wrote:
>>> On Fri, Jan 4, 2013 at 4:01 PM, Andrew Collette
>>> <firstname.lastname@example.org> 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.
More information about the NumPy-Discussion