[SciPy-dev] SciPy Foundation
Tue Aug 4 03:00:26 CDT 2009
2 cents from an outsider who thought about contributing to
scipy/scikits (but didn't (yet)):
I think it is a good idea to make scipy easy to use for beginners.
However, after reading this thread, I have the impression that it is
not the goal to provide state of the art algorithms but rather making
Scipy as popular as possible by putting money and effort into the
"marketing" of Scipy.
Don't get me wrong, I think there are some good reasons why a project
should thrive for a large user base. Some of the best projects are
Alas, correlation does not imply causality.
Me for instance, would rather like to see more efforts to get state of
the art algorithms to be implemented in Scipy because that's something
that would make a real difference in my research work. Of course,
targeting the "clueless Matlab" users is quite pointless if it is that
what you are after.
IMHO the way to go is to convince experts to implement their research
prototypes as part of scipy.
Then you really get some "killer applications". I could name a few
people who are coding some cool state of the art algorithms but waste
so much time because they started coding directly in C++. In the
meantime, they could have implemented the algorithms in Python _and_
in C++. If scipy had something really good that Matlab etc. do not
have: guess what ppl would do....
What would you need to get experts contribute to scipy instead of
hacking their prototype in Matlab or C++?
I can't speak for everyone, so I'll just say what I think (and feel):
I would instantly start "contributing research prototypes" to scipy if
1) an easy, modular and flexible build system (fortran, c, c++, D,
swig, boost:python, cython,...)
2) very low entry barrier for possible contributors:
a simple checkout, then ./manage.py startapp mycoolmodule
and everything is ready to go ( "Start coding in 5 minutes!")
3) a distributed version control system (e.g. git). SVN really scares me off...
4) standardized unit tests
5) automated documentation generation
Then I could simply
1) fork the master branch
2) ./manage.py startapp mycoolmodule
3) adjust config files that were written in ./scipy/mycoolmodule/config.py
4) start coding
5) share the experimental code with collaborators or interested users
who are not afraid to use experimental code
6) eventually, when the project has matured, hope that it gets
included in the master branch
hope that made sense,
On Mon, Aug 3, 2009 at 11:54 PM, Ondrej Certik<firstname.lastname@example.org> wrote:
> On Mon, Aug 3, 2009 at 3:36 PM, Gael
> Varoquaux<email@example.com> wrote:
>> On Mon, Aug 03, 2009 at 03:32:31PM -0600, Ondrej Certik wrote:
>>> On Sat, Aug 1, 2009 at 4:52 PM, Gael
>>> Varoquaux<firstname.lastname@example.org> wrote:
>>> > For a web environment, the Sage notebook is amazing. Unfortunately last
>>> > time I looked, it was GPL licensed, which renders it improper for my use,
>>> > as the tools we use at the lab must be BSD, in order to be able to build
>>> > (eventually) medical imaging products from them one day.
>>> Actually, in this thread:
>>> most (if not all) contributors to the Sage notebook agreed to release
>>> their code as BSD.
>>> The same about William being positive to license the build system as
>>> BSD too. So we can get lots of done by working on these things
>>> together with Sage.
>> I can see that a lot of good things are coming out of Sage (the current
>> Cython development frenzy was clearly helped by the needs of Sage). It is
>> really nice to see our community (I am talking in the sens of a
>> scientific Python community, agnostic of tools and distribution) growing.
>> Cheers to these guys, that notebook is really amazing!
> Yep. And Cython is BSD like (resp Apache) license too, so I think that
> for these basic tools that everyone needs (cython/notebook/build
> infrustructure) Sage is not against BSD at all.
> Scipy-dev mailing list
More information about the Scipy-dev