[SciPy-dev] Package organization

Fernando Perez Fernando.Perez at colorado.edu
Fri Oct 14 17:13:40 CDT 2005


Travis Oliphant wrote:
> I really like the discussion that is occurring.  Part of the problem 
> with the current system is that there was no discussion and so it just 
> evolved.   I'm not against major surgery on the organization as long as 
> there is some mechanism for helping old users move forward.   That's why 
> scipy has not reached 1.0 yet -- because of code organization issues.
> 
> First.   I like what Fernando is trying to do with the scipy.kits 
> concept.   The most valuable thing scipy could provide is a mechanism 
> for auto-indexing your scipy-related packages for a help browser.  I 
> don't think packages would need to live under scipy to accomplish this 
> (but it would make it easier).   There are other mechanism like the 
> environment variable concept that could also collect package 
> information.  In fact, I wonder if scipy could detect that some module 
> imported it and add that to some internal index (or only add it if the 
> module defined some __scipy__  name or something...

There is no way that I can think of, for scipy to know who has imported it. 
This is mainly because on _second_ import, python will fully short-circuit the 
'import scipy' call out from sys.modules, so regardless of how many nasty 
stack tricks you want to play inside scipy.__init__, they'll only work for the 
first import.

You could define a scipy.register_kit(...) function, which modules who want to 
register themselves can call in their __init__ file.  I can see this being 
useful for certain things, but it still won't solve the problem of

import scipy
scipy.kits?

or

help(scipy.kits)

or

scipy.kits<TAB>

etc. (docs generation, graphical browsers...)

For that, there has to be some mechanism to tell scipy itself to look for 
toolkits, regardless of whether they have been imported yet or not.  Obviously 
things which have been installed directly in the scipy/kits/ directory on the 
filesystem can be trivially found, but this still doesn't address the issue of 
allowing users to maintain local collections of toolkits beyond the boundaries 
of write-only (or root-only) filesystems.

There are two reasonably clean and well-accepted ways to do this:

1. An environment variable for a scipy search path

2. A ~/.scipyrc file, with a suitable definition of ~ for Win32.

Since scipy is a library and not an end-user standalone program, I personally 
tend to dislike #2, though it is technically just as feasible as #1 (and 
offers room for future tweaks).

Cheers,

f




More information about the Scipy-dev mailing list