[deleted]
New Ways to Be Told That Your Python Code Is Bad
101–110 of 262 posts
Re: New Ways to Be Told That Your Python Code Is Bad
#102The ootb linter setups I've seen offer little useful checks, just everybodies feelings about your code, so personally don't find them useful. This article is a prrfect example of that, but kudos to the author for being honest about it.
Re: New Ways to Be Told That Your Python Code Is Bad
#103> 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
Agreed - relatedly, I really dislike one-liners in code because more often than not, it's done for the sake of being "clever" rather than having readable code for the next person to quickly skim and understand.
I get that it's a "flex" or some sort, but honestly in production code my experience is that it reduces productivity. Programmers need a little more squinting to truly understand what that piece of code is doing.
I find it similar to run-on sentences in books - we don't like that, and in Business Writing courses they explicitly say to not do that. Code should be similarly readable.
Re: New Ways to Be Told That Your Python Code Is Bad
#104I really hope that the condescending tone of the article was because the author was tired or something, and that it's not the attitude they use when contributing to a linter. The authors comes out as arrogant and self-centered, the "reactions" are strawmans, the tone is aggressive. Sure that nice Beeping Busy Beaver uses only one loop, very cool. The "guessing game" program that almost everyone wrote when learning pr…
> The "guessing game" program that almost everyone wrote when learning programming also uses one loop. Just because it’s used by very beginners it doesn’t mean it’s good. That’s, like, the opposite of the truth. Beginners also clutter their code with endless “else if” sequences. You just complained about strawmans and followed with a strawman.
> Just because it’s used by very beginners it doesn’t mean it’s good. That’s, like, the opposite of the truth.
I don't remember saying anywhere that this guessing game was good. You're putting words into my mouth (keyboard?) here. What I meant to say was that saying that the Beeping Busy Beaver only needs one loop doesn't add anything to the discussion, since a simple guessing game also needs one loop. Quoting the article:
> If you have a while loop and you are not working on something that requires unbounded computation, chances are that it can be rewritten more clearly as a for loop. I ran this check against the Pylint codebase itself, and I was shocked by the hideousness of some of the while’s that turned up. They couldn’t all be rewritten, but many could.
> Even the recently-discovered Beeping Busy Beaver champion program only uses one unbounded while loop, and that’s as a kind of toplevel program driver.
Here's how I would put it, in a kinder and more humble way:
"Most of the code I write only needs one main loop, and usually I'm not the one writing it. When I'm using something like Django, I have no need for a while loop, as it's already handled by the framework. In that case, I want the linter to highlight these loops. They are a potential danger, and something I want to pay special attention to. Even when I have to write myself that loop, I want to clearly separate the main loop from what runs into it. In my experience, this leads to code that is more readable, more maintanable, and that has less bugs. Thus, this is a good linter rule."
> Beginners also clutter their code with endless “else if” sequences.
Well, it's not like they can use a switch, considering it's Python. Or are you referring to pattern matching? Or you think using a dictionnary would be more idiomatic? I'm not sure what you're trying to say here.
The part about the Bible and bold text was a parody of the article to quickly highlight what's wrong with it. I personally dislike bold text. I think people shouldn't use it most of the time. Thus I did the same thing as in the article: I used an appeal to authority (the Bible, equivalent to the Beeping Busy Beaver) to say that everything smaller than the Bible shouldn't even use bold text, as the Bible doesn't need any.
Re: New Ways to Be Told That Your Python Code Is Bad
#105I’m ~intermediate at python and understand the arguments in this article, but the comments are so negative and varied that i don’t know how to make sense of the contrary. Could somebody please share some more advanced resources about while loops/for loops/iterables, or point me in the right direction?
Re: New Ways to Be Told That Your Python Code Is Bad
#106> Python programmers in general have an irrational aversion to if-expressions
If that's the case, maybe the problem is the if-expression, and not the programmers?
If you have a syntactical construct in your language that the programmers are avoiding in general, then that construct has problems.
Re: New Ways to Be Told That Your Python Code Is Bad
#107People raging over the ternary operation in Python should learn to use:
x = {True: 5, False: 4}[condition()]
x = {True: lambda: 5, False: lambda: 4}[condition()]()Re: New Ways to Be Told That Your Python Code Is Bad
#108People raging over the ternary operation in Python should learn to use: x = {True: 5, False: 4}[condition()] , or if you don't want to evaluate the values: x = {True: lambda: 5, False: lambda: 4}[condition()]()
[deleted]
Re: New Ways to Be Told That Your Python Code Is Bad
#109I just want to read and write:
x = if condition(): 4 else: 5Re: New Ways to Be Told That Your Python Code Is Bad
#110People raging over the ternary operation in Python should learn to use: x = {True: 5, False: 4}[condition()] , or if you don't want to evaluate the values: x = {True: lambda: 5, False: lambda: 4}[condition()]()
This pattern also nicely expands when you need to select from more than 2 values. And it lets you keep the mapping as a data instead of turning it into logic.
{"a": 1, "b": 2}.get(selector(), default_value)