Live data from Hacker News

Python programming is drowning in red tape

stefanoborini.com

121–130 of 183 posts

Re: Python programming is drowning in red tape

#121

Line length is such a hard problem to solve. I wish there was a way to be like don’t allow more than 95% percent of my lines to be longer than X. I run into this in Django a lot with my chained ORM queries. The usually tend to be like 10-15 chars to long. And in this case you have to line break on the parameters or on a ‘.’ which is ugly as well. While not related to Python, I feel like whenever I write JS code, espe…

Yes My personal preference regarding line lengths: 80 chars are not enough. And even pep8 says that "foolish consistency is the hobgoblin of little minds" So try being under 80 chars but sometimes you can't. Also don't break a line that's like 85 chars if it will just make it more ugly I'm glad Prospector by default doesn't enforce "the cult of 80 chars" dogma

The quote is from Emerson

Re: Python programming is drowning in red tape

#122

Earlier quoted context omitted.

I keep hearing these arguments but to me they sound like a romantic attachment to the past. There's no intrinsic quality in using 80 columns besides historical legacy. But hey we can also keep using the size of body parts as measurement units as well, or we can evolve. :) The 2 column use case is useful, but to be honest, rare. I just tested it here and I still need a big monitor and a "medium" font size for 2x80 to…

> I keep hearing these arguments but to me they sound like a romantic attachment to the past. If you think that "I like 80 because it allows me to have two files open side by side on my laptop with a readable font size." sounds like a romantic attachment to the past you should probably just read it over and over again until it doesn't.

Did you read the 2nd paragraph?

Just to be sure, I just tested on my notebook screen (13"): 2x80 doesn't fit with a comfortable font size for me, so maybe we should start using 70 chars?

Re: Python programming is drowning in red tape

#123
post #117

I'm a firm believer that good code should be consistent in its style, but that consistency should not prevent the programmer from communicating intent via subjective style choices. I'm OK with following someone else's (be it an individual code owner or a team's) style rules even when I strongly disagree with them (my personal style opinions have even changed on occasion because of this). I find code linting really us…

I have had the opposite experience. Black has been liberating for me, in that I can just worry about writing the code / worrying about the actual business logic, and Black handles all the formatting for me.

I used to worry far too much about whether this style was more readable than that style, which in the end is less important than almost everything else, as long as one of them is actually readable. Now I am free.

No automatic system is going to be perfect. Black might have edge-cases where a different style would be more readable, but that is true for any formatter. Using an opinionated (non-configurable) one means that I spend 0 time on config (not a useful way to spend time imo) and that my code will be consistent with the code of many others.

Re: Python programming is drowning in red tape

#124
post #12

> It was bikeshedding at its worst It's ironic that discussions about formatting are taking up so much mindshare in the python community. For years all you'd hear was that whitespace significance was a sign of the lowliness of python. Meanwhile, tons of people were ignoring the bikeshedding and getting things done. Now it's one of the most widely used languages in existence. The kinds of people that are focused on is…

I completely agree. Who cares if black is ugly? It's a standard which is easy to automate. Want a better standard? Make it. Until then black works.

> Want a better standard? Make it.

That is what this post is advocating for, his own fork of black.

Re: Python programming is drowning in red tape

#125
post #89

As a long time Python fan, I find the current state of the language frustrating. Tools like black and poetry are nice, but are not part of the standard library. Yet they seem to be required by every popular project out there. (Also, black’s formatting is quite ugly, as noted in this blog post) Meanwhile, the language itself is increasingly baroque and complicated. Type-annotated, asyncio-enabled Python hardly resembl…

> Type-annotated, asyncio-enabled Python hardly resembles the easy-to-understand language I fell in love with back in 2006. I'm all with this, but you can pretty much use python without touching these at all. They have a niche business use cases. E.g., when you work on large projects and you want to catch some errors to not be in the runtime. async was very needed to be able to write performant web servers such as no…

I don't think catching errors before runtime is a niche business use case.

Re: Python programming is drowning in red tape

#126
post #124

Earlier quoted context omitted.

I completely agree. Who cares if black is ugly? It's a standard which is easy to automate. Want a better standard? Make it. Until then black works.

> Want a better standard? Make it. That is what this post is advocating for, his own fork of black.

Yes, but in this case it was all bark with no bite. The author has made 0 commits to his fork since forking (in Feb).

Re: Python programming is drowning in red tape

#127
post #12

> It was bikeshedding at its worst It's ironic that discussions about formatting are taking up so much mindshare in the python community. For years all you'd hear was that whitespace significance was a sign of the lowliness of python. Meanwhile, tons of people were ignoring the bikeshedding and getting things done. Now it's one of the most widely used languages in existence. The kinds of people that are focused on is…

I completely agree. Who cares if black is ugly? It's a standard which is easy to automate. Want a better standard? Make it. Until then black works.

I personally think Black has the most beautiful style of the Python formatters. For example, I really dislike yapf's way of doing things.

Re: Python programming is drowning in red tape

#129

"black can kick and scream and its proponent can say that the frowny face is all they need but they are wrong. They are wrong visually, and they are wrong according to pep8. End of story." The "frowny face" is ): which in Python is all over the place, but hopefully you don't notice it, and if you do, you don't care. I find it to be sufficient separation between the arguments and the code. It's too bad the author does…

The current project I'm working on is Python+Black for backend and React+Prettier for frontend and I've really enjoyed the consistency / not worrying about formatting.

Re: Python programming is drowning in red tape

#130

Line length is such a hard problem to solve. I wish there was a way to be like don’t allow more than 95% percent of my lines to be longer than X. I run into this in Django a lot with my chained ORM queries. The usually tend to be like 10-15 chars to long. And in this case you have to line break on the parameters or on a ‘.’ which is ugly as well. While not related to Python, I feel like whenever I write JS code, espe…

Yes My personal preference regarding line lengths: 80 chars are not enough. And even pep8 says that "foolish consistency is the hobgoblin of little minds" So try being under 80 chars but sometimes you can't. Also don't break a line that's like 85 chars if it will just make it more ugly I'm glad Prospector by default doesn't enforce "the cult of 80 chars" dogma

My aim these days is usually around 70 chars, plus whatever the block indentation is. That way, I can always move the editor viewport to the right to keep the local region on the screen.
Post reply on HN