-### Command line options
-
-*Black* doesn't provide many options. You can list them by running
-`black --help`:
-
-```text
-black [OPTIONS] [SRC]...
-
-Options:
- -l, --line-length INTEGER How many characters per line to allow.
- [default: 88]
- -t, --target-version [pypy35|cpy27|cpy33|cpy34|cpy35|cpy36|cpy37|cpy38]
- 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.
- --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|_build|buck-
- out|build|dist)/]
- -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 PATH 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).
-
-
-### NOTE: This is a beta product
-
-*Black* is already successfully used by several 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:
-
-l = [1,
- 2,
- 3,
-]
-
-# out:
-
-l = [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:
- ...
-```
-
-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:
-```
-$ isort --multi-line=3 --trailing-comma --force-grid-wrap=0 --use-parentheses --line-width=88 [ file.py ]
-```
-</details>
-
-### Line length
-
-You probably noticed the peculiar default line length. *Black* defaults
-to 88 characters per line, which happens to be 10% over 80. This number
-was found to produce significantly shorter files than sticking with 80
-(the most popular), or even 79 (used by the standard library). In
-general, [90-ish seems like the wise choice](https://youtu.be/wf-BqAjZb8M?t=260).
-
-If you're paid by the line of code you write, you can pass
-`--line-length` with a lower number. *Black* will try to respect that.
-However, sometimes it won't be able to without breaking other rules. In
-those rare cases, auto-formatted code will exceed your allotted limit.
-
-You can also increase it, but remember that people with sight disabilities
-find it harder to work with line lengths exceeding 100 characters.
-It also adversely affects side-by-side diff review on typical screen
-resolutions. Long lines also make it harder to present code neatly
-in documentation or talk slides.
-
-If you're using Flake8, you can bump `max-line-length` to 88 and forget
-about it. Alternatively, use [Bugbear](https://github.com/PyCQA/flake8-bugbear)'s
-B950 warning instead of E501 and keep the max line length at 80 which
-you are probably already using. You'd do it like this:
-```ini
-[flake8]
-max-line-length = 80
-...
-select = C,E,F,W,B,B950
-ignore = E501
-```
-
-You'll find *Black*'s own .flake8 config file is configured like this.
-If you're curious about the reasoning behind B950,
-[Bugbear's documentation](https://github.com/PyCQA/flake8-bugbear#opinionated-warnings)
-explains it. The tl;dr is "it's like highway speed limits, we won't
-bother you if you overdo it by a few km/h".
-
-
-### Empty lines
-
-*Black* avoids spurious vertical whitespace. This is in the spirit of
-PEP 8 which says that in-function vertical whitespace should only be
-used sparingly.
-
-*Black* will allow single empty lines inside functions, and single and
-double empty lines on module level left by the original editors, except
-when they're within parenthesized expressions. Since such expressions
-are always reformatted to fit minimal space, this whitespace is lost.
-
-It will also insert proper spacing before and after function definitions.
-It's one line before and after inner functions and two lines before and
-after module-level functions and classes. *Black* will not put empty
-lines between function/class definitions and standalone comments that
-immediately precede the given function/class.
-
-*Black* will enforce single empty lines between a class-level docstring
-and the first following field or method. This conforms to
-[PEP 257](https://www.python.org/dev/peps/pep-0257/#multi-line-docstrings).
-
-*Black* won't insert empty lines after function docstrings unless that
-empty line is required due to an inner function starting immediately
-after.
-
projects / etc / vim.git / blobdiff