Roundup Robot devn...@psf.upfronthosting.co.za 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
Changes by Nick Coghlan ncogh...@gmail.com:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
___
Éric Araujo mer...@netwok.org added the comment:
Thanks, I can’t wait to use that in my code!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
___
Ethan Furman et...@stoneleaf.us 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)
Changes by Nick Coghlan ncogh...@gmail.com:
--
assignee: - ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
___
___
Python-bugs-list
Nick Coghlan ncogh...@gmail.com 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
Changes by Raghuram Devarakonda draghu...@gmail.com:
--
nosy: -draghuram
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
___
___
Ethan Furman et...@stoneleaf.us 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,
Ethan Furman et...@stoneleaf.us added the comment:
I just noticed that no one is assigned to this issue -- anybody on the nosy
list able to review?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
Ethan Furman et...@stoneleaf.us 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
Ethan Furman et...@stoneleaf.us 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 ...'
Ethan Furman et...@stoneleaf.us added the comment:
Attached patch now includes doc changes.
--
Added file: http://bugs.python.org/file24386/raise_from_none_v4.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
Ethan Furman et...@stoneleaf.us 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 rep...@bugs.python.org
Nick Coghlan ncogh...@gmail.com 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__ =
Ethan Furman et...@stoneleaf.us 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
Georg Brandl ge...@python.org 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 rep...@bugs.python.org
Patrick Westerhoff patrickwesterh...@gmail.com 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
Ethan Furman et...@stoneleaf.us 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
Ethan Furman et...@stoneleaf.us 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
Steven D'Aprano steve+pyt...@pearwood.info added the comment:
Patrick Westerhoff wrote:
Patrick Westerhoff patrickwesterh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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,
Patrick Westerhoff patrickwesterh...@gmail.com 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
Ethan Furman et...@stoneleaf.us 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)
Ethan Furman et...@stoneleaf.us 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
Ethan Furman et...@stoneleaf.us 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
Nick Coghlan ncogh...@gmail.com 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.
Ethan Furman et...@stoneleaf.us 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
Ethan Furman et...@stoneleaf.us added the comment:
Nick Coghlan wrote:
1. Any syntax change requires a PEP
PEP is on python-dev.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
___
Steven D'Aprano steve+pyt...@pearwood.info added the comment:
Nick Coghlan wrote:
Nick Coghlan ncogh...@gmail.com 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
Steven D'Aprano steve+pyt...@pearwood.info added the comment:
[...]
My comment has been overtaken by additional comments by Nick on the Python-Dev
list.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
Changes by Catalin Iacob iacobcata...@gmail.com:
--
nosy: +catalin.iacob
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
___
___
Ethan Furman et...@stoneleaf.us 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:
Patrick Westerhoff patrickwesterh...@gmail.com 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
Éric Araujo mer...@netwok.org 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
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +ezio.melotti
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
___
___
Python-bugs-list
Changes by Armin Ronacher armin.ronac...@active-4.com:
--
nosy: +aronacher
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
___
___
Matthew Barnett pyt...@mrabarnett.plus.com 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
Antoine Pitrou pit...@free.fr added the comment:
Le vendredi 31 décembre 2010 à 00:07 +, Patrick W. a écrit :
Patrick W. p...@borntolaugh.de 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 -
Ethan Furman et...@stoneleaf.us 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
Patrick W. p...@borntolaugh.de 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
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
using `None` as the cause of an exception would be the
best solution in my opinion:
+1
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
Antoine Pitrou pit...@free.fr 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 rep...@bugs.python.org
Patrick W. p...@borntolaugh.de 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
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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
Antoine Pitrou pit...@free.fr added the comment:
Le mercredi 29 décembre 2010 à 01:15 +, Ethan Furman a écrit :
Ethan Furman et...@stoneleaf.us 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
Ethan Furman et...@stoneleaf.us 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
Changes by Ethan Furman et...@stoneleaf.us:
--
versions: +Python 3.3 -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
___
___
Antoine Pitrou pit...@free.fr 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
Ethan Furman et...@stoneleaf.us 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
Antoine Pitrou pit...@free.fr 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
Ethan Furman et...@stoneleaf.us 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
Antoine Pitrou pit...@free.fr 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?
--
Ethan Furman et...@stoneleaf.us 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
Antoine Pitrou pit...@free.fr 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.
Ethan Furman et...@stoneleaf.us 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
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
___
___
Python-bugs-list
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +stoneleaf
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
___
___
Python-bugs-list
Ethan Furman et...@stoneleaf.us 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]()
Raymond Hettinger rhettin...@users.sourceforge.net 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
Changes by Matthew Barnett pyt...@mrabarnett.plus.com:
--
nosy: +mrabarnett
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
___
___
Antoine Pitrou pit...@free.fr 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
Ethan Furman et...@stoneleaf.us 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
Matthew Barnett pyt...@mrabarnett.plus.com 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:
Changes by Georg Brandl ge...@python.org:
--
assignee: - pitrou
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
___
___
Antoine Pitrou pit...@free.fr 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
Nick Coghlan ncogh...@gmail.com 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
Steven D'Aprano steve+pyt...@pearwood.info 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 =
Changes by Raghuram Devarakonda draghu...@gmail.com:
--
nosy: +draghuram
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
___
___
Nick Coghlan ncogh...@gmail.com 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
New submission from Patrick W. p...@borntolaugh.de:
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
Changes by Benjamin Peterson benja...@python.org:
--
versions: +Python 3.2 -Python 3.0
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
___
___
72 matches
Mail list logo
