Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Ways to Be Told That Your Python Code Is Bad

nickdrozd.github.io

Post reply on HN
Print view View original

91–100 of 262 posts

Re: New Ways to Be Told That Your Python Code Is Bad

#91

Post by Zababa »

mixmastamyk wrote: post #84
Zababa wrote: post #45

Earlier quoted context omitted.

My favorite way to write that is with expression oriented langauges. Example in OCaml: x = if condition() then 5 else 4 I dislike how the regular order of if is changed when used as an expression. I don't know how you could retrofit that into existing Python tough. Probably a consequence of defining blocks with whitespaces.

It is simply a design choice, the common value is given first. Comprehensions in Py are the same.

Sure it's a design choice but, quoting the Zen of Python:

> Special cases aren't special enough to break the rules.

> There should be one-- and preferably only one --obvious way to do it.

Both are broken by the existance of 2 if syntaxes depending on the context.

Re: New Ways to Be Told That Your Python Code Is Bad

#92

Post by chrismorgan »

priansh wrote: post #62
frosted-flakes wrote: post #60

Earlier quoted context omitted.

Did you miss the fact that these rules are disabled by default?

It should never have been introduced or approved in the first place.

I think there is a place for it, though it was poorly justified in the article.

It depends on the type of programming you’re doing.

Algorithmics routinely does stuff that matches while loops and C-style for loops while loops, but doesn’t match iterator for loops very well.

In most parts of line-of-business sort of software development (and that’s the significant majority of software development, frankly, certainly a lot bigger than algorithmics), I’d say it’s rare for a while loop to be desirable: it should almost always be iterator-powered instead.

I think the C-style for loop thing is a particularly interesting aspect to this: I suspect most code that uses while loops where an iterator would not be appropriate would actually be at least as well-served by a C-style for loop. But Python made a deliberate decision not to have C-style for loops, because most uses of them are better-served by iteration. And so this nudging from while to for is really a perfectly natural extension of that.

Still, all things being considered, it’s not the sort of lint that I would ever turn on for myself or for code that I review, because I know when to use each.

Re: New Ways to Be Told That Your Python Code Is Bad

#93

Post by Zababa »

29athrowaway wrote: post #32
ChrisMarshallNY wrote: post #9

I 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...

Hating linters is like hating a weight scale for telling you your weight, or hating a blood exam for telling you that you have high cholesterol. If the linter says your function is too long then you refactor it, you don't turn off the linter. You also fix it immediately, not "later" (broken windows theory) before the next offender copies and pastes the offending code or continues making it worse. In underdeveloped co…

Linters tell you when your code doesn't respect certain rules. That's it. These rules may or may not lead to better programming, that depends on the rules themselves. I could build a linter that forbids all variable names longer than three characters. Would that make the code good? I doubt it. Sometimes the extra weight you notice on the scale is just muscle, and there's nothing to worry about.

Re: New Ways to Be Told That Your Python Code Is Bad

#94

Post by q-rews »

yongjik wrote: post #72

> You know what else doesn’t have unbounded loops? Excel. Right, one of the many reasons why nobody (with half a brain) hosts a web server in Excel. I wonder how much "boring web app" experience the author had. If I'm debugging on 11 pm why the webserver is timing out talking to microservice A, but only if it first opened connection to service B, and someone strolls along saying "Hey, your code is bad because it's us…

Congrats on insulting someone you don’t know because he made a valid point without saying anything about the point they made.

They love linters, you sound like you hate linters. Don’t use them and let your colleagues deal with your unbounded computation.

Re: New Ways to Be Told That Your Python Code Is Bad

#95

Post by q-rews »

Zababa wrote: post #52

I 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.

Re: New Ways to Be Told That Your Python Code Is Bad

#96

Post by nirs »

l0b0 wrote: post #7

Sure, 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…

Theses are good examples for not using ternary expressions. The code looks wrong even if it is correct, and it is hard to follow.

There is a very simple rule avoiding most of these issues - if the ternary expression does not fit in one line, use if/else.

Re: New Ways to Be Told That Your Python Code Is Bad

#97

Post by dijit »

Unbounded computation is necessary when working on either event driven architecture (block/wait for something, run it, block/wait again) or working with frames.

I can’t imagine making a game (though not sure who makes games in python) without a while loop to run on the main thread.

Re: New Ways to Be Told That Your Python Code Is Bad

#98

Post by [deleted] »

yongjik wrote: post #72

> You know what else doesn’t have unbounded loops? Excel. Right, one of the many reasons why nobody (with half a brain) hosts a web server in Excel. I wonder how much "boring web app" experience the author had. If I'm debugging on 11 pm why the webserver is timing out talking to microservice A, but only if it first opened connection to service B, and someone strolls along saying "Hey, your code is bad because it's us…

[deleted]

Re: New Ways to Be Told That Your Python Code Is Bad

#99

Post by pbreit »

zootboy wrote: post #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

If a one liner is preferred, what if it could be:

if condition(): x=4 else: x=5

Re: New Ways to Be Told That Your Python Code Is Bad

#100

Post by fomine3 »

chrismorgan wrote: post #61
hermitdev wrote: post #59

Earlier quoted context omitted.

Because "while 1:" is valid Python, but "while true:" is not ;) (gotta capitalize "True"). In addition to the GP's self deprecating sibling comment, I started using Python around 2.2, before there were even "True" and "False". So, seeing a 'while 1' loop is perfectly natural to me. But, I'm also perfectly comfortable with Python's "truthiness" in more places than most people are. As a bonus: consider "while 'false' :…

> consider "while 'false' :" as a perfectly valid start to an unbounded loop That sort of thing is ubiquitous in dynamically-typed languages. Even HTML: the state of boolean attributes is determined by the attribute being set, regardless of its value, so will give you a nice disabled text box. Mind you, some attributes that you might think would be boolean actually aren’t, for varying reasons good and bad, e.g. autoc…

Enjoy YAML with Norway. https://news.ycombinator.com/item?id=17359376
Post reply on HN