We use Black in a pre-commit hook for all our python code. It makes legibility and formatting a non-issue in the team. Yes it can look strange at first if you're not used to it, but after a while it makes formatting invisible (and it's odd reading non-black python). Would recommend.
Black – Uncompromising Python code formatter
21–30 of 251 posts
Re: Black – Uncompromising Python code formatter
#22I'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…
Are you sending unfortunate examples upstream? It's still beta, so it can be improved somewhat.
Re: Black – Uncompromising Python code formatter
#23How do you enforce the use of a formatter in a project -- pre-commit hook? pre-receive hook? both? And is there a convention to put a specific dotfile at the project root to hint at your IDE/editor that it should use a certain tool for automatic formatting?
I use the format on save for black + prettier.
Re: Black – Uncompromising Python code formatter
#24I like the idea of auto-formatting code, like go does. Though I think I prefer autopep8
Black goes much further than autopep8. Black is an auto-formatter. autopep8 tries to automatically fix PEP-8 issues.
Re: Black – Uncompromising Python code formatter
#25Let me know when it's available as a Vim plugin.
It’s been available that way for over a year:
https://github.com/python/black/blob/master/plugin/black.vim
Re: Black – Uncompromising Python code formatter
#26I'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…
You could configure your IDE to re-format files into your favorite format and just have a pre-commit hook that formats them back into the official format. That's how I work. No arguments about style and formatting, yet I get to make the code look how I personally prefer it.
Re: Black – Uncompromising Python code formatter
#27The way you can tell that black is good is that everyone mildly dislikes a few things about it, but they're usually different things. That's usually a good clue that you've hit real middle-ground. I blackify my projects once we hit 3 contributors.
Why wait? I run black on all my new single-author projects.
i have my personal tics about formatting that i enjoy. As long as it’s just me, i’ll persist them.
Re: Black – Uncompromising Python code formatter
#28Against my better judgment I'll bite.
I super dislike black's formatting, and I think it's really rare to actually see it in codebases. It wraps weirdly (sometimes not at all). I'd prefer to use yapf, but last I checked it still crashes on "f-strings".
Here's a small example:
basket.add({
apple.stem
for satchel in satchels
for apple in satchel
})
basket.add(
{
apple.stem
for satchel in satchels
for apple in satchel
}
)
I totally believe using a formatter is good practice. Black is in a challenging position of coming into a community with a lot of existing code and customs, and I get that. But I also think that's an opportunity, rather than having to guess at what is good, there's a wealth of prior art to look at. I wish it had done this, rather than essentially codify the author's style.
Re: Black – Uncompromising Python code formatter
#29This is a case where I'm completely decided. Everybody should use an autoformatter. The minimal benefit you get from custom formatting is completely outweighed by the uniformity, the consistency and readability of autoformatted code.
I also switched to mandatory clang-format for a big C project of mine last month. Just the PR hooks and linter integration into github not yet. Saves away a full round of nit picking.
Re: Black – Uncompromising Python code formatter
#30Black is essential for maintenance of Pandas code which uses method chaining.
If you use Pandas you should be using method chaining and therefore also black.