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

[Stefan Behnel]

Stefan Behnel, 14.02.2012 08:46:
> 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.

Thinking about this some more - as long as we can get away with what the C
preprocessor gives us, it will make it easier for developers to ship the
generated C sources. It has always been Cython's philosophy that Cython
code should be compiled down to C once and then build on as many platforms
as possible without modifications.

Stuffing the code for both CPython and PyPy into the same C source file may
result in a noticeable increase in C code size at some point, but as long
as the C preprocessor can filter it back out, at least the build times
won't go up all that much, and it's not like a couple of compressed KBytes
more would hurt a PyPI package these days.

Stefan