| 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) * |
Date: 2012-04-09 15:49 |
| Stefan's latest patch looks fine to me. |
|
|
| msg157885 - (view) |
Author: Martin v. Löwis (loewis) * |
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) * |
Date: 2012-04-19 12:35 |
| Thanks for the patch! |
|
|
| msg158730 - (view) |
Author: Ronald Oussoren (ronaldoussoren) * |
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. |
|
|