[Python-ideas] What is Python-ideas for? [meta] [Inspired by: Simpler syntax for basic iterations]

[Stephen J. Turnbull]

Ryan Gonzalez writes:

Avoid top-posting.  It helps prevent posting merely to be
contrary.<wink />  Reordering....

 > Mark Lawrence writes:

 >> Stop pointlessly discussing something that simply is not going to
 >> happen.

 > Like multi-line lambdas, multi-line with statements, null
 > coalescing operators, and all the other topics that come up every
 > other week?

There is a clear qualitative difference here.  Mark is right about the
"repeat n:" proposal, and your comparison is specious.

				*****

The rest of my post is an attempt to present my understanding of some
aspects of Pythonic design thinking as relevant to discussions on
Python-Ideas.  As a running example, I try to argue why this thread
should have ended with at most two posts in it.  (Some might say it
shouldn't have started because of PEP 284, but figuring out relevance
of several hundred PEPs is a task more suited to scripture scholars
than language designers.)

Guido admits the benefits of all of the features Ryan mentions, and
entertains *new* proposals of syntax to invoke them.  That's not
because he's a nice guy handing out warm fuzzies to would-be
contributors.  We currently don't have a good way to do them, where
"good" involves both "concise" and "esthetically pleasing, especially
to Guido".  He really would like to serve the constituencies for those
features (and might even warm up to them himself, given suitable
syntax).

Guido also values the educational use of Python, and when introducing
new features he works hard to find syntax (including choice of
keyword) that is "intuitive" to both new users of Python and new
programmers.  If anybody "gets" CP4E, Guido does.  Of course there are
different ways to get there, but arguing that lack of "repeat n:" is
somehow contrary to CP4E is disrespectful.  It's a different path to
that end.

*This proposal* to introduce a special syntax for pure repetition,
however, obviously falls afoul of several principles *of Pythonic
language design*.  On the contrary, the arguments *for* the proposal
are "non-Pythonic", which doesn't make them unimportant, much less
invalid.  It does, however, make them low-value on *this* list, which
is for proposed improvements to the Python language.  We're not here
to discuss language improvements in general.[1]  Here's my list:

1.  The bar for new keywords is *very* high.  I don't think the
    educational purpose would be well-served by twisting "for" into a
    knot with "for 4:"; that just doesn't correspond to valid English
    usage.  "while 4:" is a little closer (IMO YMMV), but already has
    a meaning so it's out anyway due to backward compatibility.  I
    think this proposal needs a new keyword, and "repeat" is excellent
    for the purpose.  That's already a deal-killer for such a
    specialized construct.

2.  We already have a good way to write "repeat 4:".  The proposed
    syntax is just syntactic sugar, and even in its educational
    context, it's not much sweeter than (proper) use of the existing
    syntax.  Watch one user's lips move as she draws a square:

        First I draw the top, then I go down the right, then I draw
        across the bottom, and then I connect the left up to the top.

    Now compare:

        repeat 4:
            forward(10)
            right(90)

    versus:

        for side in ('across top',
                     'down right',
                     'across bottom',
                     'up left'):
            forward(10)
            right(90)

    Which expresses her intent better?  Is it really educational to
    have *this* user to think of a square as an abstract regular
    polygon that happens to have 4 sides?  True, it's easy to cargo-
    cult the "repeat 4:" idiom the next time she needs a square, but
    in learning to use "repeat n:", has she learned anything about
    implementing her own procedures?  (This is a variation on the
    individuality issue that Terry expressed with "kangaroo".)

    Note: this is a plausible example user, and I am asking whether
    *she* is served by the new syntax.  I don't maintain that she is
    *the* typical user.  I do think that educators should consider her
    needs as well as the question of how common her type is.  While
    there probably is educational benefit to this change, it's far
    from clear to me what it is, or whether in fact the student's 
    benefit is anywhere near as large as that to teachers who want to
    present one "simple" programming construct and move on quickly to
    another one.

3.  The "repeat 4" idiom clearly involves counting (otherwise the
    program doesn't know when to stop), but it completely conceals
    the process.  That violates "explicit is better than implicit",
    and furthermore makes the idiom very specialized, dramatically
    reducing the benefits it can have.

    It seems to me that the "for ... in" construct gets the balance
    just right.  It exposes both counting as an isomorphism between
    concrete sets (above, repetitions of a subprocedure corresponding
    to named sides of a square), and abstractly using numbers merely
    to count (via "range(n)").  (Of course "range()" also provides a
    flexible way to denote various concrete sets of numbers.)

4.  True, when you really do have an algorithm that simply cares about
    the number and repeats the same suite independently of the
    iteration count, exposing an iteration count variable is arguably
    a wart.  But it's very small compared to the power of the "for
    ... in" idiom.  Proposing to address that wart runs into "Special
    cases aren't special enough to break the rules."

Now, all of these principles ("Read my lips: no new keywords!" and the
three from the Zen) are pragmatic guidelines, not absolutes.  Not even
"no keywords".  And they're Pythonic principles: they don't always
generalize to other languages.[2]  But when a proposal infringes so
many Pythonic principles so flagrantly (IMHO, each is sufficient
reason to deny the proposal by itself, though YMMV), it is indeed a
non-starter on this list.

Regards,


Footnotes: 
[1]  Note that several core Python developers have unsubscribed or
muted this list completely, partly because of these off-target
threads.

[2]  I have to admit that I'm thoroughly drunk on the Kool-Aid
though, and tend to apply them to other languages, which inevitably
fall short.