Something I love about Python is that almost everything you do can be
written in pseudo code then carried across into Python without a great-
deal of difference.
But reading through the warts and reading about a lack of "do while
statements" I also started to ponder about the "'do something' if
'true' else 'do this'", and pondered if perhaps this statement could
do with the including of the keyword do.
It would clear up the usage of such a statement because it would read
happily. Or am I making a mountain out of an ant hill?
I doubt this will gain any traction. Similar proposals have been made
before - e.g. http://www.python.org/dev/peps/pep-0315/
But they didn't
There are a few tricks you can use to emulate the desired behavior without
being to disruptive to the eye. E.g.
while True:
do_something()
if condition: break
Granted,
do
do_something()(
while condition
is a bit more pleasant - but not enough to change the language I'd say.
Diez
When I use languages that supply do-while or do-until looping
constructs I rarely need them.
I personally miss
for init; condition; next:
more than do-while, but the structured for loop doesn't fit in
Python since init and next would (probably) have to be statements
(or statement suites) rather than expressions. Hence, the cool
innovations of iterators and generators, which otherwise might
not have found a home in Python. I wonder what programming Python
was like before iterators sometimes.
However, did you have an specific need for a do-while construct?
Perhaps we could show you the alternatives.
--
Neil Cerutti
Python has support for this in versions >= 2.5:
>>> a = range(0, 5)
>>> b = range(5, 8)
>>> min(a) if sum(a) < sum(b) else min(b)
0
In prior versions, you can use the and/or trick:
>>> (sum(a) < sum(b) and [min(a)] or [min(b)])[0]
0
-Tor Erik
> When I use languages that supply do-while or do-until looping constructs
> I rarely need them.
...
> However, did you have an specific need for a do-while construct? Perhaps
> we could show you the alternatives.
"Need" is a strong word. After all, all looping constructs could be done
with a conditional jump, so arguably we don't "need" while or for either.
But loops that run at least once is a basic element of algorithms.
Perhaps not as common as the zero or more times of the while loop, but
still fundamental. It is a shame it has to be faked using:
while True: # force the first iteration to always run
process
if condition: break
Ugly and misleading. But here to stay until Guido has an epiphany and
decides that a do...until loop is elegant enough that it is well worth
the addition of two new keywords. (I find the idea of do...while
unspeakable. The test is backwards.)
Oh well... when I'm Malevolent Dictator For Life, Guido will do as he's
told, and no mistake!!!
*wink*.
--
Steven.
I disagree. Nothing is being faked. The generic loop is
while True:
pre_process
if condition: break
post_process
If there is no pre_process, abbreviate the first two lines as 'while
condition:'. If there is no post_process, some would like another
abbreviation. Understanable. But the use cases seem relatively few. And
anyway, a competant programmer must understand the generic loop and a
fraction form, which I believe is at least as common as the no post_process
case.
Terry Jan Reedy
And this generic loop is faked. There is no notion in the language that
somehow connects this if statement to be a breaking condition for a
loop. If it would be a real syntatic construct in the language, it would
probably look more like:
do:
pre_process
until condition:
post_process
Personnaly I would have preferred to have this one generic loop
construct with no abbreviations instead of having the while abbreviation
that is to be combined with a break statement to fake the generic loop.
--
Antoon Pardon
If really beginning, an overview of this whole idea of control structures
makes sense, such as this wikipedia article:
http://en.wikipedia.org/wiki/Control_flow
Then explain how Python is very minimalist in its approach, unlike
some languages, which try to provide all kinds of control structure
semantics, including multiple case loops (do... case... case...)
which Python famously does not natively have either.
> they find the "while" logic to be unintuitive, and I often find myself
> feeling the same way: crafting it with the until logic, and then reversing
> it.
I wouldn't make "intuitive" the guiding light in all cases, as it's
often just code for "conditioned reflex" or "what we're used to."
Usually beginners outgrow their initial discomfort, like when
learning to drive stick instead of automatic or whatever.
Kirby
I agree that it's fundamental, but I'd like to mention that I've
written many thousands of lines of Python code, from throwaway code
for demonstration to enterprisey servers and all sorts of things in
between and I've *never* written a "1 or more times" loop except when
I was demonstrating that exact thing. One thing that Python has
definitely changed my thinking about is that I tend to formulate both
problems and solutions in terms of iteration over sequence rather than
as traditional conditional based looping. If I need a "1 or more" loop
I formulate the problem as a sequence of 1 or more elements.
This isn't something I go out of my way to do, simply the way I think
about problems in Python.
I just did a scan of some of the code I've been working on for the use
of while. This is a few thousand LOC (and one project, an SVN
renderer, doesn't have any use if it at all) and I've got exactly 3
instances.
I've got a while True: as the mainloop of a thread, which technically
qualifies as a "1 or more" loop but doesn't count because the exit
condition is complicated and couldn't be easily written with do..until
(you'd either break the same way or you'd have to set a flag instead,
which is ugly).
I've got the use of while as a counter in some code that unpacks bits
from an integer (interop with C structures). It's a 0 or more loop.
And I've got an iterator for a linked list, which is close but I don't
want to yield anything if the head is None, so it's in a plain while:
style:
def linkedListIter(head, nextName="next"):
current = head
while current:
yield current
current = getattr(current, nextName)
> On Dec 11, 2007 2:19 PM, Steven D'Aprano
> <st...@remove-this-cybersource.com.au> wrote:
>> On Tue, 11 Dec 2007 15:06:31 +0000, Neil Cerutti wrote:
>>
>> > When I use languages that supply do-while or do-until looping
>> > constructs I rarely need them.
>> ...
>> > However, did you have an specific need for a do-while construct?
>> > Perhaps we could show you the alternatives.
>>
>> "Need" is a strong word. After all, all looping constructs could be
>> done with a conditional jump, so arguably we don't "need" while or for
>> either.
>>
>> But loops that run at least once is a basic element of algorithms.
>> Perhaps not as common as the zero or more times of the while loop, but
>> still fundamental. It is a shame it has to be faked using:
>>
>>
> I agree that it's fundamental, but I'd like to mention that I've written
> many thousands of lines of Python code, from throwaway code for
> demonstration to enterprisey servers and all sorts of things in between
> and I've *never* written a "1 or more times" loop except when I was
> demonstrating that exact thing. One thing that Python has definitely
> changed my thinking about is that I tend to formulate both problems and
> solutions in terms of iteration over sequence rather than as traditional
> conditional based looping. If I need a "1 or more" loop I formulate the
> problem as a sequence of 1 or more elements.
I'm not entirely sure this is a good, or bad, thing. Iteration over a
sequence is one mental tool. while and do loops are two others. Having
more tools available frees you to a wider range of possible solutions --
which can mean people can find better solutions, or they can find worse
solutions. One good tool is better in many ways than two poor tools, but
on the flip side, relying on only one tool constrains your thinking.
It's a shame that generators and iterators came to Python so late in its
history, otherwise Guido could have made the language even more
minimalist by using only one loop construct (for) and not needing the
while keyword.
*half-wink*
--
Steven
> I agree that it's fundamental, but I'd like to mention that I've
> written
> many thousands of lines of Python code, from throwaway code for
> demonstration to enterprisey servers and all sorts of things in
> between
> and I've *never* written a "1 or more times" loop except when I was
> demonstrating that exact thing. One thing that Python has definitely
> changed my thinking about is that I tend to formulate both problems
> and
> solutions in terms of iteration over sequence rather than as
> traditional
> conditional based looping. If I need a "1 or more" loop I formulate
> the
> problem as a sequence of 1 or more elements.
How would you code an integrator-loop to stop when its error goes below
some limit with iterations? While loops are as far as I can tell
essential for
a number of problems in math and physics.
Cheers
TG
I have wanted do-while loops in exactly one kind of algorithms, when
you generate something and you have to keep trying until it gets
right. For example, generating random and non-overlapping points on a
grid:
import random
grid = dict()
for i in range(10):
while True:
x = random.randint(0, 4)
y = random.randint(0, 4)
if not (x, y) in grid:
break
grid[x, y] = 1
The loop runs one or more times until a vacant spot in the grid is
found. This type problem would be better expressed using a do-while:
import random
grid = dict()
for i in range(10):
do:
x = random.randint(0, 4)
y = random.randint(0, 4)
while (x, y) in grid
grid[x, y] = 1
--
mvh Björn
I often miss what can be done in other languages
that support what I call 'side effect' assignment:
while x = get_val_somewhere():
process(x)
Although, I know that if I write the get function,
I could make it an iterator, and do:
for x in get_val_somewhere():
process(x)
in which case, I'm even happier.
--
Posted via a free Usenet account from http://www.teranews.com