Guido van Rossum wrote:
> [Nick]
> Is that use case strong enough to require the added complexity? For a
> transactional wrapper, I can see that __exit__ needs to know about
> exceptions (though I'm unsure how much detail it needs), but what's
> the point of being able to tell an exception from a non-local goto
> (which break, continue and return really are)?
The only real reason the statement template can tell the difference is because
those non-local goto's all result in TerminateBlock being passed in as the
exception (that's why the __exit__ method can't really tell the difference
between those statements and the user code raising TerminateBlock, and also why
TerminateBlock can't be suppressed by the statement template).
As far as use cases go, any case where we want the statement template to be
able
to manipulate the exception handling requires that this information be passed
in
to the __exit__() method. The current examples given in the PEP are
transaction() and auto_retry(), but others have been suggested over the course
of the discussion. One suggestion was for automatically logging exceptions,
which requires access to the full state of the current exception.
I go into the motivation behind this a bit more in the updated draft I just
posted (version 1.3). The basic idea is to allow factoring out of arbitrary
try/except/else/finally code into a statement template, and use a 'do'
statement
to provide the contents of the 'try' clause.
If the exception information isn't passed in, then we can really only factor
out
try/finally statements, which is far less interesting.
> What's your use case for giving __enter__ an opportunity to skip the
> block altogether?
I realised that I don't have one - so the idea doesn't appear in the updated
draft.
Regards,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.blogspot.com
_______________________________________________
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
