classification
Title: provide public C-API for reading/setting sys.exc_info()
Type: enhancement Stage: commit review
Components: Interpreter Core Versions: Python 3.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: amaury.forgeotdarc, loewis, pitrou, python-dev, ronaldoussoren, scoder
Priority: normal Keywords: patch

Created on 2012-02-23 07:58 by scoder, last changed 2012-04-19 14:11 by ronaldoussoren. This issue is now closed.

Files
File name Uploaded Description Edit
exc_info_capi.patch scoder, 2012-02-23 15:46 proposed patch, including doc changes and test review
pyerr_getexcinfo.patch scoder, 2012-03-05 09:51 updated patch with "versionadded 3.3" in new documentation sections review
Messages (10)
msg154052 - (view) Author: Stefan Behnel (scoder) * Date: 2012-02-23 07:58
Following up on recent mailing list threads on pypy-dev and python-dev, this is a request for adding a public C-API to read and write the sys.exc_info() fields, currently stored in tstate->exc_*.

While not of major interest for CPython itself, this C-API addition would allow other Python implementations (currently PyPy) to hide their internal representation of these fields and to allow extensions that need to access them (most notably those generated by the Cython compiler) to write portable code.

Martin von Löwis proposed the names PyErr_GetExcInfo() and PyErr_SetExcInfo(), making them simple getter and setter functions that operate on owned references.

http://thread.gmane.org/gmane.comp.python.devel/129787/focus=129792

I'm currently working on a patch for CPython 3.3.
msg154057 - (view) Author: Stefan Behnel (scoder) * Date: 2012-02-23 10:09
I wonder if these functions should have an error return value, i.e. return -1 on failure. They'd "never" fail in CPython, but other implementations may want to report failures, in case their internal implementation is more involved. OTOH, documenting that they may fail (even though they won't) means that users will have to deal with errors in potentially tricky situations.

Amaury, any comments?
msg154067 - (view) Author: Stefan Behnel (scoder) * Date: 2012-02-23 15:38
Writing up a test case, I noticed that it makes sense to let PyErr_SetExcInfo() steal the references. This matches the main use case of saving and restoring the fields. For the getter, it's still best to return new references in order to support the use case of just reading the fields, as well as the use case of reading and clearing the fields (which a subsequent call to PyErr_SetExcInfo(NULL,NULL,NULL) does).
msg157286 - (view) Author: Stefan Behnel (scoder) * Date: 2012-04-01 13:29
This is now implemented in PyPy:

https://bitbucket.org/pypy/pypy/changeset/623bcea85df3

Are there any objections to applying the equivalent patch to CPython?
msg157855 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-04-09 15:49
Stefan's latest patch looks fine to me.
msg157885 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-04-09 19:32
Fine with me as well. Stefan, please submit a contributor form.
msg157974 - (view) Author: Stefan Behnel (scoder) * Date: 2012-04-10 18:17
Done.
msg158721 - (view) Author: Roundup Robot (python-dev) Date: 2012-04-19 12:34
New changeset 9fdec1354af4 by Martin v. Löwis in branch 'default':
Issue #14098: New functions PyErr_GetExcInfo and PyErr_SetExcInfo.
http://hg.python.org/cpython/rev/9fdec1354af4
msg158722 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-04-19 12:35
Thanks for the patch!
msg158730 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2012-04-19 14:11
The documentation does not explain how this new API is different from PyErr_Fetch/PyErr_Restore.  In particular the documentation doesn't mention that PyErr_Fetch and PyErr_GetExcInfo access different bits of the error state (curexc_* vs. exc_* in the thread state). 

Because of this it is not clear why there are two sets of functions, and why you want to use one set or the other.
History
Date User Action Args
2012-04-19 14:11:25ronaldoussorensetnosy: + ronaldoussoren
messages: + msg158730
2012-04-19 12:35:03loewissetstatus: open -> closed
resolution: fixed
messages: + msg158722
2012-04-19 12:34:24python-devsetnosy: + python-dev
messages: + msg158721
2012-04-10 18:17:38scodersetmessages: + msg157974
2012-04-09 19:32:23loewissetmessages: + msg157885
2012-04-09 15:49:21pitrousetnosy: + pitrou

messages: + msg157855
stage: commit review
2012-04-01 13:29:19scodersetmessages: + msg157286
2012-03-05 09:51:30scodersetfiles: + pyerr_getexcinfo.patch
2012-02-23 15:46:03scodersetfiles: + exc_info_capi.patch
keywords: + patch
2012-02-23 15:38:17scodersetmessages: + msg154067
2012-02-23 10:09:21scodersetnosy: + amaury.forgeotdarc
messages: + msg154057
2012-02-23 07:58:40scodercreate