[Python-Dev] PEP 548: More Flexible Loop Control

Ben Hoyt benhoyt at gmail.com
Wed Sep 6 08:05:46 EDT 2017


I think Serhiy's response is excellent and agree with it. My gut reaction
is "this looks like Perl" (and not in a good way), but more specifically it
makes the control flow almost invisible. So I'm definitely -1 on this.

The current while True ... break idiom is not pretty, but it's also very
clear and obvious, and the control flow is immediately visible.

One thing I do like about the proposal is the bare "while:", and I think
that syntax is obvious and might be worth keeping (separately to the rest
of the proposal). A bare "while:" (meaning "while True:") seems somehow
less insulting to the intelligence, is still clear, and has precedent in
Go's bare "for { ... }".

-Ben

On Wed, Sep 6, 2017 at 2:42 AM, Serhiy Storchaka <storchaka at gmail.com>
wrote:

> 06.09.17 03:11, R. David Murray пише:
>
>> I've written a PEP proposing a small enhancement to the Python loop
>> control statements.  Short version: here's what feels to me like a
>> Pythonic way to spell "repeat until":
>>
>>      while:
>>          <do stuff>
>>          break if <done condition>
>>
>> The PEP goes into some detail on why this feels like a readability
>> improvement in the more general case, with examples taken from
>> the standard library:
>>
>>       https://www.python.org/dev/peps/pep-0548/
>>
>> Unlike Larry, I don't have a prototype, and in fact if this idea
>> meets with approval I'll be looking for a volunteer to do the actual
>> implementation.
>>
>> --David
>>
>> PS: this came to me in a dream on Sunday night, and the more I explored
>> the idea the better I liked it.  I have no idea what I was dreaming about
>> that resulted in this being the thing left in my mind when I woke up :)
>>
>
> This looks rather like Perl way than Python way.
>
> "There should be one-- and preferably only one --obvious way to do it."
>
> This proposing saves just a one line of the code. But it makes "break" and
> "continue" statement less visually distinguishable as it is seen in your
> example from uuid.py.
>
> If allow "break if" and "continue if", why not allow "return if"? Or
> arbitrary statement before "if"? This adds PHP-like inconsistency in the
> language.
>
> Current idiom is easier for modification. If you add the second condition,
> it may be that you need to execute different code before "break".
>
>     while True:
>         <do stuff>
>         if not <condition>:
>             <exit code>
>             break
>         <do stuff 2>
>         if not <condition >:
>             <exit code 2>
>             break
>
> It is easy to modify the code with the current syntax, but the code with
> the proposed syntax should be totally rewritten.
>
> Your example from sre_parse.py demonstrates this. Please note that
> pre-exit code is slightly different. In the first case self.error() is
> called with one argument, and in the second case it is called with two
> arguments. Your rewritten code is not equivalent to the existing one.
>
> Other concern is that the current code is highly optimized for common
> cases. Your rewritten code checks the condition "c is None" two times in
> common case.
>
> I'm -1 for this proposition.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/benhoyt%
> 40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170906/6d3ac240/attachment.html>


More information about the Python-Dev mailing list