[Python-Dev] PEP 255 - BDFL Pronouncement: 'def' it stays

Guido van Rossum guido@digicool.com
Thu, 21 Jun 2001 10:32:40 -0400

I've thought long and hard and tried to read almost all the mail on
this topic, and I cannot get myself to change my mind.

No argument on either side is totally convincing, so I have consulted
my language designer's intuition.  It tells me that the syntax
proposed in the PEP is exactly right - not too hot, not too cold.
But, like the Oracle at Delphi in Greek mythology, it doesn't tell me
why, so I don't have a rebuttal for the arguments against the PEP
syntax.  The best I can come up with (apart from agreeing with the
rebuttals that Tim and others have already made) is "FUD".  If this
had been part of the language from day one, I very much doubt it would
have made Andrew Kuchling's "Python Warts" page.

So I propose that Tim and others defending 'def' save their remaining
breath, and I propose that Paul and others in favor of 'gen[erator]'
start diverting their energy towards thinking about how to best teach
generators the PEP syntax.  Tim, please add a BDFL pronouncement to
the PEP to end the argument.  You can also summarize the arguments on
either side, for posterity -- without trying to counter them.

I found one useful comment on the PEP that isn't addressed and is
orthogonal to the whole discussion: try/finally.  When you have a
try/finally around a yield statement, it is possible that the finally
clause is not executed at all when the iterator is never resumed.  I
find this disturbing, and am tempted to propose that yield inside
try/finally be disallowed (but yield inside try/except is still
allowed).  Another idea might be to somehow continue the frame with an
exception at this point -- but I don't have a clue what exception
would be appropriate (StopIteration isn't because it goes in the other
direction) and I don't know what to do if the generator catches
exception and tries to yield again (maybe the exception should be
raised again?).  The continued execution of the frame would be part of
the destructor for the generator-iterator object, so, like a __del__
method, any unhandled exceptions wouldn't be able to propagate out of

PS I lost my personal archive of the last 18 hours of the iter mailing
list, and the web archive is down, alas, so I'm writing this from
memory.  I *did* read most of the messages in my archive before I
accidentally deleted it, though. ;-)

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