

PyPy funded to begin support for Python 3 and Numpy - synparb
http://morepypy.blogspot.com/2012/01/py3k-and-numpy-first-stage-thanks-to.html

======
EdM
This post made me think of this article:
[http://technicaldiscovery.blogspot.com/2011/10/thoughts-
on-p...](http://technicaldiscovery.blogspot.com/2011/10/thoughts-on-porting-
numpy-to-pypy.html)

For those who don't know, Travis Oliphant is the creator of NumPy and(?)
SciPy.

It's a good read and it puts some of the issues with a port into perspective.

~~~
fijal
Hey.

While I generally grossly disagree with Travis in regard to how far PyPy can
go I wonder what kind of perspective are you talking about?

~~~
teoliphant
Fijal, I'm not sure you even understand my perspective. None of your comments
in response have given me confidence that you do. I have no disagreement with
you about how far "PyPy could go". Obviously, we could re-create the entire
Python ecosystem including the scientific stack under its run-time. I just
question your understanding of how expensive and time-consuming that would be.
My official position is that I think it's possible to get the benefits of PyPy
(i.e. fast Python loops) in different ways that don't also toss out years of
extension modules in the process and whose answer to current users about the
features they rely on in CPython not working under PyPy is "just port it" or
"just use ctypes".

~~~
synparb
From having read the various replies to this and similar threads, I think a
basic problem (as Travis pointed out) is that Fijal has been (1) highly
dismissive of numpy and particularly cython, which a lot of really smart
people have put a lot of time and effort into and created an amazing
scientific community within python, and (2) confrontational with people who
are trying to lend an alternative opinion which has been informed by a lot of
experience in the scientific python world. PyPy might eventually be a wholly
superior alternative for scientific computing with Python, but it would be
good to acknowledge the insight of those who are 'in the trenches' even if you
go a different route, because part of the success of scientific python has
been the community.

I know very little about the development aspect of PyPy or Numpy, but I know
that at this moment in time Numpy/Scipy/Cython have revolutionized how I do
research on a day to day basis. It seems unfortunate that there seems to be
such animosity surrounding this issue.

~~~
wesm
My thoughts exactly.

------
ColdAsIce
I like pypy and its ambitions, last time I tested it, about a month ago it was
very speedy and startup time considerable faster than Cpython. However the
regex exercises I wanted to do couldnt be done. Pypy seemingly didnt have a
good regexp engine. If I remember correctly, something with groups and
backwards-reference...

Has that changed?

~~~
bitcracker
The fundamental question is: How compatible will PyPy ever be? Which kind of
applications can be run with PyPy?

<http://pypy.org/compat.html> mentions compatiblity according to the standard
library. This is fine for (web) servers and command line applications.

But what about desktop applications? Can I (someday) take a PyQt or PyGTK code
and compile it with PyPy without modifications?

~~~
dripton
Maybe.

cpyext is a hack to let PyPy run Python/C API modules. It works for some, but
not all, and it's slow. I'm sure it'll keep getting better, but not sure if
it'll ever be good enough to run PyGTK or PyQt.

PyPy has good support for ctypes, so ctypes bindings are a good option. There
are projects out there like pygir-ctypes and ctypes-gtk. One of them just
needs to become complete enough to be a good choice for GTK programming.
Compatibility with new PyGObject is more likely than compatibility with legacy
PyGTK, though.

PyQt is harder because it's C++.

