[SciPy-User] Contributing to SciPy was Re: Least-squares fittings with bounds: why is scipy not up to the task?

josef.pktd@gmai... josef.pktd@gmai...
Sat Mar 10 12:16:09 CST 2012

I would like to extend the discussion a bit.
(I thought of dropping the half finished message and go back to my
corner but I think this might still be useful.)

On Fri, Mar 9, 2012 at 1:47 PM, Pauli Virtanen <pav@iki.fi> wrote:
> Hi,
> 09.03.2012 17:51, william ratcliff kirjoitti:
> [clip]
>> In this particular case, what are the exact steps needed to get it into
>> scipy?  Can they charge be listed as tickets somewhere so that others of
>> us can help?  Can we document the process to make it easier the next
>> time?  I realize everyone is busy, but if the barrier to contribution is
>> lowered it will make life better in the long run.
> In general, basically two ways for contributions:
> 1. A pull request via Github. We have a writeup here with various tips:
>   http://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html
>   Just replace "Numpy" by "Scipy" everywhere.
> 2. File a ticket in the Trac: http://projects.scipy.org/scipy/
>   Attach whetever you have (a patch, separate files) to the ticket,
>   and tag it as "enhancement" and "needs_review".
> That's about it.
>    ***
> However, to make it easier for someone to look at the work and verify it
> works properly:
> - Ensure your code is accompanied by tests that demonstrate it actually
>  works as intended. You can look for examples how to write them in the
>  Scipy source tree, in files named test_XXX.py
> - Ensure the behavior of the public functions is documented in the
>  docstrings.
> - Prefer the Github way. Granted, there *is* a learning curve, but it
>  saves work in the long run, and it is far less clunky to use.
> - The more finished the contribution is, the less work it is to merge,
>  and gets in faster.
> If you get no response, shout on the scipy-devel mailing list. If
> there's still no response, shout louder and start accusing people ;)
> If the contribution is "controversial" --- duplicates existing
> functionality, breaks backwards compatibility, is very specialized for a
> particular research problem, relies on magic, etc. --- it's good to give
> an argument why the stuff should be included, as otherwise the
> motivation may be missed.

Code that is not ready for Prime Time

Stata has a large library of user contributed code
matlab has the file exchange
several other statistical packages have user contributed code
collections in forums

SciPy has mailing lists, pull requests, gists, tickets and
scipy-central and open source and pypi

Pull request on github are very convenient for code that changes,
improves, fixes, existing code, or code that can be included after
some work.
For new functions or modules intended for library code, I find them
easier to try out when they are standalone.

One of the bottlenecks in including code in established packages is
the time it takes to review, refactor and test code that isn't quite
right or doesn't quite fit.

I think it would be useful to have a central location for publishing
code and get earlier feedback from users. (Currently I bookmark, for
example,  gists or modules in a random package, that look interesting
and I might not find again when I need them in future.)

I'm still envious of the matlab fileexchange with a very useful
commenting system where I look more often than at scipy-central, and I
like the commenting system on stackoverflow that gives a much faster
way of evaluating several ways of doing things.

I also think Mathworks and Statacorp are very smart in supporting user
code, since (I assume) that they look at the download statistic to see
what is in high demand and might incorporate code if it's license

A community supported scipy-central !?



> Cheers,
> Pauli
> _______________________________________________
> SciPy-User mailing list
> SciPy-User@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user

More information about the SciPy-User mailing list