[issue6210] Exception Chaining missing method for suppressing context

Éric Araujo added the comment: Thanks, I can’t wait to use that in my code! -- ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue6210] Exception Chaining missing method for suppressing context

Changes by Nick Coghlan : -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker ___ ___ Pyth

[issue6210] Exception Chaining missing method for suppressing context

Roundup Robot added the comment: New changeset b299c4f31ff2 by Nick Coghlan in branch 'default': Close issue #6210: Implement PEP 409 http://hg.python.org/cpython/rev/b299c4f31ff2 -- nosy: +python-dev ___ Python tracker

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: > Remaining problems: > - default sys.excepthook implementation currently does the wrong thing Unable to duplicate on my system (Win XP SP3) > - needs a test for the pythonrun display logic (test_cmd_line_script > would be the appropriate place) Not sure I un

[issue6210] Exception Chaining missing method for suppressing context

Changes by Raghuram Devarakonda : -- nosy: -draghuram ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue6210] Exception Chaining missing method for suppressing context

Nick Coghlan added the comment: I started work on integrating this into 3.3 this evening, but ran into too many issues to finish it. Problems found and fixed: - traceback.py displayed the wrong exception (test added and impl fixed) Additional changes: - eliminated duplicate code paths for __c

[issue6210] Exception Chaining missing method for suppressing context

Changes by Nick Coghlan : -- assignee: -> ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: I just noticed that no one is assigned to this issue -- anybody on the nosy list able to review? -- ___ Python tracker ___ __

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: > Because Ellipsis is now the default value for __cause__, > 'raise ... from Ellipsis' is treated the same as 'raise ...' Not exactly true -- if ... is a new exception then they are the same; if ... is a caught exception that is being reraised, __cause__ will be

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: PEP 409 has been accepted. :) Attached is the latest patch implementing it, with the (hopefully ;) final changes. Because Ellipsis is now the default value for __cause__, 'raise ... from Ellipsis' is treated the same as 'raise ...' -- Added file: htt

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: Latest version of PEP is on python-dev; here is the latest patch. Summary: For __cause__ we are replacing the old special value of None with Ellipsis: Ellipsis means check __context__ for an exception to display; None means ignore __context__ and stop followi

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: Okay, *all* the documentation updates this time. Thanks, Nick! -- Added file: http://bugs.python.org/file24387/raise_from_none_v5.diff ___ Python tracker ___

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: Attached patch now includes doc changes. -- Added file: http://bugs.python.org/file24386/raise_from_none_v4.diff ___ Python tracker ___ __

[issue6210] Exception Chaining missing method for suppressing context

Patrick Westerhoff added the comment: Oh, where did that PEP come from? ^^ Also thanks for hinting at python-dev, didn’t realize that there was a discussion going on about this! -- ___ Python tracker _

[issue6210] Exception Chaining missing method for suppressing context

Nick Coghlan added the comment: This was discussed a little more in the python-dev thread for PEP 409, but both Guido and I have been burned in the past by badly written libraries that replaced detailed exceptions that explained *exactly* what was going wrong with bland, generic "it broke!" e

[issue6210] Exception Chaining missing method for suppressing context

Steven D'Aprano added the comment: Patrick Westerhoff wrote: > Patrick Westerhoff added the comment: > > I have to agree with Georg on that. I think it would make more sense to > introduce some internal flag/variable that keeps track of if the cause was > explicitely set. So if cause was set (

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: Not sure I have traceback._iter_chain() patched correctly, but all the tests pass. Here's the latest code. -- Added file: http://bugs.python.org/file24362/raise_from_none_v3.diff ___ Python tracker

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: Patrick: The value in this enhancement is in not displaying the chained exception. I do not see any value in throwing it away completely. If you don't care about __context__ you can safely ignore it. On the other hand, if it is completely removed, and you do

[issue6210] Exception Chaining missing method for suppressing context

Patrick Westerhoff added the comment: I have to agree with Georg on that. I think it would make more sense to introduce some internal flag/variable that keeps track of if the cause was explicitely set. So if cause was set (i.e. `from X` syntax is used), then always display it in favor of the

[issue6210] Exception Chaining missing method for suppressing context

Georg Brandl added the comment: Hmm, so "from None" sets cause to "True", while all other "from X" sets cause to "X". That does not sound like a good idea to me. -- nosy: +georg.brandl ___ Python tracker

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: Current semantics (before patch): cause is not None --> cause is set, display it instead of context cause is None --> no cause, try to display context context is not None --> no context context is None --> context set, display it (unless cause already displa

[issue6210] Exception Chaining missing method for suppressing context

Nick Coghlan added the comment: Ah, nice idea of bringing the boolean constants into the mix so we don't need to invent a new sentinel value. However, to preserve the current behaviour that "raise X from Y" is essentially just syntactic sugar for: "_var = X; _var.__cause__ = Y; raise Y", I su

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: It looks like agreement is forming around the raise ... from None method. It has been mentioned more than once that having the context saved on the exception would be a Good Thing, and for further debugging (or logging or what-have-you) I must agree. The

[issue6210] Exception Chaining missing method for suppressing context

Steven D'Aprano added the comment: [...] My comment has been overtaken by additional comments by Nick on the Python-Dev list. -- ___ Python tracker ___

[issue6210] Exception Chaining missing method for suppressing context

Steven D'Aprano added the comment: Nick Coghlan wrote: > Nick Coghlan added the comment: > > 1. Any syntax change requires a PEP (and, IMO, any such PEP for this issue > should get rejected: I don't consider this an important enough feature to > deserve dedicated syntax. Others disagree, which

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: Nick Coghlan wrote: > 1. Any syntax change requires a PEP PEP is on python-dev. -- ___ Python tracker ___ ___

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: > 1. Any syntax change requires a PEP (and, IMO, any such PEP for this issue > should get rejected: I don't consider this an important enough feature to > deserve dedicated syntax. Others disagree, which is one of the reasons why a > PEP is needed. The other, m

[issue6210] Exception Chaining missing method for suppressing context

Nick Coghlan added the comment: 1. Any syntax change requires a PEP (and, IMO, any such PEP for this issue should get rejected: I don't consider this an important enough feature to deserve dedicated syntax. Others disagree, which is one of the reasons why a PEP is needed. The other, more impo

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: I went with raise ... from None instead of raise as ... because there seemed to me more support for 'from None' on python-dev, possible confusion with 'raise as', and 'from None' follows the existing systax of raise SomeError() from SomeOtherErr

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: Okay, here is a patch implementing the 'raise ... from None' method. All critiques appreciated (especially if they include links to learn from!). -- keywords: +patch Added file: http://bugs.python.org/file24332/raise_from_none.diff _

[issue6210] Exception Chaining missing method for suppressing context

Changes by Catalin Iacob : -- nosy: +catalin.iacob ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue6210] Exception Chaining missing method for suppressing context

Patrick Westerhoff added the comment: Yeah, I would really like that solution, especially as it separates from the `from X` syntax that sets the exception’s cause. Also I would prefer a syntax solution over a class method simply because the exception context is something that is implicitely s

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: Okay, I like Matthew Barnett's idea of except SomeError [as e]: raise as SomeOtherError('...') This would require a change to the grammer as well, yes? From: raise_stmt: 'raise' [test ['from' test]] to raise_stmt: 'raise' [test ['from' t

[issue6210] Exception Chaining missing method for suppressing context

Éric Araujo added the comment: I like the class method idea, but not the no_context name. Would without_context be too long? I don’t dislike raise MyError from None, but a method will be more easy to search and will help people reading code and discovering this unknown idiom. I think it’s

[issue6210] Exception Chaining missing method for suppressing context

Changes by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue6210] Exception Chaining missing method for suppressing context

Matthew Barnett added the comment: I've been looking through the list of current keywords and the best syntax I could come up with for suppressing the context is: try: x / y except ZeroDivisionError as e: raise as Exception( 'Invalid value for y' ) The rationale is tha

[issue6210] Exception Chaining missing method for suppressing context

Changes by Armin Ronacher : -- nosy: +aronacher ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: raise AttributeError from None makes sense to me, and in a nice, short example like that I prefer it. In real code, however, I think raise AttributeError.no_context("Field %s is not in table" % attr) is going to be easier for the human to parse than raise Att

[issue6210] Exception Chaining missing method for suppressing context

Antoine Pitrou added the comment: Le vendredi 31 décembre 2010 à 00:07 +, Patrick W. a écrit : > Patrick W. added the comment: > > Antoine Pitrou (pitrou) at 2010-12-30 18:32 (UTC) > > We are talking about context, not cause. > > Yes, but - as said before - obviously the cause takes a hig

[issue6210] Exception Chaining missing method for suppressing context

Patrick W. added the comment: Antoine Pitrou (pitrou) at 2010-12-30 18:32 (UTC) > We are talking about context, not cause. Yes, but - as said before - obviously the cause takes a higher precedence than context (otherwise it wouldn't show a context message when you explicitely set that). So wh

[issue6210] Exception Chaining missing method for suppressing context

Antoine Pitrou added the comment: > > using `None` as the cause of an exception would be the > > best solution in my opinion: > > +1 We are talking about context, not cause. -- ___ Python tracker ___

[issue6210] Exception Chaining missing method for suppressing context

Raymond Hettinger added the comment: > using `None` as the cause of an exception would be the > best solution in my opinion: +1 -- ___ Python tracker ___ __

[issue6210] Exception Chaining missing method for suppressing context

Patrick W. added the comment: Nick Coghlan (ncoghlan) at 2010-12-29 08:46 (UTC): > No, the context must always be included unless explicitly suppressed. Then there should be some actually working way to suppress it, right? I think the standard behaviour that automatically sets the `__context__

[issue6210] Exception Chaining missing method for suppressing context

Changes by Ethan Furman : -- versions: +Python 3.3 -Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: > I said the *except* block, not the *try* block ;) Ah. So you did. Okay, if I'm understanding correctly, the scenario you are talking about involves the code in the except block calling some other function, and that other function is raising an exception...

[issue6210] Exception Chaining missing method for suppressing context

Antoine Pitrou added the comment: Le mercredi 29 décembre 2010 à 01:15 +, Ethan Furman a écrit : > Ethan Furman added the comment: > > > I'm talking about the exception raised from the except block. > > So was I -- why should this: > > try: > x = y / z > except ZeroDivisionError as e

[issue6210] Exception Chaining missing method for suppressing context

Nick Coghlan added the comment: For "can't tell" in my previous message, read "we aren't going to impose the requirement to be able to tell if an exception is being raised directly in the current exception handler as a feature of conforming Python implementations". We probably *could* tell th

[issue6210] Exception Chaining missing method for suppressing context

Nick Coghlan added the comment: No, the context must always be included unless explicitly suppressed. The interpreter can't reliably tell the difference between a raise statement in the current exception handler and one buried somewhere inside a nested function call. The whole point is to giv

[issue6210] Exception Chaining missing method for suppressing context

Changes by Éric Araujo : -- nosy: +eric.araujo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: > I'm talking about the exception raised from the except block. So was I -- why should this: try: x = y / z except ZeroDivisionError as exc: raise InvalidInput() be different from this: try: x = divide_and_conquer(y, z) except ZeroDivisionError as

[issue6210] Exception Chaining missing method for suppressing context

Antoine Pitrou added the comment: > > And what if the exception is raised from a subroutine? > > Well, if I have it surrounded by a try/except block, presumably I'm > aware that an exception could be raised. ;) I'm talking about the exception raised from the except block. -- ___

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: > And what if the exception is raised from a subroutine? Well, if I have it surrounded by a try/except block, presumably I'm aware that an exception could be raised. ;) And if I'm aware that an exception could be raised, it may also be possible that I want to

[issue6210] Exception Chaining missing method for suppressing context

Antoine Pitrou added the comment: > and, finally, if all I have is > > except ValueError as exc: > raise AttributeError("blah") > > I just get the normal, previous context free, traceback. And what if the exception is raised from a subroutine? -- ___

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: >> During handling of the above exception, another exception occurred: >> >> This is a blatant falsehood -- another exception did not occur, a >> different exception was raised. > > This doesn't make any difference in any other context, so why would it > here?

[issue6210] Exception Chaining missing method for suppressing context

Antoine Pitrou added the comment: > During handling of the above exception, another exception occurred: > > This is a blatant falsehood -- another exception did not occur, a > different exception was raised. This doesn't make any difference in any other context, so why would it here? If only t

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: > Besides, if you are writing library code (as opposed to application > code), you shouldn't care at all how tracebacks are displayed, should > you? I care when it lies: During handling of the above exception, another exception occurred: This is a blatant false

[issue6210] Exception Chaining missing method for suppressing context

Antoine Pitrou added the comment: > I'm not sure how that's going to help as I don't want my library code > to be responsible for printing out exceptions, I just want them to > print reasonably -- and it seems very unreasonable to have the > exception I'm converting /from/ show up in the traceba

[issue6210] Exception Chaining missing method for suppressing context

Matthew Barnett added the comment: Regarding syntax, I'm undecided between: raise with new_exception and: raise new_exception with caught_exception I think that the second form is clearer: try: ... exception SomeException as ex: raise SomeOtherException() wit

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: > There is already support for this in the traceback module (see the > "chain" parameter to various funcs). I'm not sure how that's going to help as I don't want my library code to be responsible for printing out exceptions, I just want them to print reasonably

[issue6210] Exception Chaining missing method for suppressing context

Antoine Pitrou added the comment: > A person writing an exception handler should have control over what > the user sees. There is already support for this in the traceback module (see the "chain" parameter to various funcs). -- ___ Python tracker <

[issue6210] Exception Chaining missing method for suppressing context

Changes by Matthew Barnett : -- nosy: +mrabarnett ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue6210] Exception Chaining missing method for suppressing context

Raymond Hettinger added the comment: I agree with the OP that we need a way to either suppress chaining or have it turned-off by default. A person writing an exception handler should have control over what the user sees. -- nosy: +rhettinger ___ P

[issue6210] Exception Chaining missing method for suppressing context

Ethan Furman added the comment: I like MRAB's suggestion best: MRAB wrote: > Suggestion: an explicit 'raise' in the exception handler excludes the > context, but if you want to include it then 'raise with'. For example: > > # Exclude the context > try: > command_dict[command]() > except Key

[issue6210] Exception Chaining missing method for suppressing context

Changes by Ethan Furman : -- nosy: +stoneleaf ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue6210] Exception Chaining missing method for suppressing context

Nick Coghlan added the comment: To get back to my original objection, it shouldn't be that difficult to differentiate between "__context__ never set" and "__context__ explicitly suppressed". (e.g. using a property that sets an internal flag when set from Python code or via PyObject_SetAttr,

[issue6210] Exception Chaining missing method for suppressing context

Antoine Pitrou added the comment: It is not possible to do this using a method, since "raise exc" will add a context anyway. So, if this is desired, it needs some new syntax and should be discussed on python-ideas. (I don't think this is very important personally. Tracebacks are for developer

[issue6210] Exception Chaining missing method for suppressing context

Changes by Georg Brandl : -- assignee: -> pitrou nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue6210] Exception Chaining missing method for suppressing context

Steven D'Aprano added the comment: It seems to me that an explicit raise inside an except block should *not* chain exceptions by default. The rationale for chaining exceptions is to detect bugs in the exception handler: try: something except SomeError: y = 1/x # oops, what happens wh

[issue6210] Exception Chaining missing method for suppressing context

Changes by Raghuram Devarakonda : -- nosy: +draghuram ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue6210] Exception Chaining missing method for suppressing context

Nick Coghlan added the comment: The current behaviour also doesn't match the spec in PEP 3134, which states the __context__ attribute will only be set by the VM if it hasn't already been set. This is not currently the case, as setting __context__ does not keep the VM from setting it (I also tri

[issue6210] Exception Chaining missing method for suppressing context

Changes by Benjamin Peterson : -- versions: +Python 3.2 -Python 3.0 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue6210] Exception Chaining missing method for suppressing context

New submission from Patrick W. : I'm currently writing a library that executes predefined http requests to a specified server. In case there is for example a HTTP Error, I want to raise a user-defined exception that contains additional information about when the error actually occured (so that th