I agree with David's comments. In that theme I have removed scipy.stsci from scipy. Users get it directly from us at STScI via STSCI_PYTHON. It doesn't have any documentation in the doc system. It isn't by default in the scipy namespace. And as a recent bug report indicates they can't import it anyway.
That should clean some code up. If someday a generic image processing library is added to scipy we can consider incorporating our modules back into scipy. Until that time I would rather remove the redundancy. It also help scipy's maintainability and frees me from having to worry about a fork in the code developing. Cheers, Chris -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 On Aug 20, 2009, at 3:04 PM, David Cournapeau wrote: > On Thu, Aug 20, 2009 at 10:32 AM, Christopher > Hanley<chan...@stsci.edu> wrote: > > I agree those are not strong reasons without more backing. What > worries me the most, in both numpy and scipy, is code that nobody > knows about, without any test or documentation. When it breaks, we > can't fix it. That's unsustainable in the long term, because it takes > a lot of time that people could spend somewhere else more useful. > Especially when you have C code which does not work on some platforms, > with new version of python (python 3k port, for example). > > I much prefer removing code to having code that barely works and > cannot be maintained. Old code that people are ready to maintain, I > have nothing against. > > cheers, > > David > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion