REPEAT... UNTIL ?
Ingo Linkweiler
what do you think about adding "repeat .... until" to python syntax?
Often a "repeat-until" is better to use than a "while" loop.
Guido 8-) ???
Ingo
Gustavo Cordova
Given the following:
bexpr === boolean expression, exit loop when true.
then:
"""
repeat:
...
...
...
until bexpr
"""
would be exactly the same as:
"""
while 1:
...
...
...
if bexpr: break
"""
no?
-gustavo
Sean 'Shaleh' Perry
> would be exactly the same as:
>
> """
> while 1:
> ...
> ...
> ...
> if bexpr: break
> """
>
> no?
>
that is basically the python idiom. The original poster would do well to
search a few archives, this has been discussed at length many times.
Just like the GOTO, or any other syntax from another language they belong to
other languages and not python. A good coder learns to program in the idioms
of the language they are using. Or they just write in the same style
everywhere and their perl, C, java, whatever looks like their first language.
Beej Jørgensen
Gustavo Cordova <gcor...@hebmex.com> wrote:
>would be exactly the same as:
>
>"""
>while 1:
> ...
> ...
> ...
> if bexpr: break
>"""
>
>no?
Sigh. It's the age-old issue. More looping primitives, or fewer? I
always wanted more, but people would argue against me that the same
thing can be done with a normal while loop. Well, of course it can. In
fact, all the loops can be reduced to one statement, a la:
loop:
if cond: break
But not even the purists will go that far. But as the language ages, it
becomes more and more set in stone. Backward compatibility will
certainly be trashed if a do-while loop is introduced, so it's not an
issue to take lightly.
(The other side of the coin is that my only argument for more looping
primitives is that while-1 loops are ugly-looking, and don't make for
the most readable code. Some people disagree or feel it's less
important. And personally I always feel like I'm undergoing some kind
of algorithmic failure when I code one; like I must not be doing the
Right Thing. But in Python, it is.)
It's not really even worth arguing about at this point unless you can
come up with the killer app for do-while loops. The battle lines are
clear, and either someday it'll be added, or it won't.
-Beej
Ville Vainio
> (The other side of the coin is that my only argument for more looping
> primitives is that while-1 loops are ugly-looking, and don't make for
> the most readable code. Some people disagree or feel it's less
> important. And personally I always feel like I'm undergoing some kind
> of algorithmic failure when I code one; like I must not be doing the
> Right Thing. But in Python, it is.)
Strangely enough, while 1 - loop is quite often the most intuitive way
to do things, yet it's (implicitly) frowned upon in many programming
language cultures. The same applies to calling 'continue' instead of
elif. Flat is good. This seems to be mostly a documentation issue. It
would probably feel slightly less awkward if the keyword 'loop' was an
alias for 'while 1', but that will never happen.
-- Ville
Ville Vainio
> (The other side of the coin is that my only argument for more looping
> primitives is that while-1 loops are ugly-looking, and don't make for
> the most readable code. Some people disagree or feel it's less
> important. And personally I always feel like I'm undergoing some kind
> of algorithmic failure when I code one; like I must not be doing the
> Right Thing. But in Python, it is.)
Strangely enough, while 1 - loop is quite often the most intuitive way
Ville Vainio
> (The other side of the coin is that my only argument for more looping
> primitives is that while-1 loops are ugly-looking, and don't make for
> the most readable code. Some people disagree or feel it's less
> important. And personally I always feel like I'm undergoing some kind
> of algorithmic failure when I code one; like I must not be doing the
> Right Thing. But in Python, it is.)
Strangely enough, while 1 - loop is quite often the most intuitive way
Terry Reedy
"Ville Vainio" <vva...@tp.spt.fi> wrote in message
news:ad496f8.02070...@posting.google.com...
> Strangely enough, while 1 - loop is quite often the most intuitive
way
> to do things, yet it's (implicitly) frowned upon in many programming
> language cultures.
When I first learned Python, I found it somewhat grating, but I have
since learned to think of 'while 1' as a spelling for 'loop' and 'if
<condition> break' as a corresponding spelling for 'while not
<condition>' (and vice versa for 'not' reversed).
TJR
Ingo Linkweiler
>
>Just like the GOTO, or any other syntax from another language they belong to
>other languages and not python. A good coder learns to program in the idioms
>of the language they are using. Or they just write in the same style
>everywhere and their perl, C, java, whatever looks like their first language.
>
>
am using it, but I just think a repeat-until looks better. If nobody
else has this opinion: Let's forget my stupid question <8-)
Ingo
Andrae Muys
> I know that I can use a while loop with break instead of repeat-until. I
> am using it, but I just think a repeat-until looks better. If nobody
> else has this opinion: Let's forget my stupid question <8-)
>
Two comments:
Please do a google-groups search for "repeat until do while" in c.l.p,
once you've finished reading all the past discussion on this topic
I'll join you in celebrating the start of the 4th millenium ;). Of
course to summarise, you will ask about adding a post-tested loop to
python; somebody will reply that they use while 1:/if:break; you
will suggest you don't like while 1:; eventually the noise will wake
up the martelli-bot who will rave about Knuthian N-1/2 loops and
generic looping constructs; the thread will petter out and lie
dormant until next time.
IOW, you're going to have to do alot better then a two line post if
you want to overcome the inertia this issue has achived over the
years.
Personally I couldn't care less, if I find myself writing any form of
explicit loop I tend to consider it an algorithmic flaw. So I tend to
use list comprehensions, and occasionally map(). Of course I
recognise that sometimes a foreach loop (written for..in..: in python)
is cleaner, and less regularly a while-loop, but when it comes to
aesthetics by the time I get to a while loop, using while 1:/if:break
is a trivial matter.
Andrae
Greg Ewing
>
> I know that I can use a while loop with break instead of repeat-until. I
> am using it, but I just think a repeat-until looks better.
The trouble with repeat-until is that the entire loop always
executes at least once, even if the stopping condition is
true at the outset. The more experience you get at programming,
the more you come to realise that situations where this is
the right behaviour are extremely rare, and in the vast
majority of cases, writing a loop that way is asking for a
bug.
On the other hand, a situation that *is* very common is
a loop-and-a-half, with the exit condition in the middle.
So far, I've never seen *any* really good loop-and-a-half
structure in any language, and I think Python has a chance
to be truly innovative here.
The syntax I favour at the moment for Python looks like
while:
line = f.readline()
gives line <> "":
do_something()
Some day I'll get around to PEPping this...
--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg
Ville Vainio
> Strangely enough, while 1 - loop is quite often the most intuitive way
...
And note that I'm not exceedingly thirsty for attention by
triple-posting this thing. Blame google groups.
Michele Simionato
>
> On the other hand, a situation that *is* very common is
> a loop-and-a-half, with the exit condition in the middle.
> So far, I've never seen *any* really good loop-and-a-half
> structure in any language, and I think Python has a chance
> to be truly innovative here.
>
> The syntax I favour at the moment for Python looks like
>
> while:
> line = f.readline()
> gives line <> "":
> do_something()
>
> Some day I'll get around to PEPping this...
Python2.2 has already
for line in f: do_something()
where f is a file object.
--
Michele Simionato - Dept. of Physics and Astronomy
210 Allen Hall Pittsburgh PA 15260 U.S.A.
Phone: 001-412-624-9041 Fax: 001-412-624-9163
Home-page: http://www.phyast.pitt.edu/~micheles/
Alex Martelli
...
>> while:
>> line = f.readline()
>> gives line <> "":
>> do_something()
>>
>> Some day I'll get around to PEPping this...
>
> Python2.2 has already
>
> for line in f: do_something()
>
> where f is a file object.
...and for those cases where the function called is
not specifically f.readline(), iter can still help:
while:
blup = anobj.amethod()
if blup == '': break
do_something(blup)
becomes:
for blup in item(anobj.amethod, ''):
do_something(blup)
You can take this as an indication of things to come,
maybe -- appropriate iterators or other generators do
let you express just about any loop as a for.
My tutorial about iterators and generators is up for
download at the Europython site, www.europython.org,
since I just presented it at the Europython conference.
Not sure about the URL, and www.europython.org is not
responding right now so I can't check -- anyway, what's
up for sure is a ZIP of the .PPT (Microsoft Powerpoint
file) -- Marc Andre Lemburg also kindly turned it into
a .PDF file, but I don't know if that's up for download
yet (but should be pretty soon anyway).
Alex
Thomas Bellman
> On the other hand, a situation that *is* very common is
> a loop-and-a-half, with the exit condition in the middle.
> So far, I've never seen *any* really good loop-and-a-half
> structure in any language, and I think Python has a chance
> to be truly innovative here.
As others have already said, iterators can sometimes alleviate
this problem.
And there is *one* language where I think the structure for
loop-and-a-half *is* good: Forth. The syntax goes something
like
BEGIN
spam
spam
spam
eggs?
WHILE
norwegian
blue
REPEAT
The call to 'eggs?' is the predicate for checking whether the
loop should continue or not; it should put zero (0) on the stack
if it should break, and non-zero if it should continue. 'WHILE'
pops the top number off the stack, and if that number was zero,
it jumps to after 'REPEAT', but if it is non-zero, the loop
continues with the words after 'WHILE'. The 'REPEAT' word
unconditionally jumps back to 'BEGIN'.
Some dialects of Forth allow several calls to WHILE within the
loop, so it could look like
BEGIN
part-1
test-1
WHILE
part-2
test-2
WHILE
part-3
test-3
WHILE
part-4
REPEAT
I *would* have liked that to be
repeat:
part_1()
while test_1():
part_2()
while test_2():
part_3()
while test_3():
part_4()
in Python, but that is unfortunately not compatible with the
current Python syntax. :-(
--
Thomas Bellman, Lysator Computer Club, Linköping University, Sweden
"You cannot achieve the impossible without ! bellman @ lysator.liu.se
attempting the absurd." ! Make Love -- Nicht Wahr!
Alexis Layton
<see_repl...@something.invalid> wrote:
> On the other hand, a situation that *is* very common is
> a loop-and-a-half, with the exit condition in the middle.
> So far, I've never seen *any* really good loop-and-a-half
> structure in any language, and I think Python has a chance
> to be truly innovative here.
>
> The syntax I favour at the moment for Python looks like
>
> while:
> line = f.readline()
> gives line <> "":
> do_something()
>
> Some day I'll get around to PEPping this...
The syntax I've always liked comes from an old SIGPLAN Notices
submission, which I am unable to locate right now, and therefore
cannot attribute. Of course, it was for a Algol-ish/Pascal-ish
language, and adapting it to Python runs into a little trouble.
Please not that no attempt has been made to conserve reserved
words. This is a theoretical excercise.
It goes along the lines of
loop:
<stmts>
exit when <cond> ALTERNATIVE: when <cond> exit
<stmts>
when <cond>:
<stmts>
exit
<stmts>
...
Pseudo BNF: (note does not handle suite one-liners)
LoopStmt -> "loop" ":" INDENT LoopSuite DEDENT
LoopSuite -> Statement
| ExitWhenClause
| WhenClause
ExitWhenClause -> "exit" "when" Condition
WhenClause -> "when" Condition ":" INDENT ExitSuite DEDENT
ExitSuite -> Statements* ExitStatement
ExitStatement -> "exit"
Any attempt to move the "when" clauses out to the "loop" level of
indentation runs into the problem of continuing the loop after the
exit:
loop:
unconditional-stmts
when <cond>:
cleanup-stmts
exit
<<where do we put the next unconditional statement?>>
If we don't allow cleanup, we could do
loop:
stmts
exit when <cond>
stmts
...
which is certainly simpler but less practical. It has the "distinction"
of having indentation following a non-":" statement. This just
looks wrong to me, but in any exit-in-the-middle construct you
have this problem.
Note that there is no reason that exit/when clauses could not also
apply to for and while loops.
The principal advantages of exit/when clauses is that they are lexical
constructs tied to the loop itself, rather than arbitrarily deeply
constructed if-elif-else statements with break/continue statements.
loop:
thing = getAThing()
exit when not thing
thing.process()
--
Alexis Layton
alexis . layton @ post . harvard . edu
Andrew Clover
> I *would* have liked that to be
>
> repeat:
> part_1()
> while test_1():
> part_2()
> while test_2():
> part_3()
> in Python, but that is unfortunately not compatible with the
> current Python syntax. :-(
I like that kind of syntax. I'd like to propose an alternative
keyword:
while cond1:
dofoo()
andwhile cond2:
dobar()
with an analogous structure:
if cond1:
dofoo()
andif cond2:
dobar()
else:
doqux()
where foo is done if cond1, bar is done if (cond1 and cond2) and qux
is done if not (cond1 and cond2). For consistency with elif it could
be called anif instead?
--
Andrew Clover
mailto:a...@doxdesk.com
http://and.doxdesk.com/
Rich Harkins
> keyword:
>
> while cond1:
> dofoo()
> andwhile cond2:
> dobar()
>
So does this eqate to the following in current python?
while cond1:
dofoo()
if cond2:
dobar()
or?
while cond1:
dofoo()
if cond2:
dobar()
else:
break
> with an analogous structure:
>
> if cond1:
> dofoo()
> andif cond2:
> dobar()
> else:
> doqux()
>
and this?
if cond1:
dofoo()
if cond2:
dobar()
else:
doqux()
or?
if cond1:
dofoo()
if cond2:
dobar()
else:
doqux()
else:
doqux()
> where foo is done if cond1, bar is done if (cond1 and cond2) and qux
> is done if not (cond1 and cond2). For consistency with elif it could
> be called anif instead?
What if I get more complicated:
if cond1:
true1()
andif cond2:
true2()
elif cond3:
true3()
andif cond4:
true4()
else:
false()
How does this translate to current Python? (I'm gettting a headache now)
I think I like Python's explicit nature better than these cases (as well as
the all of the messages in this thread). I don't have to guess how Python
will process my instructions nor do I have to think very hard about what a
program will do when reading it.
Rich
Paul Svensson
>Greg Ewing <see_repl...@something.invalid> wrote:
>
>> On the other hand, a situation that *is* very common is
>> a loop-and-a-half, with the exit condition in the middle.
>> So far, I've never seen *any* really good loop-and-a-half
>> structure in any language, and I think Python has a chance
>> to be truly innovative here.
>
>As others have already said, iterators can sometimes alleviate
>this problem.
>
>And there is *one* language where I think the structure for
>loop-and-a-half *is* good: Forth. The syntax goes something
>like
(---)
Bourne Shell also has
while
foo
bar
gazonk ?
do
gurka
done
>I *would* have liked that to be
>
> repeat:
> part_1()
> while test_1():
> part_2()
> while test_2():
> part_3()
> while test_3():
> part_4()
>
>in Python, but that is unfortunately not compatible with the
>current Python syntax. :-(
The problem is that there's no indication where the repeat: block ends.
If we should invent new syntax, I would limit it to the loop-and-a-half,
and keep "break" for multiple exit loops.
repeat:
part_1()
while test_1():
part_2()
This is unambigous to the compiler, but not could be confusing to humans,
specially if part_1() is large. Adding more new keywords makes it clearer:
repeat:
part_1()
until not test_1():
part_2()
Or, inspired by Bourne, with no new keywordss at all (and even more cryptic):
while:
part_1()
test_1():
part_2()
I don't see anything like this happening anytime soon.
/Paul
Andrew Clover
>> while cond1:
>> dofoo()
>> andwhile cond2:
>> dobar()
> So does this eqate to the following in current python?
Yes, the latter:
> while cond1:
> dofoo()
> if cond2:
> dobar()
> else:
> break
Except that any else-clause following the loop would be unaffected.
>> if cond1:
>> dofoo()
>> andif cond2:
>> dobar()
>> else:
>> doqux()
> and this?
Again, the latter:
> if cond1:
> dofoo()
> if cond2:
> dobar()
> else:
> doqux()
> else:
> doqux()
I find myself writing structures like this very often, in many languages.
I find both current solutions - repeating the else-clause as above, or
using a temporary variable - quite unsatisfactory.
> What if I get more complicated:
> [if ... andif ... elif ... andif]
Two possibilities:
a. andif has higher precedence than elif, binds to last else/elif
clause only
b. this is too confusing to be usable, allow andif only after an
if or andif, not else/elif.
I prefer (b).