why no "do : until"?

[Alex Martelli]

"Bjorn Pettersen" <pbjorn at uswest.net> wrote in message
news:3A53F4B1.6227D241 at uswest.net...
    [snip]
> If what you want to do can't be expressed directly in the language, and
> the only reason people don't want to change it is because they're used to
> the status quo, I feel justified in calling it a holy cow ;-)

The "if-then" construct is reasonable; as the antecedent is false,
of course, this sillogism tells us nothing about the consequent.

MY "only reason" not to want ad-hoc 'expressions' to be added to
Python is hardly "because I'm used to the status quo" -- I have
barely more than a year's worth of Python experience, and much,
MUCH more experience in a huge variety of other programming
languages -- from a Fortran that wasn't _quite_ up to Fortran IV
standards, to C# (just chronologically mind you -- lots of 'older'
languages such as Haskell are obviously much 'newer' than C#!-).

Even today, the amount of somewhat-C-ish-syntax code I write and
maintain on a daily basis (C, C++, Java, C#, Javascript...) is
higher than the amount I get to write and maintain in Python.  So,
it would be utterly silly to claim that I'm somehow more "used"
to the lack of do/while forms than to its presence -- not to speak
of the even more absurd claim that such totally phantomatic 'being
used to' is the "only" reason for my preferences.

I wouldn't mind it, in the abstract, if some backwards-incompatible
Python successor adopted a better syntax for its general loops, on
the lines originally suggested by Knuth 27 years ago:
    loop <condition1>:
        <suite1>
    while <condition2>:
        <suite2>
with the 'obvious' ability to elide unused parts.  It's unlikely to
happen, if nothing else because the extremely slight syntax-sugar
advantage of such general syntax is a TINY plus over today's
existing syntax for the identical semantics:
    while <condition1>:
        <suite1>
        if not <condition2>: break
        <suite2>
and no doubt the plus is so small as to not justify the pragmatical
cost of having to change mountains of existing, working code.  Oh well.


I *WOULD* mind, *A LOT*, if, rather than regularizing syntax for the
general form of loop, Python were to add other special-cases with
their own syntax variations.  *SIMPLICITY*!  *ONE* general loop form
(plus the enormously-useful 'for' loop, for the extremely frequent
case where the items in a sequence are what we're looping on) is just
right.  Every language (every programming system) tends to accumulate
'features' with time -- perhaps because, in each single case, it may
seem less trouble to give in to the vocal minority clamoring for 'just
one more addition for expressiveness', than to fight to keep the
overall system *SMALL AND SIMPLE*.  End results: PL/I, Ada, C++, Perl...

The "just a little mint" syndrome needs eternal vigilance to fight
against it -- despite Guido's superb stewardship, even Python can
fall prey to it, as witness the horrid 'print>>' blotch.  Which is
why many of us take the trouble to argue against each and every one
of the "little extra features" which keep being proposed on this
group, striving to show they are not warranted -- to *KEEP IT SIMPLE*.

Sometimes we manage to convince the current one in the endless stream
of 'enhancers' that Python is actually better off *staying SIMPLE*,
because its existing mechanisms afford perfectly acceptable solutions;
sometimes we don't -- them's the breaks.  As long as the slide towards
more and more language complexity is resisted, by pre-empting the
formation of a consensus towards complexification, I still think my
time and energy well spent.


Alex