[pypy-dev] pypy with sympy

[Ondrej Certik]

Hi Carl,

> Ondrej Certik wrote:
>  > since pypy is in Debian for some time, I sometimes test it with our
>  > project SymPy[1], written in pure Python 2.4 and newer. Generally, it
>  > works out of the box and it's very nice and quite fast. You did an
>  > awesome job!
>
> Thanks for doing that! It's nice to hear that it's mostly working.
> Indeed at one point we could probably consider to use SymPy as some sort
> of benchmark for PyPy – it's not easy to find nice pure-Python programs
> that are computationally bound.

We are actually optimizing sympy to by fast on top of a normal
CPython, for example instantiating python classes is very expensive.
But I guess it should be very similar in pypy as well.

There is another problem actually:

$ py.test --exec=pypy
* opening PopenGateway:  /usr/bin/pypy
MASTER: initiated slave terminal session ->
MASTER: send start info, topdir=/home/ondra/sympy
Traceback (most recent call last):
  File "?", line 32, in run_toplevel
  File "?", line 265, in run_it
  File "<string>", line 1, in <module>
  File "<string>", line 40, in <module>
ImportError: No module named thread
Traceback (most recent call last):
  File "/usr/bin/py.test", line 4, in ?
    py.test.cmdline.main()
  File "/usr/lib/python2.4/site-packages/py/test/cmdline.py", line 15, in main
    failures = session.main()
  File "/usr/lib/python2.4/site-packages/py/test/terminal/remote.py",
line 82, in main
    failures = self.run_remote_session(failures)
  File "/usr/lib/python2.4/site-packages/py/test/terminal/remote.py",
line 111, in run_remote_session
    return channel.receive()
  File "/usr/lib/python2.4/site-packages/py/execnet/channel.py", line
175, in receive
    raise self._getremoteerror() or EOFError()
EOFError

There is not module thread in there. So I cannot test the whole sympy
using pypy, because we have all our tests made using py.test. Feel
free to put this into the issues.

> Thanks for reporting it. Our problem with it is that we don't quite know
> how to fix it properly. Potentially, int_w itself should be calling
> __int__, but we are not sure whether this is good for all use-cases of
> int_w.

Right, but do you agree, that this should be working in python 2.4? So
there must be some way to do it.

> I think the PyPy team cannot put much more effort into this than what we
> did already. So we would need somebody interested who would work mostly
> exclusively on the JavaScript backend to make it live up to its full
> potential.

So what is your priority now with pypy? I think it has such an
enormous potential, but currently for me it's just a playground. Do
you plan to apply pypy in some area, where people will use it as the
best technology available in there? Or do you plan more to have pypy
just as a means of testing new JIT ideas?

Ondrej