issues, the equivalence of code after formatting is
[checked](the_black_code_style/current_style.md#ast-before-and-after-formatting) with
limited special cases where the code is allowed to differ. If issues are found, an error
-is raised and the file is left untouched.
+is raised and the file is left untouched. Magical comments that influence linters and
+other tools, such as `# noqa`, may be moved by _Black_. See below for more details.
## How stable is Black's style?
[file collection and discovery](usage_and_configuration/file_collection_and_discovery.md)
for details.
+## Why is my Jupyter Notebook cell not formatted?
+
+_Black_ is timid about formatting Jupyter Notebooks. Cells containing any of the
+following will not be formatted:
+
+- automagics (e.g. `pip install black`)
+- multiline magics, e.g.:
+
+ ```python
+ %timeit f(1, \
+ 2, \
+ 3)
+ ```
+
+- code which `IPython`'s `TransformerManager` would transform magics into, e.g.:
+
+ ```python
+ get_ipython().system('ls')
+ ```
+
+- invalid syntax, as it can't be safely distinguished from automagics in the absence of
+ a running `IPython` kernel.
+
## Why are Flake8's E203 and W503 violated?
Because they go against PEP 8. E203 falsely triggers on list
to format Python 2 files too! There are no current plans to drop support, but most
likely it is bound to happen. Sometime. Eventually. In terms of running _Black_ though,
Python 3.6 or newer is required.
+
+## Why does my linter or typechecker complain after I format my code?
+
+Some linters and other tools use magical comments (e.g., `# noqa`, `# type: ignore`) to
+influence their behavior. While Black does its best to recognize such comments and leave
+them in the right place, this detection is not and cannot be perfect. Therefore, you'll
+sometimes have to manually move these comments to the right place after you format your
+codebase with _Black_.