[SciPy-dev] Is scipy.stci an orphan?

[josef.pktd at gmail.com]

On Tue, Jan 6, 2009 at 2:02 PM, Christopher Hanley <chanley at stsci.edu> wrote:
> I don't think it is for us (STScI) to decide if image and convolve
> should be part of scipy.  I will leave that decision to the scipy community.
>
> I will say that image and convolve were once distributed with the
> numarray open source project.  When that project was discontinued there
> was some desire within the community to keep the projects available to
> developers.  Numpy was not an appropriate location given its desire to
> be minimalistic in size and scope.  Scipy was the logical solution at
> the time.  Perhaps that is not the case anymore.
>
> Although we happily accept patches and make our code freely available
> the stsci_python distribution is not as readily modified by external
> developers as a project like scipy.  This is due to our need to support
> a software production environment for the HST and JWST.
>
> So that is some of the history that went into getting image and convolve
> where they are now.  I'll let others way the pros and cons of keeping
> them in scipy and then delete them if desired.
>
> Thanks,
> Chris
>
>
> Cohen-Tanugi Johann wrote:
>> hi there, sorry for my pedestrian question,
>> but if you distribute it in standalone somewhere else anyway, what is
>> the argument to keep it in scipy?
>> :)
>> Johann
>>
>> Christopher Hanley wrote:
>>> josef.pktd at gmail.com wrote:
>>>
>>>> I think the imports are also not correctly exposed.
>>>>
>>>> * convolve and image are not exposed on the stsci module level (no
>>>> __all__ anywhere_) and have to be imported individually. I don't know
>>>> if this is on purpose, but it might confuse the doc generation
>>>>
>>>> * there is a `scipy.stsci.convolve.lineshape` that really looks
>>>> orphaned, import doesn't work and it doesn't seem to be used, but I
>>>> didn't check carefully
>>>>
>>>> * test coverage = 0
>>>>
>>>>
>>>>>>> stsci.convolve
>>>>>>>
>>>> Traceback (most recent call last):
>>>>   File "<pyshell#36>", line 1, in <module>
>>>>     stsci.convolve
>>>> AttributeError: 'module' object has no attribute 'convolve'
>>>>
>>>>>>> from scipy.stsci import convolve
>>>>>>>
>>>>
>>>>>>> import scipy.stsci.convolve.lineshape as lsh
>>>>>>>
>>>> Traceback (most recent call last):
>>>>   File "<pyshell#43>", line 1, in <module>
>>>>     import scipy.stsci.convolve.lineshape as lsh
>>>>   File "\Programs\Python25\Lib\site-packages\scipy\stsci\convolve\lineshape.py",
>>>> line 43, in <module>
>>>>     from convolve._lineshape import *
>>>> ImportError: No module named convolve._lineshape
>>>>
>>>> Josef
>>>> _______________________________________________
>>>> Scipy-dev mailing list
>>>> Scipy-dev at scipy.org
>>>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>>>
>>> OK.  I'll check the imports and see about making the stsci module level
>>> stuff more scipy friendly.
>>>
>>> There are doctests for image and convolve.  I will look into exposing them.
>>>
>>> We normally package these as stand alone modules with our software
>>> distributions.  We haven't yet wanted our users to need to install
>>> scipy.  Obviously we need to make this more scipy friendly as well.
>>>
>>> Chris
>>>
>>>
>>>
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>
> --
> Christopher Hanley
> Senior Systems Software Engineer
> Space Telescope Science Institute
> 3700 San Martin Drive
> Baltimore MD, 21218
> (410) 338-4338
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>


I'm relying more and more on the new windows help files which make
browsing and searching very easy. And when I see modules and functions
in the source that are missing in the docs, I'm getting curious why
they are not exposed to the public.

As a relatively new user of scipy, I'm still trying to find my way
around and the representation of the modules in the docs and exposure
to np.lookfor is useful to find out what is available.

So, all I would like to see is that modules and functions are properly
exposed, so that a "generic" user can find and make use of them.
(Which, of course, makes it also more likely to expose any problems
with the code, as I saw in stats)

Josef