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

Black – Uncompromising Python code formatter

github.com

Post reply on HN
Print view View original

151–160 of 251 posts

Re: Black – Uncompromising Python code formatter

#151

Post by edflsafoiewq »

RussianCow wrote: post #129
a1369209993 wrote: post #103

Earlier quoted context omitted.

No, we can't. My (and, by the sound of it, CrLf's) favorite format relies on information that your pre-commit hook has artificially removed from the code. Eg: munge(gidget, thing1,thing2,thing3); cmplt(dtypeA,valueA, dtypeB,valueB); (Most cases are more subtle (and thus less amenable to "oh, you just need to build a complete static type checker into the formatter") than this, but I wanted an obvious example.)

It seems like the signature of the functions should be different, especially the second example. I would have written the cmplt function to take tuple pairs: cmplt( (type_a, value_a), (type_b, value_b), ) That's much more clear about the relationship between each pair of values either way, and would get formatted nicely by Black.

No it wouldn't; black will put that all on one line if it can. The semantic information in vertical space is lost.

A better example is a matrix laid out as a grid, which auto-formatters always destroy

    mat3x3(
         0,  a, -b,
        -a,  0,  c,
         b, -c,  0,
    )

Re: Black – Uncompromising Python code formatter

#152

Post by weberc2 »

alexhutcheson wrote: post #114
weberc2 wrote: post #99

Earlier quoted context omitted.

Sounds like you're using it wrong. The autoformatter is for the whole repo, not for individual contributors. The point is that the whole repo has the same style, so you should only ever get diffs on the lines that were changed or the first time you run the autoformatter on the repo (and then you shouldn't be making manual changes that will be hidden amid the autoformatter noise).

Most larger orgs/projects aren't going to be willing to reformat all the code in their repo in one big bang. Regardless of what promises the tool claims to make, you need to be concerned about behavior changes or breakages, and most projects don't have high enough test coverage to cover everything. Depending on the size of your repo, it might not even be technically possible to make this change all at once. It's also…

I shouldn’t have said repo, but rather some agreed upon unit of code. It could be a single package or file as long as all contributors touching that file adhere. You should not use black for any unit of code that you can’t get buy-in on. Black is a technical tool; it doesn’t solve political problems.

Re: Black – Uncompromising Python code formatter

#153

Post by frosted-flakes »

CrLf wrote: post #17

I've been using it for a few months now, but I don't really like it. It does remove quabbles about formatting, but I've personally never felt that as a problem and it just replaces them with constant frustration. I think code formatting is very important for readability, and I think many (subtle) choices about how to make a piece of code more readable are very subjective. These types of tools are just incapable to ma…

> And some rules make this painfully obvious even in less subjective cases. Eg: black formats dictionaries into a single line if they fit one line, which makes nested structures unreadable if they combine bigger and smaller sub-dictionaries.

Prettier for JS has a simple solution to this specific problem, and that is to follow the code's lead. If the first element of the object or array starts on the same line as the opening bracket, keep it as a single line if it fits. Otherwise, if the first element starts on a new line, put every element on a new line (explode the collection), even if they would all fit on a single line.

Black should consider doing this instead of the open PR to explode collections if there is a trailing comma[0], which feels... wrong.

[0] https://github.com/python/black/pull/826

Re: Black – Uncompromising Python code formatter

#154

Post by a1369209993 »

edflsafoiewq wrote: post #151
RussianCow wrote: post #129

Earlier quoted context omitted.

It seems like the signature of the functions should be different, especially the second example. I would have written the cmplt function to take tuple pairs: cmplt( (type_a, value_a), (type_b, value_b), ) That's much more clear about the relationship between each pair of values either way, and would get formatted nicely by Black.

No it wouldn't; black will put that all on one line if it can. The semantic information in vertical space is lost. A better example is a matrix laid out as a grid, which auto-formatters always destroy mat3x3( 0, a, -b, -a, 0, c, b, -c, 0, )

To be fair, I suspect RussianCow would write that as something like:

  mat3x3(
    rowvec3( 0, a, b),
    rowvec3(-a, 0, c),
    rowvec3( b,-c, 0),
    )
Which is probably better, especially with tuples instead of struct{Scalar[3]}. Doesn't fix

  mat3x3(( 0, a, b),(-a, 0, c),( b,-c, 0))
, though.

Re: Black – Uncompromising Python code formatter

#155

Post by gen220 »

mintcoffee wrote: post #130
owenmarshall wrote: post #128

Earlier quoted context omitted.

> no-one likes what the autoformatter does to their code, everyone likes what the autoformatter does to their coworkers' code It always strikes me as strange that we spend our own effort and time on systems that mandate code style when my unambiguously correct style and my coworkers obviously incorrect style both end up converted to the same AST for any useful work. Why isn't style an entirely local choice, with a hi…

JetBrains' MPS does exactly that - it stores the code as an AST, then renders it based on your own preferences: https://www.jetbrains.com/mps/concepts/

Wow this is a killer feature. If you're really zealous about how things "ought to be", now you can just write your preferences out once and be done with it. Stinks that it locks you into JetBrains, presumably: unless, is this part open-sourced?

Re: Black – Uncompromising Python code formatter

#156

Post by frosted-flakes »

goostavos wrote: post #87
infecto wrote: post #64

I have just started using it and love it. It sounds funny but while formatting is not always a deal breaker it still kills me for 1) readability and 2) the faith that when someone reads the code base later one they know I was not an idiot. I know 2 is kind of subjective but when I look at someone elses code and I see obvious mistakes against pep8 I start judging both the person and the code harshly. Perhaps unfair bu…

That's pretty lazy thinking, imho. "Person x doesn't care about their code because they didn't use the formatting I like" Worrying about or judging code based on PEP8 is missing the forest for the trees[0] [0] https://www.youtube.com/watch?v=wf-BqAjZb8M

It's not that, it's that they use inconsistent and non-standard formatting.

For example, in JavaScript, there is always a space before a function's opening curly bracket. This is pretty much a global standard, and it's rare to see code that doesn't follow this rule.

However, I'll occasionally see code on Stack Overflow that randomly excludes these spaces. It honestly makes it so much harder to read, and I'm less willing to put in the effort to help them, because they didn't even go to the effort of properly formatting their code. Inconsistent indentation especially kills me because it makes code impossible to read.

Re: Black – Uncompromising Python code formatter

#157

Post by SomeOldThrow »

mintcoffee wrote: post #130
owenmarshall wrote: post #128

Earlier quoted context omitted.

> no-one likes what the autoformatter does to their code, everyone likes what the autoformatter does to their coworkers' code It always strikes me as strange that we spend our own effort and time on systems that mandate code style when my unambiguously correct style and my coworkers obviously incorrect style both end up converted to the same AST for any useful work. Why isn't style an entirely local choice, with a hi…

JetBrains' MPS does exactly that - it stores the code as an AST, then renders it based on your own preferences: https://www.jetbrains.com/mps/concepts/

Seems like the underlying format is unrelated to editing with customizable AST—in fact, that seems like it'd make things like code review pretty miserable. You'd have to upgrade all tooling to be ast-aware.

That said, once upgraded, that would be far, far, far superior to text. Our tooling hit the limits of text a long time ago: consider how terrible diffs are at communicating simple operations like indentation changes, or how basic our refactoring is even in the best case scenarios.

Re: Black – Uncompromising Python code formatter

#158

Post by voidfunc »

epistasis wrote: post #78
ben509 wrote: post #72

Earlier quoted context omitted.

> Having a standard is more important... Let me take a shot at why it's important. We spend years peering at code hunting for tiny, miniscule mistakes. Thus we're training ourselves, quite rigorously, to spot minor deviations. We're also irrational in the moment: our aesthetic sense is bothered by certain patterns, and our social sense wants to assign blame for this "wrongness" to individuals. An auto-formatter remov…

Agree 100%, except for a minor quibble at the end. I've tried a few small projects with pipenv and black recently, and though I love black, I'm still struggling to accept pipenv as good. It's so slow so often, and I can't understand why.

I used pipenv on a few projects and my experience has been somewhere between "this is hot garbage" and "meh".

I'm no longer using it for Python projects.

Re: Black – Uncompromising Python code formatter

#159

Post by AlexCoventry »

epistasis wrote: post #78
ben509 wrote: post #72

Earlier quoted context omitted.

> Having a standard is more important... Let me take a shot at why it's important. We spend years peering at code hunting for tiny, miniscule mistakes. Thus we're training ourselves, quite rigorously, to spot minor deviations. We're also irrational in the moment: our aesthetic sense is bothered by certain patterns, and our social sense wants to assign blame for this "wrongness" to individuals. An auto-formatter remov…

Agree 100%, except for a minor quibble at the end. I've tried a few small projects with pipenv and black recently, and though I love black, I'm still struggling to accept pipenv as good. It's so slow so often, and I can't understand why.

Try poetry. https://johnfraney.ca/posts/2019/03/06/pipenv-poetry-benchma...

Re: Black – Uncompromising Python code formatter

#160

Post by haraball »

Beside the benefit that black removes any discussion regarding formatting, my favourite benefit otherwise is the speed-up it yields by having it run everytime I save a file. I don't have to care about line lengths or single/double quotes or stuff like that anymore, since black will fix it for me anyway. And if black fails to trigger, it means there is something wrong with my code somewhere.

This is what I've stuffed in my VS code settings:

    "python.formatting.provider": "black",
    "editor.formatOnSave": true,
Post reply on HN