X-Git-Url: https://git.madduck.net/etc/vim.git/blobdiff_plain/d2c938eb02c414057aa2186c7ae695d5d0d14377..f3b1a3b9d2fc6de8f0845399cb80d8bdfd6400fd:/docs/faq.md?ds=sidebyside diff --git a/docs/faq.md b/docs/faq.md index 0cff6ae..a6a422c 100644 --- a/docs/faq.md +++ b/docs/faq.md @@ -8,10 +8,22 @@ The most common questions and issues users face are aggregated to this FAQ. :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 -[integrations](integrations/index.rst) are provided, but a Python interface is not one +[integrations](/integrations/index.md) are provided, but a Python interface is not one of them. A simple API is being [planned](https://github.com/psf/black/issues/779) though. @@ -27,7 +39,7 @@ other tools, such as `# noqa`, may be moved by _Black_. See below for more detai ## How stable is Black's style? Stable. _Black_ aims to enforce one style and one style only, with some room for -pragmatism. See [The Black Code Style](the_black_code_style/index.rst) for more details. +pragmatism. See [The Black Code Style](the_black_code_style/index.md) for more details. Starting in 2022, the formatting output will be stable for the releases made in the same year (other than unintentional bugs). It is possible to opt-in to the latest formatting @@ -45,7 +57,8 @@ _Black_ is timid about formatting Jupyter Notebooks. Cells containing any of the 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 @@ -71,9 +84,18 @@ readability because operators are misaligned. Disable W503 and enable the 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? -Support for formatting Python 2 code was removed in version 22.0. +Currently the runtime requires Python 3.7-3.11. Formatting is supported for files +containing syntax from Python 3.3 to 3.11. 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. 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. + +Runtime support for 3.6 was removed in version 22.10.0. ## Why does my linter or typechecker complain after I format my code? @@ -93,3 +115,24 @@ _Black_ is an autoformatter, not a Python linter or interpreter. Detecting all s errors is not a goal. It can format all code accepted by CPython (if you find an example where that doesn't hold, please report a bug!), but it may also format some code that CPython doesn't accept. + +(labels/mypyc-support)= + +## What is `compiled: yes/no` all about in the version output? + +While _Black_ is indeed a pure Python project, we use [mypyc] to compile _Black_ into a +C Python extension, usually doubling performance. These compiled wheels are available +for 64-bit versions of Windows, Linux (via the manylinux standard), and macOS across all +supported CPython versions. + +Platforms including musl-based and/or ARM Linux distributions, and ARM Windows are +currently **not** supported. These platforms will fall back to the slower pure Python +wheel available on PyPI. + +If you are experiencing exceptionally weird issues or even segfaults, you can try +passing `--no-binary black` to your pip install invocation. This flag excludes all +wheels (including the pure Python wheel), so this command will use the [sdist]. + +[mypyc]: https://mypyc.readthedocs.io/en/latest/ +[sdist]: + https://packaging.python.org/en/latest/glossary/#term-Source-Distribution-or-sdist