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

Django: Reformatted code with Black

github.com

Post reply on HN
Print view View original

201–210 of 256 posts

Re: Django: Reformatted code with Black

#201

Post by bwhmather »

mkesper wrote: post #188
bwhmather wrote: post #154

Earlier quoted context omitted.

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?

It is a bit backwards, but in exchange you get predictability

With backwards sorting you know that, unless there is a cycle, you can always scroll up from a call site to find the definition or down from a definition to see where it is used. With forwards sorting you can scroll down to find a definition, unless the function was imported, or used as a decorator somewhere, or called by something that was used as a decorator, or used in some other way that I haven't thought of.

My personal experience is that this predictability is hugely useful. It almost entirely obviates the need for jump-to-definition within a module, and gives modules a very obvious shape and structure.

Re: Django: Reformatted code with Black

#202

Post by s5806533 »

jessaustin wrote: post #156
3pt14159 wrote: post #117

Earlier quoted context omitted.

Well, sorta. It's really, really mentally annoying switching between projects where standards are different. For example 80 char limit to 120 char limit takes me at least a month to fully get used to. I agree black is better than the alternative, I agree it has downsides, I'm happy some of the parameters are tunable, but I'm also glad most of them are not. I just want to write software with tools I'm used to.

Who is using 120 chars?!?!? I can certainly understand the adjustment difficulties...

moi

Re: Django: Reformatted code with Black

#203

Post by jreese »

Spiritus wrote: post #199
jreese wrote: post #183

Earlier quoted context omitted.

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

For me µsort is a non-starter since it doesn't ignore the import/from part when sorting lexicographically. So when an import changes from `import foo` to `from foo import bar` (and vice versa), the import is moved. Sorting should start at the package name, nothing else.

I suspect you are fighting the tide of common practice in the Python community. In your example, switching from `import foo` to `from foo import bar` is changing the entire nature of the import. Sorting module- and from-imports separately also makes it much easier for many people to visually scan a block of imports. And similar to black, having a tool be consistent and predictable across projects and modules is more important than bikeshedding every possible opinion.

Re: Django: Reformatted code with Black

#204

Post by TheRealPomax »

The reason to use Black is the same as Prettier on the HTML/CSS/JS side: forever stop having an opinion on code style, it's wasted time and effort. Any "it's not exactly what we want" comment with an attempt to customize the style to be closer to "what we were already using" is exactly why these things exist: by all means have that opinion, but that's exactly the kind of opinion you shouldn't ever even need to have, tooling should style the code universally consistently "good enough". Which quotes to use, what indent to use, when to split args over multiple lines, it's all time wasted. Even if you worked on a project for 15 years, once you finally add autoformatting, buy in to it. It's going to give you a new code style, and you will never even actively have to follow it. You just need to be able to read it. Auto-formatting will do the rest.

Re: Django: Reformatted code with Black

#205

Post by dumdumdumdum »

declnz wrote: post #28
belval wrote: post #22

Earlier quoted context omitted.

Indeed, I don't like Black's style, but I prefer working in a Black codebase than one where everyone has their own preference. Having style guidelines in a team is also a great way to remove pointless debates when reviewing PRs.

+1 ...which is why I wish Black allowed more configuration. A team can often agree on a set of styles. Every team on the Python planet agreeing... now that's much harder

https://github.com/google/yapf

Re: Django: Reformatted code with Black

#206

Post by BiteCode_dev »

eredengrin wrote: post #185
BiteCode_dev wrote: post #172

Earlier quoted context omitted.

> 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.

I don't have one team, I'm a freelancer, I meet 2 teams each month. I have a large sample to generalize from.

Re: Django: Reformatted code with Black

#207

Post by OJFord »

mynegation wrote: post #114
OJFord wrote: post #87

Earlier quoted context omitted.

Does the user matter? As long as the commit message is something sensible like 'Autoformat with black' it can be easily ignored when seen, and you can avoid seeing it with blame as simonw suggests.

The problem is that this revision will override all the previous ones in the “blame” output so it needs to be explicitly ignored. See a great link elsewhere in the thread on how to deal with that in newer versions of git.

Yes, as I said?

My point was that the user doesn't matter (vs. anything else about the commit) to me in any context that I see it.

And then I mentioned without reiterating the advice about hiding the commit from blame just as you did.

In any context where I see "OJFord committed 'Autoformat with black'" for this, it's not 'OJFord' that's the problem IMO.

Re: Django: Reformatted code with Black

#208

Post by albertzeyer »

crad wrote: post #107
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)

I'll take yapf --style=pep8 formatting over black any day.

I found this comment: https://news.ycombinator.com/item?id=17155048

Are the mentioned issues resolved by now? E.g. the quadratic algorithm?

Re: Django: Reformatted code with Black

#209

Post by wolverine876 »

Do Black and other autoformatters enable significantly more reusable code and computer-generated code? Formatting is certainly not the only or greatest barrier, but if format is standardized across projects, it's easier to plug and play code from outside.

Re: Django: Reformatted code with Black

#210

Post by l-lousy »

atoav wrote: post #140
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

Some illustrative before-after syntax-highlighted code segments would be a nice addition for the readme.

He added some :)
Post reply on HN