[Python-Dev] PEP 343 - Abstract Block Redux

Guido van Rossum gvanrossum at gmail.com
Sat May 14 19:43:32 CEST 2005

[Fredrik Lundh]
> intuitively, I'm -1 on this proposal.

So we need to do better. Do you just prefer all of PEP 340? What about
the objections against it? The mostly unnecessary loopiness in

> unlike the original design, all you get from this is
> the ability to add try/finally blocks to your code
> without ever writing a try/finally-clause (neither
> in your code or in the block controller).  that
> doesn't strike me as especially pythonic.

Would it be better if we pulled back in the generator exit handling
from PEP 340? That's a pretty self-contained thing, and would let you
write try/finally around the yield.

> (neither does the argument that just because you
> can use a mechanism to write inscrutable code,
> such a mechanism must not be made available
> feel right; Python's design has always been about
> careful tradeoffs between policy and mechanism,
> but this is too much policy for my taste.  the
> original PEP 340 might have been too clever, but
> this reduced version feels pretty pointless).

Maybe. It still solves the majority of use cases for PEP 340, most of
which are try/finally abstractions.

Maybe I'm overreacting to Raymond Chen's rant about flow-control
macros -- but having had to maintain code once that was riddled with
these, it rang very true.

PEP 340 is still my favorite, but it seems there's too much opposition
to it, so I'm trying to explore alternatives; at the same time I
*really* dislike the complexities of some of the non-looping
counterproposals (e.g. Nick Coghlan's PEP 3XX or the proposals that
make every keyword associated with 'try' a method).

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

More information about the Python-Dev mailing list