On Tue, 27 Feb 2007 13:37:21 +1300, Greg Ewing <[EMAIL PROTECTED]> wrote:
>I don't like that answer. I can think of legitimate
>reasons for wanting to pre-create exceptions, e.g. if
>I'm intending to raise and catch a particular exception
>frequently and I don't want the overhead of creating
>a new instance each time.
This seems like kind of a strange micro-optimization to have an impact on a
language change discussion. Wouldn't it be better just to optimize instance
creation overhead? Or modify __new__ on your particular heavily-optimized
exception to have a free-list, so it can be both correct (you can still mutate
exceptions) and efficient (you'll only get a new exception object if you really
need it).
>For me, this is casting serious doubt on the whole
>idea of attaching the traceback to the exception.
I'm sorry if this has been proposed already in this discussion (I searched
around but did not find it), but has anyone thought of adding methods to
Exception to handle these edge cases and *not* attempting to interact with the
'raise' keyword at all? This is a strawman, but:
except Foo as foo:
if foo.some_property:
foo.reraise(modify_stack=False)
This would make the internal implementation details less important, since the
'raise' keyword machinery will have to respect some internal state of the
exception object in either case, but the precise thing being raised need not be
the result of the method, nor the exception itself.
_______________________________________________
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
