[Numpy-discussion] Change in scalar upcasting rules for 1.6.x?
Charles R Harris
Tue Feb 14 00:07:37 CST 2012
On Mon, Feb 13, 2012 at 11:00 PM, Travis Oliphant <firstname.lastname@example.org>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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion