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

[Ryan Gonzalez]

On October 14, 2015 12:28:07 AM CDT, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
>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.)
>


...

That was supposed to be a joke. :O

>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.

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.