Re: [Python-Dev] peps: New PEP 490: Chain exceptions at C level
On 26.03.15 10:08, victor.stinner wrote: https://hg.python.org/peps/rev/7daf3bfd9586 changeset: 5741:7daf3bfd9586 user:Victor Stinner date:Thu Mar 26 09:08:08 2015 +0100 summary: New PEP 490: Chain exceptions at C level +Python 3.5 introduces a new private ``_PyErr_ChainExceptions()`` function which +is enough to chain manually exceptions. It also was added in Python 3.4.3. I meditar about adding _PyErr_ReplaceException() in 2.7 for simpler backporting patches from 3.x. +Functions like ``PyErr_SetString()`` don't chain automatically exceptions. To +make usage of ``_PyErr_ChainExceptions()`` easier, new functions are added: + +* PyErr_SetStringChain(exc_type, message) +* PyErr_FormatChaine(exc_type, format, ...) Typo. +* PyErr_SetNoneChain(exc_type) +* PyErr_SetObjectChain(exc_type, exc_value) I would first make these functions private, as _PyErr_ChainExceptions(). After proofing their usefulness in the stdlib, they can be made public. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] peps: New PEP 490: Chain exceptions at C level
There is another issue: exception chain is not set up on exception creation in python code, only on throwing. Thus I have to assign `__context__` and `__cause__` attributes manually if I want to call `future.set_exception(exc)` instead of `raise exc`. See aiohttp code for usage example: https://github.com/KeepSafe/aiohttp/blob/931efbd518d0d99522d1cd36b43620657cd07304/aiohttp/client.py#L522 On Thu, Mar 26, 2015 at 11:11 AM, Serhiy Storchaka wrote: > On 26.03.15 10:08, victor.stinner wrote: >> >> https://hg.python.org/peps/rev/7daf3bfd9586 >> changeset: 5741:7daf3bfd9586 >> user:Victor Stinner >> date:Thu Mar 26 09:08:08 2015 +0100 >> summary: >>New PEP 490: Chain exceptions at C level > > >> +Python 3.5 introduces a new private ``_PyErr_ChainExceptions()`` function >> which >> +is enough to chain manually exceptions. > > > It also was added in Python 3.4.3. > > I meditar about adding _PyErr_ReplaceException() in 2.7 for simpler > backporting patches from 3.x. > >> +Functions like ``PyErr_SetString()`` don't chain automatically >> exceptions. To >> +make usage of ``_PyErr_ChainExceptions()`` easier, new functions are >> added: >> + >> +* PyErr_SetStringChain(exc_type, message) >> +* PyErr_FormatChaine(exc_type, format, ...) > > > Typo. > >> +* PyErr_SetNoneChain(exc_type) >> +* PyErr_SetObjectChain(exc_type, exc_value) > > > I would first make these functions private, as _PyErr_ChainExceptions(). > After proofing their usefulness in the stdlib, they can be made public. > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com -- Thanks, Andrew Svetlov ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] peps: New PEP 490: Chain exceptions at C level
2015-03-26 11:52 GMT+01:00 Andrew Svetlov : > There is another issue: exception chain is not set up on exception > creation in python code, only on throwing. I'm not suprised of that. > Thus I have to assign `__context__` and `__cause__` attributes > manually if I want to call `future.set_exception(exc)` instead of > `raise exc`. Do you mean that we need an helper to make this task even simpler? Or do you suggest to set them automatically in the constructor? Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RFC: PEP 490 - Chain exceptions at C level
Hi,
Here is the first draft of my PEP to chain automatically exceptions at
C level in Python 3.5. Plain text version of the PEP below. HTML
version of the PEP:
https://www.python.org/dev/peps/pep-0490/
It has already an implementation, the pyerr_chain.patch file attached to
http://bugs.python.org/issue23763
The patch is very short.
We may modify more functions to hide the previous exception when the
new exception contains as much or more information. Keeping the
previous exception waste memory, make reference cycles more likely and
is useless when displaying the full exception chain.
I wrote a huge patch modifying a lot of functions to explicitly *not*
chain exceptions: pyerr_match_clear-2.patch of the issue #23763. I
wrote the patch to show where exceptions will be chained with
pyerr_chain.patch applied. But we might apply it if we want to keep
exactly the same behaviour between Python 3.4 and 3.5 for C modules
the stdlib.
pyerr_match_clear-2.patch adds also checks on the type of the previous
exception to not replace an "unexpected" exception. For example, we
can replace an expected TypeError with a ValueError (without chaining
them), but we should not raise a ValueError if we got a
KeyboardInterrupt, a MemoryError or other unexpected exceptions. But
such changes are unrelated to the PEP and may be done in a separated
issue.
The starting point of my PEP is my work on CPython done with the
pyfailmalloc module. This module injects MemoryError. I fixed a ton of
issues in the code handling errors in CPython (see the issue #18408).
I noticed that Python didn't complain when exceptions are lost. I
added many assertions to detect these mistakes. Recently, I modified
Python 3.5 to raise an exception even in release mode (issue #23571)
if a C function returns NULL without an exception set, or if a C
function returns a result with an exception set.
Victor
PEP: 490
Title: Chain exceptions at C level
Version: $Revision$
Last-Modified: $Date$
Author: Victor Stinner
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 25-March-2015
Python-Version: 3.5
Abstract
Chain exceptions at C level, as already done at Python level.
Rationale
=
Python 3 introduced a new killer feature: exceptions are chained by
default, PEP 3134.
Example::
try:
raise TypeError("err1")
except TypeError:
raise ValueError("err2")
Output::
Traceback (most recent call last):
File "test.py", line 2, in
raise TypeError("err1")
TypeError: err1
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "test.py", line 4, in
raise ValueError("err2")
ValueError: err2
Exceptions are chained by default in Python code, but not in
extensions written in C.
A new private ``_PyErr_ChainExceptions()`` function was introduced in
Python 3.4.3 and 3.5 to chain exceptions. Currently, it must be called
explicitly to chain exceptions and its usage is not trivial.
Example of ``_PyErr_ChainExceptions()`` usage from the ``zipimport``
module to chain the previous ``OSError`` to a new ``ZipImportError``
exception::
PyObject *exc, *val, *tb;
PyErr_Fetch(&exc, &val, &tb);
PyErr_Format(ZipImportError, "can't open Zip file: %R", archive);
_PyErr_ChainExceptions(exc, val, tb);
This PEP proposes to also chain exceptions automatically at C level to
stay consistent and give more information on failures to help
debugging. The previous example becomes simply::
PyErr_Format(ZipImportError, "can't open Zip file: %R", archive);
Proposal
Modify PyErr_*() functions to chain exceptions
--
Modify C functions raising exceptions of the Python C API to
automatically chain exceptions: modify ``PyErr_SetString()``,
``PyErr_Format()``, ``PyErr_SetNone()``, etc.
Modify functions to not chain exceptions
Keeping the previous exception is not always interesting when the new
exception contains information of the previous exception or even more
information, especially when the two exceptions have the same type.
Example of an useless exception chain with ``int(str)``::
TypeError: a bytes-like object is required, not 'type'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "", line 1, in
TypeError: int() argument must be a string, a bytes-like object or
a number, not 'type'
The new ``TypeError`` exception contains more information than the
previous exception. The previous exception should be hidden.
The ``PyErr_Clear()`` function can be called to clear the current
exception before raising a new exception, to not chain the current
exception with a new exception.
Modify functions to chain exceptions
Some functions save and then restore the current exception. If a new
exception i
Re: [Python-Dev] peps: New PEP 490: Chain exceptions at C level
Thanks Serhiy for your review, I modified the PEP. I just sent a first draft (including your suggestions) to python-dev. Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] peps: New PEP 490: Chain exceptions at C level
I think setting context in exception constructor would be fine. On Thu, Mar 26, 2015 at 1:36 PM, Victor Stinner wrote: > 2015-03-26 11:52 GMT+01:00 Andrew Svetlov : >> There is another issue: exception chain is not set up on exception >> creation in python code, only on throwing. > > I'm not suprised of that. > >> Thus I have to assign `__context__` and `__cause__` attributes >> manually if I want to call `future.set_exception(exc)` instead of >> `raise exc`. > > Do you mean that we need an helper to make this task even simpler? Or > do you suggest to set them automatically in the constructor? > > Victor -- Thanks, Andrew Svetlov ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Needed reviews
2015-03-19 10:28 GMT+01:00 Serhiy Storchaka : > https://bugs.python.org/issue23681 > Have -b warn when directly comparing ints and bytes closed > https://bugs.python.org/issue23676 > Add support of UnicodeTranslateError in standard error handlers commented > https://bugs.python.org/issue23671 > string.Template doesn't work with the self keyword argument closed > https://bugs.python.org/issue23637 > Outputting warnings fails when file patch is not ASCII and message is > unicode on 2.7. commented > https://bugs.python.org/issue23622 > Deprecate unrecognized backslash+letter escapes in re closed > https://bugs.python.org/issue23611 > Pickle nested names (e.g. unbound methods) with protocols < 4 commented > https://bugs.python.org/issue23583 > IDLE: printing unicode subclasses broken (again) closed > https://bugs.python.org/issue23573 > Avoid redundant memory allocations in str.find and like closed and reopened, already commented > https://bugs.python.org/issue23509 > Speed up Counter operators reviewed > https://bugs.python.org/issue23502 > Tkinter doesn't support large integers (out of 32-bit range) closed (note: the title was different, "pprint: added support for mapping proxy") > https://bugs.python.org/issue23488 > Random objects twice as big as necessary on 64-bit builds reviewed > https://bugs.python.org/issue23466 > PEP 461: Inconsistency between str and bytes formatting of integers already reviewed > https://bugs.python.org/issue23419 > Faster default __reduce__ for classes without __init__ closed (rejected) > https://bugs.python.org/issue23290 > Faster set copying commented and reviewed I stop here for tonight. Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
