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 _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
