Thanks. However, rather than making the CPYTHON macro ambiguous, I'd like to see a change of its usages to distinguish PYPY from the others. PyPy is currently the only other "supported" backend apart from CPython, so the current macro usages were just a guess and are subject to change.

Also, we do not define our own officlal looking C-API functions in Cython. Instead, we use our own internal functions prefixed with __Pyx_. So adding __Pyx_PyFrame_SetLineNumber() and __Pyx_PyCode_HasFreeVars() would be ok. Preferably as macros, as "inline" isn't C89 compatible.

Thanks for your feed back. But would you mind to clarify your first paragraph please?

Sure. Sorry for not being clear. What I meant was that many usages of "COMPILING_IN_CPYTHON" might better be spelled as "COMPILING_IN_PYPY else ...". In fact, PYPY has even improved their C-API implementation a lot during the last year, so some of the special casing could even be removed at some point.

If Pyston can handle the normal CPython path, it's best to change the "CPYTHON" check to a "PYPY" check, i.e. swap the default behaviour to CPYTHON and special case PYPY instead, rather than special casing CPYTHON and PYSTON and whatever else might come up in the future.

To be even more clear: I encourage you to be more ambitious in your change and also clean up the current macro usage.

I replaced most of the macro usages by more feature-specific macros. Please take a look and see if that helps in what you're doing. 71de578

I also added macro indirections for your C-API functions here: 9a3f96e

Thanks! I will take a look.

Hi @scoder . Thanks for your patches.

Hi @scoder I updated the commit again. Would you mind to review this commit if you have time, please? Pyston will try to support more CPython extensions. So more Pyston change will come.

Looks good. Thanks!

Thanks for your help!