[pypy-dev] Questions on the pypy+numpy project

[Michael Foord]

On 17 October 2011 16:42, Ian Ozsvald <ian at ianozsvald.com> wrote:

> > 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.
>
> Michael - I agree that the PyPy community shouldn't do all the
> legwork! I agree also that the proposed path may spur more work (and
> maybe that's the best goal for now).
>
> I've gone back to the donations page:
> http://pypy.org/numpydonate.html
> to re-read the spec. What I get now (but didn't get before the
> discussion at Enthought Cambridge) is that "we don't plan to implement
> NumPy's C API" is a big deal (and not taking it on is  entirely
> reasonable for this project!).
>
> In my mind (and maybe in the mind of some others who use scipy?) a
> base pypy+numpy project would easily open the door to matplotlib and
> all the other scipy goodies, it looks now like that isn't the case.
> Hence my questions to try to understand what else might be involved.
>
>
Well, I think it definitely "opens the door" - certainly a lot more than not
doing the work! You have to start somewhere.

It seems like other projects (like the pypy cython backend) will help make
other parts of project easier down the line.

Back to Alex's question, how else would you *suggest* starting? Isn't a core
port of the central parts the obvious way to begin?

Given the architecture of numpy it does seem that it opens up a whole bunch
of questions around numpy on multiple implementations. Certainly pypy should
be involved in the discussion here, but I don't think it is up to pypy to
find (or implement) the answers...

All the best,

Michael





> i.
>
> > 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!
> >
> >
> > 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,
> >
> > Michael Foord
> >
> >>
> >> Alex
> >>
> >> --
> >> "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
> >> http://mail.python.org/mailman/listinfo/pypy-dev
> >>
> >
> >
> >
> > --
> >
> > http://www.voidspace.org.uk/
> >
> > 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
> >
>
>
>
> --
> Ian Ozsvald (A.I. researcher)
> ian at IanOzsvald.com
>
> http://IanOzsvald.com
> http://MorConsulting.com/
> http://StrongSteam.com/
> http://SocialTiesApp.com/
> http://TheScreencastingHandbook.com
> http://FivePoundApp.com/
> http://twitter.com/IanOzsvald
>



-- 

http://www.voidspace.org.uk/

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...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20111017/3335fcbd/attachment.html>