[Python-Dev] PEP 343 - Abstract Block Redux

Brett C. bac at OCF.Berkeley.EDU
Sat May 14 21:31:42 CEST 2005


Guido van Rossum wrote:
> [Fredrik Lundh]
> 
>>intuitively, I'm -1 on this proposal.
> 

Just to toss in my opinion, I prefer PEP 340 over 343 as well, but not so much
to give 343 a -1 from me.

[SNIP - question of how to handle argument against 340 being a loop which I
never totally got since you know it ahead of time so you just deal with it]

[SNIP]
> 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.
> 

You might be overreacting.  I read the essay and I understand his arguments
having been taught how to program in Scheme.  But I don't think this is as
serious.  People will have the semantics of the block statement explained to
them so how that works will be clear.  And at that point they just have to
track down the generator or iterator that the block statement is using.

If you think about it, how is it different than the implicit iter() call on a
'for' loop along with the implicit next() call each time through the loop?
Just because there is an implicit closing call back into the block generator at
the end of a block statement?  Doesn't seem so bad to me or that much of a
stretch from the magic of a 'for' loop to be that huge of a thing.

I think Raymond was reeling against arbitrary macro creation that hides flow
control.  We don't have that here.  What we have is a clearly defined statement
that does some very handy syntactic sugar for us.  It doesn't feel as arbitrary
as what Lisp and Scheme allow you to do.

> 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).
> 

Nick's was obviously directly against looping, but, with no offense to Nick,
how many other people were against it looping?  It never felt like it was a
screaming mass with pitchforks but more of a "I don't love it, but I can deal"
crowd.

And as for the overly complex examples, that I believed stemmed from people
realizing what might be possible if the statement was extended and tweaked this
way or that so as to be able to do just one more thing.  But that happens with
every proposal; seemed like standard feature creep.  The reason we have a BDFL
is to tell us that yes, we could get the jumbo sized candy bar for $2 more but
there is no way you will be able to finish that much chocolate before it melts
all over your hands and get it all over your nice PyCon t-shirt.

But then again I don't know if you got private emails asking to see if PEP 340
weighed as much as wood so it could be burned at the stake for being a witch.

-Brett


More information about the Python-Dev mailing list