[Python-Dev] re: syntax feedback from LANL course (very long)

Tim Peters tim_one@email.msn.com
Fri, 4 Feb 2000 03:55:02 -0500


Just picking on the loop issue here.

[Ka-Ping Yee, on Greg Wilson's post]
> Wow, these were really informative.  Thanks for collecting the results.

Ditto!  It's posts like these that make me glad Guido has so much spare time
<wink>.


>> 1. "What's with 'while 1: break' for normal loops?"

> I'd probably agree that this is a significant thing.

Me too:  it's the ugliest thing in Python newbies hit right away, and while
*I* can't really "see" the convolution in "while 1: ... if xxx: break ..."
anymore, that's learned behavior; but I get reminded of how grating it is at
first each time someone new at work starts learning Python.  This one made
Andrew's "Python Warts" paper.  Enough is enough already <0.5 wink>.

> I think it would be very nice to have do...while, and of all your
> examples i liked
>
>     do:
>         first-body
>     while condition:
>         second-body
>
> best.

Actually suggested by Guido Himself on Christmas Eve of '98 (see DejaNews; I
found the URL for Greg offline but have since lost it).  And the IDLE editor
already handles it fine <wink -- but that means pymode is likely to too, and
so also "most things of that kind">.

>>         while:
>>             first-half
>>         and while condition-1:
>>             second-half
>>         and while condition-2:
>>             third-half # [sic]
>>         and while final-condition # no trailing ':'

> This *is* confusing.

It's from an old c.l.py thread; don't recall who suggested it; I don't like
it myself; "and while xxx:" is just sugar for "if not xxx: break"; its
advantage is the absence of new keywords; the "while:" at the top reads
poorly; the semantics of "and while" are indeed unclear at first (IIRC,
Christian took way too many drugs at the time <wink> and tried to generalize
it to "and if" as well ...).

> ...
> "do" doesn't even have to be made into a keyword for the
> do...while construct to work: there is no other valid
> construct in which a name would appear followed by a colon
> as the first thing in a statement or expression, so the
> parser should be able to figure it out.

Good point!  Not the kind of point Guido warms to instantly, but a good
point all the same.  I had already checked, and there are at least two
functions named "do" in Python's own std distribution.  So making "do" a
keyword is very unattractive.  I'm not sure "repeat:" (a la Pascal) or
"loop:" (Icon? too lazy to look it up -- *one* of those loser languages I'm
always irritating people about <wink>) would actually be better.  If hackery
could overload "do" (or repeat, or loop), I'm in favor of it.

if-syntax-matters-then-syntax-matters-ly y'rs  - tim