[deleted]
Black: An uncompromising Python code formatter
41–50 of 262 posts
Re: Black: An uncompromising Python code formatter
#4288 characters per line is a weird choice. Why not 90?
Originally PEP 8 had 79 characters. Now that was a weird choice so most companies went with 80 instead, including Facebook. You want a low-ish limit because it makes it possible to fit two files side by side on a typical screen resolution. Even if you don't edit like that, you look at diffs like that. More importantly, a low column limit is helpful to disabled engineers who don't have to navigate horizontally so much.
So we used 80. I always felt bad when the linter stopped people from pushing impactful changes because they went over the limit by two characters. So two years ago I set up a "highway speed limit" style warning in flake8 (code B950 in PyCQA/flake8-bugbear). What it does is it keeps your limit intact (for example "80") but doesn't trigger unless you went over by more than 10%. So the limit happens to be 88.
When I was working on Black, I was faced with a dilemma. Should the formatter stick to 80 or be able to "go over" a bit, too, as we would let humans do. I felt like the latter made more sense as the resulting code looks nicer (fewer occasions to break a single line into three or more). Then I remembered Raymond's talk "Beyond PEP8" where he mentions that experience shows "90-ish" is the wisest choice. So I went with it.
Re: Black: An uncompromising Python code formatter
#43> By using it, you agree to cede control over minutiae of hand-formatting. I may be in a minority, but I do not want to cede control over minutiae of hand-formatting. Am I the only person that feels this way?
I'm fine with ceding control right up until the formatter does something I don't like for no good reason. For languages like Rust, where there is a single format convention that is closely tied to the language (via rstfmt), I am okay with this kind of forced standard. For something like Python, C++, or Java where there isn't a single "winner" for format guidelines, there's virtually no chance that I would embrace som…
A little bit of a catch 22 you think?
C++ has clangfmt.
Black has a good momentum right now it very well might be the clear winner in a few months
Re: Black: An uncompromising Python code formatter
#44Earlier quoted context omitted.
If you’re working alone, fine. But when working with other people, getting everyone to do the same thing, and have that automatically done for you / enforces is incredibly valuable. It’s such a massive win that any deviation from “my personal optimum formatting” is rounding error.
Not really. I worked at one place where they enforced PEP8 (using flake8 etc) using a git commit hook. In other words, when you try to commit some code, it would run flake8 which would most likely balk at some of the changes you made (and not let you commit until those were fixed). A lot of the rules/warnings are extremely nitpicky, and they had all of them turned on (except for the line length); I don't know how man…
> I don't know how many times I could not commit my code because I left a space at the end of a line, or an empty line contained whitespace, or I had only one blank line between two class definitions, etc.
On the other hand, it drives me nuts when I see stuff like this in our source files. I would love to have a commit hook that did nothing but enforce a minimal set of white space rules. Just requiring no trailing white space and no mixed tabs and spaces would make me so happy.
>Admittedly, Black works differently; as I understand it, it will just auto-reformat your code rather than yelling at you and making you go through your code and fix everything by hand, which is what the aforementioned approach did.
I don't actually write much Python, but surely you could have run the same tool (or some other formatter configured to match the linter) locally to have it do that auto-format for you?
Re: Black: An uncompromising Python code formatter
#45> By using it, you agree to cede control over minutiae of hand-formatting. I may be in a minority, but I do not want to cede control over minutiae of hand-formatting. Am I the only person that feels this way?
maybe give it a try. I felt the same way about prettier, but then I realized how much time I save by no longer having to worry about formatting. As I type, I just type it all on one line and then do a keyboard shortcut and it magically gets reformatted and looks pretty.
This is what I do too. Provided it's easy to type out, I don't really care all that much what the code looks like - especially when I'm getting paid.
(It just wants to be consistent, something the computer is very good at enforcing.)
Re: Black: An uncompromising Python code formatter
#46Earlier quoted context omitted.
If you’re working alone, fine. But when working with other people, getting everyone to do the same thing, and have that automatically done for you / enforces is incredibly valuable. It’s such a massive win that any deviation from “my personal optimum formatting” is rounding error.
Not really. I worked at one place where they enforced PEP8 (using flake8 etc) using a git commit hook. In other words, when you try to commit some code, it would run flake8 which would most likely balk at some of the changes you made (and not let you commit until those were fixed). A lot of the rules/warnings are extremely nitpicky, and they had all of them turned on (except for the line length); I don't know how man…
> I don't know how many times I could not commit my code because I left a space at the end of a line, or an empty line contained whitespace
Trailing whitespace causes issues with git, editors, diff tools, and numerous other things, as well; keeping it out of a repository is a good thing.
> I had only one blank line between two class definitions
I certainly agree that that's the kind of thing a tool should help with rather than complain about and make you fix.
Re: Black: An uncompromising Python code formatter
#47> By using it, you agree to cede control over minutiae of hand-formatting. I may be in a minority, but I do not want to cede control over minutiae of hand-formatting. Am I the only person that feels this way?
Why are you interested in minutiae? Esp that which has no functional impact and can be automated. People are into things like this pep8 etc because they don't want to waste another second of their lives thinking about formatting. Or, worse discussing, arguing, bikesheding, documenting, enforcing, teaching the new guy how we format "here". I'm sorry to sound snarky, but this is one of the things you slowly learn over…
I've noticed that, these days, I only find myself worrying about careful hand-formatting when the auto-formatter is doing an inadequate job. e.g., IntelliJ's default Java standard makes far too much stuff optional, which is another way of saying that it is full of cases where it forces me to make the decision.
Looking through Black's rules, it seems to me like the rules it's implementing are comprehensive and specific enough that I'd probably end up with few, if any, situations where I even want to take control. And I'd gladly give those up in return for not having to wade through so much diff clutter when I'm doing code reviews.
Re: Black: An uncompromising Python code formatter
#48> By using it, you agree to cede control over minutiae of hand-formatting. I may be in a minority, but I do not want to cede control over minutiae of hand-formatting. Am I the only person that feels this way?
It's more cargo cult for nitpickers.
Re: Black: An uncompromising Python code formatter
#49I like the spirit of it, but the implementation seems to contain too many exceptions (e.g. trailing comma, whilespaces around :). This problem is not unique to Black, it is actually too common for most auto-formatters. I usually prefer a set of dead-simple formatting/styling rule, easier to enforce, lower cognitive load.
The reality is that the way humans write code is complex and if you try to use simple rules it's going to look bad in many cases.
What linters have been doing is to figure out --some-- rules that are general enough that can be enforced.
Complete formatters like black are making decisions for --every single formatting choices--.
In practice, they need to be complex if they want to have people using them.
Re: Black: An uncompromising Python code formatter
#50Earlier quoted context omitted.
Hey Vjeux. What does black mean for the prettier python plugin[1]? I had high hopes to move over all projects to prettier (for JS/Python). Is there going to be any merging between prettier python and black? Do you recommend one over the other? Thanks [1] https://github.com/prettier/plugin-python
I don't know :) I worked on prettier myself because I wanted to solve formatting for the language I was involved in. It turned out that the prettier infrastructure was actually really good for other languages so we used it for CSS, Markdown, GraphQL... and added support for a plugin system for other people to build printers for their own language. patrick91 (not working at Facebook) is working on a python formatter u…
> One interesting thing I realized is that communities are built around programming languages and it's really hard to influence another community from the outside.
IMO, that point is worthy of a detailed blog post or conference talk, if you would be so inclined. Would love to hear more.