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

[Chris Angelico]

On Sat, Apr 14, 2018 at 1:44 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Fri, Apr 13, 2018 at 10:35:59PM +1000, Chris Angelico wrote:
>> 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.

Which is also the most important clause in some situations, since it's
the governing clause. In an if *statement*, it's the one in the
header, before the indented block. I don't think there's enough logic
here to draw a pattern from.

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

I don't know about professional-level mathematics, but certainly what
I learned in grade school was conventionally written with the
dependent variable before the equals sign. You'd write "y = x²" to
graph a parabola, not "x² = y". So the programming language convention
of putting the assignment target first was logical to me.

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

Agreed. Whichever way the arrow points, it's saying "the data flows
thattaway". C++ took this to a cute level with "cout << blah", abusing
the shift operators to signal data flow, and it's a nuisance because
of operator precedence sometimes, but nobody can deny that it makes
intuitive sense.

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

(Now I want to use "pointy end" somewhere in the PEP. Just because.)

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

If I were to take a poll of Python developers, offering just these
three options:

1) TARGET := EXPR
2) EXPR as TARGET
3) EXPR -> TARGET

and ask them to rank them in preferential order, I fully expect that
all six arrangements would have passionate supporters. So far, I'm
still seeing a strong parallel between expression-assignment and
statement-assignment, to the point of definitely wanting to preserve
that.

ChrisA