All patches and comments are welcome. Please squash your changes to logical
commits before using git-format-patch and git-send-email to
patches@git.madduck.net.
If you'd read over the Git project's submission guidelines and adhered to them,
I'd be especially grateful.
1 [//]: # "NOTE: THIS FILE WAS AUTOGENERATED FROM README.md"
3 # Installation and usage
7 _Black_ can be installed by running `pip install black`. It requires Python 3.6.0+ to
8 run but you can reformat Python 2 code with it, too.
10 ### Install from GitHub
12 If you can't wait for the latest _hotness_ and want to install from GitHub, use:
14 `pip install git+git://github.com/psf/black`
18 To get started right away with sensible defaults:
21 black {source_file_or_directory}
24 You can run _Black_ as a package if running it as a script doesn't work:
27 python -m black {source_file_or_directory}
30 ## Command line options
32 _Black_ doesn't provide many options. You can list them by running `black --help`:
35 Usage: black [OPTIONS] [SRC]...
37 The uncompromising code formatter.
40 -c, --code TEXT Format the code passed in as a string.
41 -l, --line-length INTEGER How many characters per line to allow.
44 -t, --target-version [py27|py33|py34|py35|py36|py37|py38|py39]
45 Python versions that should be supported by
46 Black's output. [default: per-file auto-
49 --pyi Format all input files like typing stubs
50 regardless of file extension (useful when
51 piping source on standard input).
53 -S, --skip-string-normalization
54 Don't normalize string quotes or prefixes.
55 -C, --skip-magic-trailing-comma
56 Don't use trailing commas as a reason to
59 --check Don't write the files back, just return the
60 status. Return code 0 means nothing would
61 change. Return code 1 means some files
62 would be reformatted. Return code 123 means
63 there was an internal error.
65 --diff Don't write the files back, just output a
66 diff for each file on stdout.
68 --color / --no-color Show colored diff. Only applies when
71 --fast / --safe If --fast given, skip temporary sanity
72 checks. [default: --safe]
74 --include TEXT A regular expression that matches files and
75 directories that should be included on
76 recursive searches. An empty value means
77 all files are included regardless of the
78 name. Use forward slashes for directories
79 on all platforms (Windows, too). Exclusions
80 are calculated first, inclusions later.
83 --exclude TEXT A regular expression that matches files and
84 directories that should be excluded on
85 recursive searches. An empty value means no
86 paths are excluded. Use forward slashes for
87 directories on all platforms (Windows, too).
88 Exclusions are calculated first, inclusions
89 later. [default: /(\.direnv|\.eggs|\.git|\.
90 hg|\.mypy_cache|\.nox|\.tox|\.venv|\.svn|_bu
91 ild|buck-out|build|dist)/]
93 --force-exclude TEXT Like --exclude, but files and directories
94 matching this regex will be excluded even
95 when they are passed explicitly as
98 --stdin-filename TEXT The name of the file when passing it through
99 stdin. Useful to make sure Black will
100 respect --force-exclude option on some
101 editors that rely on using stdin.
103 -q, --quiet Don't emit non-error messages to stderr.
104 Errors are still emitted; silence those with
107 -v, --verbose Also emit messages to stderr about files
108 that were not changed or were ignored due to
111 --version Show the version and exit.
112 --config FILE Read configuration from FILE path.
113 -h, --help Show this message and exit.
116 _Black_ is a well-behaved Unix-style command-line tool:
118 - it does nothing if no sources are passed to it;
119 - it will read from standard input and write to standard output if `-` is used as the
121 - it only outputs messages to users on standard error;
122 - exits with code 0 unless an internal error occurred (or `--check` was used).
124 ## Using _Black_ with other tools
126 While _Black_ enforces formatting that conforms to PEP 8, other tools may raise warnings
127 about _Black_'s changes or will overwrite _Black_'s changes. A good example of this is
128 [isort](https://pypi.org/p/isort). Since _Black_ is barely configurable, these tools
129 should be configured to neither warn about nor overwrite _Black_'s changes.
131 Actual details on _Black_ compatible configurations for various tools can be found in
132 [compatible_configs](https://github.com/psf/black/blob/master/docs/compatible_configs.md#black-compatible-configurations).
134 ## Migrating your code style without ruining git blame
136 A long-standing argument against moving to automated code formatters like _Black_ is
137 that the migration will clutter up the output of `git blame`. This was a valid argument,
138 but since Git version 2.23, Git natively supports
139 [ignoring revisions in blame](https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revltrevgt)
140 with the `--ignore-rev` option. You can also pass a file listing the revisions to ignore
141 using the `--ignore-revs-file` option. The changes made by the revision will be ignored
142 when assigning blame. Lines modified by an ignored revision will be blamed on the
143 previous revision that modified those lines.
145 So when migrating your project's code style to _Black_, reformat everything and commit
146 the changes (preferably in one massive commit). Then put the full 40 characters commit
147 identifier(s) into a file.
150 # Migrate code style to Black
151 5b4ab991dede475d393e9d69ec388fd6bd949699
154 Afterwards, you can pass that file to `git blame` and see clean and meaningful blame
158 $ git blame important.py --ignore-revs-file .git-blame-ignore-revs
159 7a1ae265 (John Smith 2019-04-15 15:55:13 -0400 1) def very_important_function(text, file):
160 abdfd8b0 (Alice Doe 2019-09-23 11:39:32 -0400 2) text = text.lstrip()
161 7a1ae265 (John Smith 2019-04-15 15:55:13 -0400 3) with open(file, "r+") as f:
162 7a1ae265 (John Smith 2019-04-15 15:55:13 -0400 4) f.write(formatted)
165 You can even configure `git` to automatically ignore revisions listed in a file on every
169 $ git config blame.ignoreRevsFile .git-blame-ignore-revs
172 **The one caveat is that GitHub and GitLab do not yet support ignoring revisions using
173 their native UI of blame.** So blame information will be cluttered with a reformatting
174 commit on those platforms. (If you'd like this feature, there's an open issue for
175 [GitLab](https://gitlab.com/gitlab-org/gitlab/-/issues/31423) and please let GitHub
178 ## NOTE: This is a beta product
180 _Black_ is already [successfully used](https://github.com/psf/black#used-by) by many
181 projects, small and big. It also sports a decent test suite. However, it is still very
182 new. Things will probably be wonky for a while. This is made explicit by the "Beta"
183 trove classifier, as well as by the "b" in the version number. What this means for you
184 is that **until the formatter becomes stable, you should expect some formatting to
185 change in the future**. That being said, no drastic stylistic changes are planned,
186 mostly responses to bug reports.
188 Also, as a temporary safety measure, _Black_ will check that the reformatted code still
189 produces a valid AST that is equivalent to the original. This slows it down. If you're
190 feeling confident, use `--fast`.