[Tim]
So, to match your sarcasm, here's mine: try using a feature for what it's good at instead of for what it's bad at ;-)
[Lukasz Langa <lukasz@langa.pl>]
Yes, this is the fundamental wisdom. Judging which is which is left as an exercise to the programmer.
With this, I'm leaving the discussion. With Guido and you on board for PEP 572, I feel that Chris' streak is indeed about to break.
I still expect it could go either way, but do wish people didn't believe it will be a major loss if "the other side wins". I'll be fine regardless - and so will everyone else. Guido rarely makes language design mistakes. In this case he's seeing serious opposition from several core developers, and you shouldn't believe either that he just dismisses that. [Ćukasz Langa]
Well, you have an entire code style built around this feature called Yoda conditions. You teach people on Day 1 to never ever confuse == with =. Some compilers even warn about this because so many people did it wrong.
Sorry, I couldn't follow that.
Part of the problem here is that I had never seen "Yoda conditions" before, and had no idea what it meant. Some later Googling suggests it's "a thing" youngsters say at times ;-)
You implied that newbies don't have to even know about assignments in expressions. I wanted to demonstrate that this isn't really the case because mistaking `=` for `==` is a relatively common occurence for newbies. If you want to argue that it isn't, I'd like to point out that the WordPress code style *requires* Yoda conditions because it was enough of a hindrance. ESLint (a JavaScript linter) also has a warning about assignment in a conditional.
What does that have to do with Python? If they try to use "=" in an expression now, they get a SyntaxError. The PEP doesn't change anything about that. Indeed, that's why it uses ":=" instead. I have experience in other languages with embedded assignments that also use ":=", and it's _never_ the case that people type ":=" when they intend "equality test" in those. The horrid "I typed = when I meant ==" mistakes are unique to languages that mindlessly copied C. The mistakes aren't primarily due to embedded assignments, they're due to that even highly experienced programmers sometimes type "=" when they're _thinking_ "equals". Nobody types ":=" when they're thinking "equals".
... What you're saying is true. But for it to be true, newbies *have to* learn the distinction, and the fact that yes, sometimes the programmer indeed meant to put a single `=` sign in the conditional.
Again, the PEP is about Python: a single "=" in a conditional is, and will remain, a SyntaxError. So nobody can sanely intend to put a single "=" in a condition _in Python_ unless they're writing a test intending to provoke a syntax error.
That's why we'll end up with the Pascal assignment operator.
":=" is already in the PEP.
And that *is* a thing that you will have to explain to newbies when they encounter it for the first time.
Sure. That doesn't frighten me, though. It's easy to explain what it does - although it may be hard to explain when it's _desirable_ to use it.
Sadly, googling for a colon followed by an equal sign isn't trivial if you don't know what you're looking for.
To judge from Stackoverflow volume, the single most misunderstood of all Python operators - by far - is "is" - try Googling for that ;-) In far second and third places are "and" and "or", for which searches are also useless. Regardless, I'm not concerned about one-time tiny learning curves. Don't know what ":=" means already? Ask someone. If you know what "=" means, you're already close to done. Given that you already understand what "binding a name" means, ":=" may well be the simplest of all Python's operators (there's no computation _to_ be understood, and no possibility either of a dunder method changing its meaning depending on operand type(s)).
Well, you can also use it as a statement. But don't!
Why not? _Every_ expression in Python can be used as a statement. Nothing forbids it, and that's even (very!) useful at an interactive prompt.
Because it suggests different intent, because it's limited, because it's slower at runtime, and because PEP 572 says so itself.
I didn't say you're _required_ to use it as a statement. Regardless of what PEPs say, people will do what they find most useful. I trust people to figure this out quickly for themselves.
At this point I think you must have a lower opinion of Python programmers than I have ;-) If adding even a dozen characters to a line makes it exceed a reasonable line-length guide, the code was almost certainly too confusingly dense to begin with.
Around 5% of if and elif statements in the standard library don't fit a single line *as is*. Sure, that's a low percentage but that's over 1,000 statements. If you're putting an `if` statement in a method, you are already starting out with 71 characters left on the line. Four of those are going to be taken by "if", a space, and the colon. Adding a parenthesized assignment expression takes at least 10% of that available space.
Confirming that you do have a lower opinion of them ;-) Are you picturing people stampeding to introduce ":=" in every place they possibly could? I may be wrong, but I don't expect that at all. I expect a vast majority of uses in real life will replace: name = expression if name: by if name := expression: and while True: name = expression if name comparison expression2: break by while (name := expression) inverted_comparison expression2: _provided that_ the latter spelling doesn't make the line uncomfortably long. In all the code of mine I've seen a good use for it, there's a whole lot of empty horizontal screen space to spare, even after recoding. In places where I already had "long lines", I didn't even check to see whether a binding operation could be used too - why would I? I don't feel _compelled_ to use it - I'm only looking to reduce redundancy where it's an obvious win.
The silver lining for me is that this makes the environment riper for auto-formatting.
See? It's win-win for you too no matter how this turns out ;-)