[SciPy-dev] License review / weave bsd-ification
Mon Nov 3 10:16:03 CST 2008
Looking at the bug output of the tests of weave, the unknown bugs are in the
support for wxwidgets types.
If nobody supports that code (the error is there since 2004 ? (
http://mlblog.osdir.com/python.scientific.devel/2004-04/index.shtml )) then
why not remove support for those types?
I don't see the use of wxwidget string type and such support.The core python
and numpy types are supported, so conversion to that is possible in python.
2008/11/3 Travis E. Oliphant <email@example.com>
> Jarrod Millman wrote:
> > On Mon, Nov 3, 2008 at 1:30 AM, Gael Varoquaux
> > <firstname.lastname@example.org> wrote:
> >> +1 on all this. Practicality beats purity. It is going to be pretty hard
> >> to explain to people that they have to install a bunch of different
> >> packages get a full working environment.
> > Well my vote is to move weave out of scipy (and has been for some
> > time), but it seems like there is some interest in keeping it as part
> > of scipy. I am not going to have anymore time to work on weave for
> > the next week. But I am opposed to releasing another version of scipy
> > with GPL code; so this needs to be fixed or removed before the 0.7
> > release. I also want to have all tests passing before we release 0.7,
> > which means that all the weave tests need to pass as well.
> > If you feel strongly about keeping weave in scipy, now would be a good
> > time to step up and get weave in shape for the 0.7 release.
> It's only the blitz portion of weave that has "GPLish" features. These
> can be disabled or moved to a scikit with no difficulty. Or, they could
> be moved back to an older version of blitz (I recall that an upgrade to
> the blitz code is what changed the license. I'm pretty sure that Eric
> did not put GPL code into weave to begin with).
> The original idea was to move weave into numpy not out into a scikit.
> So, I'm very much against moving weave outside. If weave were to move
> outside then I would support it if it were to move it into a weave /
> f2py / pypy hybrid package called "compile" or something like that ---
> where C-code, Fortran-code, and RPython code could be compiled into fast
> loops, dynamically loaded, and integrated into NumPy (in the spirit of
> Ilan's fast_vectorize).
> > It looks like the license issue can be resolved. Newer versions of
> > the Mersenne Twister random number generator have a more liberal
> > license:
> > Is anyone willing to volunteer to get the newer version working? Is
> > it worth considering moving this code out of weave and making the MT
> > RNG more generally available?
> Isn't NumPy's random number generator the MT algorithm?
> Scipy-dev mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Scipy-dev