Python formatter that supports tabs

[jsh9]

Hi @onlycs, @dhushyanth-s, , @SkirOwen, @mabeyj, @itsthejoker, @JimDabell, @caniko, @blooalien, @DaRoee, @rslinckx, @BrettMoan:

I recently forked Black (https://github.com/psf/black) and started to make my fork more configurable: https://github.com/jsh9/cercis

My main motivation for forking was not to use tabs (I personally use spaces), but I added tab support after reading all these discussions:

• give us tab support, still. psf/black#2584
• Give us tab support psf/black#2122
• [WIP] Add a --use-tabs argument to use tabs instead of spaces psf/black#513
• Support for tab indentation psf/black#47
• Tab Support Request psf/black#2798

You either participated in them, or you up-voted the "give us tab option" comments. Your reasons for wanting tabs differ, but I think they are all valid, so I empathize with you.

I added two options:

• --use-tabs (bool, default = False)
• --tab-width (int, default = 4)

In particular, the 2nd option is necessary for getting the line length correctly (because we can't simply assume a tab has a width of 4).

Please feel free to try it out (the documentation is in README) and please feel free to share feedback with me!

Also, I'm cc'ing @sciyoshi, @jleclanche, @FredHappyface because I saw that you also forked Black just to add tab support. I read your relevant comments on Black's issue board -- I really can empathize with your frustration.

[caniko]

Thanks! I probably won't use cercis for now, but will keep it on my radar!

Suggest to look at this!

[jsh9]

Hi @kattkieru, I just saw you post here (astral-sh/ruff#2319), so I'm tagging you here for your awareness.

If you are interested, please feel free to try out this tool and provide feedback. Thanks!

[mabeyj]

Thanks, this is very impressive and very much appreciated!

I did a quick test and tabs seem to work as expected. Collapsing nested brackets is a massive improvement. I will definitely be switching to Cercis when I get the chance.

I have also forked Black to add tab support as well as a few personal stylistic preferences. Tabs was really not that much effort to get working. What stood out to me was how many times they hardcoded 4, 4 * " ", and " " instead of using proper variables.

Black's stance on this is just incredibly bizarre to me. I work on a Python web application which uses Prettier and about five other Python formatting tools (particularly, docformatter and isort). They all support tabs. I contributed an improvement related to tabs to one these tools, and there was no problem. Black has been the only outlier in my experience.

In the case of a web application, it's absurd that I would have to either deal with half the project using different indentation or reconfigure Prettier and reformat half the project again just to use Black as they intend.

Black's aggressive responses, the close-mindedness on accessibility (especially), the fact that they already support similar preferences like line length, the fact that tabs is the first question in their FAQ... Rather than implement a low-effort, commonly supported preference that some projects clearly need, they choose to make it difficult or impossible for those projects to use and benefit from their otherwise excellent tool. That's a shame.

I'd like to make one suggestion that I implemented in my fork:

• An option for preserving blank lines inside brackets (tuples, lists, dictionaries, function arguments, etc.): https://github.com/mabeyj/black-ex/pull/3/files

  Blank lines immediately after an opening bracket and before a closing bracket are removed. Multiple blank lines are reduced to one blank line. This is similar to how blank lines are treated elsewhere.

  This is useful for large lists of things that are grouped logically. Black discards blank lines in these cases which can hurt readability. Black has rejected this suggestion, but may be open to it more recently in certain cases.

[jsh9]

An option for preserving blank lines inside brackets (tuples, lists, dictionaries, function arguments, etc.)

Ah, this a very good suggestion! I did ran into this issue myself, and was bugged by Black's default style.

I ended up using an empty # line to stop Black from removing it:

something = [
    # Group 1
    1,
    2,
    #
    # Group 2
    3,
    4,
    ...
]

Your implementation (https://github.com/mabeyj/black-ex/pull/3/files) is clean and the test cases are great!

May I have your permission to directly copy and paste your implementation? If so, I can cite your fork in the README file.

[jsh9]

Black's aggressive responses, the close-mindedness on accessibility (especially), the fact that they already support similar preferences like line length, the fact that tabs is the first question in their FAQ... Rather than implement a low-effort, commonly supported preference that some projects clearly need, they choose to make it difficult or impossible for those projects to use and benefit from their otherwise excellent tool. That's a shame.

Someone left a comment on another discussion thread of Cercis, with completely different wording 😂 : #15 (comment)

[mabeyj]

Yep, feel free to use/modify my implementation as needed.

I wanted it for a few basic lists like your example, but it seemed to work fine in other cases. Looking at it again, the tests probably need more cases for dictionaries and sets as those aren't really covered.

That comment is hilarious. 😆

[jsh9]

Hi @raylu, @nilsbunger, @Gotos, @awoo-civ, @samtygier-stfc, @Avasam, @reitzensteinm, @memark:

I saw that you upvoted/hearted this comment (astral-sh/ruff#1904 (comment)) by @JimDabell, so I assume you are all looking for a Python auto-formatter that supports different indentation styles.

I forked Black a few weeks ago (this is my fork: https://github.com/jsh9/cercis) and added support for different indentation width and styles. Here are the relevant options:

• --use-tabs
• --tab-width
• --base-indentation-spaces
• --function-definition-extra-indent
• --other-line-continuation-extra-indent
• --closing-bracket-extra-indent

One or more of these options should satisfy your use case.

Please feel free to take a look and provide feedback! Thanks!

[jsh9]

What would you preferred style be? I'm actually fine with the styles that you listed above, so I'm curious.

[Avasam]

I'm not familiar with Black's internals. So I don't know how feasable it would be.
I've seen some formatters (like ESLint plugins and dprint) simply not unwrap lines, even if it would fit. (rules about newlines, braces, parenthesis, etc being separate)

If you have to target specific concepts, then as mentioned above, the option to not unwrap method parameters (both for method calls and definitions), comprehensions (list, sets, generators), ternary conditions, and operators. At least no onwrapping on the keywords & operators themselves.

[Avasam]

This is a very relevant comment: grantjenks/blue#2 (comment)

[jsh9]

Do you mean that you prefer Version A over Version B?

Version A:

answer = [
    _ + 2
    for _ in something
    if _ > 1
]

Version B:

answer = [
    _ + 2 for _ in something if _ > 1
]

[Avasam]

I do, Version A looks preferable to me if the formatter has to change to either.

[jsh9]

Hi @silverwind, I saw in this post (astral-sh/ruff#1904 (comment)) that you need 2-space indentation. Lots of downvotes as expected, and I know Black would never support it.

Nevertheless, I forked Black a while ago added this option.

My fork is the repo that contains this discussion, and you can set --base-indentation-spaces=2 to achieve what you need.

[silverwind]

I actually use this fork of black just for 2-space indent: https://github.com/pausan/cblack

[jsh9]

It's interesting to see that, despite Black's claim that "non configurability reduces bike-shedding", there are so many different forks just to address minor style disagreements such as the indentation width.