[Uncle T] > 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. > [Uncle T] >>> 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 <luk...@langa.pl>] >> 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 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. [Uncle T]] > 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* learn the 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. [Łukasz] >> 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. -- Ł _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
