[Python-ideas] Spelling of Assignment Expressions PEP 572 (was post #4)

[Nick Coghlan]

On 15 April 2018 at 19:41, Mikhail V <mikhailwas at gmail.com> wrote:
> So IIUC, the *only* reason is to avoid '==' ad '=' similarity?
> If so, then it does not sound convincing at all.
> Of course Python does me a favor showing an error,
> when I make a typo like this:
> if (x = y)
>
> But still, if this is the only real reason, it is not convincing.

It's thoroughly convincing, because we're already familiar with the
consequences of folks confusing "=" and "==" when writing C & C++
code. It's an eternal bug magnet, so it's not a design we're ever
going to port over to Python. (And that's even before we get into the
parsing ambiguity problems that attempting to reuse "=" for this
purpose in Python would introduce, especially when it comes to keyword
arguments).

The only way Python will ever gain expression level name binding
support is with a spelling *other than* "=", as when that's the
proposed spelling, the answer will be an unequivocal "No, we're not
adding that".

Even if the current discussion does come up with a potentially
plausible spelling, the final determination on python-dev may *still*
be "No, we're not going to add that". That isn't a predetermined
answer though - it will depend on whether or not a proposal can be
developed that threads the small gap between "this adds too much new
cognitive overhead to reading and writing the language" and "while
this does add more complexity to the base language, it provides
sufficient compensation in allowing common ideas to be expressed more
simply".

> Syntactically seen, I feel strong that normal '=' would be the way to go.
>
> Just look at this:
> y = ((eggs := spam()), (cheese := eggs.method())
> y = ((eggs = spam()), (cheese = eggs.method())
>
> The latter is so much cleaner, and already so common to any
> old or new Python user.

Consider how close the second syntax is to "y = f(eggs=spam(),
cheese=fromage())", though.


> Given the fact that the PEP gives quite edge-case
> usage examples only, this should be really more convincing.

The examples in the PEP have been updated to better reflect some of
the key motivating use cases (embedded assignments in if and while
statement conditions, generator expressions, and container
comprehensions)

> And as a side note: I personally find the look of ":=" a bit 'noisy'.

You're not alone in that, which is one of the reasons finding a
keyword based option that's less syntactically ambiguous than "as"
could be an attractive alternative.

> Another point:
>
> *Target first  vs  Expression first*
> =======================
>
> Well, this is nice indeed. Don't you find that first of all it must be
> decided what should be the *overall tendency for Python*?
> Now we have common "x = a + b" everywhere. Then there
> are comprehensions (somewhat mixed direction) and
> "foo as bar" things.
> But wait, is the tendency to "give the freedom"? Then you should
> introduce something like "<--" in the first place so that we can
> write normal assignment in both directions.
> Or is the tendency to convert Python to the "expression first" generally?

There's no general tendency towards expression first syntax, nor
towards offering flexibility in whether ordinary assignments are
target first.

All the current cases where we use the "something as target" form are
*not* direct equivalents to "target = something":

* "import dotted.modname as name": also prevents "dotted" getting
bound in the current scope the way it normally would
* "from dotted import modname as name": also prevents "modname"
getting bound in the current scope the way it normally would
* "except exc_filter as exc": binds the caught exception, not the
exception filter
* "with cm as name": binds the result of __enter__ (which may be
self), not the cm directly

Indeed, https://www.python.org/dev/peps/pep-0343/#motivation-and-summary
points out that it's this "not an ordinary assignment" aspect that
lead to with statements using the "with cm as name:" structure in the
first place - the original proposal in PEP 310 was for "with name =
cm:" and ordinary assignment semantics.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia