New Ways to Be Told That Your Python Code Is Bad
nickdrozd.github.io
New Ways to Be Told That Your Python Code Is Bad
1–10 of 262 posts
Re: New Ways to Be Told That Your Python Code Is Bad
#2If expressions are good, but python's hideous middle-endian if expressions are rightfully feared.
Re: New Ways to Be Told That Your Python Code Is Bad
#3"it unconditionally flags every use of while expressions."
I'd find that pretty annoying.
Consider a while loop in a thread:
while not quit_thread_requested:
# do threaded taskRe: New Ways to Be Told That Your Python Code Is Bad
#4> less code is better than more code
Not when it's at the cost of readability. The example "better" code fails my readability test horribly. I'd gladly take C's ternary operator over this monstrosity:
> x = 4 if condition() else 5
Re: New Ways to Be Told That Your Python Code Is Bad
#5Tools that enforce "expert level" coding standards do make code more concise, but also less comprehendible for the less experienced developers. I never saw the harm in four lines of code instead of one, especially when it's much more readable.
Re: New Ways to Be Told That Your Python Code Is Bad
#6> less code is better than more code Not when it's at the cost of readability. The example "better" code fails my readability test horribly. I'd gladly take C's ternary operator over this monstrosity: > x = 4 if condition() else 5
Exactly. I pretty much love everything about Python except its ternary operator. I also prefer C’s.
Re: New Ways to Be Told That Your Python Code Is Bad
#7Sure, once you cherry-pick the most trivial imaginable example ternary expressions are easy enough to read. First counter-example which came to mind:
print("yes") if random.choice([True, False]) else print("no")
There are lots of examples where ternary makes things obviously harder to read, such as when at least two of the three expressions are non-trivial. Which one would you rather read?
if some_complex_condition(using, four, different, parameters):
do_a_thing(now, using, five, different, parameters)
else:
do_another_thing(with, three, parameters)
do_a_thing(now, using, five, different, parameters) if some_complex_condition(using, four, different, parameters) else do_another_thing(having, three, parameters)
do_a_thing(now, using, five, different, parameters) if some_complex_condition(
using, four, different, parameters
) else do_another_thing(having, three, parameters)
Re: New Ways to Be Told That Your Python Code Is Bad
#8> less code is better than more code Not when it's at the cost of readability. The example "better" code fails my readability test horribly. I'd gladly take C's ternary operator over this monstrosity: > x = 4 if condition() else 5
Exactly. I pretty much love everything about Python except its ternary operator. I also prefer C’s.
When I first started using python, I assumed it had a normal (c-like) ternary operator and was a little surprised to discover the syntax we're talking about. But after some time, it actually feels very natural to me, and is arguably more intuitive than ?: syntax. I assume this is where the author is coming from.
Re: New Ways to Be Told That Your Python Code Is Bad
#9I love linters.
This is one of the first things that I add to a new project, before I write one line of code: https://github.com/realm/SwiftLint
I write about it here: https://littlegreenviper.com/miscellany/swiftwater/swiftlint...
Re: New Ways to Be Told That Your Python Code Is Bad
#10Sure, once you cherry-pick the most trivial imaginable example ternary expressions are easy enough to read. First counter-example which came to mind: print("yes") if random.choice([True, False]) else print("no") Does this do the right thing? I was pleasantly surprised to find that this is indeed lazily evaluated, but that's not at all intuitive: first because `print("yes")` comes before the conditional (note that the…
Neither of your examples qualify for the lint rule that's about cases that assign to the same variable, so I'm not sure why you accuse the author of "cherry-picking"?