[issue18861] Problems with recursive automatic exception chaining

Irit Katriel added the comment: I think this problem is actually simpler than what we've been discussing. First, note that by-and-large our current system works: >>> try: ... raise VE(1) ... except VE as e1: ... try: ... raise VE(2) ... except VE as e2: ... raise VE(3) from e2

[issue18861] Problems with recursive automatic exception chaining

Irit Katriel added the comment: For the issue of which contexts need to be suppressed when __suppress_context__ is true, I think we don't need to keep the whole tree of exceptions. It might be enough to save the dynamic "nesting depth of the try-excepts". Here is a solution with two

[issue18861] Problems with recursive automatic exception chaining

Change by Martin Panter : -- nosy: +martin.panter ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue18861] Problems with recursive automatic exception chaining

Change by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker ___ ___

[issue18861] Problems with recursive automatic exception chaining

Changes by Nathaniel Smith : -- nosy: +njs ___ Python tracker ___ ___ Python-bugs-list

[issue18861] Problems with recursive automatic exception chaining

Nick Coghlan added the comment: Actually, this won't the subTest example because that actually *suppresses* the errors, and reports them later. Annotations only help when the exception is allowed to escape. -- ___ Python tracker

[issue18861] Problems with recursive automatic exception chaining

Nick Coghlan added the comment: Adjusting the target version, since it isn't feasible to move away from the current behaviour any earlier than Python 3.5. -- versions: +Python 3.5 -Python 3.3 ___ Python tracker rep...@bugs.python.org

[issue18861] Problems with recursive automatic exception chaining

Nick Coghlan added the comment: Something else that this might make simpler: the unittest.TestCase.subTest API is currently kind of ugly. If the subtest details could be stored as a frame annotation instead... -- ___ Python tracker

[issue18861] Problems with recursive automatic exception chaining

Nick Coghlan added the comment: So, I've been pondering the idea of traceback/frame annotations and exception trees a bit. And what I'm wondering is if it may make sense to have the ability to annotate *frames* at runtime, and these annotations can be qualified by module names. So, for

[issue18861] Problems with recursive automatic exception chaining

Nick Coghlan added the comment: Walter suggested annotating the exceptions directly might work: https://mail.python.org/pipermail/python-dev/2013-November/130155.html However, that potentially runs into nesting problems (e.g. the idna codec invokes the ascii codec), although Walter suggested

[issue18861] Problems with recursive automatic exception chaining

Nick Coghlan added the comment: It may not immediately look like it, but I think issue 17828 offers an example of a related problem. In that issue, I didn't want to *change* the exception raised, I wanted to annotate it to say Hey, something I called raised an exception, here's some relevant

[issue18861] Problems with recursive automatic exception chaining

Nick Coghlan added the comment: Unrelated to my previous comment, I'm also wondering if this may actually represent a behavioural difference between contextlib.ExitStack and the interpreter's own exception handling machinery. ExitStack uses a recursive-iterative transformation for its stack

[issue18861] Problems with recursive automatic exception chaining

Nikolaus Rath added the comment: Hi Nick, I am interested in working on this, but I have never worked on the C parts of cpython before. Do you think this is a feasible project to start with? To me it looks a bit daunting, I'd certainly need some mentoring to even know where to start with

[issue18861] Problems with recursive automatic exception chaining

Benjamin Peterson added the comment: The first thing to do is to carefully specificy what the behavior should be. 2013/11/10 Nikolaus Rath rep...@bugs.python.org: Nikolaus Rath added the comment: Hi Nick, I am interested in working on this, but I have never worked on the C parts of

[issue18861] Problems with recursive automatic exception chaining

Nick Coghlan added the comment: Yes, I suggest using ExitStack to figure out the behaviour we *want* first, before diving into the messy practical details of how to make that a reality in CPython. We somehow have to get the state of the exception object and its traceback to represent an

[issue18861] Problems with recursive automatic exception chaining

Nick Coghlan added the comment: I actually think Nikratio is right about the way this *should* work (intuitively). I'm just not sure it's feasible to *implement* those semantics in CPython without significant changes to the way exception handling works - I don't believe the exception

[issue18861] Problems with recursive automatic exception chaining

Benjamin Peterson added the comment: raise ... from None explictly silences the printing of exception context, so I don't see the problem. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18861

[issue18861] Problems with recursive automatic exception chaining

Nick Coghlan added the comment: Nothing is lost either way, it just isn't displayed by default. While I can see the appeal of treating an outer context differently from an inner one, I don't see any way for the exception context suppression machinery to tell the difference. The traceback

[issue18861] Problems with recursive automatic exception chaining

Nikolaus Rath added the comment: Benjamin: I think that in most cases the intention of a .. from None is to disable printing of a stack trace for a specific exception when it occurs in the try .. except block. (In the example, that would be suppressing the stacktrace for the Second exception,

[issue18861] Problems with recursive automatic exception chaining

Nikolaus Rath added the comment: *ping* No one any comments on this at all? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18861 ___ ___

[issue18861] Problems with recursive automatic exception chaining

Changes by Antoine Pitrou pit...@free.fr: -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18861 ___ ___ Python-bugs-list

[issue18861] Problems with recursive automatic exception chaining

New submission from Nikolaus Rath: Consider this: $ python3 test_exc.py Traceback (most recent call last): File test_exc.py, line 14, in module fail1() File test_exc.py, line 11, in fail1 fail2() File test_exc.py, line 5, in fail2 raise RuntimeError('Third') from None

[issue18861] Problems with recursive automatic exception chaining

Nikolaus Rath added the comment: The second paragraph should of course read ...consequence of the 'First' exception *and* should thus be chained... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18861