[Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Tim Peters]

[Raymond Hettinger <raymond.hettinger at gmail.com>]
>>> After re-reading all the proposed code samples, I believe that
>>> adopting the PEP will make the language harder to teach to people
>>> who are not already software engineers.

[Tim]
>> Can you elaborate on that?

[Raymond]
> Just distinguishing between =, :=, and == will be a forever recurring
> discussion, far more of a source of confusion than the occasional
> question of why Python doesn't have embedded assignment.

To be clear, is distinguishing between "=" and "==" already a forever
recurring discussion in your experience?  Or are you predicting that
adding ":=" will create that situation?


> Also, it is of concern that a number of prominent core dev
> respondents to this thread have reported difficulty scanning
> the posted code samples.

Yes, it is - although some of the examples sucked ;-)


>> I've used dozens of languages over the
>> decades, most of which did have some form of embedded assignment.

> Python is special, in part, because it is not one of those languages.
> It has virtues that make it suitable even for elementary school children.
> We can show well-written Python code to non-computer folks and walk
> them through what it does without their brains melting (something I can't
> do with many of the other languages I've used).  There is a virtue
> in encouraging simple statements that read like English sentences
> organized into English-like paragraphs, presenting itself like
> "executable pseudocode".

It's certainly possible to stick to a subset of Python for which
that's true.  But I didn't mention those dozens of languages because I
seek to emulate them, but to establish that I've had decades of
experience with embedded assignments in a wide variety of languages
and language communities.


> Perl does it or C++ does it is unpersuasive.

Wasn't meant to be.


> Its omission from Python was always something that I thought Guido had
> left-out on purpose, intentionally stepping away from constructs that would
> be of help in an obfuscated Python contest.

He left out lots of stuff at first, but warmed to it later.  Probably
the most profound:  there were exactly and only 3 scopes at first:
local, global, and builtin.  Functions (for example) could still nest,
but had no way to access names local to enclosing functions save via
deep trickery.  That was a noble experiment (it was a deliberate
attempt to avoid complex scoping rules), but eventually proved too
restrictive in practice.

This is nothing compared to that ;-)  But it's a tiny bit related in
that biting the arbitrarily-deeply-nested-scopes bullet was aimed more
at experienced programmers than at newbies.  The scoping rules became
far harder to explain as a result - but far more what experienced
programmers expected.


>> Yes, I'm a software engineer, but I've always pitched in on "help
>> forums" too.

> That's not really the same.

I believe it!

>  I've taught Python to many thousands of professionals, almost
> every week for over six years.  That's given me a keen sense of
> what is hard to teach.  It's okay to not agree with my assessment,
> but I would like for fruits of my experience to not be dismissed in a
> single wisp of a sentence.

I asked you to elaborate - I didn't dismiss anything.  You merely made
a raw assertion in your original message, without enough detail to
even know _what_ it is you thought would be hard to teach.  Your
elaboration is helping.

> Any one feature in isolation is usually easy to explain, but showing
> how to combine them into readable, expressive code is another matter.

OK, so it's not binding expressions in isolation that you expect will
be hard to teach if they're added, but ... how to use them
intelligently (if ever)?  That's progress, if so.

That part I can see having major trouble with.  Even the proponents of
this PEP don't always agree with each other about which examples are
"good ones".


> And as Yuri aptly noted, we spend more time reading code than writing code.
> If some fraction of our users finds the code harder to scan
> because the new syntax, then it would be a net loss for the language.

It would be a tradeoff pitting their losses against others' gains, of
course.  I don't know how to quantify that (not even to the extent of
determining the sign bit) in advance.  I'm also at least as concerned
about - indeed - professional software engineers as beginners.


> I hesitated to join this thread because you and Guido seemed to be
> pushing back so hard against anyone's who design instincts didn't favor
> the new syntax.

That's just vigorous debate, at least on my part.  Guido gets annoyed
by emotional tirades and FUD, of which there's always plenty in
threads that have gone on for hundreds of messages (I don't know
whether you followed any of this on python-ideas, but most arguments
on python-dev were already many-times-over old by the time it first
appeared here).


> It would be nice to find some common ground and perhaps stipulate that the
> grammar would grow in complexity, that a new operator would add to the
> current zoo of operators, that the visual texture of the language would change
> (and in a way that some including me do not find pleasing), and that while
> simplest cases may afford a small net win, it is a certitude that the syntax
> will routinely be pushed beyond our comfort zone.
>
> While the regex conditional example looks like a win, it is very modest win
> and IMHO not worth the overall net increase language complexity.
>
> Like Yuri, I'll drop-out now.  Hopefully, you all wind find some value
> in what I had to contribute to the conversation.

Absolutely!  While I've slowly moved from -1 to +1 on this one, I
respect your -1, and am grateful for your thoughtful elaboration.
Indeed, I'll feel better now when Guido rejects it ;-)