[Python-ideas] PEP 572: Assignment Expressions (post #4)

[Steven D'Aprano]

On Fri, Apr 13, 2018 at 10:35:59PM +1000, Chris Angelico wrote:

> > On the contrary, it puts the expression first, where it belongs
> > *semi-wink*.
> 
> The 'as' syntax already has that going for it. What's the advantage of
> the arrow over the two front-runners, ':=' and 'as'?

Personally, I like "as" better than -> since English-like expressions 
and syntax is nicer than symbols. (Up to a point of course -- we surely 
don't want COBOL-like "ADD 1 TO x" syntax.)

The arrow also completely bypasses the entire with/except problem.

So my position is:

- "as" is more Pythonic and looks nicer;

- but it requires a compromise to avoid the with/except problem;

- I'm okay with that compromise, but if others aren't, my second
  preference is the arrow binding operator ->

- which also has the advantage that it is completely unused apart
  from function annotations;

- and if people don't like that, I'm okay with := as a distant
  third choice. (But see below.)

 
> > The expression is the most important part of the assignment expression,
> > and because we read from left to right, it should come first. Let's take
> > a simple example:
> >
> >     pair = (first_value := x + y + z,
> >             a + b + first_value
> >             )
> >
> > What's the first item of the pair? If you're like me, and I think most
> > people are similar, when skimming the code, you read only far across
> > each line to get an idea of whether it is relevant or not.
> 
> Yet Python has an if/else operator that, in contrast to C-inspired
> languages, violates that rule. So it's not a showstopper. :)

A ternary operator can't put *all* three clauses first. Only one can go 
first. And you know which one we picked?

Not the condition, as C went with.

Not the alternative "else" expression.

But the primary "if" clause, in other words, the expression that we 
consider to be the usual case.

So the ternary if supports my position, it isn't in opposition :-)

But of course your general observation is correct. "Expression first" is 
violated by regular assignment, by long tradition. I believe that was 
inherited from mathematics, where is may or may not make sense, but 
either way it is acceptible (if only because of long familiarity!) for 
assignment statements. But we should reconsider it for expressions.

Analogy: we write "with expression as name" for context managers. We 
could have put the name first and written "using name from expression", 
but that puts the name and expression in the wrong order.

Similarly we don't write "import as np numpy", rather we use "import 
numpy as np". We put the entity being imported first, the name it is 
bound to last.

But again, I acknowledge that there are exceptions, like for loops, and 
they've been around a long time. Back to the 1950s and the invention of 
Fortran. So no, this isn't an absolute showstopper.


> >> The arrow faces the other way in languages like Haskell,
> >
> > Indeed, but in R, it faces to the right. (Actually, R allows both
> > direction.) There's also apparently a language BETA which uses -> for
> > assignment, although I've never used it.
> 
> I looked up R's Wikipedia page and saw only the left-facing arrow. How
> common is the right-facing arrow? Will people automatically associate
> it with name binding?

I don't interact with the R community enough to know how commonly people 
use -> versus <- but you can certainly try it for yourself in the R 
interpreter if you have any doubts that it works.

The statistician John Cook says -> is "uncommon":

https://www.johndcook.com/blog/r_language_for_programmers/#assignment

but in any case, I think that the idea of arrows as pointers, motion, 
"putting into" and by analogy assignment shouldn't be hard to grasp.

The first time I saw pseudo-code using <- for assignment, I was confused 
by why the arrow was pointing to the left instead of the right but I had 
no trouble understanding that it implied taking the value at non-pointy 
end and moving it into the variable at the pointy end.


> So we have calculators, and possibly R, and sorta-kinda Haskell,
> recommending some form of arrow. We have Pascal and its derivatives
> recommending colon-equals. And we have other usage in Python, with
> varying semantics, recommending 'as'. I guess that's enough to put the
> arrow in as another rejected alternate spelling, but not to seriously
> consider it.

Well, it's your PEP, and I can't force you to treat my suggestion 
seriously, but I am serious about it and there have been a few other 
people agree with me.

I grew up with Pascal and I like it, but it's 2018 and a good twenty to 
thirty years since Pascal was a mainstream language outside of academia. 
In 1988, even academia was slowly moving away from Pascal. I think the 
death knell of Pascal as a serious mainstream language was when Apple 
stopped using Pascal for their OS and swapped to C for System 7 in 1991.

The younger generation of programmers today mostly know Pascal only as 
one of those old-timer languages that is "considered harmful", if even 
that. And there is an entire generation of kids growing up using CAS 
calculators for high school maths who will be familiar with -> as 
assignment.

So in my opinion, while := is a fine third-choice, I really think that 
the arrow operator is better.



-- 
Steve