Hello,
I know that “tabs vs spaces” is a long discussed topic. Objectively seeing the topic after so many years and taking into account that our world is becoming more inclusive, may I bring this back to consideration again?
Consider this point of view when thinking about it.
Cheers,
David
We already chose 4 spaces.
Even if TAB is better than spaces, I want to keep “always use 4 spaces” recommendation.
Hi,
please notice that I am not addressing this from the “which is better” perspective, but from an inclusion one. The referenced link explains the problematic behind the idea.
thanks in advance,
David
What “more inclusive” means? I understand “more inclusive” as “BOTH”, so I pasted the meme.
We don’t prohibit using TABs. We just recommend 4 spaces.
Divergence is important for humans, but not for coding style.
Hi,
“more inclusive” means supporting Persons with visual impairments.
In the organization were I work now, I have seen how colleagues with visual impairment works, that’s why I identify myself with the information provided in the referenced link.
Regarding:
We don’t prohibit using TABs. We just recommend 4 spaces.
Maybe the whole idea is just misinterpreted. The results I can appreciate everywhere I look is that everybody runs for enforcing the recommendation. Resulting also in a plethora of tooling working in that direction too.
One could argue that the best way to go here is to ask those tool vendors to take in consideration this topic and implement accordingly. From my point of view PEP is the source of reference for many, if not all devs using python, that’s why I decided to bring it to this forum.
Maybe i just need to rephrase myself… my question would be then:
What can be done in order to guarantee more freedom of choice and same level (as for spaces usage) of support when it comes to choose between spaces or tabs?
Please notice I am not talking about mixing them, I am against that too.
Thanks in advance for your time.
Regards,
David
Some references:
tabs-or-spaces
flake8 - W191
The linked story mentions they wanted to change their recommendation (to spaces), and got push-back from people that were deeply invested (due to accessibility) in their current workflow (with tabs). The presented conclusion is tabs are better for accessibility.
But maybe that’s the wrong conclusion, even with accessibility as the most important aspect. Maybe changing the recommendation was the big mistake. There is no evidence presented that accessibility is better with tabs, just that in this story people had adapted to the existing tab workflow, and changing the workflow had an unnecessary, large impact on them. Maybe in the Python world many are invested similarly in special accessibility workflows centered around spaces, and changing to tabs would be just as big of a problem for them.
And I agree with you @petersuter. I am not saying we should change everything now. Please see my rephrased question on previous answer:
What can be done in order to guarantee more freedom of choice and same level (as for spaces usage) of support when it comes to choose between spaces or tabs?
Let’s say that, if a project, decide to not check for this constraint. Do they have also means supporting them in their quest for ensuring tabs? How will this impact them later on? Interoperability, if apply?
I know these are quite specific questions which not always apply. What I am trying to say is that from my personal point of view, this has to do with poor editor support, at the time it was suggested. It has become now historically accepted and I think we should leave room for questioning ourselves if we can do otherwise.
If at the end of the discussion, the overall opinion is that, spaces should be used always, for whatever reason. I will be fine with that too.
PS:
There was another link I wanted to post on previous answers but forum allowed me to post only two. Please check this in the context of my previous answer: Python Archives (1994q2): Re: Tabs, spaces, and indentation
I agree this is more a question for editors, and that the situation has probably changed a lot. For example VSCode has this:
and extensions like stretchy-spaces and consider adding relevant features.
(This thread doesn’t belong in the PEPs category)
Short answer: spaces is already decided and tabs will never be encouraged in Python. It’d be a disruptive change for negative benefit to most Python users around the world.
Accessibility is entirely up to every individuals editor/IDE. Source code is data and is shared amongst everybody working on a project. Everybody has different accessibility needs. Thus encoding one person’s accessibility preferences into the data that is source will always be not what some others want. No matter which choice you make. So pick one, which we have done: leading spaces, as the most common source data encoding. Everyone’s editors can render Python code in whatever way they actually need and emit source in the appropriate common form.
Allowing a mix of tabs and spaces in source data is never the right choice for reasons long since discussed ad nauseum for the past half century. There’s a good reason py3 is stricter about it. Encouraging people and projects to pick one or the other violates the “only one way to do it” mantra and creates conflict and complicates life for everyone and all tooling now having to deal with conflicting inconsistent idioms.
If anything I think we should’ve banned the tab characters entirely in py3. Or at least required 100% one or the other within a file. We highlight the issue better than py1-2’s lenience but that’s it. Leading to things like Python3 allows mixture of tabs and spaces for indentation · Issue #82677 · python/cpython · GitHub.
This might also be of interest in the Editor/IDE Integration category, if there is interest in promoting a common standard for a11y features across editors/IDEs, rather than in whatever happens to be in the source code file. Ultimately, as the interface between developers and their raw source code, editors and IDEs have by far the most ability to improve a11y, and while our resources are, as always, limited, I’d like to hear if you have any particular suggestions on how we can improve it.
Apparently the accessibility tradeoffs are much more nuanced/complex than that reddit post makes it seem, at least according to the folks posting in this thread:
Thanks @njs for the thread to read, I have learn a lot lately thanks to this discussion here.
Please folks, keep in mind I don’t want by any means to start a “War” because of this, we have enough of that with what our politics give us on a daily basis.
Keep in mind also that I see myself as a constant learner who in the last years have been doing more Python professionally and who has been exposed to these accessibility topics, unconsciously I must say, just by watching others work.
I know it is a sensible topic and just wanted to know what was the feeling of the community about it. Taking into account new Information that could came up with the years, technically and sociologically. I was expecting to get information like those exposed here. Information from people who need this for real and people who take care of Python technologies and community. Which I already got.
Regarding:
Short answer: spaces is already decided and tabs will never be encouraged in Python. It’d be a disruptive change for negative benefit to most Python users around the world.
This seems completely legitime to me. Consistency is important to me also.
I would be happy to hear any other comments to this respect. As for this thread, consider it closed if you like.
Thanks to all for the insights,
Regards,
David
It seems it can also be handled by expand/unexpand commands, notably in association with githooks, as this SO answer points out.
Yes. The question might be rephrased as “Does spaces indentation prohibit visually-impaired coding?”
Yes, as I think through this situation, several factors come to mind:
print(index) #TEMPORARY DEBUG CODE
Rephrasing the statement above: “This discussion has taken place fully and, as far as we can tell, the reasoning hasn’t changed. If there’s something new to bring to the discussion, then we can re-open this discussion. Otherwise this is a resolved question.”
The bullet points above show that tabs are not the only solution, and are not a universal solution.
(This thread doesn’t belong in the PEPs category)
It might be associated with the PEPs category if the reasoning and conclusions about spaced indentation has not been documented yet; in that case, maybe a PEP should be drafted. HOWEVER, the path to PEP is to start a discussion in Ideas or (better) what used to be Users. [@staff, are we going to create the Discussion category now that we’ve made the two category name changes?] I recommend that this be moved to Discussion if/when the category becomes available.
[EDIT: ] From the cybre.space quote:
Even between blind people there’s [disagreement] about this. The advantage of a tab is that it can be represented by a single character (a ctrl-i) on the display, so it only eats up one cell.
The disadvantage is that any sort of alignment (for example putting the params at the same column as the (from a function) becomes impossible to tell, whereas we can with spaces.
[EDIT: ] Another quote from the cybre.space discussion:
the most important thing is consistency.
My conclusion: This is more of an a11y industry situation than anything else. Hardware can be made more configurable/intelligent and extensions can be created for editors. On the other hand, any changes at the language level are clearly only going to affect a fraction of the overall situation and may make other areas worse, such as braille readers that are expecting spaced indentation. In the case of standards, one has to consider how much established work will be broken by a change. We can do our part better by being consistent and avoiding breaking changes, as the writer of the original Reddit post realized.
I personally wasn’t planning on it as it feels like it would overlap too much with Ideas and be too hard to explain the differences.
Overall fight is obsolete for a long time. Instruments that we use to write code have tabs/spaces settings for backward compatibility. The overall direction of the instrument’s evolution directed not just to simplify the editing process. It is about hiding text layer from user. Editors format code automatically, CI/CD apply rules to the whole code base of the project and check every possible aspect of the code style on from low to very high level. For instance, including order of the imports and read complexity of the functions.
Being in the industry for 12 years (this is from your site) you definitely see this. You are aware of GitHub Copilot and similar projects, who save typing time by suggesting big piles of the code instantly.
For people with special needs, more fruitful will be focus on more high level instruments, not low lever code representation. For the start: better coloring and fonts, or code highlight and visual structuring of the program flow.
Python scripts still and for a long time will be text files. But at some level, tabs and spaces are an internal representation of the file. Nobody care what is inside the Word document on binary level.