[Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Tim Peters]

I think I'll bow out of this now.  It's just too tedious.

Like here:

[Nick]
> I never said the motivation was to gain performance relative to the
> two-statement version - I said the motivation given in the PEP is to
> gain performance relative to the *repeated subexpression* version,
> *without* making the transition to the already supported two-statement
> version.

This is what you wrote:

>> "NAME := EXPR" exists on a different level of complexity, since it
>> adds name binding in arbitrary expressions for the sake of minor
>> performance improvement in code written by developers that are
>> exceptionally averse to the use of vertical screen real estate,

I'm not telepathic, so took it for it what said.  It didn't say a word
about "repeated expressions", nor a word about "two-statement versions"

It did say "minor" performance improvements, which sure suggested to me
that you had in mind the tiny changes in bytecode that can result from
squashing a current two-statement spelling into a one-statement form with
an embedded assignment.  That fit both "minor performance improvement" and
"vertical screen space", which were the only the two clues I had to go on.

In the example you eventually gave in a later message, the performance
difference was more on the order of a factor 2 (regexp searches can be
expensive indeed), which matches nobody's idea of "minor".  So the use of
"minor" wholly ruled out in my mind that you had _anything_ akin to your
eventual example in mind.

For the rest, sure, words could be added to the PEP without end.   At least
some of the points I covered were telegraphically mentioned in my Appendix,
although I'll grant that nobody else is telepathic either ;-)

For the question:


> > The remaining point of contention is only the "Inevitable cost of

> > change" one: given the level of disruption this will cause in the way

> > that Python gets taught to new users, is it giving a commensurate

> > pay-off in increased semantic expressiveness?

> >

> > My answer to that question remains "No", while your answer is either

> > "Yes" or "I don't see why that should matter" (I'm genuinely unsure

> > which).

I don't know, and I'm not qualified to guess - I don't teach Python to new
users for a living.  Decades ago I tutored "advanced" engineering
undergrads in a variety of science-y subjects, and was routinely surprised
by what broke their brains.

I have noted that assignment expressions have been part of a great many
languages for decades (this isn't cutting edge tech), questions about them
are conspicuous by absence on StackOverflow (everyone else seems to teach
them effectively), and skimming various online teaching materials for other
languages convinced me that none of those professional educators thought it
needed more than a page to teach (and to teach them with relatively few
words).  There's really not much to them:  people have to learn what
binding means in Python regardless, pretty much starting in the first hour,
yes?  "Binding" on its own is the hard part.

If they don't drop out and stick around for the 10-minute lesson on
assignment expressions 3 weeks later, will _that_ finally break their
brains?  "Wow - it not only binds the name, but ALSO returns the object
that was bound?!  I just can't take it - please, let's go back to the
lesson on metaclasses" just doesn't seem likely to me ;-)

At heart, ":=" could make a good case for being the simplest of all
Python's operators.  It does no computation at all, and you don't even have
to worry about a dunder method changing its meaning depending on context.

So, ya, when someone claims they'll make Python significantly harder to
teach, I'm skeptical of that claim.  Which does not mean I believe it's
wrong - it means I'm skeptical.  I would also be skeptical of a claim that
teaching them would be no trouble at all, except nobody has made such a
claim ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180701/3183a905/attachment.html>