[SciPy-dev] [SciPy-user] scipy.linalg.eig() returns transposed eigenvector matrix
Fernando.Perez at colorado.edu
Mon Nov 14 13:18:12 CST 2005
Travis Oliphant wrote:
>>If I may suggest, I think these two should be unified, though. It will be
>>seriously disconcerting for new users to find that
> If the two are to be unified, I think scipy.basic should change. But,
> that leads to a problem because of compatibility with Numeric.
> So, what to do?
This one seems worth fixing to me, and I'd rather not clutter the API with too
many similarly-named functions (people will always end up using the wrong one
by accident). How about this: let's introduce a CompatibilityWarning call
using the Python warnings framework. All functions whose API has changed will
trigger such a warning (just noise on screen) when used.
I see a few advantages to this:
- people can turn it off using the warnings controls, if they really know they
don't need it. Easy instructions on how to do this should be given, of course.
- it will reduce the number of 'support calls' on the list due to broken code
as people start transitioning. At least one hopes so :)
- after 1.0 (or a little later?) is out, we can easily clear all this code
out. Since these are real function calls, we'd have to fully purge them out
at least from the python sources (no #ifdef in python without nasty bytecode
hacks). Their counterpart in C extensions could be ifdef'd out.
If you like this approach, it may make you more comfortable in introducing
backwards-compatibility-breaking changes you feel are necessary. With nice,
explicit messages in the warnings, the library becomes self-documenting to
help users transition. I know the line between backwards-compatibility and
clean evolution is a hard one to walk; this may be a tool to help in that.
Does this sound reasonable?
More information about the Scipy-dev