Tab Support Request

[itsthejoker]

Is your feature request related to a problem? Please describe.

I run an accessibility-based organization (https://github/com/grafeasgroup, https://reddit.com/r/transcribersofreddit) and we would like to transition our codebases over to tab support to allow new folks, regardless of visual ability, to join in and work on our stuff without too much effort. See https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/ for the majority of the argument.

I recognize that this has been brought up before; we use Black happily on all of our codebases and very much enjoy the work that it does for us. I also recognize that PEP-8 prefers spaces over tabs. The organization as a whole has decided to investigate moving to tabs, and I really don't want to lose the helpfulness of Black here as it really does make our workflows better.

Describe the solution you'd like

I would like an optional flag that allows setting tabs instead of spaces.

Describe alternatives you've considered

• https://github.com/jleclanche/tan
• yapf with use_tabs

Additional context

The work has already been done with a test suite, so we know that it's not impossible. I know that a lot of people are against this change for various reasons, but I implore that we at least discuss it from an accessibility standpoint. Formatting Python is a lot easier from an audio perspective when there are three tabs as opposed to 12 spaces and with the ability to set the visual width of tabs to whatever the developer needs, it has a clear benefit for those with visual impairments.

Thank you for your time and consideration; I would love to discuss this more in depth if possible.

Cheers!

[felix-hilden]

Thank you for the thoughtful request!

Historically, changing spaces to tabs has been quickly rejected. And I think for a good reason: spaces have become the indentation norm of Python, at least as far as I can tell. But since this accessibility argument has been raised, I feel like a discussion beyond style should be had. So we have these options, each of which I'll try to argue for:

• Continue ignoring this request: we have an ethos of consistency that should be pretty much put before everything else. And there aren't that many people that this will affect. Surely the ones that are can use some other tool, a fork of Black, or nothing at all.
• Provide a disabling flag for indent normalisation: as we already do for string quotes, this would allow us to accept tabs where we find them, but not fix any mixed indentation or normalise to four spaces if the flag is on. This would be nice for Black's purism, because we'll keep our style and only ignore indentation. And it would still technically be supporting tabs.
• Provide a switch for indentation style: this would allow us to more actively support tabs. Surely we want to allow people to read (hear?) previously space-indented code. Since Black normalises indents, this would be a very consistent way of producing readable code.
• Switch our preferred style to tabs: no.

This all being said, I think completely ignoring this is harsh. As I said, the accessibility question almost elevates this discussion beyond style in my eyes. But we have to be reasonable and careful. I'd like to know what tools, if any, exist for speaking code or stretching indentation, how do they deal with existing code bases that are space-indented and if any exist for changing spaces to tabs only temporarily. If this issue is taken care of by something else already, we can be more prudent with our changes.

So I'd like to ask you: which of the options above are you after, and what would you be minimally satisfied with? And on our side: how far are we willing to go?

A funny issue this is, since anyway you slice it, it's really just a few lines of code. So we aren't talking about a huge maintenance burden either.

BTW here are all the previous discussions #47, #2122, #2584.

[itsthejoker]

And thank you @felix-hilden for being open to discussion on what is historically a hot-button topic 😄

As we go through this, I want to clarify why I think this would be a valuable change from an accessibility standpoint for Black. From a USA standpoint (where I'm based) according to the American Foundation for the Blind, roughly 13% (an estimated 32.2 million people) report that they either "have trouble" seeing even with glasses / contacts or have extremely limited / no vision. To refine that further, Cornell University's Disability Statistics gives an estimated 2.3% (3ish million) people who identify as having a visual disability as defined by the following two questions from the national census:

16. Does this person have any of the following long-lasting conditions:

• Blindness, deafness, or a severe vision or hearing impairment?
• A condition that substantially limits one of more basic physical activities such as walking, climbing stairs, reaching, lifting, or carrying?

17. Because of a physical, mental, or emotional condition lasting 6 months or more, does this person have any difficulty in doing any of the following activities:

• Learning, remembering, or concentrating?
• Dressing, bathing, or getting around the home?
• (Answer if this person is 16 years old or over.) Going outside the home alone to shop or visit a doctor's office?
• (Answer if this person is 16 years old or over.) Working at a job or business?

There are a couple of ways to approach this data, but for Black's use case, I want to highlight the ~29 million people who report visual difficulties even when using easily available accessibility devices (glasses or contacts, like I myself wear). There are many different reasons for loss or lack of visual acuity, and the effects that they have on the human body are equally varied -- anything from blurriness, "fogginess" at the edges of vision, loss of vision in the center but retaining peripheral, sensitivity to light, sensitivity to lack of light... the list goes on.

All of this here comes back to technology and, eventually, back to me opening this issue. Much of the work in addressing these types of issues can be done locally by the individual: increasing font size, specific fonts, specific color schemes, or a screen reader. Here we get back to tabs vs spaces.

Tabs vs. spaces, as an accessibility argument, only really comes up in two specific arenas: low vision that requires zoom and any form of blindness which requires a screen reader. The benefit for indented languages like Python immediately appears when you zoom your monitor in by even 150% on a laptop. Screen readers are a little bit more complicated; though it varies widely based on the individual setup, most screenreaders don't narrate whitespace unless you specifically instruct it to. Normally this isn't much of a problem if you have decent tooling that handles indents for you, but we again come back to the fact that Python is a whitespace-dependent language. Debugging a misplaced block or identifying the source of an IndentationError does require dealing with the whitespace directly, and likely not for just a single line.

In these cases, tabs over spaces makes logical sense. The primary benefit of tabs, besides the number of bytes, is that it is configurable on a per-user basis (like fonts and colors). This gives control of how the code is viewed back to the person viewing it as opposed to fixing it in a single point of view.

So in answer to your primary question, my preferred outcome is your third option: a switch that defaults to space indentation but allows tab indentation instead. As you wrote, the change itself is not large, especially when compared to the total complexity of Black, but it is a departure from the current stance and ethos and that should be considered.

As for tooling, if you are on a Mac then you already have access to VoiceOver. Windows users have NVDA, JAWS (not free) or the built-in Narrator, while Linux has ORCA. I am not aware of any tooling that temporarily modifies code or text while working on it.

I also want to say that one of the things that I like about Black is the fact that it's not very configurable. It doesn't leave a lot of room for argument, and I believe that is beneficial. If the collective decision is that this is the end of this feature request and tab support will not be added, then I will accept and respect that decision. In this particular case, I believe that support for this feature, for the reason I've given above, is beneficial for Black in the long run as the formatter of choice for the Python Software Foundation.

Cheers!

[JelleZijlstra]

Thanks for writing this up!

My first reaction is that this seems like an argument for using tabs everywhere, not for making it configurable. After all, we'd want visually impaired editors to be able to contribute to all codebases, not just the ones that choose to use a non-standard configuration option.

But the reality is that the vast majority of code is written using spaces, not tabs, so I'm surprised that tools for visually impaired coders don't already support displaying four-space indents differently. It seems like an easy thing to implement: instead of reading "space space space space", you read "indent". Some discussion on Discord brought up a VSCode extension that does this, for example.

[itsthejoker]

Of course! From my perspective, I'm mainly trying to argue for "tabs if the team desires it" as opposed to "tabs for everyone". As you say, spaces are default, and it's lunacy to try and really change that; the best I can do is suggest ways that it can be better for folks who need it.

[sciyoshi]

@felix-hilden I'm glad to read your considerate response to this contentious issue that, like you point out, has been brought up many times in the past. I won't rehash my points in favor of your 3rd option (to add a --use-tabs argument) except to say again that if this is accepted by the black maintainer team, I'm happy to do the work to open a PR and shepherd this change through.

Because of black's opinionated formatting (i.e., no character-by-character alignment, 4-column indents) the diff itself against 22.1.0 is very small and won't incur much maintenance burden at all. (And to make it clear, I would be against adding other options to black like changing the indentation size, etc).

Congratulations on the stable release - I'm a big fan of the tool and it's been a great contribution to the Python ecosystem :)

[ichard26]

For the record, I'd be alright allowing tabs to be used (option 3) but under the condition no other options are merged in regards to this tab support (so no --tab-width for example). Although surprisingly the tan fork hasn't been brought up yet even though it mostly solves this issue ... I will also repeat that the acceptance (which is not confirmed, I'm just one maintainer out of ten) of this does not mean we are open to accepting other configurability.

As another example, the recent addition of the --skip-magic-trailing-comma option seems similar in that the behavior is important enough to people to warrant its inclusion.

Anything can become important enough to warrant its inclusion via this argument, this is 100% against the ethos of Black. Honestly I'm unhappy --skip-magic-trailing-comma exists but oh well. I understand we're both biased in opposite directions (you want your feature accepted and I want Black to stay uncompromising) but it's a bit frustrating to read repeatedly to be honest. It's fine if you continue to use this argument but FTR I won't be considering it at all.

---

[...] the formatter of choice for the Python Software Foundation.

Side note - I find it interesting how we are deemed the official formatter when we're just under the PSF namespace, there's no policy or bylaw that states Black is the formatter of choice. It's the same way with python/mypy, it's popular and a community standard sure but by no means the type checker of Python.

---

I'm also fine if this gets rejected as I do understand Black's popularity and stance means whatever configurability we do add basically makes it acceptable in the wider community. And to be fair I haven't gone through any major formatting bikeshedding before so it is possible I'm simply losing sight what Black is aiming to be.

Continue ignoring this request: we have an ethos of consistency that should be pretty much put before everything else. And there aren't that many people that this will affect. Surely the ones that are can use some other tool, a fork of Black, or nothing at all.

This still speaks to me.

[ichard26]

And actually, I am curious what's the conclusion y'all have come to considering tan as an alternative. I'd still much prefer option 1 if we could but this alternative fails, what I said above applies. What problems do y'all face using tan vs black?

[jleclanche]

Although surprisingly the tan fork hasn't been brought up yet even though it mostly solves this issue

The issue mentions it in passing. I'll say as the "maintainer" of tan, I do not intend it to remain a fork. It's meant to be a WIP pull request that is installable alongside Black, as a workaround to tab support not being merged in (hopefully "yet"). And once merged in, I intend to delete it.

I also am fully on board with no --tab-width option or any other indent-related option, and I don't think I've seen it seriously brought up anywhere.

Honestly I'm unhappy --skip-magic-trailing-comma exists but oh well. I understand we're both biased in opposite directions (you want your feature accepted and I want Black to stay uncompromising) but it's a bit frustrating to read repeatedly to be honest.

I agree with you there. I think the real reason it gets brought up time and again though is that it's annoying to see that Black did compromise on something like this, but drives a hard bargain on tabs which forces the exclusion of a significant amount of codebases and workflows.

So I read it not as "If you did it for X, you should be able to do it for Y", but as "Why did you cave in for X despite not caving in for Y".

[sciyoshi]

What problems do y'all face using tan vs black?

There are two main problems, but neither are huge:

• New team members need to know to configure their editors to use tan instead of black.
• Every few months the patch needs to be rebased and a new version of tan released. It normally only takes a few minutes, and will hopefully be even easier now that black has reached stability.

If this gets rejected, then we'll simply continue using tan as we have been for the past few years, and I would additionally recommend it as a viable solution to the OP to address their accessibility concerns.

And there aren't that many people that this will affect. Surely the ones that are can use some other tool, a fork of Black, or nothing at all.

This is fair and a valid point - it's unlikely to affect many people, and those that it does affect can use the fork. (I don't think "use nothing at all" or "switch to yapf" are fair suggestions, since the fact we're discussing this at all is because we all recognize the value of an opinionated code formatter!)

If a --use-tabs option is accepted, I'd be OK with (and would probably encourage) adding some wording to the docs along the lines of: "this option should ONLY be used for compatibility with legacy codebases or other specific concerns such as accessibility. Do not use this for new projects, as this goes against PEP-8 recommendations." Alternatively, if the option still isn't desired after this, maybe a section in the docs or FAQ could be added outlining the rationale behind why the option does not exist and a link to tan for those that still need it.

[felix-hilden]

Thanks for all the discussion so far! It seems that nobody here is wanting the indent normalisation disabling flag. So I'll try to articulate what this boils down to us:

Improved accessibility for projects using Black - VS. - the cost of unnecessary tabs vs spaces style arguments this will raise within projects using Black.

The upside is undeniable. We've decided as a society that we want to help those that need it 😄 But I'm starting to think that having this option in Black is not the best way to do that. Jelle had similar thoughts in this comment, but I'll try to dig deeper. Fork? Sure, but not really the best either. Since most Python projects use spaces, and since the problem needs a solution even in projects that don't use Black, I'd expect to find a tool that either 1) visually stretches space indents in some clever way, 2) temporarily converts spaces to tabs and back, in IDE or post-pull/pre-commit, or 3) simply converts between the two so that other integrations may use it. At least (3) would be trivial to implement, at least assuming normalised indent levels, say after applying Black.

The downside is equally indisputable. This project was specifically created to avoid unnecessary style discussions, and tabs vs. spaces seems like the granddaddy of those debates. We want the output produced by Black to be as consistent as possible, which I'm sure has become clear from the discussions already 😅

So comparing my thoughts above, my intuition is that this issue should be indeed taken care of by some other tool. It is a win-win of sorts: the people that need it don't have to introduce Black to every code base they work with, which is a hurdle in itself, and we don't have to provide a controversial style toggle. Sure, it would be slightly more convenient for projects that already use Black, but that feels less important.

Is this a fair assessment?

[jleclanche]

Other tools already exist, yet this discussion and feature request is still there, so I'm not sure how you're reaching that conclusion.

I think one thing you're not considering also is that Black has become the de-facto formatter, and is in a very strong position in the Python community. It's not just "any" tool. IMO this reputation is well earned.

the people that need it don't have to introduce Black to every code base they work with, which is a hurdle in itself

In fact, we want to introduce Black to every code base we work with. But we can't :)

and we don't have to provide a controversial style toggle.

Is it really controversial? I understand that it's difficult to add option flags (and with good reason). What I don't understand is why this is more "controversial" than, say, --spaces-around-brackets. The reasoning behind adding the option should be evaluated standalone.

Maybe I'm a little bothered by putting the wording "controversial" around an issue which affects accessibility, as @itsthejoker reminded everyone above. Imagine if VSCode, a highly-used editor that is becoming part of several workflows, decided 11pt is the perfect font size for code, and if you have trouble with that font size, it's okay, you can just use another editor which doesn't provide controversial options... 😉

[felix-hilden]

I'll try to answer your concerns:

I think one thing you're not considering also is that Black has become the de-facto formatter, and is in a very strong position in the Python community. It's not just "any" tool. IMO this reputation is well earned.

Firstly, thank you 😄 But secondly, the fact that it has become a standard is in no small part thanks to our ethos, which this would go against. Now there is the argument of accessibility, which we're trying to hash out.

In fact, we want to introduce Black to every code base we work with. But we can't :)

And this is in my opinion a strong argument for why an accessibility tool like this should be independent of Black.

Maybe I'm a little bothered by putting the wording "controversial" around an issue which affects accessibility

I tried to be careful to use the phrase "controversial style". There's nothing controversial about helping people read, that much we can all agree on 😄

Imagine if VSCode -- decided 11pt is the perfect font size for code, and if you have trouble with that font size, it's okay, you can just use another editor which doesn't provide controversial options... 😉

I don't think that's entirely fair, especially because the font size is entirely a local choice that doesn't affect how the code is checked in. Maybe if historically the entire world would have been using 11pt, and having 12pt somewhere could break something or cause confusion.

In any case, I don't mean to dismiss this issue. I was just voicing my current thoughts! Let's continue the discussion.

---

By the way, regardless of what happens, I'd want a FAQ entry summarising our reasoning. If we reject this, it should point to tools and resources for setting up this sort of tool, and if we accept it, we should discourage any style-related arguments.

[itsthejoker]

I'm sorry, I added a bunch of email rules to my inbox and apparently sinkholed all of my github notifications 😭

Again, thanks to everyone for continuing this conversation with the gravity I believe it deserves. Just wanted to jump in and agree with several of the points raised.

As far as the ethos side of things... I cannot really weigh in on that. It's something that you all will have to decide as maintainers. But! @jleclanche's example with VSCode does touch on part of my argument; as you (@felix-hilden) pointed out, font size is configurable on a per-user basis. It's entirely up to you to have your own font size to display code in the way that works best for you, and I doubt you use the 18pt font that I do. That's why I think this change is important, because as an individual user we're talking about something that I can't adjust on my own and you can't adjust either. It just is, and four spaces at a time are rigidly inflexible. Both a good thing and a mildly questionable thing (not necessarily a bad thing).

I whole-heartedly agree with the idea of a FAQ entry (or even just putting it in the regular docs!) and even the "please don't use this" part! As a programming language, we have standards that should be observed. Hell, I'll even write the documentation for it if you'd like. Here, in the style of https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html#line-length:

---

Tabs and spaces

In the spirit of The Oldest Argument™, Black uses spaces in multiples of four to indent each line. This is the default behavior, the recommended behavior, the approved behavior, and should be used both on new projects and when introducing Black to an older project.

There are very rare occasions where formatting with tabs is the preferred option, so for compatibility and accessibility reasons the flag --use-tabs is available. This will replace each block of four spaces with one tab character.

Warning: Python disallows mixing tabs and spaces. This option should only be used for specific compatibility goals or for accessibility reasons. If your reasoning is "I like one better than the other", then you should use the defaults.

There are no available modifiers for this flag and none are planned. This flag only affects indents for code; spaces (or tabs) inside docstrings are untouched.

If you must use this, you will need to adjust flake8 to allow for the change. Something like the following should do the trick:

[flake8]
extend-ignore = W191

---

Now, I can't say that I have your doc style down pat, but I perceive that would probably fit reasonably well. 😄

Anyway. I'll leave you to it. Thanks again and I look forward to hearing thoughts from other contributors. Cheers!

[felix-hilden]

Thanks for the FAQ draft! 😄 But I'll have to reiterate on one point:

-- It's entirely up to you to have your own font size to display code in the way that works best for you --

Font size is not saved to any file and checked in to a VCS, meaning it's more easily adjustable by each contributor of a code base independently. Tabs vs spaces is more concrete and affects others. That's why the best solution in my mind is some sort of conversion between pulls and commits. That would leave Black and any other tool that complains about spaces or tabs out of the question.

[ambv]

Thanks for writing this up, Joe. Sadly, I'm -1 on introducing this functionality to Black itself.

Back in 2019 I discussed accessibility with screen readers at PyCon US with someone who was legally blind and using one. I also had many conversations around the same topics with legally blind software engineers at Facebook in 2018 and 2019.

The consensus then was that a style suited for a bad screen reader is way different from what you'd like to do visually. I mean, for a screen reader, you want to avoid wrapping long lines as much as possible because this introduces unnecessary tokens and punctuation which a screen reader reads without scrutiny. Same with standardizing on trailing commas. Multiple spaces are just one piece of punctuation here.

While I'm sympathetic to users of screen readers, this is out of scope for Black. A screen reader should be able to read multiple tokens in succession descriptively, without resorting to "space space space space space space space space" readouts. I strongly believe this is where the issue lies. Case in point, out of the five handicapped people I talked about this with, three weren't using screen readers because it was easier for them to use macOS's Screen Magnifier at max setting than to reliably use a screen reader. Those people preferred Black as is, ideally they'd like as narrow lines as possible, which is already configurable. Those conversations also lead to the default line length not being 100 or wider. By the way, one of the screen reader users did it because of severe RSI, they couldn't use a keyboard, so they used screen reading and dictation in tandem. Their frustration with the software had little to do with spaces vs tabs.

Transitioning your organization to tabs will always only be partially successful as you will be reading third-party code, including the standard library, which will never use tabs for indentation. One could argue this kind of change is painting yourself into a corner because it makes members of the organization less likely to contribute to open source where tabs in Python are very uncommon.

[sciyoshi]

That's why the best solution in my mind is some sort of conversion between pulls and commits.

There is a way to do this with git (https://stackoverflow.com/a/2318063), although I'm not sure about svn/hg/bzr/pijul/etc. The major issue with that is that it makes it very difficult to have the tooling work correctly (i.e. auto-format in your editor, or run black in pre-commit hooks) unless that tooling can work on your local checkout. This is also because black normally runs in-place. If black supported some --pre-filter and --post-filter options to run files through unexpand/expand then that could be another possible solution.

[jleclanche]

@ambv I'm not sure how this jumped from general accessibility to screen readers. As you yourself noted, good screen readers won't care about tabs vs spaces.

I mentioned this before; when I started using tabs, my eyesight was perfect. Now year after year it's deteriorating. I might end up using a screen magnifier at some point (I've already found myself increasing DPI every now and then).

But I'm not legally blind. Or any kind of blind. Or even wearing glasses. What I get is headaches from staring at code.
For now, what makes the most significant difference in the codebases I'm working with is increasing DPI, setting tab indent to 6, and spacing things out in my own code as well (clear blocks and long descriptive variable names, etc). For one of these, I cannot use Black and have to resort to Tan. It's not pleasant, and I feel like I'm trading a headache from working on my code in favour of a headache for explaining why this matters.

[sciyoshi]

And just as a possible alternative to @itsthejoker's writeup in the case that this request is not accepted by the maintainer team:

---

Tabs and spaces

In the spirit of The Oldest Argument™, Black uses spaces in multiples of four to indent each line. This is the style recommended by PEP-8 and enforced by Black. There are no options to configure or change the indentation style, and requests for any such options will not be considered for acceptance. If you must use tabs for compatibility or accessibility reasons, a fork of Black called Tan is available which provides a --use-tabs option and can be used as a drop-in replacement.

[ambv]

People are free to use forks if they need them. However, we won't be endorsing any forks in our documentation.

[jleclanche]

I’m not comfortable advertising tan in the official documentation either fwiw.

[zsol]

Regardless of my opinion on this issue, I just wanted to make a meta-point: It has been so refreshing to read the respectful arguments and discussion in this thread. Thank you everyone for keeping things civil

[itsthejoker]

@ambv Thanks for weighing in. I just want to clarify that most of my argument is for the benefit of the folks that you mentioned and for folks like @jleclanche, and that while screenreader support is something to keep in mind, there are a lot more people who stand to benefit from a change like this who have general vision problems over a complete lack of vision.

From my comment above:

There are a couple of ways to approach this data, but for Black's use case, I want to highlight the ~29 million people who report visual difficulties even when using easily available accessibility devices (glasses or contacts, like I myself wear). There are many different reasons for loss or lack of visual acuity, and the effects that they have on the human body are equally varied -- anything from blurriness, "fogginess" at the edges of vision, loss of vision in the center but retaining peripheral, sensitivity to light, sensitivity to lack of light... the list goes on.

You're definitely right in that third party libraries (and the standard library, by extension) will never use this. And that's alright, I think; in my experience, most of the time I spend is spent staring at my own code with occasional glances out to other things to see why whatever I just wrote isn't working 😅

And again, if we decide this isn't right for Black, that's fine. I'm just glad we talked about it.

[felix-hilden]

There is a way to do this with git

Nice! This makes things a lot easier for people that want to use tabs in general. A huge step forward regardless of what happens here 👌

-- it makes it very difficult to have the tooling work correctly --. If black supported some --pre-filter and --post-filter options to run files through unexpand/expand then that could be another possible solution.

This should be easy enough by just running black . && unexpand, right? Or am I missing something?

---

I'd be interested to hear your thoughts on using this kind of more general solution @itsthejoker (and everyone else that this applies to)! Is it off-putting because of the more complex setup? Or do you use it already? I understand if you're tired of fighting a losing battle (which this looks like it unfortunately is, for introducing the option in Black), but I think as you're someone who this issue touches personally, it'd be nice to know if there's something we've not taken into account so that we can guide users appropriately in our FAQ entry.

[JimDabell]

Git is a version control system. I use it to manage versioning. Black is a code formatter. I would like to use it to format code. This solution seems entirely wrong to me – it’s a clumsy workaround for not being able to use the code formatter to format the code. This is solving the problem in the wrong place.

[felix-hilden]

Git is a version control system. -- Black is a code formatted.

Both true, but we're in a pickle here. I think we've established that accessibility is the only argument we're considering at this time. Having tabs in a formatter means that you have to apply that formatter to get tabs. This doesn't help with accessibility on code bases that have spaces nor with a person contributing back code with their tabs if they are hesitant to introduce Black, both of which would be fixed by converting at the borders. Then if Black is introduced, you'd additionally convert after applying it. Am I making sense?

[jleclanche]

Both true, but we're in a pickle here. I think we've established that accessibility is the only argument we're considering at this time. Having tabs in a formatter means that you have to apply that formatter to get tabs. This doesn't help with accessibility on code bases that have spaces nor with a person contributing back code with their tabs if they are hesitant to introduce Black, both of which would be fixed by converting at the borders. Then if Black is introduced, you'd additionally convert after applying it. Am I making sense?

None of the suggested solutions in the above discussion make sense, frankly. If you're using a code formatter, you don't want a second tool to touch your formatting and potentially create conflicts. For example, Black verification jobs would fail in CI if you were to use something to reformat post-black.

You also don't want something that runs at git commit/push time, as, for one that conflicts with what you're writing in the editor, and two that is not usable outside of a git environment. This is what Jim above is getting at, really.

Furthermore, when you use it on-save (as I do), running two scripts over the same lines of code can and eventually will cause conflicts. I've had this issue with isort (and would similarly advocate for isort to be integrated into black, or something to merge the two, but that's a discussion for another day).

It doesn't really feel like accessibility is being considered. So far, we got a -1 because.. something about screenreaders? and a lot of trying to fit round pegs in square holes and call it a solution so Black doesn't have to jump in. The only reasonably useful solution is to use Tan, and if that is ultimately the answer, it doesn't feel particularly like a good faith one. Remember, Tan isn't a fork, it's a pull request.

Finally, I want you to keep in mind that Black being a well-maintained, PSF-approval-stamped software makes it very easy to use in larger codebases that may be stricter in what can and cannot be used. Those codebases don't have the luxury of using code that some random guy is maintaining, that could secretly backdoor the code upon reformatting.

I invite maintainers here to think about use cases that aren't necessarily theirs. I myself try to: Tan fits me just fine, I maintain the damn thing, why am I here arguing in favour of including this in Black when concretely, I don't need it? Because it matters to others. And one day, it might matter to you, too... Like I said, when I started using tabs, my eyesight was fine and I just did so because I liked them better. Now they make a significant difference in how much code I can read without getting migraines.

[JimDabell]

All of my files are indented with tabs, so that would have the effect of rendering Black useless. Aren’t you essentially saying “you can’t follow that PEP 8 advice; switch to spaces”?

[ambv]

I'm in no position to tell you what you should do. Clearly you chose tabs over spaces despite PEP 8 so it made sense for you. Black didn't interfere then, and it doesn't interfere now. You can choose to reformat to 4-space indents as PEP 8 prescribes, you can choose to auto-format with a different tool, or you can keep doing what you're doing right now and change nothing. You got plenty of options.

[itsthejoker]

At least we made it for a few days 😅

Thank you so much to everyone for your insightful comments, discussion, and help. I appreciate it greatly. I will close this issue at this time.

Cheers!

[MarcoGorelli]

As I said, the only reasonable solution is "use tan", and that is IMO not viable.

May I suggest another alternative?

It could be a tool which:

• for each file passed, converts it to a temporary file, which replaces tabs with 4 spaces
• runs black on the temporary files via subprocess.run
• replaces 4 spaces with tabs in the temporary files
• overwrites the original files
• outputs whatever stdout, stderr, and returncode black did when running on the temporary files

Then there's no need to keep it up-to-date with black itself or to resolve merge conflicts and keep making new releases whenever there's a new black version. As long as the CLI version of black doesn't have breaking changes, it'll keep working. And any config-file option would be respected.

The structure would be similar to what I put together in nbQA in order to run black and other tools on notebooks, so I could reuse a fair bit of it.

If I put something like this together and maintained it, would that be an acceptable solution?

[itsthejoker]

There could be a tool like that, but we will try expand and unexpand first. No reason to reinvent the wheel, after all :)

[MarcoGorelli]

black . && unexpand

Are you sure it's that simple? Not sure the return code would be correct - also, I tried this, and it just hangs

[felix-hilden]

No, I'm not 😅 but that should do it, right? I mean, unexpand probably needs some configuration depending on the project. Is it expecting input instead of hanging by any chance?

In any case, the initial FAQ entry was included in #2855 now! Do let us know if you find a better approach to the issue so we don't lead users astray.

[MarcoGorelli]

Hi @itsthejoker, @JimDabell , and @jleclanche - I've put together https://github.com/MarcoGorelli/black-tabby-formatter

Does this address your concerns, and provide a viable solution? It just calls black in subprocess.run, so it should work with any version of black, respect configs and any additional flags passed (such as --check), and require very little maintenance