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

2017-09-07 Thread Guido van Rossum
No worries. We all learned stuff!

On Wed, Sep 6, 2017 at 4:22 PM, R. David Murray 
wrote:

> On Wed, 06 Sep 2017 09:43:53 -0700, Guido van Rossum 
> wrote:
> > I'm actually not in favor of this. It's another way to do the same thing.
> > Sorry to rain on your dream!
>
> So it goes :)  I learned things by going through the process, so it
> wasn't wasted time for me even if (or because) I made several mistakes.
> Sorry for wasting anyone else's time :(
>
> --David
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2017-09-06 Thread R. David Murray
On Wed, 06 Sep 2017 09:43:53 -0700, Guido van Rossum  wrote:
> I'm actually not in favor of this. It's another way to do the same thing.
> Sorry to rain on your dream!

So it goes :)  I learned things by going through the process, so it
wasn't wasted time for me even if (or because) I made several mistakes.
Sorry for wasting anyone else's time :(

--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2017-09-06 Thread Guido van Rossum
I'm actually not in favor of this. It's another way to do the same thing.
Sorry to rain on your dream!

On Wed, Sep 6, 2017 at 9:34 AM, R. David Murray 
wrote:

> On Wed, 06 Sep 2017 15:05:51 +1000, Chris Angelico 
> wrote:
> > On Wed, Sep 6, 2017 at 10:11 AM, R. David Murray 
> wrote:
> > > 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:
> > > 
> > > break if 
> > >
> > > 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/
> >
> > Is "break if" legal in loops that have their own conditions as well,
> > or only in a bare "while:" loop? For instance, is this valid?
> >
> > while not found_the_thing_we_want:
> > data = sock.read()
> > break if not data
> > process(data)
>
> Yes.
>
> > Or this, which uses the condition purely as a descriptor:
> >
> > while "moar socket data":
> > data = sock.read()
> > break if not data
> > process(data)
>
> Yes.
>
> > Also - shouldn't this be being discussed first on python-ideas?
>
> Yep, you are absolutely right.  Someone has told me I also missed
> a related discussion on python-ideas in my searching for prior
> discussions.  (I haven't looked for it yet...)
>
> I'll blame jet lag :)
>
> --David
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2017-09-06 Thread R. David Murray
On Wed, 06 Sep 2017 15:05:51 +1000, Chris Angelico  wrote:
> On Wed, Sep 6, 2017 at 10:11 AM, R. David Murray  
> wrote:
> > 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:
> > 
> > break if 
> >
> > 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/
> 
> Is "break if" legal in loops that have their own conditions as well,
> or only in a bare "while:" loop? For instance, is this valid?
> 
> while not found_the_thing_we_want:
> data = sock.read()
> break if not data
> process(data)

Yes.

> Or this, which uses the condition purely as a descriptor:
> 
> while "moar socket data":
> data = sock.read()
> break if not data
> process(data)

Yes.

> Also - shouldn't this be being discussed first on python-ideas?

Yep, you are absolutely right.  Someone has told me I also missed
a related discussion on python-ideas in my searching for prior
discussions.  (I haven't looked for it yet...)

I'll blame jet lag :)

--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2017-09-06 Thread 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  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 
> 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:
>>>  
>>>  break if 
>>>
>>> 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:
>> 
>> if not :
>> 
>> break
>> 
>> if not :
>> 
>> 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@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@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/agoretoy%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2017-09-06 Thread Ben Hoyt
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 
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:
>>  
>>  break if 
>>
>> 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:
> 
> if not :
> 
> break
> 
> if not :
> 
> 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@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@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2017-09-06 Thread Ivan Levkivskyi
On 6 September 2017 at 08:42, Serhiy Storchaka  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:
>>  
>>  break if 
>>
>>
> I'm -1 for this proposition.
>
>
>
I also think this is not worth it. This will save few lines of code but
introduces some ambiguity and makes syntax more complex.

--
Ivan
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2017-09-05 Thread Serhiy Storchaka

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:
 
 break if 

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:

if not :

break

if not :

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@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2017-09-05 Thread Chris Angelico
On Wed, Sep 6, 2017 at 10:11 AM, R. David Murray  wrote:
> 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:
> 
> break if 
>
> 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/

Is "break if" legal in loops that have their own conditions as well,
or only in a bare "while:" loop? For instance, is this valid?

while not found_the_thing_we_want:
data = sock.read()
break if not data
process(data)

Or this, which uses the condition purely as a descriptor:

while "moar socket data":
data = sock.read()
break if not data
process(data)

Also - shouldn't this be being discussed first on python-ideas?

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2017-09-05 Thread 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:

break if 

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 :)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com