[SciPy-User] Arpack changes from 0.7.2 to 0.8.0

[josef.pktd at gmail.com]

On Wed, Aug 11, 2010 at 6:58 AM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
>
>
> On Wed, Aug 11, 2010 at 12:56 PM, <josef.pktd at gmail.com> wrote:
>>
>> On Wed, Aug 11, 2010 at 12:05 AM, Lutz Maibaum <lutz.maibaum at gmail.com>
>> wrote:
>> > On Tue, Aug 10, 2010 at 5:26 PM,  <josef.pktd at gmail.com> wrote:
>> >> I think there is a problem that the function is shadowing the module.
>> >> I remember I had problems with this before. I don't remember whether
>> >> there was a work around.
>> >
>> > Thanks, that's what I thought. Was this done on purpose? It seems like
>> > this is an API change that breaks backwards compatibility (that's how
>> > I stumbled upon it). It would be nice if there was a warning in the
>> > release notes, and/or in the scipy.sparse.linalg documentation.
>>
>> reading the thread again from jan 11
>> [Numpy-discussion] TypeError: 'module' object is not callable
>>
>> I'm still not clear what was going on.
>>
>> The import into the sparse.linalg namespace was missing only for 2
>> months, after ARPACK had been temporarily removed, between r:5154 and
>> r:5527,   which it looks like was just when 0.7.0 was branched.
>>
>> I think I added the import in 5527 just to restore the previous state.
>> I don't think this was an intended change in behavior.
>>
> This removal in r5088 made
>     import scipy.sparse.linalg.eigen.arpack as arpack
> work, by accident. This was just before the 0.7.x branch was made, so there
> it worked. The issue is that arpack.py contains a function called eigen, and
> in eigen/__init__.py there is a line
>     from arpack import *
> and then the function gets added to eigen.__all__, which then in turn is
> imported from one level up.
>
> This looks like a bad idea, so either the module of the function should be
> renamed. Or the functions in eigen.__all__ should not be made available in
> the sparse.linalg namespace. But I'd prefer renaming.

I also think renaming would be the best solution, renaming the module
wouldn't break the current code (the damage with 0.7 is already done)

ode is (or was) another case where the class/function shadows the
module name. The previous reply was that ode should be rewritten. But
since it doesn't look like that is happening soon, a renaming of the
shadowed module might a better short tem solution.  (this is from
memory, I haven't checked recent changes to ode)

Josef

>
> Cheers,
> Ralf
>
>
>
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>
>