[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