[SciPy-dev] Technology Previews and Sphinx Docstring Annotations

[Bruce Southey]

Ryan May wrote:
> 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
>
>   
+1 on this as I have experienced the problems with Scikits.

I would note that Python provides the __future__ module 
(http://www.python.org/doc/2.5.2/lib/module-future.html) that provides a 
somewhat similar goal.

Bruce