For future reference (since I've given up for now):
- Checkout PyGObject git (I've tested 3.4/3.8, 3.4 has lower glib/gir
dependencies if that's a problem)
- Apply the following patches to make autotools work with PyPy:
- Apply the attached patch that works around some limitations in cpyext.
- Run the following to build against PyPy (a nightly build for example):
- To run the tests:
SKIP_PEP8=1 make check.gdb (since it segfaults and pep8 tests are slow)
The first segfault is because
baseclass.tp_new(subclass, ...) # baseclass != subclass
doesn't seem to work.
The PyGObject patches are all upstream now.
The attached patch is still needed.
Do you have a gdb traceback?
Also, last time I checked it was because pygobject_register_constants() uses a
type that is not yew PyType_Ready().
I modified gobjectmodule.c and moved the call to pygobject_type_register_types()
AFAIR tp_new returned a NULL pointer and it didn't crash in cpyext itself.
Could you attach a gdb traceback?
As I said, there is no crash in pypy itself, but in pygobject, because tp_new
returned an unexpected result.
Am I missing something?
Also, I won't spend time on this atm.. just wanted to make it easy for someone
else to pick up where I left off.
A call to tp_new will return NULL in case of a Python exception.
In this case the calling code should handle the error, and probably return
Where is this call to tp_new?
tp_new call: https://git.gnome.org/browse/pygobject/tree/gi/_gobject/pygenum.c#n39
Ah, ok, thanks. The exception is: "type object 'PyGLibUserDirectory' has no
attribute '__enum_values__'".. probably from pyg_enum_new below.
Could it be that PyInt_Type.tp_new(int_subclass) calls new of the subclass
instead of the PyInt one?
.. I'm not that familiar with the Python C API.
I came to the same conclusion. This is an old issue with our C API layer: there is only one
emulation of tp_new for all types provided by PyPy, and it does something like
The solution is to have a distinct tp_new for each type, which makes sense if you think about it.
Here is a tentative patch; it's not finished: more tests are needed, and we should migrate all
slots emulation in this manner; but I fear that the (translated) code size explodes...
+1 for pygobject.
In pygobject master all the above issues are solved now, but it fails shortly after :)
pygobject now uses distutils, pytest and pycairo has full PyPy support.
We use namespace packages (in an invalid way, because __init__.py is not empty and thus things depend on the import order) and while CPython only imports the first __ini__.py, PyPy imports both and then gets confused it seems. I'll look into that later.
the test suite runs now: 51 failed, 1229 passed, 15 skipped, 13 xfailed