Black is just slightly too opinionated. It gives you configuration options for benign things such as numeric separators, but it flat out refuses to allow tab indent, which a fairly significant part of the python community uses.

I tried to PR a --use-tabs flag but the PR was rejected without comments. Had to fork Black to be able to use it. Tan is a drop-in replacement that allows --use-tabs (and use-tabs = true in pyproject.toml).

https://github.com/jleclanche/tan

The reason Black is fast becoming standard is precisely because it is so opinionated. Like the other code formatters that have successfully become 'normal', such as gofmt. An option means that there isn't a standard, but several standards. And the people pushing Black in their projects see the benefit of a global standard, even though it is rarely 100% their personal preferences. It is a consensus.

Prettier is more widespread than black, is very opinionated, and still has an option for tab indent. This is a strawman.

How is this argument a strawman?

Prettier's opinion then is that tabs are irrelevant to the formatting. Which is probably fine for the all the languages Prettier seems to support. Unlike Python, where tabs vs spaces matter. Mixing tabs and spaces is a problem, and a formatter cannot automatically support both or risks changing the meaning of code.

I don't know how you arrive to this conclusion… prettier never mixes tabs and spaces, it would be a bug if it did. And there's no meaningful difference between tabs and spaces in Python either. Python has significant indent stops, that's all.

Furthermore, prettier has a python plugin which does support tabs.

Thats a shame, especially as I've heard tabs are more accessible: https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t...

Precisely why I use them and why I'm uncomfortable with Black refusing to add the option (https://github.com/psf/black/pull/513).

This argument sounds quite bizarre to me. Why would a visually impaired programer not manage to set their editor up to show indenting spaces the way they want, or failing that, collaborate with others to do so?

It's not like they can be effective at their job either without the ability to read 3rd party code, which overwhelmingly will be space indented.

How to set an editor to use big visual indents for spaces?

Depends on the editor, of course, but e.g.

https://www.emacswiki.org/emacs/redshift-indent.el

(Haven't tried the above, but I've done fairly extensive display hacks with emacs in the distant past, so I have a fair amount of confidence that it's not hard).

While I prefer tabs whenever I can, I can see why it doesn't support it. If you have to share code, you're going to use spaces. For some reason everyone including Guido insists on spaces. I would rather not have to waste time thinking about formatting or much less which formatting style to use. New languages like Go and Rust solved this problem.

I disagree with a few of Black's decisions, so I forked it to Lavender [0], which I keep up to date with the latest stable Black release (and use actively in all my Python projects).

> Differences from Black

> - The default line length is 99 instead of 88 (configurable with --line-length).

> - Single quoted strings are preferred (configurable with --string-normalization none/single/double).

> - Empty lines between classes and defs are treated no differently from other code. The old behavior, which sometimes inserts double empty lines between them, remains available via --special-case-def-empty-lines.

> - The Vim plugin configuration variable for line length is named g:lavender_line_length instead of g:lavender_linelength, for consistency with the other configuration variable names.

[0] https://github.com/spinda/lavender

Nice to hear. The single quote issue is the main thing that keeps me from using black. Double quotes are just too noisy.

Black can be configured to use single quotes. In fact, I think it's the only style configuration you can make.

Where do you see that?

https://black.readthedocs.io/en/stable/the_black_code_style....

I think it's the `--skip-string-normalization` flag which means "Don't normalize string quotes or prefixes".

But I want them normalized. Normalized to single quotes.

Yes, this. I have early-stage cateracs, which by-and-latge is not an issue on my 40 inch monitor. But it does mean that my astigmatism drifts around monthly. My prescription changes faster than I can get new lenses cut. The BIGGEST ergonomic issue for my with Python is single versus double quotes. Double quotes are the difference between happily coding all day versus a headache at lunch time and 5% less done. Fuck Black.

Can you say more about how single quotes vs double quotes is helpful for you? I rarely write python, but I have a passion for accessibility and I'm curious about this.

It doesn't really matter which standard you use imho, as long as you automate the tedious task of code formatting to arbitrary standards. If it's something the computer can do let it do it don't waste your time on it. This goes especially in pull requests where dedicated focus to trivial things like formatting often distracts from the real things that need review, like code architecture.

It would be nice if things converted on a single standard, however.

True, but the order of things will never allow this to happen, either the old standard lags behind, some people disagree on something (just look at the tabs vs spaces discussion) or some people just have inherently different personal preferences. Then there is always the eb and flow of of convergence and deviation. Thats why I've given up on pushing my preferred standard in a team and just enforce the rule that is must be automated so I don't have to spend time on it no matter which way the current standard wind blows.

black is opinionated. If you disagree with black's opinions then a negotiable formatter like YAPF might be better.

I personally love black though.

Black is opinionated enough that you will occasionally mumble about it, but good enough that you will keep using it anyway. That's a remarkable achievement for a formatter. For me it just took a little to get used to double-quoted strings.

Rust's "cargo fmt" tool is similarly good.

I hear you on the double-quoted strings; and that's why the only black configuration I allow myself, is "skip-string-normalization = true" in my pyproject.toml

I'd say that black is way too opinionated, especially since it doesn't produce good output a lot of the time. At my company we consistently have to adjust the way we write code in order for black not to mangle it.