Hi Stefan, Thanks for getting back to me. I've been digging pretty deep to try and see what's so special about __Pyx_GetException() and the only thing I see is that it copies curexc_* fields into exc_* fields. I've dug around in the CPython source and I'm having a hard time figuring out the importance of exc_* If we could establish that, we could build a new __Pyx_GetException() that only relies on PyErr_Fetch(). (The only other thing is __Pyx_GetException() deals with refcounts too, but that could be added easily)
I'm glad you're open to having multiple implementations, that way everyone is happy :-) I suppose since I've brought this up, and I'm most immediately affected, it falls to me to implement. That's fine as long as it doesn't take my whole summer :-p. And hopefully someone will be willing to guide me and answer my possibly dumb questions. I see that cython has a healthy heaping of tests too, which should help in determining compliance. I think I'm up to the challenge... I think... Thanks, Dan On May 9, 2010 3:49 AM, "Stefan Behnel" <[email protected]> wrote: Dan Roberts, 09.05.2010 08:12: > The code that Cython generates for numpy/random/mtrand/mtrand.pyx contains > several __Pyx_*() fun... 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: > ... 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... 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
_______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
