On Fri, May 9, 2008 at 12:31 PM, Alan G Isaac <[EMAIL PROTECTED]> wrote: > > That's how we got here in the first place, I think. > Trading off problems in current behavior vs. the possibility > that other code (like Nathan's) might rely on that bad behavior. > Uncomfortable either way.
We'll, I think we've established that the possibility of breaking people's code is 1 :) > One piece of good news: Nathan's fixes were easy, > so one way forward is not looking too rocky. True, but scipy.sparse makes fairly limited use of matrix and I have 386 unittests to tell me what broke. End-users might spend considerably longer sorting out the problem, particularly if they don't know what they're looking for. Personally, I would not have thought a 1.0 -> 1.1 version bump would break something like this. Yes, we can put caveats in the release notes, but how many numpy.matrix users read those? Some aspects of the change are still broken. It's probably annoying to end users when they pass a matrix into a function and get an ndarray back out. Now matrix indexing is itself guilty of this offense. Furthermore, some users probably *do* rely on the lack of dimension reduction because that's one of the few differences between the matrix and ndarray. Alan, I don't fundamentally disagree with your positions on the deficiencies/quirks of matrices in numpy. However, it's completely inappropriate to plug one hole while creating others, especially in a minor release. I suspect that if we surveyed end-users we'd find that "my code still works" is a much higher priority than "A[0][0] now does what I expect". IMO scalar indexing should raise a warning (as you first suggested) in the 1.1 release. -- Nathan Bell [EMAIL PROTECTED] http://graphics.cs.uiuc.edu/~wnbell/ _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
