[pypy-dev] offtopic, ontopic, ...

Stefan Behnel stefan_ml at behnel.de
Tue Feb 14 08:46:56 CET 2012


Antonio Cuni, 14.02.2012 00:04:
> On 02/13/2012 11:26 PM, Stefan Behnel wrote:
>>> >  Last time I looked, Cython still generates code that PyPy cannot handle:
>>> >  for example, it explicitly messes with tstate->curexc_type&co,
>>> >  Couldn't PyErr_Fetch() and PyErr_Restore() be used instead?
>> Just two general comments on this, because these internals are really
>> off-topic for this list and much better suited for the cython-dev list.
>>
>> 1) These things are usually done for two reasons: sometimes for better
>> performance (inlining!), but also because there are cases where CPython
>> fails to match its own Python-level semantics at the C-API level (simply
>> because no-one else but Cython actually needs them there). So we sometimes
>> end up rewriting parts of its C-API in a way that allows us to reimplement
>> the correct Python semantics on top of them.
> 
> what about wrapping these "cython hacks" into some macros (which would be
> defined only when compiling against CPython)?

These things (and I would not commonly use the word 'hacks' for them)
"never" happen in generated code (and if they do, that should be easy to
fix). They only exist in helper functions that we write out into the C
module code, sometimes with template replacements, but most of the time
just as they were written. It wouldn't be hard at all to generate
completely different helper code for a PyPy target, be it by explicitly
selecting a different implementation at code generation time, or by making
their inner workings depend on a C preprocessor flag (which we tend to do
anyway in order to accommodate for C-API changes in CPython).

In fact, we might even start telling our utility code management component
about alternative implementations, and have it select the right one on the
way out, depending on the code target. That would keep the changes to the
actual compiler code at a bare minimum, while giving us a huge level of
flexibility in the implementation.


> This way, they would still
> have the same semantic/performance when compiling for CPython, but that
> would still allow PyPy to implement them.
> 
> Basically, I'm proposing to unoficially extend a bit the C API so that PyPy
> and Cython can meet. I agree that in the long run this is probably not the
> best solution, however it might be interesting in the short run.

I agree that this would be at least a good thing to start with. I have no
idea how to do things like buffer code interfacing or GIL handling yet, but
if any PyPy developers attend PyCon-US this year, Dag and Mark will be the
perfect people to talk to about that.

Stefan



More information about the pypy-dev mailing list