[Numpy-discussion] Uncomfortable with matrix change

[Nathan Bell]

On Fri, May 9, 2008 at 12:31 PM, Alan G Isaac <aisaac at american.edu> 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 wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/