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