Glyph:
> This seems like kind of a strange micro-optimization to have an impact
> on a language change discussion.
Just as a reminder, my concern is that people reuse exceptions (rarely)
and that the behavior of the "with_exceptions()" method is ambiguous
when that happens. It has nothing to do with optimization.
The two solutions of:
1. always replace an existing __traceback__
2. never replace an existing __traceback__
both seem to lead to problems.
Here are minimal examples for thought:
# I know PJE says this is bad style for 3.0. Will P3K help
# identify this problem? If it's allowable, what will it do?
# (Remember, I found existing code which reuses exceptions
# so this isn't purely theoretical, only rare.)
BAD = Exception("that was bad")
try:
raise BAD
except Exception:
pass
raise BAD # what traceback will be shown here?
(Oh, and what would a debugger report?)
# 2nd example; reraise an existing exception instance.
# It appears that any solution which reports a problem
# for #1 will not allow one or both of the following.
try:
raise Exception("bad")
except Exception as err:
first_err = err
try:
raise Exception("bad")
except Exception:
raise first_err # what traceback will be shown here?
# 3rd example, like the 2nd but end it with
raise first_err.with_exception(first_err.__traceback__) # what
traceback will be shown here?
> I'm sorry if this has been proposed already in this discussion (I
> searched around but did not find it),
I saw references to a PEP about it but could not find the PEP.
Nor could I find much discussion either. I would like to know
the details. I assume that "raise" adds the __traceback__ if
it's not None, hence there's no way it can tell if the __traceback__
on the instance was created with "with_traceback()" from an
earlier "raise" or from the with_traceback.
But in the current examples it appears that the Exception class
could attach a traceback during instantiation and "with_traceback"
simply replaces that. I doubt this version, but cannot be definitive.
While variant method/syntax may improve matters, I think people
will write code as above -- all of which are valid Python 2.x and
3.x -- and end up with strange and hard to interpret tracebacks.
Andrew
[EMAIL PROTECTED]
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
