Tab Support Request

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!

[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:

1. 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?

1. 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!

[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.