[Numpy-discussion] Change in scalar upcasting rules for 1.6.x?
Tue Feb 14 00:00:35 CST 2012
> > 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.
> Now we are in an odd situation. We have undocumented old behavior, and documented new behavior. What do we do? I understand the drive to revert, but I hate the idea of putting back what I see as buggy, especially when new software may fail with old behavior.
> Maybe a Boolean switch defaulting to new behavior? Anybody having issues with old software could just flip the switch?
> Ben Root _______________________________________________
> NumPy-Discussion mailing list
More information about the NumPy-Discussion