On 19 February 2012 13:04, Stefan Behnel <stefan...@behnel.de> wrote: > When compiling for PyPy, Cython therefore needs a way to tell PyPy about > any changes. For the tstate->curexc_* fields, there are the two functions > PyErr_Fetch() and PyErr_Restore(). Could we have two similar "official" > functions for the exc_* fields? Maybe PyErr_FetchLast() and > PyErr_RestoreLast()?
It sounds reasonable to simply write a patch implementing and documenting these functions, put it in the tracker, and ask for it to be applied - I can't see an obvious reason not to do so. (There may be reasons not to put them in the "stable API", but that's not so relevant here). > Note that Cython would not have a reason to actually use them in CPython, > and it should be uncommon for non-Cython extension modules to care about > the exc_* fields at all. So these functions won't be of much use if > actually implemented in CPython (although I wouldn't mind doing that). The > question is just if we could have two officially named functions that PyPy > (and maybe other Pythons) could implement in order to access the last > raised exception in a way that does not depend on implementation details. You're probably worrying too much here. Get them added to Python 3.3, and then you're fine (if PyPy need to implement them for earlier versions, that's no problem for CPython, presumably PyPy don't have quite so stringent backward compatibility requirements yet, and the fact that they exist in 3.3 gives you the standardisation you need). Certainly "to have a standard API for getting at this information, even though it's probably not necessary for CPython extensions" isn't the best justification, but it's not the worst I've seen either :-) Of course, you could always go through the Python API, getting the sys module, extracting the relevant functions and calling them using the abstract API. That's what I'd recommend if this were purely a CPython question. But I assume that (for some reason) that's not appropriate for PyPy. Of course, my opinion doesn't carry a lot of weight here, so don't read too much into this :-) Paul. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
