Thoughts on PEP315

[Stephen Horne]

On Tue, 23 Sep 2003 15:19:12 +0100, Tim Rowe
<tim at remove_if_not_spam.digitig.co.uk> wrote:

>On Tue, 23 Sep 2003 04:39:14 +0100, Stephen Horne
><$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk> wrote:
>
>>On Mon, 22 Sep 2003 21:47:05 -0400, "John Roth"
>><newsgroups at jhrothjr.com> wrote:
>
>>>do:
>>>    bibbity
>>>    bobbity
>>>    boo
>>>    while condition  # note the lack of a colon!
>>
>>Yuck!!!
>>
>>This is really no different to the following, which is quoted in the
>>PEP as something to move away from...
>>
>>  while True :
>>    ...
>>    if condition : break
>>    ...
>>
>>The fundamental problem is that the exit point is not obvious because
>>it is 'hidden' in the detail of the loop - it is a statement within
>>the loop body instead of being lexically a part of the loop.
>
>It is very different indeed.  In the second case stuff can go after
>the "if condition: break", so the terminating condition is potentially
>buried in the surrounding code.  On my reading of John's proposal
>nothing can go after the "while condition", so the end is clearly
>marked in the Python way by the indentation dropping back a level.

Maybe - but in my reading of Johns suggestion the 'while' was just a
statement like the existing 'break' or 'continue' (hence the lack of a
colon). So you could legally write...

>>>do:
>>>    blah; blah; blah; blah; blah; blah
>>>    blah; blah; blah; blah; blah; blah
>>>    blah; while condition;  blah; blah
>>>    blah; blah; blah; blah; blah; blah
>>>    blah; blah; blah; blah; blah; blah

Which hides the 'while' quite well He said there was no colon - he
said nothing about semicolons.

This was not true for the original PEP315 suggestion, nor for my own,
which is...

  while True :
    blah; blah; blah; blah
    blah; blah; blah; blah
  break if condition :
    blah; blah; blah; blah
    blah; blah; blah; blah

Even with a severe case of not-enough-whitespace, it is still clear
where the loop exit point is.

>What I /don't/ like about it is the overloading of the "while"
>keyword.  I would much sooner reverse the condition and use "until",
>though I realise the back-compatibility issues of introducing new
>keywords.

I agree. That's why I suggested 'break if' - it reuses existing
keywords, yet is unambiguous and explicit about what it is doing. The
sense of the condition seems unimportant to me (a boolean not is
simple enough) so the fact that 'break if' reads more like 'until'
than 'while' seems irrelevant to me.

Actually, I kind of like the fact that it will normally be an easy
drop-in replacement for 'if condition : break'.

In itself, I don't think my suggestion is compelling - but as an
alternative to the existing PEP315, on the assumption that some change
is going to happen, I think my idea has significant merit.


-- 
Steve Horne

steve at ninereeds dot fsnet dot co dot uk