On 01/08/2013 10:32 PM, Dag Sverre Seljebotn wrote: > On 01/08/2013 06:20 PM, Andrew Collette wrote: >> Hi, >> >>> I think you are voting strongly for the current casting rules, because >>> they make it less obvious to the user that scalars are different from >>> arrays. >> >> Maybe this is the source of my confusion... why should scalars be >> different from arrays? They should follow the same rules, as closely > > Scalars (as in, Python float/int) are inherently different because the > user didn't specify a dtype. > > For an array, there was always *some* point where the user chose, > explicitly or implicitly, a dtype. > >> as possible. If a scalar value would fit in an int16, why not add it >> using the rules for an int16 array? > > So you are saying that, for an array x, you want > > x + random.randint(100000) > > to produce an array with a random dtype? > > So that after carefully testing that your code works, suddenly a > different draw (or user input, or whatever) causes a different set of > dtypes to ripple through your entire program? > > To me this is something that must be avoided at all costs. It's hard > enough to reason about the code one writes without throwing in complete > randomness (by which I mean, types determined by values).
Oh, sorry, given that this is indeed the present behaviour, this just sounds silly. I should have said it's something I dislike about the present behaviour then. Dag Sverre > > Dag Sverre > > > > >> >>> Returning to the question of 1.5 behavior vs the error - I think you >>> are saying you prefer the 1.5 silent-but-deadly approach to the error, >>> but I think I still haven't grasped why. Maybe someone else can >>> explain it? The holiday has not been good to my brain. >> >> In a strict choice between 1.5-behavior and errors, I'm not sure which >> one I would pick. I don't think either is particularly useful. Of >> course, other members of the community would likely have a different >> view, especially those who got used to the 1.5 behavior. >> >> Andrew >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion