Michael Foord, 18.10.2011 11:44:
> On 17 October 2011 18:20, David Cournapeau wrote:
> On Mon, Oct 17, 2011 at 2:22 PM, Michael Foord wrote:
>>> 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.
>>>> The net negative would be the community split, with numpy losing some
>> resources taken by numpy on pypy. This seems like a plausible
>> situation.
>> Note that this is *exactly* the same "negative" that Python itself faces
> with multiple implementations. It has in fact been a great positive,
> widening the community and improving Python (and yes sometimes improving it
> by pointing out its problems).
I think both of you are talking about two different scenarios here.
One situation is where PyPy gains a NumPy compatible implementation (based
on NumPy or not) and most code that runs on NumPy today can run on either
CPython's NumPy or PyPy's NumPy. That may lead to the gains that you are
talking about, because users can freely choose what suits their needs best,
without getting into dependency hell. It may also eventually lead to
changes in CPython's NumPy to adapt to requirements or improvements in
PyPy's. Both could learn from each other and win.
The other situation is where PyPy does its own thing and supports some
NumPy code that happens to run faster than in CPython, while other code
does not work at all, with the possibility to replace it in a PyPy specific
way. That would mean that some people would write code for one platform
that won't run on the other, and vice-versa, although it actually deals
with the same kind of data. This strategy is sometimes referred to as
"embrace, extend and extinguish". It would not be an improvement, not for
CPython, likely not for PyPy either, and certainly not for the scientific
Python community as a whole.
Stefan