[pypy-dev] pypy with sympy
Carl Friedrich Bolz
cfbolz at gmx.de
Sun Sep 16 01:30:42 CEST 2007
> I have many ideas:
> 1) Make predictable releases, get pypy into distributions, fix bugs
> and just make it another Python interpreter.
That one is a bit boring, don't you think? :-) No seriously, we can't
really compete with CPython on its home turf, we need additional
features that set us apart.
> 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.
Yes, that's correct. We are working on this, actually. Especially Java
is interesting, I guess, since Jython is still behind CPython. Competing
with IronPython won't be so easy.
> 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.
This, too, is definitely part of PyPy's agenda. We plan to work on this
not even too far into the future, I would think.
> 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.
In my opinion this is way outside what the current team of people
actively working on PyPy can manage. We would need outside people that
are ready to work on this.
> 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
Right now we have a GIL as well, since it was easiest to implement. It's
too early to think about removing the GIL, since we would need a better
thread-aware garbage collector first – Boehm is just not up to the task.
> 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.
Not sure whether it is as efficient as by hand, but such a translation
is obviously possible.
> This is connected to 4).
I disagree with this. The JIT techniques that PyPy uses are very
different from its RPython translators.
> 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.
I guess so, yes. Although right now our Python interpreter is not
exactly lightweight, so running on very small machines is not going to
be reasonable without quite some additional work.
More information about the Pypy-dev