[Python-Dev] PEP 340 - Remaining issues

[Nick Coghlan]

Paul Moore wrote:
> 1. Choice (or not) of a keyword. I honestly believe that there will
> never be a consensus on this, and we'd be better deferring the
> decision to Guido's judgement.

The keyword-less approach is less confusing when the block statement is not a 
loop, as that eliminates the suprising behaviour of break and continue statements.

If there is a keyword, the wide variety of user-defined statements means that 
any real English word will be a bad fit for at least some of them. Something 
relatively nonsensical, but usefully mnemonic (like 'stmt') may be a good way to go.

> 2. Separate protocol or not? I'm not entirely sure I have a view on
> this, but it feels related to the looping question below. I do like
> being able to write these things as generators, and I don't mind
> needing a decorator (although I, personally, don't feel a compelling
> *need* for one).

If the block statement doesn't loop, the PEP 310 protocol makes a lot more 
sense. A function (usable as a generator decorator) can then be provided to 
convert from a callable that returns iterables to a callable that returns 
objects that support the PEP 310 protocol.

> Given that Guido has stated that he is willing to accept a consensus
> decision on changes to the PEP, can I suggest that rather than writing
> a competitor, someone (who understands the technicalities better than
> me) simply propose a modification to PEP 340 that does not loop

My attempt at doing exactly that is "PEP 340: Non-looping version (aka PEP 310 
redux)" [1]

And the seemingly simple change ('run the block at most once') had far more 
wide-ranging ramifications than I expected.

> I think the separate protocol issue is subtler - maybe it's just a
> case of renaming some methods and specifying a decorator, but I really
> don't understand the issues at this depth.

When I was writing my suggested semantics for a non-looping version, the use of 
an iteration protocol (next, StopIteration) became obviously inappropriate. So 
while having a separate protocol is a little murky when block statements are 
loops, the PEP 310 interface protocol is a clear winner when block statements 
are _not_ loops.

> I apologise if this post (1) misrepresents anyone's view, or (2)
> hinders things rather than helping. But I feel that we are pretty
> close to a solution here, and I fear that more competing PEPs will
> simply muddy the waters.

In this case, I think having a separate document (perhaps PEP 310, or maybe a 
Wiki page) to describe how a non-looping block statement can support all of the 
identified use cases for the PEP 340's block statement will be clearer than 
trying to describe the two main alternatives in the same PEP.

Cheers,
Nick.

[1] http://mail.python.org/pipermail/python-dev/2005-May/053400.html

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.skystorm.net