-### Command line options
-
-_Black_ doesn't provide many options. You can list them by running `black --help`:
-
-```text
-Usage: black [OPTIONS] [SRC]...
-
- The uncompromising code formatter.
-
-Options:
- -c, --code TEXT Format the code passed in as a string.
- -l, --line-length INTEGER How many characters per line to allow.
- [default: 88]
-
- -t, --target-version [py27|py33|py34|py35|py36|py37|py38]
- Python versions that should be supported by
- Black's output. [default: per-file auto-
- detection]
-
- --pyi Format all input files like typing stubs
- regardless of file extension (useful when
- piping source on standard input).
-
- -S, --skip-string-normalization
- Don't normalize string quotes or prefixes.
- --check Don't write the files back, just return the
- status. Return code 0 means nothing would
- change. Return code 1 means some files
- would be reformatted. Return code 123 means
- there was an internal error.
-
- --diff Don't write the files back, just output a
- diff for each file on stdout.
-
- --color / --no-color Show colored diff. Only applies when
- `--diff` is given.
-
- --fast / --safe If --fast given, skip temporary sanity
- checks. [default: --safe]
-
- --include TEXT A regular expression that matches files and
- directories that should be included on
- recursive searches. An empty value means
- all files are included regardless of the
- name. Use forward slashes for directories
- on all platforms (Windows, too). Exclusions
- are calculated first, inclusions later.
- [default: \.pyi?$]
-
- --exclude TEXT A regular expression that matches files and
- directories that should be excluded on
- recursive searches. An empty value means no
- paths are excluded. Use forward slashes for
- directories on all platforms (Windows, too).
- Exclusions are calculated first, inclusions
- later. [default: /(\.eggs|\.git|\.hg|\.mypy
- _cache|\.nox|\.tox|\.venv|\.svn|_build|buck-
- out|build|dist)/]
-
- --force-exclude TEXT Like --exclude, but files and directories
- matching this regex will be excluded even
- when they are passed explicitly as arguments
-
- -q, --quiet Don't emit non-error messages to stderr.
- Errors are still emitted; silence those with
- 2>/dev/null.
-
- -v, --verbose Also emit messages to stderr about files
- that were not changed or were ignored due to
- --exclude=.
-
- --version Show the version and exit.
- --config FILE Read configuration from PATH.
- -h, --help Show this message and exit.
-```
-
-_Black_ is a well-behaved Unix-style command-line tool:
-
-- it does nothing if no sources are passed to it;
-- it will read from standard input and write to standard output if `-` is used as the
- filename;
-- it only outputs messages to users on standard error;
-- exits with code 0 unless an internal error occurred (or `--check` was used).
-
-### Using _Black_ with other tools
-
-While _Black_ enforces formatting that conforms to PEP 8, other tools may raise warnings
-about _Black_'s changes or will overwrite _Black_'s changes. A good example of this is
-[isort](https://pypi.org/p/isort). Since _Black_ is barely configurable, these tools
-should be configured to neither warn about nor overwrite _Black_'s changes.
-
-Actual details on _Black_ compatible configurations for various tools can be found in
-[compatible_configs](https://github.com/psf/black/blob/master/docs/compatible_configs.md).
-
-### NOTE: This is a beta product
-
-_Black_ is already [successfully used](#used-by) by many projects, small and big. It
-also sports a decent test suite. However, it is still very new. Things will probably be
-wonky for a while. This is made explicit by the "Beta" trove classifier, as well as by
-the "b" in the version number. What this means for you is that **until the formatter
-becomes stable, you should expect some formatting to change in the future**. That being
-said, no drastic stylistic changes are planned, mostly responses to bug reports.
-
-Also, as a temporary safety measure, _Black_ will check that the reformatted code still
-produces a valid AST that is equivalent to the original. This slows it down. If you're
-feeling confident, use `--fast`.
-
-## The _Black_ code style
-
-_Black_ reformats entire files in place. It is not configurable. It doesn't take
-previous formatting into account. It doesn't reformat blocks that start with
-`# fmt: off` and end with `# fmt: on`. `# fmt: on/off` have to be on the same level of
-indentation. It also recognizes [YAPF](https://github.com/google/yapf)'s block comments
-to the same effect, as a courtesy for straddling code.
-
-### How _Black_ wraps lines
-
-_Black_ ignores previous formatting and applies uniform horizontal and vertical
-whitespace to your code. The rules for horizontal whitespace can be summarized as: do
-whatever makes `pycodestyle` happy. The coding style used by _Black_ can be viewed as a
-strict subset of PEP 8.
-
-As for vertical whitespace, _Black_ tries to render one full expression or simple
-statement per line. If this fits the allotted line length, great.
-
-```py3
-# in:
-
-j = [1,
- 2,
- 3
-]
-
-# out:
-
-j = [1, 2, 3]
-```
-
-If not, _Black_ will look at the contents of the first outer matching brackets and put
-that in a separate indented line.
-
-```py3
-# in:
-
-ImportantClass.important_method(exc, limit, lookup_lines, capture_locals, extra_argument)
-
-# out:
-
-ImportantClass.important_method(
- exc, limit, lookup_lines, capture_locals, extra_argument
-)
-```
-
-If that still doesn't fit the bill, it will decompose the internal expression further
-using the same rule, indenting matching brackets every time. If the contents of the
-matching brackets pair are comma-separated (like an argument list, or a dict literal,
-and so on) then _Black_ will first try to keep them on the same line with the matching
-brackets. If that doesn't work, it will put all of them in separate lines.
-
-```py3
-# in:
-
-def very_important_function(template: str, *variables, file: os.PathLike, engine: str, header: bool = True, debug: bool = False):
- """Applies `variables` to the `template` and writes to `file`."""
- with open(file, 'w') as f:
- ...
-
-# out:
-
-def very_important_function(
- template: str,
- *variables,
- file: os.PathLike,
- engine: str,
- header: bool = True,
- debug: bool = False,
-):
- """Applies `variables` to the `template` and writes to `file`."""
- with open(file, "w") as f:
- ...
-```
-
-_Black_ prefers parentheses over backslashes, and will remove backslashes if found.
-
-```py3
-# in:
-
-if some_short_rule1 \
- and some_short_rule2:
- ...
-
-# out:
-
-if some_short_rule1 and some_short_rule2:
- ...
-
-
-# in:
-
-if some_long_rule1 \
- and some_long_rule2:
- ...
-
-# out:
-
-if (
- some_long_rule1
- and some_long_rule2
-):
- ...
-
-```
-
-Backslashes and multiline strings are one of the two places in the Python grammar that
-break significant indentation. You never need backslashes, they are used to force the
-grammar to accept breaks that would otherwise be parse errors. That makes them confusing
-to look at and brittle to modify. This is why _Black_ always gets rid of them.
-
-If you're reaching for backslashes, that's a clear signal that you can do better if you
-slightly refactor your code. I hope some of the examples above show you that there are
-many ways in which you can do it.
-
-However there is one exception: `with` statements using multiple context managers.
-Python's grammar does not allow organizing parentheses around the series of context
-managers.
-
-We don't want formatting like:
-
-```py3
-with make_context_manager1() as cm1, make_context_manager2() as cm2, make_context_manager3() as cm3, make_context_manager4() as cm4:
- ... # nothing to split on - line too long
-```
-
-So _Black_ will now format it like this:
-
-```py3
-with \
- make_context_manager(1) as cm1, \
- make_context_manager(2) as cm2, \
- make_context_manager(3) as cm3, \
- make_context_manager(4) as cm4 \
-:
- ... # backslashes and an ugly stranded colon
-```
-
-You might have noticed that closing brackets are always dedented and that a trailing
-comma is always added. Such formatting produces smaller diffs; when you add or remove an
-element, it's always just one line. Also, having the closing bracket dedented provides a
-clear delimiter between two distinct sections of the code that otherwise share the same
-indentation level (like the arguments list and the docstring in the example above).
-
-If a data structure literal (tuple, list, set, dict) or a line of "from" imports cannot
-fit in the allotted length, it's always split into one element per line. This minimizes
-diffs as well as enables readers of code to find which commit introduced a particular
-entry. This also makes _Black_ compatible with [isort](https://pypi.org/p/isort/) with
-the following configuration.
-
-<details>
-<summary>A compatible `.isort.cfg`</summary>
-
-```
-[settings]
-multi_line_output=3
-include_trailing_comma=True
-force_grid_wrap=0
-use_parentheses=True
-line_length=88
-```
-
-The equivalent command line is:
projects / etc / vim.git / blobdiff