4 ms·

I’ve found that operators boil down to saving time writing (once) at the expense of later readability. They are also almost impossible to trace if operators ar

I’ve found that operators boil down to saving time writing (once) at the expense of later readability. They are also almost impossible to trace if operators are overloaded. And you have to hope that the overloaded operator has a meaning consistent with other uses of the operator. Stop trying to shorten code by 2 lines. It’s not that bad to write it out. If it helps, think ahead to the 1st or 5th revision of the code you’re about to write and imagine where you’d even be able to add new code, given magical operators. In a case like this, it’s easy to imagine a single “else” case with “?” needing to change into multiple else-if cases, requiring the entire fancy operator expression to be rewritten. No real saving.

CurlyJefferson 8y ago
"Stop trying to shorten code by 2 lines." Agreed. Python code tends to be concise as is. There's no need to add little tricks to cut out a line or two at the expense of readability. Along those lines, in a recent code review a developer balked at some proposed code and boasted how he could do the same thing in fewer lines. His "improved" code had a keyword parameter where the default was set to a lambda function containing nested list comprehensions plus a zip function... I voted against his "improvement" since it was the most unpythonic thing I'd ever seen. I'll take added readability and simplicity at the expense of a few extra lines.
- talltimtom 8y ago
  > Agreed. Python code tends to be concise as is. There's no need to add little tricks to cut out a line or two at the expense of readability. I must say I agree fully, and even so, in cases where you really want to cut down verbose sections or boilerplate, there is so much you can do through defining your own classes and functions and overloading operators. Even then there is little need for new fundamental syntax.
AlexeyMK 8y ago
> Stop trying to shorten code by 2 lines. It’s not that bad to write it out. That brings me back to Blub. """ After a certain age, programmers rarely switch languages voluntarily. Whatever language people happen to be used to, they tend to consider just good enough. [...] I don't want to hurt anyone's feelings, so to explain this point I'm going to use a hypothetical language called Blub. Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language. And in fact, our hypothetical Blub programmer wouldn't use either of them. Of course he wouldn't program in machine language. That's what compilers are for. And as for Cobol, he doesn't know how anyone can get anything done with it. It doesn't even have x (Blub feature of your choice). As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub. - http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html """ Being able to express an idea concisely (IE, "save two lines") is a big part of why we bother to innovate on programming languages. It's what it means for one language to be more powerful or expressive than another. None-aware operators can help express an idea more concisely (IE, make python more powerful a language). I've used them to that effect in Ruby and CoffeeScript. I agree there is potential for terseness. Every project needs to have a sense of where the team stands on terseness versus time - probably don't use `??` much if you're creating tutorials or teaching, but also avoid other pitfalls - picking unclear variable names, writing deeply nested logic (cyclomatic complexity), or clunky nested list comprehensions. Avoiding needless terseness is the job of the programmer or the code reviewer, not the language. The job of the language is to provide power, or the ability to concisely describe intent. None-aware operators have helped me with that in other languages, and would be great to have in python.

CurlyJefferson 8y ago

"Stop trying to shorten code by 2 lines." Agreed. Python code tends to be concise as is. There's no need to add little tricks to cut out a line or two at the expense of readability. Along those lines, in a recent code review a developer balked at some proposed code and boasted how he could do the same thing in fewer lines. His "improved" code had a keyword parameter where the default was set to a lambda function containing nested list comprehensions plus a zip function... I voted against his "improvement" since it was the most unpythonic thing I'd ever seen. I'll take added readability and simplicity at the expense of a few extra lines.

talltimtom 8y ago
> Agreed. Python code tends to be concise as is. There's no need to add little tricks to cut out a line or two at the expense of readability. I must say I agree fully, and even so, in cases where you really want to cut down verbose sections or boilerplate, there is so much you can do through defining your own classes and functions and overloading operators. Even then there is little need for new fundamental syntax.

AlexeyMK 8y ago

> Stop trying to shorten code by 2 lines. It’s not that bad to write it out. That brings me back to Blub. """ After a certain age, programmers rarely switch languages voluntarily. Whatever language people happen to be used to, they tend to consider just good enough. [...] I don't want to hurt anyone's feelings, so to explain this point I'm going to use a hypothetical language called Blub. Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language. And in fact, our hypothetical Blub programmer wouldn't use either of them. Of course he wouldn't program in machine language. That's what compilers are for. And as for Cobol, he doesn't know how anyone can get anything done with it. It doesn't even have x (Blub feature of your choice). As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub. - http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html """ Being able to express an idea concisely (IE, "save two lines") is a big part of why we bother to innovate on programming languages. It's what it means for one language to be more powerful or expressive than another. None-aware operators can help express an idea more concisely (IE, make python more powerful a language). I've used them to that effect in Ruby and CoffeeScript. I agree there is potential for terseness. Every project needs to have a sense of where the team stands on terseness versus time - probably don't use `??` much if you're creating tutorials or teaching, but also avoid other pitfalls - picking unclear variable names, writing deeply nested logic (cyclomatic complexity), or clunky nested list comprehensions. Avoiding needless terseness is the job of the programmer or the code reviewer, not the language. The job of the language is to provide power, or the ability to concisely describe intent. None-aware operators have helped me with that in other languages, and would be great to have in python.