Hướng dẫn python black tabs

Python is a language that is conscience of spaced alignment. requiring which requires consistency in the offset of the characters from the newlines.

tabs for indentation are the devil.

this is as ignorant as it is absurd

The "tab" key was named in the 1900s, and is based off of the definitions of words, at that time.

at that time
to tabulate was to make spaced words flat
while
to indent was to create two inequal sections on a sheet.
http://webstersdictionary1828.com

at that time, "to indent" text was "to tabulate"

Tab stops create alignment, originally for mathematical tables.

Python uses alignment for code blocks. tabs are the natural character for this purpose, not spaces.

Furthermore, even the modern definitions show that tabulation and indentation go hand in hand.

tabulate
(transitive) To arrange in tabular form; to arrange into a table.
(transitive) To set out as a list; to enumerate, to list.
https://en.wiktionary.org/wiki/tabulate

tabular (comparative more tabular, superlative most tabular)
having a flat, plane surface
organized as a table or list
calculated by means of a table
https://en.wiktionary.org/wiki/tabular

indent (plural indents)
A cut or notch in the margin of anything, or a recess like a notch.
https://en.wiktionary.org/wiki/indent

Tabs notch the text in an flat, organized and calculateble way.

Furthermore:
The fact that "line length" is configurable in Black's philosophy but characters for indentation is not, is intellectually inconsistent. Please consider becoming intellectually consistent in this use case.

Łukasz I've been playing with Black for a while, and I'm pretty sure, that looking at the aim of the project you'll have a strong position about why something might or might not be accepted, since basically as the project states, this is an opinionated code formatter, right?

Actually, when I look at the output, the thing is that I can agree on some formatting and maybe dislike or not be completely comfortable with other formatting options. But guess what... that's the aim of the project, to have an opinionated standard that people might or might not like, so if you like it you use it, and if you don't then... you'll go for yapf, autopep8, or any other formatter.

The thing is, I've been experimenting personally with several formatters, and several options for some formatters, and black seems the one that fits better if only for one small, tiny thing.... 4 spaces. Please don't reply quite yet and bear with me on the next paragraphs.

At this point, if I haven't missed anything, in black, there are basically three arguments that change the output of the program:

• string normalization
• trailing commas for python 3.6+
• line length

If you think about it, the formatting of the code, the actual text, expressions, function calls, definitions, ... are only affected by string normalization and by trailing commas.

Line length affects spacing and affects indentation, but it does not change formatting rules. Why do I say that line length affects indentation? Basically because if you have a line length of 80 and the function call has 6 parameters and ends in the column 95, then it will get indented in multiple lines. If for example, you rerun black with a line length of 100, then the indentation of the script will change, it will fit in one line and won't get indented the same way. Still the formatting rules have not changed.

Now back to spaces. Spaces affect indentation, they don't affect formatting rules either. Over the years I've seen basically 2 kind of spacing standards used in projects with 3 flavours each:

• tabs (configured to either 2, 4 or 8 chars)
• spaces (also configured to either 2, 4, 8)

In most cases, using tabs has a major drawback over spaces. Main drawback is that different editors with different configurations might display code with different number of spaces, thus when a programmer opens the file with a different tab length than the original programmer, the file might look broken. So I totally agree of going for spaces instead of tabs and forcing that choice.

Now, regarding the different spacing options:

• 8 spaces: I would disallow this option, since using an indentation of 8 spaces is adding a lot of blank space while it does not add readability.
• 4 spaces: it is readable and indentation does not consume as much space as 8 space characters does, so I understand that some people chose it over 2 spaces.
• 2 spaces: it is readable and indentation consumes half the spaces as previous option, to me this is the minimum number of spaces a coding standard should allow.

Even though 4 spaces has been chosen over 2, and that's why black forces this amount of spaces on the first place, I see no difference in being able to chose spacing vs being able to chose line length. I mean, there should be a default, and the default might be 4 spaces, like for line length it is 88, but if there is an option to adjust and customize the line length, then why there is no option to adjusting the spaces?

Spaces, like line length, only change how the code will get indented, but won't change any actual formatting rules...

To stay consistent, I only see two alternatives, either to allow 2 spaces or to remove line-length altogether, since if everything was opinionated, then there should be no option for trailing commas or string quotes or line length.... but in fact those parameters exist, and I really like to be able to chose line length. And I understand that different companies or different projects might have chosen a line length for one reason or the other (e.g different screen sizes, accessing code through ssh, ...). And none of the existing parameters really change how the code gets formatted in the end. Even with string quotes, code looks the same, all characters in same position, only one quote is replaced by the other.

Can you please reconsider your reasoning for not allowing 2 spaces as well?

(as a final note: I actually made a change locally to test black with 2 spaces, and I only had to removing 2 characters in black.py, so I guess adding an option for this optional behaviour should not be hard, in fact, if needed I offer myself volunteer to do the changes and add the parameter if you would reconsider and accept the pull request).