On Wed, Oct 19, 2011 at 6:47 PM, Leonardo Santagada wrote:
>
> Why not move more of scipy to cython/ctypes? That is what you guys
> want for the future, and then it would not make anyone have to work on
> something they have no interest in.
Independently of pypy's direction w.r.t. numpy, this wi
On Wed, Oct 19, 2011 at 3:36 PM, Peter Cock wrote:
> On Wed, Oct 19, 2011 at 6:25 PM, Maciej Fijalkowski wrote:
>> On Wed, Oct 19, 2011 at 4:49 PM, Gary Robinson wrote:
>>> I wonder if it would be worthwhile to have another poll, this time
>>> clearly differentiating between
>>>
>>> a) focusing
On Wed, Oct 19, 2011 at 10:38 -0400, Gary Robinson wrote:
> > By the way, did you ever considered the possibility of running pypy and
> > cpython side-by-side?
> > You do your pure-python computation on pypy, then you pipe them (e.g. by
> > using execnet) to a cpython process which does the proce
On Wed, Oct 19, 2011 at 6:25 PM, Maciej Fijalkowski wrote:
> On Wed, Oct 19, 2011 at 4:49 PM, Gary Robinson wrote:
>> I wonder if it would be worthwhile to have another poll, this time
>> clearly differentiating between
>>
>> a) focusing on integrating the existing numpy in such a way that
>> sci
On Wed, Oct 19, 2011 at 4:49 PM, Gary Robinson wrote:
> I wonder if it would be worthwhile to have another poll, this time clearly
> differentiating between
>
> a) focusing on integrating the existing numpy in such a way that scipy and
> other such packages are also enabled, probably using the e
I wonder if it would be worthwhile to have another poll, this time clearly
differentiating between
a) focusing on integrating the existing numpy in such a way that scipy and
other such packages are also enabled, probably using the existing project to
provide a C interface that IronPython and ot
>
> I think the original topic of this discussion is numpy, not scipy.
> The answer is that I don't know. I am sure that people will
> reimplement whatever module is needed, or design a generic but slower
> way to interface with C a la cpyext, or write a different C API, or
> rely on Cython versio
On 10/19/2011 8:32 AM, Wes McKinney wrote:
On Wed, Oct 19, 2011 at 6:35 AM, Gary Robinson wrote:
Jacob Hall?n, 18.10.2011 18:41:
I'd just like to note that the compelling reason for PyPy to develop numpy
support is popular demand. We did a survey last spring, in which an
overwhelming number of
>> You would like pypy+numpy+scipy so that you could write fast
>> python-only algorithms and still use the existing libraries. I
>> suppose this is a perfectly reasonable usecase, and indeed
>> the current plan does not focus on this.
>
Yes. That is exactly what I want.
> However, I'd like to
> By the way, did you ever considered the possibility of running pypy and
> cpython side-by-side?
> You do your pure-python computation on pypy, then you pipe them (e.g. by
> using execnet) to a cpython process which does the processing using scipy.
> Depending on how big the data is, the overhe
Hello Gary,
On 19/10/11 15:38, Gary Robinson wrote:
You would like pypy+numpy+scipy so that you could write fast
python-only algorithms and still use the existing libraries. I
suppose this is a perfectly reasonable usecase, and indeed
the current plan does not focus on this.
Yes. That is ex
On 10/19/2011 02:38 PM Armin Rigo wrote:
Hi Bengt,
PyPy is indeed supporting multiple _existing_ languages (with SWI
Prolog being the 2nd quasi-complete language right now). However,
most of us are not interested in exploratory language design, say in
the form of syntax tweaks to Python.
You a
On Wed, Oct 19, 2011 at 6:35 AM, Gary Robinson wrote:
>> Jacob Hall?n, 18.10.2011 18:41:
>>> I'd just like to note that the compelling reason for PyPy to develop numpy
>>> support is popular demand. We did a survey last spring, in which an
>>> overwhelming number of people asked for numpy support.
Hi Bengt,
PyPy is indeed supporting multiple _existing_ languages (with SWI
Prolog being the 2nd quasi-complete language right now). However,
most of us are not interested in exploratory language design, say in
the form of syntax tweaks to Python.
You are welcome to fork PyPy's bitbucket reposit
On Wed, Oct 19, 2011 at 12:57 PM, Antonio Cuni wrote:
> On 19/10/11 13:42, Antonio Cuni wrote:
>
>> I'm not sure to interpret your sentence correctly.
>> Are you saying that you would still want a pypy+numpy+scipy,
>> even if it ran things slower than CPython? May I ask why?
>
> ah sorry, I think
Hi there
Maciej Fijalkowski skrev 2011-10-17 10:30:
On Mon, Oct 17, 2011 at 10:17 AM, Alex Pyattaev wrote:
I have a fully-functional wireless network simulation tool written in
pypy+swig. Is that nice? Have couple papers to refer to as well. If you want I
could write a small abstract on how it
On 19/10/11 13:42, Antonio Cuni wrote:
I'm not sure to interpret your sentence correctly.
Are you saying that you would still want a pypy+numpy+scipy, even if it ran
things slower than CPython? May I ask why?
ah sorry, I think I misunderstood your email.
You would like pypy+numpy+scipy so tha
On 10/18/2011 02:41 PM Armin Rigo wrote:
Hi,
On Tue, Oct 18, 2011 at 14:19, Stefan Behnel wrote:
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
Hi Gary,
On 19/10/11 12:35, Gary Robinson wrote:
So, I have to say, I am unhappy with the current PyPy approach to NumPy. I'd
rather see a much slower NumPy/PyPy integration if that meant being able to use
SciPy seamlessly with PyPy.
I'm not sure to interpret your sentence correctly.
Are you
> Jacob Hall?n, 18.10.2011 18:41:
>> I'd just like to note that the compelling reason for PyPy to develop numpy
>> support is popular demand. We did a survey last spring, in which an
>> overwhelming number of people asked for numpy support. This indicates that
>> there is a large group of people wh
On Tue, Oct 18, 2011 at 8:02 PM, Armin Rigo wrote:
> Hi David,
>
> On Tue, Oct 18, 2011 at 18:29, David Cournapeau wrote:
(...) with the possibility to replace it in a PyPy specific way.
>>>
>>> I think you are disregarding what 8 years of the PyPy project should
>>> have made obvious. (...)
On Tue, Oct 18, 2011 at 1:41 PM, Armin Rigo wrote:
> Hi,
>
> On Tue, Oct 18, 2011 at 14:19, Stefan Behnel wrote:
>> 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 p
Jacob Hallén, 18.10.2011 18:41:
I'd just like to note that the compelling reason for PyPy to develop numpy
support is popular demand. We did a survey last spring, in which an
overwhelming number of people asked for numpy support. This indicates that
there is a large group of people who will be re
23 matches
Mail list logo
