[SciPy-dev] Technology Previews and Sphinx Docstring Annotations

Ryan May rmay31@gmail....
Tue Nov 4 11:51:26 CST 2008


Jarrod Millman wrote:
<SNIP>
> 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.

My $0.02.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma


More information about the Scipy-dev mailing list