I have a much better time with Python just doing what I want instead of following the Python community's sometimes arbitrary and capricious standards.
New Ways to Be Told That Your Python Code Is Bad
21–30 of 262 posts
Re: New Ways to Be Told That Your Python Code Is Bad
#22> 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
For the cost of 4 extra characters, this line tells you exactly what it does even if you've never seen Python in your life.
Re: New Ways to Be Told That Your Python Code Is Bad
#23> 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
I wouldn't mind it so much if I could write it as:
x = 4 unless shenanigans(); then x = 5
Yes, that is a semicolon. Fight me.Re: New Ways to Be Told That Your Python Code Is Bad
#24I have a much better time with Python just doing what I want instead of following the Python community's sometimes arbitrary and capricious standards.
I mean sure, that’s true of every programming language. The reason to follow community standards is to make the lives of other people reading your code easier. Consistency is far more important than any individual’s optimal style.
Re: New Ways to Be Told That Your Python Code Is Bad
#25"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 task
Re: New Ways to Be Told That Your Python Code Is Bad
#26> 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 prefer this a lot more to at least avoid using else: x = 5 if condition(): x = 4
(x = 5, condition())
is inconsistent state (using the word "consistent" in the same sense as the C in ACID).It really is clearest and safest to avoid inconsistent state, even if is only transient. There are so many ways programs can be wrong; no need to deliberately create inconsistent state when there's no need to.
Re: New Ways to Be Told That Your Python Code Is Bad
#27 scale = 5
while (scale > 0.1):
do_stuff(scale)
scale = scale/2
Sure, you could use exponentials with range(), but is that really clearer?Re: New Ways to Be Told That Your Python Code Is Bad
#28> 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 prefer this a lot more to at least avoid using else: x = 5 if condition(): x = 4
Also, your version isn't safe to use with objects (e.g. 'myObject.x = ...'), since the initial assignment could trigger arbitrary code (properties, __setattr__, etc.).
Also, your version isn't safe to use when the right-hand-side has effects, e.g.
x = fetch_config_url() if remote else read_config_file()Re: New Ways to Be Told That Your Python Code Is Bad
#29> 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
I'm really not seeing what's illegible about this? For the cost of 4 extra characters, this line tells you exactly what it does even if you've never seen Python in your life.
Re: New Ways to Be Told That Your Python Code Is Bad
#30(The author is on point when they say almost all code used in practice is primitive recursive, though)