[Python-Dev] Merging PEP 310 and PEP 340-redux?

Guido van Rossum gvanrossum at gmail.com
Wed May 11 19:00:19 CEST 2005


[Guido]
> > Now it would make more sense to change the syntax to
> >
> >         with EXPR as VAR:
> >             BLOCK
> >
> > and we have Phillip Eby's proposal.

[Greg]
> Change the 'with' to 'do' and I'd be +1 on this.

Great! But the devil is in the details. I want to reduce the
complexity, and I'm willing to reduce the functionality somewhat. It
would help if you could support this.

In particular, while I like the use case transactional() (example 3 in
PEP 340) enough to want some indicator of success or failure, I don't
see the point of having separate __except__, __else__ and __finally__
entry points.  It's unclear how these would be mapped to the generator
API, and whether more than one could be called e.g. what if __else__
raises an exception itself -- will __finally__ be called?  I'm sure
that could be specified rigorously, but I'm not so sure that it is
going to be useful and clear.

I see several possible levels of information that could be passed to
the __exit__ call:

(1) None. This is insufficient for the transactional() use case.

(2) Only a bool indicating success or failure. This is sufficient for
the transactional() use case.

(3) Full exception information, with the understanding that when
__exit__() returns normally, exception processing will resume as usual
(i.e. __exit__() is called from a finally clause). Exceptions raised
from __exit__() are considered errors/bugs in __exit__() and should be
avoided by robust __exit__() methods.

(4) Like (3), but also distinguish between non-local gotos
(break/continue/return), exceptions, and normal completion of BLOCK.
(I'm not sure that this is really different from (3).)

What do you think?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list