[pypy-dev] pypy with sympy

[Ondrej Certik]

> Then, of course, the problem is that there are so many things that
> could be the 'next step' for PyPy.  Some of us (me for instance) are
> actively looking for paying customers who have a business case for
> wanting PyPy to do X.  Tim Parkin, who designed the current python.org
> site is also interested in working on finding out what should be the
> next step for PyPy.  He is collecting opinions, and people who are
> willing to put money where their mouth is here:
> http://wiki.python.org/moin/PyPyDonations

I'd suggest to put that link on the front page of pypy. And also to
put that question where to go now on the front page.

Compared to your donations, I hope you won't take mine as an offence,
but I am a student.

> It would be nice to get PyPy to such a state that it again had many
> tasks for those people who don't feel up to hacking the Just in Time
> Specialiser.  A better garbage collector is necessary, but I think that
> people find that intimidating as well.  We're much further along with the
> new scheme for working with C extensions, and that too is necessary.
>
> It would be nice to find out exactly who wants what next from PyPy,
> and perhaps more importantly, who would be willing to help on PyPy,
> but cannot now, and what they would need in the way of changes before
> they could contribute.  Besides fixes for the bugs you have reported,
> is there anything in particular you wish we were doing next?

I have many ideas:

1) Make predictable releases, get pypy into distributions, fix bugs
and just make it another Python interpreter.

2) Provide a standard interpreter to: java, .NET and other platforms.
In Jython, they need to code it in Java, by hand I guess. In PyPy, if
I understand it correctly, you just update the interpeter in rpython
and you get all those interpreters and all platforms for free. I guess
this is one of the goals of pypy. So that for example SymPy can be run
on all those platforms.

3) Allow efficient writing of modules in C/Fortran. There is SWIG,
ctypes, f2py, then there are many projects like pyrex, Cython, etc.
It's a mess.  I think pypy has also something to say in this area and
maybe make things more systematic, robust and multiplatform.

4) Myabe allow to speed my code up (JIT), or make Python as fast as
possible. But this is rather a long term goal. Generally, I don't see
why my code written in C and the same code written in Python, not
using much dynamic features, couldn't be the same fast. (Of course I
understand why now it is slower, Python is interpreted, etc. But I
mean in principle. Python can have as much information about my code
as the C compiler.) I use Python for devising new numerical
algorithms, and than I need to rewrite them by hand to fortran for
speed. It's a pain.

5) Google Web Toolkit, but in Python using PyPy. It's a lot of work,
nevertheless it's already possible and that would be a boom to pypy
and python in general, I am pretty sure about that.

6) Allow efficient threading? CPython has the GIL (for good
technological reasons). Generally pypy can improve how to do things in
parallel in python. Currently, one needs to use pympi, pypar, or
something.

7) Using RPython as a compiled languge. Generally, many of my
algorithms are just RPython. If they could be tranlated to C and all
the other backends, the same efficient as I would do by hand, that'd
be just awesome. This is connected to 4).

8) This is very long term thing - the whole pypy machinery should in
principle allow to run Python on basically everything. So knowing
Python could be enough to contribute to a project written in almost
any language.



Anyway, I think pypy either can already do the things above, or has a
very big potential to do so, like a proof of concept.

Ondrej