[Python-Dev] PEP 340 - Remaining issues
p.f.moore at gmail.com
Thu May 5 18:01:28 CEST 2005
On 5/5/05, Steven Bethard <steven.bethard at gmail.com> wrote:
> I wonder if it would be possible to update PEP 310 with your ideas,
> or perhaps start a new PEP? I'd like to see a competitor for PEP 340 that
> addresses some of the issues that came up, e.g. that the block-statement
> doesn't look like a loop, so break and continue might look like they break
> out of an enclosing loop.
In an attempt to bring things back under control, can I summarise what
I believe are the outstanding issues?
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.
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).
3. Looping blocks, and the break issue. I see a consensus forming here
that blocks should *not* loop. No-one has come up with a strong case
for looping blocks, except the auto_retry example, and Nick (I think
it was Nick Coghlan, sorry if my memory is wrong) demonstrated how to
build this case from a for loop and a non-looping block.
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.
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.
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.
 My simplistic view is that you may be able to get away with
changing the specification of the anonymous blok statement's expansion
just to remove the "while True". There's some fixup needed to avoid
the one "break" in the expansion, and probably a lot of little details
that make this far harder than I'm assuming - but maybe that's the
More information about the Python-Dev