Hacker News new | past | comments | ask | show | jobs | submit login

Same here. This is so powerful. I absolutely love python, but this is one thing it doesn't allow. On the other when working in say Rust, I can express my thought in a line or 2 straight from brain to keyboard without having to care about any formatting, hit autoformatter and also typically get an immediate feedback about basic syntax.

When writing in a language that can be auto formatted, it is a huge cognitive overload removed from my shoulders, like having a copilot.

Have you tried any Python autoformatters? `autopep8`, `yapf`, and `Black` come to mind.

My team just converted to `black`. I find it shockingly bad. I does format code legally according to its rules, but the result is often absolute trash from a human readability standpoint.

I’m fascinated by this response: Black has been the first Python autoformatter I have had that problem with and felt comfortable enabling as a pre-commit / CI check.

Do you have any examples of things which were so bad? The team has been pretty response for the handful of things which I reported.

I think it's really a people problem:

Black will mindlessly split long lines into shorter, and my coworkers will just leave them as is. The results are eye bleedingly awful.

I hope most black proponents expect people to look at the generated code and change things until it looks decent?

Of course this problem is inherent in a tool that is autoformatting rather than warning, and seems to me to indicate a mentality that code is meant to be read by computers, not humans.

I think some of this is just that you have strong personal opinions which are somewhat out of the norm. I have Black split long lines but the results are never what I’d call awful and I’d increasingly class that as a code-smell indicator since the cases where I haven’t been happy with the results were generally unnecessarily complex lines which could be split to be more readable.

I would also flip your last sentence completely: computers don’t have problems reading code of any style. Auto-formatting is so humans don’t burn time adjusting to different styles or, worse, failing to parse them the same way as a compiler.

You seem to be sitting on two chairs here.

The split of the long lines aren't bad, but they are also bad because the long lines are inherently too complex.

Of course some times our broken up lines are too complex, and should ideally be restructured, but...

1. The mechanical way Black does it is rarely the best way to decomplexify things.

2. Often the long line wasn't complex at all. It just contained a simple but long string. Line length is a weak measure of code complexity, but as a dumb script, it's all Black can use.

That said, my main beef is really with the 88 char line length. If it was 120 or 140, I wouldn't like Black either, but I'd only be kinda annoyed. Coupled with 4 char indentations, 88 s an absurdly small space to fit code in, when we have the biggest screens in history. It's an incomprehensible madness to me.

Not sure what your final section says. I hope it's not that humans should learn to read code just like computers do?

To me, one of the most important quotes about our job is this:

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

FWIW, Black now allows line-length customization via the `--line-length` argument.

Yeah, we actually looked at that today, and I'm impressed by how it repairs what it tore apart in "88" mode.

We might change things up and I might be OK with my 'black life after all.

Yes. They can format correct python to pep8, but can't guess which if an else correspond to if I write it all on one or two lines.

This experience must have been with a formatter different than Black. That one has no problems with any valid syntax.

I think the point is that the valid python syntax is potentially a limitation on any autoformatting tool. Like, suppose you were writing in C. You might well write this:

    if(x);else if(y){if(z);else;}
and clang-format would turn it into this:

    if(x) {
    } else if(y) {
        if(z) {
        } else {
But the equivalent in Python has to be correctly indented to be interpreted properly, because you need to distinguish these two cases:

    if x: pass                 if x: pass
    elif y:                    elif y:
        if x: pass                 if x: pass
    else: pass                     else: pass
(This is the classic shift/reduce problem: https://www.gnu.org/software/bison/manual/html_node/Shift_00...)

This is sort-of not unreasonable, because of course code has to be syntactically correct for the autoformatter to do its thing, and if you're working in Python, these are the syntax rules. So, what can you do?

But suppose you'd come to find it valuable to be able to stuff all your code on one line and have the autoformatter sort it out: you might then find the Python syntax a backwards step by comparison, rather than an improvement. I think this is the claim that's being made, and no more.

It even has a name, the Dangling Else, and dates back to Algol:


This is what I meant, yes, although I could never have explained it half as well as you did!

One solution is to make the formatter interactive and prompt for which interpretation is desired.

A CL restart-style editor integration for this could be interesting.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact