[SciPy-dev] [SciPy-user] scipy.linalg.eig() returns transposed eigenvector matrix

[Fernando Perez]

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?

Cheers,

f