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 ;-)
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.
Some parting hair-splitting follows.
One language feature conspicuous by absence in newbie confusions was, consistently, assignment expressions. Read any book or tutorial for such a language, and you'll find very little space devoted to them too.
[Łukasz Langa firstname.lastname@example.org]
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.
[Uncle T] Sorry, I couldn't follow that.
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
== is a relatively common occurence for newbies.
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
In languages like C that use easily confused operator symbols, sure, people are forever typing "=" when they mean "==". That's nothing to do with whether they _understand_ what the different operators do, though.
What you're saying is true. But for it to be true, newbies have to
distinction, and the fact that yes, sometimes the programmer indeed meant to
put a single
= sign in the conditional. That's why we'll end up with the
Pascal assignment operator. And that is a thing that you will have to
explain to newbies when they encounter it for the first time. Sadly, googling
for a colon followed by an equal sign isn't trivial if you don't know what
you're looking for.
Well, you can also use it as a statement. But don't!
[Uncle 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.
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.
The silver lining for me is that this makes the environment riper for auto-formatting.