On Mon, Feb 13, 2012 at 11:00 PM, Travis Oliphant <tra...@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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
