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

241–250 of 262 posts

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

#241

Post by yongjik »

mhh__ wrote: post #83
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…

That's why you want to start thinking macro and holding your code to a high standard early. You can, for the most part, avoid firefighting if you don't let things fester. If you're in charge, that is...

Well, sure, you're absolutely right that it's best to write high-quality code so that you avoid firefighting in the first place. But that's an orthogonal question to whether the number of while loops is relevant to code quality. Most programs (or even subtasks) aren't Turing machines - they are "unbounded" in that they're supposed to run indefinitely until someone tells them to quit, or until they abruptly hit EOF, end of stream, whatever. You don't improve such logic by making them "bounded" - it will be in fact missing the point.

* If you prefer, change 11 pm to 11 am and my point still stands (though I'll be less cranky and less likely to rage-quit).

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

#242

Post by jimmaswell »

BiteCode_dev wrote: post #114
jimmaswell wrote: post #17

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.

The article is not representative of the community, quite the opposite. In fact, the community is embracing "black" these days, the python equivalent of gofmt, exactly because we have better things to do than arguing over PEP 8.

I was thinking back to my earlier days when I'd post questions with code in the freenode python channel and get quibbles about choosing to index an array or not use a list comprehension or which way to format strings. I only ever really write python for quick scripts for myself these days anyway so I guess it's a moot point. Maybe I'll look into what black formatting looks like though.

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

#243

Post by marcosdumay »

Hizonner wrote: post #198
justusthane wrote: post #191

Earlier quoted context omitted.

Serious question, what alternative(s) to Python would you recommend with nicer syntax?

Well, to be fair, sometimes, especially for short scripts, you're stuck with Python because you know it's going to be available. Personally, from a syntax point of view, as opposed to an easy availability point of view, I prefer Haskell, or Lisp if you can live with the parentheses. Haskell has some syntactic oddities, and the support for infix operators has encouraged the ecosystem to define way too many obscure -lo…

I don't think Python gets semantic whitespace right. It requires extraneous parenthesis and has an impact on lambda functions, making them way less powerful than they should be.

Haskell got it right.

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

#244

Post by marcosdumay »

klyrs wrote: post #235
shhsshs wrote: post #234

Earlier quoted context omitted.

I'm guessing he did, because it does exactly what he's implying it does.

wow, my bad. That's sets & dicts that invalidate their iterators when the size changes.

Iterating over mutable unordered containers is an entire new level of crazy.

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

#245

Post by samhh »

tbronchain wrote: post #174
MathMonkeyMan wrote: post #144

Ah, leave people alone. I stopped using ternary expressions because someone told me not to. I could start using them again, whatever. I use while loops when the burden of describing the loop as an iteration is too high (too much of a stretch), or when I'm writing something that really isn't a composition of forEach/map/filter/reduce (gasp). For me, it's whatever I need to do to get through code review without arguing…

This, really. I'm most likely less experiment than some people here but after 10+ years of writing code, I came to the conclusion that the best code is the most readable code. If all developers could write code that is easily readable for them (even after a few months break in the project), the software engineering world would be a lot better :) Of course it makes sense to avoid anti-patterns and bottlenecks, but no…

Readability is largely subjective. I think this sentiment is better described as optimising readability for the lowest common denominator in terms of both ability/experience and the most common style of code, that being imperative. That's not an unreasonable choice to make but there are other criterion by which to judge how easy or hard code is to read.

It comes up a lot in discussions about Go. A simple, "readable" language in which I can't tell you at a glance what a block of code does or is responsible for.

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

#246

Post by klyrs »

marcosdumay wrote: post #244
klyrs wrote: post #235

Earlier quoted context omitted.

wow, my bad. That's sets & dicts that invalidate their iterators when the size changes.

Iterating over mutable unordered containers is an entire new level of crazy.

That's what linters are for, right? To make your code more fun to read

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

#247

Post by ItsMonkk »

jackdh wrote: post #118
chriswarbo wrote: post #16

> Anyway, this is just a style thing. It doesn’t affect program correctness or structure in a meaningful way. The nice thing about ternaries is that they're expressions, so they don't "infect" our code like statements (e.g. 'if'). For example: if xCond: x = x1 else: x = x2 if yCond: y = y1 else: y = y2 if zCond: z = z1 else: z = z2 foo(x, y, z) This lint rule will tell us to do the following instead: x = x1 if xCond…

I think I might be in the minority here that I prefer the fully laid out statements. Sure in small cases this small ternary use is great! However too many times I've seen people chain them for far too many characters just to be "on one line". We don't use one letter variable names anymore, so in the same reasoning why should we do the same to our code?

An ideal that you want to try to attempt to work through is the Principle of Least Power[0].

While is strictly more powerful than for, for is strictly more powerful than foreach, foreach is strictly more powerful than map.

And yet 95% of the time, the power in map is sufficient. Therefore 95% of the time you should use map. When you encounter a foreach, you should be expecting non-purity. When you encounter a while, you know that it's doing some recursive operation that requires that power. If you have junior members of the team writing while loops where maps would do the senior members of the team who understand the nuance will take 10x more time to understand that code.

The same applies to statements/code blocks vs expressions. If all you are doing is assigning one value and have no other side effects, and you can do so in a way that's not overly nested, you should use an expression. If you can't, we have the more powerful statement/block structure to fall back on.

[0]: https://blog.codinghorror.com/the-principle-of-least-power/

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

#248

Post by MathMonkeyMan »

fogof wrote: post #217
MathMonkeyMan wrote: post #144

Ah, leave people alone. I stopped using ternary expressions because someone told me not to. I could start using them again, whatever. I use while loops when the burden of describing the loop as an iteration is too high (too much of a stretch), or when I'm writing something that really isn't a composition of forEach/map/filter/reduce (gasp). For me, it's whatever I need to do to get through code review without arguing…

> Don't add linter checks for these things, it's condescending. Well as he states, these checks are not turned on by default. I have trouble seeing why someone who liked these extensions enough to turn them on manually would feel condescended to by them.

Fair point, I'm being defensive unnecessarily.

It still puts me off slightly that the tool mixes "make your code less prone to error" with "this guy wants this." Ok, live and let live.

I'm reminded of Douglas Crockfords's jslint, which is a mix of "this caused bugs before" with "how I write javascript."

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

#249

Post by sumtechguy »

chriswarbo wrote: post #239
sumtechguy wrote: post #209

Earlier quoted context omitted.

I personally would have wrote the first one as a first pass, mostly so I could probably at some point put break points on what is going on. Then probably called it 'done'. I had actually forgot you could even do this thing in python. The highest complement I get from other programmers is 'your code is easy to read'. Everyone has their own 'style' they like. It is usually not that big of a deal. It becomes a big deal…

I get the sentiment, but I think it's a fundamental error to equate "verbose" with "clear"/"simple"/"readable"/etc. and "compact" with "clever"/"fast"/"difficult"/etc. I see this so often that I wrote a blog post about it http://chriswarbo.net/blog/2020-02-08-clever_code.html tl;dr trying to make things smaller isn't "clever", it's code golf; often, "clever" solutions just-so-happen to end up small. Likewise, spreadi…

Do not disagree at all. I almost always lean towards readability so I can make the next poor soul understand it (usually me 6 months from now). I once ended up with one of those 'clever' bits of code. It was the best solution because of the constraint we were in. But a co-worker (who helped create it) put it best 'no damn way are any of us going to be able to figure that out 6 months from now'. He was perfectly right, and it did take me 2 days to untangle it about a year later. That was comment time to for future me to put in what was this thing doing and why it worked the way it did (lesson learned).

Getting that 'terse'/'readable' balance right can be tricky. Usually if some code is 'hard to read' it usually means it needs a bit of refactoring to shorten/length it up and make clear (with comments) what each bit is doing. You go drop something like duffs device into the middle of a parser you should put a comment on that. As not everyone has heard of it. If the code is going to be used a couple of times a year and if it takes an extra 15 seconds, so what. Comment it with 'hey this would be a good spot for duffs device?'. Most of the type of code I write these days runs so rarely and can take a bit of extra time. I am also working with jr devs who may or may not have read up on every cool trick. I am also playing with some code I got from the net. Some of these things have 5 page long functions, yep... totally lost in abstraction.

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

#250

Post by danudey »

MathMonkeyMan wrote: post #144

Ah, leave people alone. I stopped using ternary expressions because someone told me not to. I could start using them again, whatever. I use while loops when the burden of describing the loop as an iteration is too high (too much of a stretch), or when I'm writing something that really isn't a composition of forEach/map/filter/reduce (gasp). For me, it's whatever I need to do to get through code review without arguing…

From the page:

> Generally speaking, less code is better than more code

This is true, but, generally speaking, readable code is better than compact code. Making it harder to scan through the code, or requiring more horizontal reading to understand code while you're scanning through it, is objectively bad.

This is going to push people towards making less-readable code for literally zero benefit. Considering how many of the checks in pylint are to make your code more readable, this is a clear step backwards.

I agree with him about the problems involved in while loops; there are cases where what you actually want is "loop forever until you die", but they are pretty rare, and all the rest can be converted into some other form of loop; that said, those situations also seem to more likely complicate the understanding of your code in many situations.

All in all, while-used is highly opinionated but has a point to make; consider-ternary-expression is an asinine addition that's going to push people towards writing objectively worse code for literally no benefit other than reducing line count. If that's your KPI, then sure, fill your boots, but it makes zero sense to enable it by default.

Edit: To clarify, it does not seem as though PyLint is enabling this by default, but I'm concerned that some shops will enable it by default and push their developers to write worse code.

Post reply on HN