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

[alex goretoy]

https://www.youtube.com/watch?v=pNe1wWeaHOU&list=PLYI8318YYdkCsZ7dsYV01n6TZhXA6Wf9i&index=1
Thank you,
-Alex Goretoy


On Wed, Sep 6, 2017 at 7:05 PM, Ben Hoyt <benhoyt at gmail.com> wrote:
> 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
>
>
>
> _______________________________________________
> 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/agoretoy%40gmail.com
>