On Sat, Apr 14, 2018 at 1:44 AM, Steven D'Aprano <st...@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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
