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 | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
