[pypy-dev] Questions on the pypy+numpy project
fuzzyman at gmail.com
Mon Oct 17 15:22:22 CEST 2011
On 17 October 2011 13:35, Alex Gaynor <alex.gaynor at gmail.com> wrote:
> On Mon, Oct 17, 2011 at 8:29 AM, Ian Ozsvald <ian at ianozsvald.com> wrote:
>> > This would be very useful since
>> > you don't need to use Cython or any other things like this to provide
>> > working code and it already caters for some group of people.
>> Hi Fijal. This would be useful for a demo - but will it be useful for
>> the userbase that becomes motivated to integrate Cython and SciPy?
>> If it isn't useful to the wider community (which is the point I've
>> made after David's email) then aren't we creating a (potentially)
>> dead-end project rather than one that opens the doors to increased
>> collaboration between the communities?
>> Perhaps I should ask a wider question: If the pypy-numpy project only
>> supports the core features of numpy and not the API (so excluding
>> Cython/SciPy etc for now), what's the roadmap that lets people
>> integrate SciPy's C/Fortran code in a maintainable way? I.e. how is
>> the door opened to community members to introduce SciPy compatibility?
>> Some idea of the complexity of the task would be very useful,
>> preferably with input from people involved with CPython's numpy/scipy
>> Ian Ozsvald (A.I. researcher)
>> ian at IanOzsvald.com
>> pypy-dev mailing list
>> pypy-dev at python.org
> Let me ask the opposite question: What route do you envision that gives us
> both the speed we (and everyone else) desires, while not having any of these
> issues? That's not a question that has a very good answer I think. We
> could bring CPyExt up to a point where NumPy's C code runs, but that would
> be slow and a royal pain in the ass. What's the other alternative? We
> could port all of NumPy to be pure Python + wrapping code only for existing
> C/Fortran libraries. To be honest, that sounds very swell to me, would the
> core-numpy people go for that? Of course not, because it would be heinously
> slow on CPython, which I presume is unacceptable. So where does that leave
> us? Neither of the current platforms seems acceptable, what's the way
> forward where we're all in this together, because I'm having trouble seeing
> that (especially if, as Travis's post indicates backwards compatibility
> within NumPy means that none of the C APIs can be removed).
Travis' post seems to suggest that it is the responsibility of the *pypy*
dev team to do the work necessary to integrate the numpy refactor (initially
sponsored by Microsoft). That refactoring (smaller numpy core) seems like a
great way forward for numpy - particularly if *it* wants to play well with
multiple implementations, but it is unreasonable to expect the pypy team to
pick that up!
For pypy I can't see any better approach than the way they have taken. Once
people are using numpy on pypy the limitations and missing parts will become
clear, and not only will the way forward be more obvious but there will be
more people involved to do the work.
It seems odd to argue that extending numpy to pypy will be a net negative
for the community! Sure there are some difficulties involved, just as there
are difficulties with having multiple implementations in the first place,
but the benefits are much greater.
All the best,
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> pypy-dev mailing list
> pypy-dev at python.org
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pypy-dev