X-Git-Url: https://git.madduck.net/etc/vim.git/blobdiff_plain/4041c560ec8e0233b448d97595fc9b7018a25c32..0196437f8e062817d3277bb1484de3fbdcb3e19d:/README.md?ds=sidebyside diff --git a/README.md b/README.md index 3b5e607..3c63cb5 100644 --- a/README.md +++ b/README.md @@ -5,6 +5,7 @@
+
@@ -33,9 +34,10 @@ Try it out now using the [Black Playground](https://black.now.sh). Watch the
_Contents:_ **[Installation and usage](#installation-and-usage)** |
**[Code style](#the-black-code-style)** | **[Pragmatism](#pragmatism)** |
**[pyproject.toml](#pyprojecttoml)** | **[Editor integration](#editor-integration)** |
-**[blackd](#blackd)** | **[Version control integration](#version-control-integration)**
-| **[Ignoring unmodified files](#ignoring-unmodified-files)** | **[Used by](#used-by)**
-| **[Testimonials](#testimonials)** | **[Show your style](#show-your-style)** |
+**[blackd](#blackd)** | **[black-primer](#black-primer)** |
+**[Version control integration](#version-control-integration)** |
+**[Ignoring unmodified files](#ignoring-unmodified-files)** | **[Used by](#used-by)** |
+**[Testimonials](#testimonials)** | **[Show your style](#show-your-style)** |
**[Contributing](#contributing-to-black)** | **[Change Log](#change-log)** |
**[Authors](#authors)**
@@ -52,7 +54,7 @@ run but you can reformat Python 2 code with it, too.
To get started right away with sensible defaults:
-```
+```sh
black {source_file_or_directory}
```
@@ -61,36 +63,41 @@ black {source_file_or_directory}
_Black_ doesn't provide many options. You can list them by running `black --help`:
```text
-black [OPTIONS] [SRC]...
+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]
- --py36 Allow using Python 3.6-only syntax on all
- input files. This will put trailing commas
- in function signatures and calls also after
- *args and **kwargs. Deprecated; use
- --target-version instead. [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
+ 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
@@ -99,6 +106,7 @@ Options:
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
@@ -106,16 +114,23 @@ Options:
directories on all platforms (Windows, too).
Exclusions are calculated first, inclusions
later. [default: /(\.eggs|\.git|\.hg|\.mypy
- _cache|\.nox|\.tox|\.venv|_build|buck-
+ _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
+ 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.
+ --config FILE Read configuration from PATH.
-h, --help Show this message and exit.
```
@@ -127,6 +142,60 @@ _Black_ is a well-behaved Unix-style command-line tool:
- 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).
+
+### Migrating your code style without ruining git blame
+
+A long-standing argument against moving to automated code formatters like _Black_ is
+that the migration will clutter up the output of `git blame`. This was a valid argument,
+but since Git version 2.23, Git natively supports
+[ignoring revisions in blame](https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revltrevgt)
+with the `--ignore-rev` option. You can also pass a file listing the revisions to ignore
+using the `--ignore-revs-file` option. The changes made by the revision will be ignored
+when assigning blame. Lines modified by an ignored revision will be blamed on the
+previous revision that modified those lines.
+
+So when migrating your project's code style to _Black_, reformat everything and commit
+the changes (preferably in one massive commit). Then put the full 40 characters commit
+identifier(s) into a file.
+
+```
+# Migrate code style to Black
+5b4ab991dede475d393e9d69ec388fd6bd949699
+```
+
+Afterwards, you can pass that file to `git blame` and see clean and meaningful blame
+information.
+
+```console
+$ git blame important.py --ignore-revs-file .git-blame-ignore-revs
+7a1ae265 (John Smith 2019-04-15 15:55:13 -0400 1) def very_important_function(text, file):
+abdfd8b0 (Alice Doe 2019-09-23 11:39:32 -0400 2) text = text.lstrip()
+7a1ae265 (John Smith 2019-04-15 15:55:13 -0400 3) with open(file, "r+") as f:
+7a1ae265 (John Smith 2019-04-15 15:55:13 -0400 4) f.write(formatted)
+```
+
+You can even configure `git` to automatically ignore revisions listed in a file on every
+call to `git blame`.
+
+```console
+$ git config blame.ignoreRevsFile .git-blame-ignore-revs
+```
+
+**The one caveat is that GitHub and GitLab do not yet support ignoring revisions using
+their native UI of blame.** So blame information will be cluttered with a reformatting
+commit on those platforms. (If you'd like this feature, there's an open issue for
+[GitLab](https://gitlab.com/gitlab-org/gitlab/-/issues/31423) and please let GitHub
+know!)
+
### NOTE: This is a beta product
_Black_ is already [successfully used](#used-by) by many projects, small and big. It
@@ -215,6 +284,69 @@ def very_important_function(
...
```
+_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
@@ -395,9 +527,12 @@ PEP 8
[recommends](https://www.python.org/dev/peps/pep-0008/#whitespace-in-expressions-and-statements)
to treat `:` in slices as a binary operator with the lowest priority, and to leave an
equal amount of space on either side, except if a parameter is omitted (e.g.
-`ham[1 + 1 :]`). It also states that for extended slices, both `:` operators have to
-have the same amount of spacing, except if a parameter is omitted (`ham[1 + 1 ::]`).
-_Black_ enforces these rules consistently.
+`ham[1 + 1 :]`). It recommends no spaces around `:` operators for "simple expressions"
+(`ham[lower:upper]`), and extra space for "complex expressions"
+(`ham[lower : upper + offset]`). _Black_ treats anything more than variable names as
+"complex" (`ham[lower : upper + 1]`). It also states that for extended slices, both `:`
+operators have to have the same amount of spacing, except if a parameter is omitted
+(`ham[1 + 1 ::]`). _Black_ enforces these rules consistently.
This behaviour may raise `E203 whitespace before ':'` warnings in style guide
enforcement tools like Flake8. Since `E203` is not PEP 8 compliant, you should tell
@@ -621,8 +756,11 @@ file hierarchy.
### Emacs
-Use [proofit404/blacken](https://github.com/proofit404/blacken) or
-[Elpy](https://github.com/jorgenschaefer/elpy).
+Options include the following:
+
+- [purcell/reformatter.el](https://github.com/purcell/reformatter.el)
+- [proofit404/blacken](https://github.com/proofit404/blacken)
+- [Elpy](https://github.com/jorgenschaefer/elpy).
### PyCharm/IntelliJ IDEA
@@ -648,6 +786,9 @@ $ where black
%LocalAppData%\Programs\Python\Python36-32\Scripts\black.exe # possible location
```
+Note that if you are using a virtual environment detected by PyCharm, this is an
+unneeded step. In this case the path to `black` is `$PyInterpreterDirectory$/black`.
+
3. Open External tools in PyCharm/IntelliJ IDEA
On macOS:
@@ -673,7 +814,7 @@ On Windows / Linux / BSD:
6. Optionally, run _Black_ on every file save:
1. Make sure you have the
- [File Watcher](https://plugins.jetbrains.com/plugin/7177-file-watchers) plugin
+ [File Watchers](https://plugins.jetbrains.com/plugin/7177-file-watchers) plugin
installed.
2. Go to `Preferences or Settings -> Tools -> File Watchers` and click `+` to add a
new watcher:
@@ -685,7 +826,7 @@ On Windows / Linux / BSD:
- Output paths to refresh: `$FilePath$`
- Working directory: `$ProjectFileDir$`
- - Uncheck "Auto-save edited files to trigger the watcher"
+ - Uncheck "Auto-save edited files to trigger the watcher" in Advanced Options
### Wing IDE
@@ -794,6 +935,55 @@ default. On macOS with Homebrew run: `brew install vim`. When building Vim from
use: `./configure --enable-python3interp=yes`. There's many guides online how to do
this.
+**I get an import error when using _Black_ from a virtual environment**: If you get an
+error message like this:
+
+```text
+Traceback (most recent call last):
+ File "