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<chanley@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