[Python-ideas] raising an exception type doesn't instantiate it until it gets caught

[Antoine Pitrou]

On Mon, 7 Nov 2011 18:52:55 +1100
Cameron Simpson <cs at zip.com.au> wrote:
> On 07Nov2011 04:04, Antoine Pitrou <solipsis at pitrou.net> wrote:
> | On Mon, 7 Nov 2011 12:03:46 +1000
> | Nick Coghlan <ncoghlan at gmail.com> wrote:
> | > > I'm not sure that it's still that important -- in fact I'm not sure Python 3
> | > > still has this behavior.
> | > 
> | > I'm fairly sure it does (it was the 3.x version of ceval that I was
> | > reading to remind myself of how the stack unwinding process actually
> | > works and the call to PyErr_NormalizeException() is still in there).
> | > It's just that without the multiple argument forms of the raise
> | > statement, pure Python code can only exploit it for exceptions without
> | > any arguments (so it still works for the StopIteration optimisation).
> | 
> | It's too late for me to go and take a look, but I'm not sure it does.
> | Unless the performance loss is significant, I would be in favour of
> | simplifying all this and always instantiating exceptions. Exception
> | handling in the eval loop and exception "normalization" is a nasty area
> | of the interpreter.
> 
> I presume StopIteration would get instantiated to a singleton, like
> NoneType to None? Just asking.

It is impossible to use singletons for exception instances now that the
traceback is stored on them.
(there was a bug with MemoryError which was a singleton: a raised
memory error would make its traceback immortal, making memory pressure
even worse)

Regards

Antoine.