A single, general looping construct? (was: why no "do : until"?)

William Sonna wlsonna at attglobal.net
Thu Jan 4 23:35:46 EST 2001


On Thu, 4 Jan 2001 11:07:39, "Alex Martelli" <aleaxit at yahoo.com> 
wrote:

> "William Sonna" <wlsonna at attglobal.net> wrote in message
> news:0O7zTzsxerl5-pn2-SISYKtwXTOmR at bill...
>     [snip]
> > Object Rexx's implementation of the generalized do is the best I've
> > seen (in a real language, that is).  Works like this:
> 
> Snipping: 5 different forms that _still_ don't cover the Knuth-identified
> general case of "N-and-1/2-times" loops.  We clearly have a very
> different idea of what the word "best" means.
>

My definition is easy, simple and obvious.  And Object Rexx's are 
simple, easy and obvious.  Python's while is simple, easy and obvious.
 Python's repeat until is simple, easy, but NOT OBVIOUS.

I find the N and 1/2 times to be totally loopy (pun intended).  Don't 
you?
 
> *Entities are not to be multiplied needlessly* -- Occam's razor.  ONE
> general loop form, plus one form for the very important case of loops
> over a sequence, seems just right to me.
> 
> 
> > while count < 100:   # zero or more iterations
>     [snip]
> > until count <=100:    # one or more iterations
>     [snip]
> > Which are all (with the exception of the ones that are identical or
> > nearly identical) cleaner and even more Pythonic than Python.
> 
> We clearly also disagree on the adjectives 'clean' and 'Pythonic'.
> 
> Since when is it Pythonic to have many equivalent ways to express
> one concept?

Zero or more  of  something is not mathematically or logically the 
same as one or more.

So expressing "one or more" as "one plus zero or more" smacks of using
"x^0" to express "one".

>  It's not Python that has both 'if' and 'unless', for
> example -- it's Perl.  A language which has both while and until
> for loops, but doesn't have both if and unless for non-loop tests,
> is inconsistent; one which has one form in each case, and one which
> systematically adopts multiple forms whenever feasible, are each
> consistent, albeit with, clearly, VERY different underlying
> philosophy.
> 

You don't have to take my word for it......Go ask the re module if it 
knows the difference.

It does (thank GOD).  Otherwise [a,b,c]+ would have to be written as 
[a,b,c][a,b,c]+, which is generally accepted as bad style.

So what's the deal with Python?

> "Do the simplest thing that can possibly work", "there should be
> exactly one way to perform a task" -- that is one philosophy.  It
> is Python.  The exactly-opposite philosophy, that of "the more
> ways, the merrier", of exhuberant, post-modern richness, is Perl's.
> How can you possibly call 'Pythonic' something which goes so
> drastically against the grain of its basic tenets?
> 

> > Fortran had even simpler control structures than Python, and was a
> > royal pain to use as a result.
> 
> Surely you're joking, Mr Sonna.  Have you ever USED Fortran?!  I
> must have written and maintained many tens of thousands of lines in
> it.  How can you POSSIBLY assert that the set of its control
> structures is "simpler than Python's"?!  Simple GOTO, assigned
> GOTO, computed GOTO, logical IF, arithmetic IF, the DO statement...
> it's *brimming* with complexity!  (Let's not even get into
> Fortran 77, which added even more).  Just the rules about what
> kinds of GOTO's are acceptable across which kind of DO-statement
> boundaries get longer to explain than the whole Python language!-)
>

True, they were not easy to use.

But at their core they were EXTREMELY simple concepts:  GOTO, IF, and 
DO.  

The variations you describe are grafted workarounds for the inherent 
limitations of a limited set of control structures.  Not unlike the 
loop construct we are discussing.

I am of the opinion that control structures should state what they 
mean in the simplest possible terms.  One of the reasons I always 
hated Fortran.

[snip]

> 
> The need for structure is not under discussion: rather, the basic
> guideline on how to pick the structures.  Some languages bask in
> 'being very expressive' by making you choose among umpteen ways
> to express the same thing, a la Cobol's
>     ADD CREAM TO ESPRESSO GIVING CAPPUCCINO
> vs
>     LET CAPPUCCINO = CREAM + ESPRESSO
> 

I think that  CAPPUCCINO = CREAM + ESPRESSO is even better.

For the same reason that  [a,b,c]+ is better than [a,b,c][a,b,c]*.

Of course, CREAM + ESPRESSO + WHISKEY is better when its twenty below 
zero :-)

[unprovoked anti-Perl advocacy snipped - PLEASE- I'm not here to 
troll]

> I have repeatedly agreed that it's not optimal syntax, but
> *adding* special-case syntax forms is exactly the wrong way
> to go.  ONE general syntax form for general loops:
>     loop <condition1>:
>         <suite1>
>     while <condition2>:
>         <suite2>
> would probably be ideal (with the loop-over-sequence form,
> since it's *such* a common case, singled out).  But it ain't
> gonna happen -- the gain is just too small for the disruption.
>
> 

[snip]

> I *particularly* disagree that Python's syntax for the general
> loop is "uniquely inelegant", whatever you're trying to convey
> with that "uniquely".  The spelling of the second clause in
> the general loop form as (indented) 'if not <condition2>: break'
> is, at worst, slightly awkward -- the very popularity of 'break'
> as a keyword in other languages (and the extremely similar
> semantics of equivalent keywords in languages which have a
> slightly different syntax, such as Perl's "last") helps to
> mitigate the perception of this awkwardness.
> 

In summary:

You may love it in your heart, but

while 1:
    yadda
    yadda
    if "whatever you think (should|should not) happen":
        break

Is clumsy and inconsistent compared to:

    until "whatever you think (should|should not) happen":
          yadda
          yadda

Which has:

    1. the same number of lines
    2. the same relative location and indentation for test
    3. the same location and indentation for yadda yaddas

as:

    while "whatever you think (should|should not) happen":
        yadda
        yadda

Which is optimal. 

Thus my claim that it is more consistent with the basic "while" loop 
and  thus more "Pythonic" than Python's version.

As for generalized while.......What would it really add?



More information about the Python-list mailing list