Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Thoughts on PEP315

Reply
Thread Tools

Thoughts on PEP315

 
 
Tim Rowe
Guest
Posts: n/a
 
      09-23-2003
On Tue, 23 Sep 2003 15:55:06 +1200, Paul Foley <(E-Mail Removed)>
wrote:

>On Tue, 23 Sep 2003 01:47:03 +0100, Stephen Horne wrote:
>
>> In terms of flexible loops, Ada is basically the Daddy.

>
>http://www.lispworks.com/reference/H...ody/m_loop.htm


Young upstart compared to ALGOL!
 
Reply With Quote
 
 
 
 
John Roth
Guest
Posts: n/a
 
      09-23-2003

"Tim Rowe" <tim@remove_if_not_spam.digitig.co.uk> wrote in message
news:(E-Mail Removed)...
> 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"
> ><(E-Mail Removed)> 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.


Thanks, Terry. That's exactly what I meant to convey.

> 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.


That's always a problem, although my understanding of the
objectives for 2.4 is that there will probably be a number of
new keywords, so one more won't make a significant
difference. 2.3 was supposed to avoid adding them.

My major objection is that I don't think there's enough usage
to justify the additional complexity, regardless of whether we
can come up with a clean, Pythonic way of expressing it.

John Roth
>



 
Reply With Quote
 
 
 
 
Stephen Horne
Guest
Posts: n/a
 
      09-23-2003
On Tue, 23 Sep 2003 15:19:12 +0100, Tim Rowe
<tim@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"
>><(E-Mail Removed)> 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
 
Reply With Quote
 
Stephen Horne
Guest
Posts: n/a
 
      09-23-2003
On 23 Sep 2003 06:27:44 -0400, Heather Coppersmith <(E-Mail Removed)>
wrote:

>Don't forget that values other than "True" are true, too
>(shamelessly stolen from a previous post from Tim Peters):
>
> # basic file iteration (which can be done in other ways, but
> # simply demonstrates my point)
> while "there is another line in the file":
> nextlinefromfile = getnextlinefromfile( )
> if not nextlinefromfile:
> break
> moresprocessing( )


Thanks - to you and Tim - score 1 for self-documenting code!


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk
 
Reply With Quote
 
Tim Rowe
Guest
Posts: n/a
 
      09-23-2003
On Tue, 23 Sep 2003 17:49:46 +0100, Stephen Horne
<$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk> wrote:

>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...


He's clarified that one now.

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


That makes me twitchy: looks like the thin end of a wedge to Perl and
Ruby's <statement> if <condition> construct.

>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.


Oh, better than PEP315 certainly. I still don't like it
 
Reply With Quote
 
Stephen Horne
Guest
Posts: n/a
 
      09-24-2003
On Tue, 23 Sep 2003 19:26:00 +0100, Tim Rowe
<tim@remove_if_not_spam.digitig.co.uk> wrote:

>On Tue, 23 Sep 2003 17:49:46 +0100, Stephen Horne


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

>
>That makes me twitchy: looks like the thin end of a wedge to Perl and
>Ruby's <statement> if <condition> construct.


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_stuff ()
break if ... :
inner_loop_stuff ()

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

outer_loop_stuff ()

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
 
Reply With Quote
 
Gordon Airport
Guest
Posts: n/a
 
      09-24-2003
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.

 
Reply With Quote
 
Stephen Horne
Guest
Posts: n/a
 
      09-24-2003
On Tue, 23 Sep 2003 21:59:15 -0400, Gordon Airport <(E-Mail Removed)>
wrote:

>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.


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
 
Reply With Quote
 
Stephen Horne
Guest
Posts: n/a
 
      09-24-2003
On Wed, 24 Sep 2003 06:07:21 +0100, Stephen Horne
<$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk> wrote:

>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'.


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
 
Reply With Quote
 
Bernhard Herzog
Guest
Posts: n/a
 
      09-24-2003

Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk> writes:
> 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.


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/
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
SOHO VPN design thoughts Timo.Green@gmail.com Cisco 4 09-22-2005 07:00 PM
Post your thoughts on the best hardware manufacturers ww_crimson Hardware 19 07-17-2005 02:40 AM
Thoughts on Catalyst 2948G-GE-TX? Dan Rice Cisco 0 06-23-2005 07:59 PM
Thoughts on WEP in WPA WLAN? Al Blake Cisco 3 05-17-2005 05:34 AM
Your thoughts on dual PIX 501 access - redundant SOHO access mh Cisco 6 05-10-2004 04:32 PM



Advertisments