variable inirialization and loop forms (was Re: why no "do : until"?)

Steve Lamb grey at despair.rpglink.com
Wed Jan 3 17:10:36 EST 2001


On Wed, 3 Jan 2001 13:40:38 +0100, Alex Martelli <aleaxit at yahoo.com> wrote:
>Initializing variables *to correct values* is a great thing -- but using
>*arbitrary* values for the initialization isn't optimal style.

    You know, Alex, that is why I enjoy reading your responses do me.  You
never come off like you're preaching, only teaching.  

    I still stand that initting a variable is just that, setting it to a
known, arbitrary value.

>This matters!  For example, the getCurrentTemperature function *might*
>smooth actual point-measurements (which 'wobble') by averaging with
>the previously-measured value; 

    Then don't do it that way.  Given other considerations, yes, other forms
are optimal.  But to unilaterally state that it is bad to do something under
all conditions gets people in more trouble than it gets them out of.

>*IF AND WHEN* there are NO costs in testing in the while
>statement, sure.  

    Then why not take the other extreme; remove the test in the loop.  Remove
for, remove while, remove any other's I've missed.  

loop: 
  do something
  if break condition:
    break

    There, no argument over while 1:, for (;;;), do/while, while/do, while
true, endless, zippity-do-da, snaglefarf, poo or any other such key word.  A
loop is a loop is a loop and arguing semantics of that loop and its
construction is utterly meaningless since the logical conclusion is simple,
enter a loop, break out of it when needed, no test condition in the loop
itself.

1: while

loop:
  if foo:
    break
  do something

2: for

loop:
   if blah = x
     break
   do something
   blah += step

3: for x in y, foreach x (y)

loop:
   blah = list.pop(0)
   if not blah:
     break
   do something

4: do while/until

loop:
   do something
   if foo:
     break


>But often there ARE some costs: when a loop WANTS to be an "N-and-a-half
>times loop", the general form, then coding it as such (which in Python is
>expressed by while 1/...break) produces simpler and therefore better code
>than making believe the idiom isn't available.  

    I'm not saying it isn't available, I'm pointing out that for those who
didn't like it there was something else that could be done.  But hey, as I
stated above, why not just get rid of all the different loop keywords and just
do it the want that provides the lest amount of variance if maintainability is
the only consideration one has?

    If there is often a cost in a loop wanting to be something that it is not
then why try to confine people to 3-4 cutesy keywords and let them just build
each loop as needed by providing one keyword to loop over code.  Seems far
simpler for maintainability in the long run if often we're not using the
keywords.

    Hell, we could even take that further.  If found that we have else on
while and for to be useful.  So why not have break also allow an optional
return value?  But wait, why have else on a loop at all?  Why not just remove
else on loop and allow the optional return value (else on a loop being really
an if) through an exception and a try: block?  Seems to be that is more
versitile than an else keyword attached to a loop which only takes one
condition, doesn't it?

    So with that we've gotten rid of for/else, while/else and also given
people a method of making whatever loop, loop and a half, loop and half twist
with a triple gainer in the middle that they want.

    I mean, if the semantics of it all is more important than actually getting
work done, right?  :)

    Oh, and to stave off those that do dislike while 1: and similar
constructs...  Don't kid yourself, having a test condition in te while is no
more or less reliable than having the test condition elsewhere in the loop
unless it is something independant where you're going to place an arbitrary
limit on the iterations over the loop and actually keep track.  A while foo:
loop that never modifies foo is just as endless as while 1: and both can be
aborted with an if:break.  So a "loop: if:break" construct is functionally
identical to a while condition: consutruct and no amount of semantical arguing
will change that.

    We done now?

-- 
         Steve C. Lamb         | I'm your priest, I'm your shrink, I'm your
         ICQ: 5107343          | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------



More information about the Python-list mailing list