Dan Roberts, 09.05.2010 08:12: > The code that Cython generates for numpy/random/mtrand/mtrand.pyx contains > several __Pyx_*() functions that muck about in the PyThreadState object > (which isn't standard)
Well, it's not an object, first of all, but IMHO, it's pretty much standard for CPython. And it's not Cython's fault that other runtimes refuse to implement it. > but each seems to have a sanctioned equivalent > provided in the official C API, listed here: > http://docs.python.org/c-api/exceptions.html I think "seems" is the right word here. They are either not exactly equivalent or have CPython version portability constrains, or they're simply not fast enough. Without looking closer, any subset of those three properties will likely hold for each of them. Note that exception handling in Py3 is handled very differently from that in Py2, simply because Py3 has suitable C-API functions that Py2 lacks, or that behave sufficiently different in Py2 to render them useless to Cython. > This is important because non-CPython interpreters likely won't expose that > struct, and indeed PyPy does not, and it would be cumbersome to do so. I don't expect much Cython code to run on PyPy anyway. The exception handling is only one reason why this won't easily work. That being said, I think this is absolutely worth a closer look. I wouldn't mind adding compatibility #define/#ifdef blocks to Cython to support PyPy or IronPython explicitly, as long as this doesn't get too ugly. Especially for the case of exception handling, the respective code may look yet another bit different for other runtimes. We have all sorts of portability code for various CPython versions in there anyway, and most of the relevant code is written down in separate utility functions instead of being generated line by line, so this shouldn't be too hard to integrate. Any volunteers? Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
