:class: this-will-duplicate-information-and-it-is-still-useful-here
```
+## Why spaces? I prefer tabs
+
+PEP 8 recommends spaces over tabs, and they are used by most of the Python community.
+_Black_ provides no options to configure the indentation style, and requests for such
+options will not be considered.
+
+However, we recognise that using tabs is an accessibility issue as well. While the
+option will never be added to _Black_, visually impaired developers may find conversion
+tools such as `expand/unexpand` (for Linux) useful when contributing to Python projects.
+A workflow might consist of e.g. setting up appropriate pre-commit and post-merge git
+hooks, and scripting `unexpand` to run after applying _Black_.
+
## Does Black have an API?
Not yet. _Black_ is fundamentally a command line tool. Many
following will not be formatted:
- automagics (e.g. `pip install black`)
-- non-Python cell magics (e.g. `%%writeline`)
+- non-Python cell magics (e.g. `%%writeline`). These can be added with the flag
+ `--python-cell-magics`, e.g. `black --python-cell-magics writeline hello.ipynb`.
- multiline magics, e.g.:
```python
disabled-by-default counterpart W504. E203 should be disabled while changes are still
[discussed](https://github.com/PyCQA/pycodestyle/issues/373).
-## Does Black support Python 2?
+## Which Python versions does Black support?
+
+Currently the runtime requires Python 3.6-3.10. Formatting is supported for files
+containing syntax from Python 3.3 to 3.10. We promise to support at least all Python
+versions that have not reached their end of life. This is the case for both running
+_Black_ and formatting code.
-Support for formatting Python 2 code was removed in version 22.0.
+Support for formatting Python 2 code was removed in version 22.0. While we've made no
+plans to stop supporting older Python 3 minor versions immediately, their support might
+also be removed some time in the future without a deprecation period.
## Why does my linter or typechecker complain after I format my code?