No, not much has changed about our regex engine in the last month. However, our `re` module is fully compatible with CPython's so I'm bit confused, are you saying it didn't run something, or was slow?

Hi, could you give some details about those regexes that you were trying to run? Are you sure these are problems with the PyPy implementation, not with the Python regexp spec itself? I've used grouping and back-references with pypy with no problems so far, so I wonder which case you're talking about.

Yes I am sure it was the pypy implementation since the same regex would do fine on python2.7.

Unfortunately I dont have the regex at hand, just remembering it was something with groups and backtracking.

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?

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++.

I believe that C extensions, which have always been and still are very CPython specific, will have to be replaced with ctypes and possibly Cython versions eventually.

I expect to see quite a lot of improvement in that area as a side effect of the work on numpy.

i have a pure python regexp implementation that you can use in pypy (and it passes almost every test used by the cpython re package - only the LOCALE flag is not supported). however, it's around 100x[1] slower that the re package (on simple matches; it's not backtracking so it can be similar in speed for pathological cases).

also, when i looked at pypy the re implementation was in c and looked so similar to cpython's i assumed it was the same or closely related. but i didn't pay much attention, so i may be mistaken.

[1] roughly. it actually runs 6x faster on recent pypy that cpython.