Thoughts on PEP315

[Stephen Horne]

Re: Thoughts on PEP315

On Tue, 23 Sep 2003 19:26:00 +0100, Tim Rowe
<tim@remove_if_ not_spam.digiti g.co.uk> wrote:
[color=blue]
>On Tue, 23 Sep 2003 17:49:46 +0100, Stephen Horne[/color]
[color=blue][color=green]
>> while True :
>> blah; blah; blah; blah
>> blah; blah; blah; blah
>> break if condition :
>> blah; blah; blah; blah
>> blah; blah; blah; blah[/color]
>
>That makes me twitchy: looks like the thin end of a wedge to Perl and
>Ruby's <statement> if <condition> construct.[/color]

I don't know Perl that well, and I certainly don't know Ruby. I
certainly wasn't basing this on either of them.

Anyway, you certainly couldn't turn the form above into a <statement>
if <condition> construct.

It is a part of an existing loop construct - *NOT* a statement and
therefore *NOT* a conditional statement. The indentation and the ":"
make it clear that it isn't a statement in its own right. If anything,
it removes the possibility of a future construct like that - consider
the following...


while True :
while True :
inner_loop_stuf f ()
break if ... :
inner_loop_stuf f ()

break if ...
# inner loop ended by 'break if ...' indentation

outer_loop_stuf f ()

If the <statement> if <condition> construct became a reality, both of
those "break if" lines would be legal - but with very different
meanings. The first is a part of the inner loop, and that inner loops
body continues afterwards. The second would be a part of the outer
loop, and its outdent would mark the end the inner loop.

This would be a nightmare for the parser - until it finds the colon or
end-of-line (or semicolon perhaps) it simply wouldn't know which case
it was dealing with.

But if this is bad for the parser, just think what it would do to
users! - forgetting a trailing semicolon shouldn't result in a
statement which is legal yet with a significantly different meaning.
In fact the semicolon on all these things at the moment is IIRC
totally redundant in terms of resolving ambiguity - it is compulsory
for stylistic reasons.

In my mind, "break if" is not the start of a general conditional
statement idea - it is a two-keyword combination in order to avoid
creating a new single keyword such as "until". It may suggest a
"continue if" for reasons of symmetry, but "continue" is IMO useless
anyway so probably not.


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Gordon Airport]

Re: Thoughts on PEP315

The point of do-while loops is that you don't need setup code anymore,
right? How about this:

....
dowhile <condition>:
<loop body>
....

where the body is run once before it becomes a standard while loop. It
looks like we all think of this structure as a "do-while loop", so the
expression is natural. This also makes it easy to change loop types -
just add or remove the "do". Slight downside is that the execution flow
isn't exactly as you read it.

[Stephen Horne]

Re: Thoughts on PEP315

On Tue, 23 Sep 2003 21:59:15 -0400, Gordon Airport <uce@ftc.gov>
wrote:
[color=blue]
>The point of do-while loops is that you don't need setup code anymore,
>right? How about this:
>
>...
>dowhile <condition>:
> <loop body>
>...
>
>where the body is run once before it becomes a standard while loop. It
>looks like we all think of this structure as a "do-while loop", so the
>expression is natural. This also makes it easy to change loop types -
>just add or remove the "do". Slight downside is that the execution flow
>isn't exactly as you read it.[/color]

This doesn't really solve the problem that the PEP aims to solve.

The setup code in the following example (from the PEP) is only *part*
of the code in the loop...

do:
<setup code>
while <condition> :
<loop body>

The condition is tested in the middle.

The precondition form duplicates the setup - this is what the PEP was
trying to avoid...

<setup code>
while <condition> :
<loop body>
<setup code>

But the postcondition-compliant form is really no better...

do :
<setup code>
if <condition> :
<loop body>
until !<condition> :

(or if you insist)

dowhile <condition> :
<setup code>
if <condition> :
<loop body>

You're simply duplicating the condition instead of the setup code. As
loop conditions are often at least as complex as the setup code, there
is really no gain here.

In addition, the 'if' isn't explicitly a loop exit point - it's just a
nested structure that achieves the same effect - so it doesn't express
as clearly the intention behind the code.

The whole point of the syntax in the PEP is to have the loop condition
tested in the middle of the loop - something which in C (and current
Python) is handled badly by the unstructured 'break'.


Secondly, what the PEP suggests is not what most people think of as a
'do-while' loop. Anyone sufficiently familiar with C, C++, Java, ...
will see a 'do-while' loop as being postconditioned (much like
repeat-until in Pascal etc) - ie not having the loop condition tested
in the middle as the PEP proposes.


Finally, IMO execution order should match reading order unless there
is a *VERY* good reason to do differently.

Pascal, C and even Basic manage to show a precondition at the start of
a loop, but a postcondition at the end of a loop. I don't see any good
reason why Python can't follow suit.


IMO, a loop exit point should... (highest priority first)

1. Be written at the point where the condition is tested, such that
execution order is the same as reading order.

I don't want to see variables referenced in a condition that
haven't even been defined yet, for instance. You see this as
minor - I see it as *very* important.

2. To be clearly identifiable be its leading keyword(s), and in
particular not be confusable with the start of a new structure.

This is a problem with the C 'do ... while' - it isn't always
clear that the 'while' is part of the 'do' loop rather than the
start of a new 'while' loop. IMO we don't need this hassle in
Python.

3. Be linked to the loop itself, much as 'else' is linked to 'if',
by having the same indent level and the ':' marker at the end of
the line.

This is IMO relatively minor - I don't object that much to the
existing 'if condition : break' - but I believe it is important
to the PEP authors logic.


Basically, readability and maintainability are key obsessions of mine
(and pretty much anyone who has had to read and maintain large systems
written by other people).

I'm not really sure why people don't like 'break if' - but then of
course I don't, it is my invention ;-)

Maybe it's to do with the return to the indent level of the earlier
'while' - but then 'elif' and 'else' already do this in 'if' blocks.

More likely it is that bit in point 3 above - I think it is a good
idea for a loop exit point, but it isn't exactly normal practice. Adas
'exit when' is, as I mentioned, the closest match I know of.

Maybe 'break if' would end up being like a certain common reaction to
Pythons use of indentation for structuring (initial shock and disgust,
but growing to love it) or maybe I'm just wierd ;-)


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Stephen Horne]

Re: Thoughts on PEP315

On Wed, 24 Sep 2003 06:07:21 +0100, Stephen Horne
<$$$$$$$$$$$$$$ $$$@$$$$$$$$$$$ $$$$$$$$$.co.uk > wrote:
[color=blue]
>The whole point of the syntax in the PEP is to have the loop condition
>tested in the middle of the loop - something which in C (and current
>Python) is handled badly by the unstructured 'break'.[/color]

Ooops - that 'badly' was meant to be in quotes as I don't really think
it's that bad.


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Bernhard Herzog]

Re: Thoughts on PEP315


Stephen Horne <$$$$$$$$$$$$$$ $$$@$$$$$$$$$$$ $$$$$$$$$.co.uk > writes:[color=blue]
> The PEP315 system of...
>
> do:
> ...
> while condition :
> ...
>
> is IMO broken simply because there is no lexical indicator in that
> 'while' line that it is a continuation rather than a new structure. It
> isn't a distinctive keyword because 'while' can obviously be the start
> of a loop.[/color]

I think someone once suggested "and while" instead of a plain while:

do:
...
and while condition:
...

This reads quite nicely IMO.

Bernhard

--
Intevation GmbH http://intevation.de/
Sketch http://sketch.sourceforge.net/
Thuban http://thuban.intevation.org/

[Tim Rowe]

Re: Thoughts on PEP315

On Wed, 24 Sep 2003 01:02:47 +0100, Stephen Horne
<$$$$$$$$$$$$$$ $$$@$$$$$$$$$$$ $$$$$$$$$.co.uk > wrote:
[color=blue]
>This would be a nightmare for the parser - until it finds the colon or
>end-of-line (or semicolon perhaps) it simply wouldn't know which case
>it was dealing with.
>
>But if this is bad for the parser, just think what it would do to
>users! - forgetting a trailing semicolon shouldn't result in a
>statement which is legal yet with a significantly different meaning.[/color]

That's why I don't like it in Perl and Ruby -- I can tell it's hard
for the parser because so few syntax highlighters get it right!

Maybe I'm getting twitchy about nothing -- after all, indentation
being significant brough back unhappy memories of FORTRAN, but Python
makes it work...

[Stephen Horne]

Re: Thoughts on PEP315

On Wed, 24 Sep 2003 12:14:48 +0200, Bernhard Herzog <bh@intevation. de>
wrote:
[color=blue]
>I think someone once suggested "and while" instead of a plain while:
>
>do:
> ...
>and while condition:
> ...
>
>This reads quite nicely IMO.[/color]

Hmmm.

It certainly has all the advantages I claimed for 'break if'. At the
moment my mental parser is choking on it - but I can't give a good
reason why. Probably it's just odd seeing 'and' at the start of a
line, I suspect.


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Stephen Horne]

Re: Thoughts on PEP315

On Wed, 24 Sep 2003 17:50:11 +0100, Tim Rowe
<tim@remove_if_ not_spam.digiti g.co.uk> wrote:
[color=blue]
>On Wed, 24 Sep 2003 01:02:47 +0100, Stephen Horne
><$$$$$$$$$$$$$ $$$$@$$$$$$$$$$ $$$$$$$$$$.co.u k> wrote:
>[color=green]
>>This would be a nightmare for the parser - until it finds the colon or
>>end-of-line (or semicolon perhaps) it simply wouldn't know which case
>>it was dealing with.
>>
>>But if this is bad for the parser, just think what it would do to
>>users! - forgetting a trailing semicolon shouldn't result in a
>>statement which is legal yet with a significantly different meaning.[/color]
>
>That's why I don't like it in Perl and Ruby -- I can tell it's hard
>for the parser because so few syntax highlighters get it right!
>
>Maybe I'm getting twitchy about nothing -- after all, indentation
>being significant brough back unhappy memories of FORTRAN, but Python
>makes it work...[/color]

That was basically a fluked typo - I meant the missing the trailing
colon at the end of the 'break if ...' line, but of couse a semicolon
added/lost semicolon in the wrong place can be just as bad.

I don't think this would hurt Python the same way, though, as 'if'
cannot follow after a statement on the same line for (presumably to
ensure that the indentation makes sense)...
[color=blue][color=green][color=darkred]
>>> break ; if 1 :[/color][/color][/color]
File "<stdin>", line 1
break ; if 1 :
^
SyntaxError: invalid syntax


So a 'break if ... :' cannot accidentally metamorphose into a 'break;
if ... :'.


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Neil Padgen]

Re: Thoughts on PEP315

>>>>> "Stephen" == Stephen Horne <$$$$$$$$$$$$$$ $$$@$$$$$$$$$$$ $$$$$$$$$.co.uk > writes:

Stephen> So a 'break if ... :' cannot accidentally metamorphose
Stephen> into a 'break; if ... :'.

It can if you press return at the wrong place:

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

This would be perfectly legal if the new-style while loop were in
another loop.

-- Neil

[Stephen Horne]

Re: Thoughts on PEP315

On Thu, 25 Sep 2003 13:36:40 +0000, Neil Padgen
<neil.padgen@mo n.bbc.co.uk> wrote:
[color=blue][color=green][color=darkred]
>>>>>> "Stephen" == Stephen Horne <$$$$$$$$$$$$$$ $$$@$$$$$$$$$$$ $$$$$$$$$.co.uk > writes:[/color][/color]
>
> Stephen> So a 'break if ... :' cannot accidentally metamorphose
> Stephen> into a 'break; if ... :'.
>
>It can if you press return at the wrong place:
>
> while True:
> blah ; blah ; blah
> break
> if condition:
> blah ; blah ; blah
>
>This would be perfectly legal if the new-style while loop were in
>another loop.[/color]

I don't think this is a serious problem. It's hard to miss the fact
that the 'break' and the 'if' are on different lines.

You might just as well claim that...

print "Hello World"

....is bad syntax because...

print
"Hello World"

....is legal but (particularly when not run from the command line)
different.


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk