Hi Amaury, On 13 June 2015 at 10:20, Amaury Forgeot d'Arc <amaur...@gmail.com> wrote: > But cffi extension modules are not real modules, right? > When compiled for PyPy, the init function has a different name, and fills a > C struct that cannot be considered as a Python module. > > They can be imported only because there is special support in the import > framework. > > In this case, why not have a completely different extension or SOABI? > Like _sqlite.cffi1.0.so
They are "real" modules in the sense that the .c file is exactly the same as for CPython, and they are compiled with the same unmodifed distutils. They are not "real" only in the sense that there are some "#ifdef PYPY_VERSION" which end up not making use of any of the Python.h functions and exporting a differently-named init function. That's why, so far, I didn't bother trying to convince distutils that it should give different extensions for CPython C extension modules and for CFFI modules. We could try to call them _sqlite.cffi1.0.so, or even have .so's compiled for CPython 2.7 be directly importable under PyPy2 (by always exporting both variants of the init function). This requires hacks to distutils which I'm not comfortable with. At least the current solution has one standard SOABI, namely ".pypy-26.so", rather than trying to export two of them and confuse the other tools that depend on distutils (setuptools, pip...). A bientôt, Armin. _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
