[SciPy-dev] Technology Previews and Sphinx Docstring Annotations
Tue Nov 4 11:51:26 CST 2008
Jarrod Millman wrote:
> At this point, it sounds like there is very little interest in
> pursuing an idea like scipy.preview. So unless I find that when I
> return in a week that there has been more interest I will drop it.
> Hopefully, the discussion to improve scikits will continue. I look
> forward to seeing it improve. If anyone is interested in editing the
> technology preview proposal, please feel free it is checked into the
> scipy trunk. However, I ask that if you wish to propose improvements
> to scikits that you start a second sep.
For what it's worth, I'm +1 on the idea of a scipy.preview. I
understand the desire to not make scipy more experimental and confusing
for users, and certainly understand David's point to not make building
Scipy any more of a burden than it already is. However, I think a
scipy.preview *uniquely* addresses the recent concern of API stability.
I'm sorry, but growing up as a scikit will only get a set of
functionality so much exposure. Sure for a relatively complete package,
a core group of users will be sure to install it. However, there is a
group of casual users that will not install anything beyond scipy+numpy.
And it is these users that usually find the roughest edges of the API;
the parts that are intuitive to someone deep into the algorithms but are
confusing to someone just starting out or wanting to test something. I
simply don't think any amount of "cooking" as a scikit will iron out all
API issues. So once code then gets incorporated into scipy and
released, API issues *will* crop up. It would be nice to have a place
to put things so that they get a wide release *and* can still change
API, rather than having a single shot to get it right.
Graduate Research Assistant
School of Meteorology
University of Oklahoma
More information about the Scipy-dev