Django: Reformatted code with Black • Hacker News Board

Re: Django: Reformatted code with Black

#181

Post by njharman » Tue, Feb 08, 2022, 8:27 PM UTC

Kinrany wrote: post #43

declnz wrote: post #13

Aside: I love a good linter, but as a long-time Python fan I find it sad that Black has so little configuration (yes, I know, but still) and moreover that it often produces code that no human Python dev I know would write... Python was always meant to look concise / beautiful... (MyPy has also made this trickier too)

People conflate opinionated formats with autoformatting for some reason. An autoformatter removes 99% effort from formatting code, and that includes code actively being worked on. Autoformatters are incredibly useful. A standardized format removes effort spent learning to read a new format. That's an hour per format at most. I don't see any good reasons for an autoformatter to enforce a standard. A standard would wor…

In 30yrs of dev the truest statement in standards I can make is that they change, all the time. The 2nd truest is I and coworkers have wasted far to much energy on arguing and maintaing STDs.

Blacks value isn't autoformatter, it's preemptive discussion ender.

Re: Django: Reformatted code with Black

#182

Post by mrtranscendence » Tue, Feb 08, 2022, 8:30 PM UTC

OJFord wrote: post #86

Joeboy wrote: post #31

Earlier quoted context omitted.

from typing import ( overload, List, etc..., ) would seem more sensible to me. I know you can make isort do that, I guess maybe not black.

My preference is actually for what GP doesn't like; the reason I don't like your suggestion is that: from typing import ( overload, ) is silly, but I don't want: -from typing import overload +from typing import ( + overload, + List, +) when all I actually did (semantically) was: + List,

It feels to me like importing names from a module gets you a set of names from that module, so I'm already thinking about it as a collection. It doesn't bother me at all that it's turned into a tuple and spread over multiple lines.

Re: Django: Reformatted code with Black

#183

Post by jreese » Tue, Feb 08, 2022, 8:34 PM UTC

ziml77 wrote: post #64

mrtranscendence wrote: post #20

I've been using black at work for over a year now. I don't much care for some of the choices it makes, which can sometimes be quite ugly, but I've grown used to it and can (nearly) always anticipate how it will format code. One nice side effect of encouraging its use is how, at least where I work, it was very common to use the line continuation operator \ instead of encompassing an expression in parentheses. I always…

Try isort instead https://github.com/PyCQA/isort

Give µsort a try instead; it's focused on providing more safety when applying sorting to large codebases, and is designed to pair well with black out of the box:

https://usort.readthedocs.io

https://ufmt.omnilib.dev

Re: Django: Reformatted code with Black

#184

Post by jreese » Tue, Feb 08, 2022, 8:35 PM UTC

progval wrote: post #111

ziml77 wrote: post #64

Earlier quoted context omitted.

Try isort instead https://github.com/PyCQA/isort

isort also kind of has this bad behavior when using 'import as': $ cat foo.py from x import a, b, d, e from x import c as C $ isort foo.py Fixing /tmp/foo.py $ cat foo.py from x import a, b from x import c as C from x import d, e

This is something µsort actually gets right:

    $ usort diff foo.py
    --- a/foo.py
    +++ b/foo.py
    @@ -1,2 +1 @@
    -from x import a, b, d, e
    -from x import c as C
    +from x import a, b, c as C, d, e

https://usort.readthedocs.io

Re: Django: Reformatted code with Black

#185

Post by eredengrin » Tue, Feb 08, 2022, 8:36 PM UTC

BiteCode_dev wrote: post #172

eredengrin wrote: post #146

Earlier quoted context omitted.

> Bikesheding, yes. Hours lost in meeting, chat debates, documentation to write, linting configuration Sounds like a team problem, I've been on plenty of teams that use clang-format for c/c++ and there have never been any issues like this. Team players know that (almost all) arguing over formatting is not a good use of time. (edit: in case not clear, clang-format is extremely configurable. Set a default config and li…

> Sounds like a team problem, You had a good team. I had a great mum. Some people have great doctors. > It just shifts from "let's change this flag in yapf" to "let's switch to yapf because black looks ugly and gives us no options". If the practice doesn't match the theory, I'd rather trust the practice.

Well if it helps your team out then that's great, I just wouldn't expect that to generalize well. But who knows, people are weird, maybe more would give up fighting about style because of a tool change than I expect.

Re: Django: Reformatted code with Black

#186

Post by jreese » Tue, Feb 08, 2022, 8:42 PM UTC

mrtranscendence wrote: post #58

alecbz wrote: post #15

Earlier quoted context omitted.

OOC what are your grips with black's style? I generally find black pretty "beautiful" ( concise maybe not as much).

Sometimes it takes code like this: foo = ( spark .read .parquet(...) .filter(...) .withColumn(...) ) and turns it into foo = spark.read.parquet( ... ).filter( ... ).withColumn( ... ) which feels harder to parse for me. I also never quite got on board with the trailing commas.

Actually, modern versions of black will retain the fluent style you prefer, though it will collapse up to the first method call on the first line within the parens, so you end up with something like:

    foo = (
        spark.read.parquet(...)
        .filter(...)
        .withColumn(...)
    )

Re: Django: Reformatted code with Black

#187

Post by mulmboy » Tue, Feb 08, 2022, 8:42 PM UTC

bwhmather wrote: post #84

Shameless plug: For people who like black, I've been working on ssort[0], a python source code sorter that will organize python statements into topological order based on their dependencies. It aims to resolve a similar source of bikeshedding and back and forth commits. 0: https://github.com/bwhmather/ssort

Sounds interesting and perhaps novel. Might help if there were an example or two in the readme - as it is I still don't exactly know what this is.

Re: Django: Reformatted code with Black

#188

Post by mkesper » Tue, Feb 08, 2022, 8:47 PM UTC

bwhmather wrote: post #154

aaronchall wrote: post #143

Earlier quoted context omitted.

Does it put high-level business logic at the top or the implementation details at the top? Which is preferable, and why?

Implementation details at the top. Python is a scripting language so modules are actually evaluated from top to bottom. Putting high level logic up top is nice when you just have functions, which defer lookup until they are called, but you quickly run into places (decorators, base classes) where it doesn't work and then you have to switch. Better to use the same convention everywhere. You quickly get used to reading…

But this is really backwards? Everyone uses the if __name__ == "__main__" dance to avoid calling functions before they're defined, no?

Re: Django: Reformatted code with Black

#189

Post by pchf » Tue, Feb 08, 2022, 8:48 PM UTC

supreme_berry wrote: post #12

“Black” developer refused for a long time to add option to format code with single quotes with very aggressive manners. Now Django devs didn’t see that option for single quotes and code looks unpleasant.

To keep the single quotes, which in my opinion make the code less cluttered and closer to the REPL, I use the pre-commit hook double-quote-string-fixer, in conjunction with black's option skip-string-normalization set to true.

Re: Django: Reformatted code with Black

#190

Post by VectorLock » Tue, Feb 08, 2022, 8:56 PM UTC

timhh wrote: post #96

codingkev wrote: post #90

A little shoutout to a alternative Python formating tool https://github.com/google/yapf (developed by Google). The built in "facebook style" formating felt by far the most natural to me with the out of the box settings and no extra config.

I did a blind survey of YAPF vs Black at my work. The results came back as 70% in favour of Black. Black gives generally nicer output, and also more predictable output because its folding algorithm is simpler. YAPF uses a global optimisation which makes it make very strange decisions sometimes. Black does too, but much less often. There are also non-style problems with YAPF. It occasionally fails to produce stable ou…

How did you perform the blind survey? Format some code with Black and YAPF and ask people which they liked better?