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

[Alex Martelli]

"William Sonna" <wlsonna at attglobal.net> wrote in message
news:0O7zTzsxerl5-pn2-
d47FDdZYq25y at bill...
    [snip]
> > > So what's the deal with Python?
> >
> > It's a general-purpose programming language, with no need for
> > any special compatibility with existing ones.
>
> I was going to drop this, Alex, but I simply CAN'T let a statement
> like that go by unchallenged, so (with apologies).........
>
> .......Since you haven't backed this seemingly sweeping statement up
> with any examples,  would you mind explaining what you mean by
> "special" compatibility?

Some programming languages are designed with very specific (aka
'special') compatibility with other existing ones.  For example, C++ was
designed under the strong constraint of compatibility with C -- ability
to compile most C programs (e.g., all K&R 2nd edition C programs must
also be compiled by C++ compilers and give the same results); Java chose
much-weaker C-compatibility (basically, some syntax similarity).

Occasionally, a language is designed with NO interest at all in being
even "generally" (as opposed to "specially") compatible with, or similar
to, any other existing programming language.  APL, Snobol, Prolog...
their semantics (and syntax) were utterly revolutionary in the context
of other programming languages existing at the time of their design.

Python does have some 'generic' (aka 'general') compatibility with, or,
rather, similarity to, existing languages -- many of its keywords, for
example, are the same as the ones other languages use for similar
functionality ('while', 'for', 'if', 'else', 'try', 'except', 'class', ...),
and
I'm sure you've also noticed other such similarities.  On the other hand,
it has no design goal of specifically (specially) 'staying close to' any
single given existing language.  So, for example, if the format operator's
sublanguage ("%s" for 'here, a string', "%20s" for, 'here, a string that
takes at least 20 spaces', etc etc) is SO close to the sublanguage used
in the format of C's printf (&c), it must be a deliberate choice by the
language designer, not stemming from special constraints to keep
compatibility or similarity with existing languages' usage.


> 1.  Wasn't the adoption Perl-style regex's essentially a tip of the
> hat to a widely used, widely understood (and refreshingly un-lippy)
> syntax?

I see Tim has answered this question (which is good, because I
have no idea of what 'un-lippy' is supposed to mean).


> 2.  If convenience at the expense of redundancy trully has no place in
> Python,  how do explain the likes of map, reduce and list
> comprehensions?  Are THEY not "special" instances of "while" with
> abbreviated syntax?

Well, for that matter, 'while' itself is a special instance of recursion;
whatever you can express as a loop, you can express recursing.

Python has a lot of solid Dutch pragmatism behind it: it's never
minimalist for the sake of minimalism -- it turns out to be _pretty
close_ to minimalist because utter simplicity is so often the best
pragmatical choice, so-called 'convenience' be darned (in the world
of programming, 'convenience' is generally the buzzword for adding
3,420 'shortcut' features each of which will actually get used about
as often as hell freezes over, ignoring the utter INconvenience of
the resulting bloated, complex, redundant program-systems).

For example: if you had only recursion, not 'while', most likely at
least 9 in 10 of your uses of recursion would 'actually' be 'loops'.
Such preponderance justifies giving the loop "special case" its own
syntax & semantics, from a pragmatic viewpoint.  Similarly, though
less dramatically, the frequence of 'for' wrt 'while' justifies having
two separate statements on the same kind of pragmatical grounds.

The small functional-programming 'side' of Python does elicit
controversy among some Pythonistas, as the actual and desirable
frequency of use of map (reduce, filter) and the legibility thus
gained wrt simple explicit loops are anything but clear.  In fact,
I've heard occasional regrets about them.  Still, as they are
*functions*, NOT *statements*, the situation is obviously totally
different.  Python's *libraries* are anything but 'minimal': I'd call
them pretty rich; and I have absolutely no trouble with this, since
ignoring functions, and whole modules, you don't care about, is
far easier & practical than doing so for core-language features.

List-comprehensions seem to be somewhat controversial, too,
though I, personally, like them a lot.  They're a slightly different
syntax in which you can use existing keywords ('for' and 'if') to
gain more compactness in some cases -- augmented assignment
can be seen similarly (although in that case the ability to do an
operation in-place can play an important role, so it's not _just_
syntax sugar -- while list comprehensions are).  Anyway, adding
the ability to use some existing keywords, with equal semantics,
in a somewhat syntactically different (more compact) way, is
hardly a major addition to the language.


> I submit that the ONLY practical purpose 1) or 2) serve is to produce
> cleaner (ie, less wordy) code.

It's arguable (and argued about) that more-compact code is
'cleaner' (personally, I think it can often be -- but any given
case can be a delicate question of taste and style).

> They ARE, therefore, Miesian (Mies Van Der Rohe), or  minimalist, or
> Pythonic, if you prefer; DESPITE being redundant.

Non sequitur (it does not follow): the "therefore" is unwarranted.
"Being minimalist" does not come from "letting something be expressed
more compactly" -- else Perl would be minimalism's triumph.  It's not.
And few would argue that the utter compactness it enables lets the
code that's so written be "cleaner"!


Alex