[Numpy-discussion] Change in scalar upcasting rules for 1.6.x?

Charles R Harris charlesr.harris@gmail....
Tue Feb 14 00:07:37 CST 2012


On Mon, Feb 13, 2012 at 11:00 PM, Travis Oliphant <travis@continuum.io>wrote:

>
> > >
> > > No argument on any of this.   It's just that this needs to happen at
> NumPy 2.0, not in the NumPy 1.X series.   I think requiring a re-compile is
> far-less onerous than changing the type-coercion subtly in a 1.5 to 1.6
> release.      That's my major point, and I'm surprised others are more
> cavalier about this.
> >
> > I thought the whole datetime debacle was the impetus for binary
> compatibility? Also, I disagree with your "cavalier" charge here.  When we
> looked at the rationale for the changes Mark made, the old behavior was not
> documented, broke commutibility, and was unexpected.  So, if it walks like
> a duck...
>
> First of all, I don't recall the "broken commutibility" issue --- nor how
> long it had actually been in the code-base.   So, I'm not sure how much
> weight to give that "problem"
>
> The problem I see with the weighting of these issues that is being implied
> is that
>
>        1) Requiring a re-compile is getting easier and easier as more and
> more people get their NumPy from distributions and not from downloads of
> NumPy itself.   They just wait until the distribution upgrades and
> everything is re-compiled.
>        2) That same trend means that changes to run-time code (like those
> that can occur when type-coercion is changed) is likely to affect people
> much later after the discussions have taken place on the list and everyone
> who was involved in the discussion assumes all is fine.
>
> This sort of change should be signaled by a version change.    I would
> like to understand what the "bugginess" was and where it was better because
> I think we are painting a wide-brush.   Some-things I will probably agree
> with you were "buggy", but others are likely just different preferences.
>
> I have a script that "documents" the old-behavior.   I will compare it to
> the new behavior and we can go from there.    Certainly, there is precedent
> for using something like a "__future__" statement to move forward which
> your boolean switch implies.
>
>
Let it go, Travis. It's a waste of time.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20120213/178d026b/attachment.html 


More information about the NumPy-Discussion mailing list