X-Git-Url: https://git.madduck.net/etc/vim.git/blobdiff_plain/04518c38c945ecf3c15765b71642112495cade8d..14d84ba2e96c5ca1351b8fe4d0d415cc148f4117:/docs/faq.md diff --git a/docs/faq.md b/docs/faq.md index 46e4598..70f9b51 100644 --- a/docs/faq.md +++ b/docs/faq.md @@ -5,8 +5,21 @@ The most common questions and issues users face are aggregated to this FAQ. ```{contents} :local: :backlinks: none +: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 @@ -16,19 +29,21 @@ though. ## Is Black safe to use? -Yes, for the most part. _Black_ is strictly about formatting, nothing else. But because -_Black_ is still in [beta](index.rst), some edges are still a bit rough. To combat -issues, the equivalence of code after formatting is +Yes. _Black_ is strictly about formatting, nothing else. Black strives to ensure that +after formatting the AST 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? -Quite stable. _Black_ aims to enforce one style and one style only, with some room for -pragmatism. However, _Black_ is still in beta so style changes are both planned and -still proposed on the issue tracker. See -[The Black Code Style](the_black_code_style/index.rst) for more details. +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. + +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 +styles, using the `--preview` flag. ## Why is my file not formatted? @@ -36,6 +51,30 @@ Most likely because it is ignored in `.gitignore` or excluded with configuration [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`) +- non-Python cell magics (e.g. `%%writeline`) +- 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 @@ -44,9 +83,32 @@ 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? + +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. 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? + +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_. + +## Can I run Black with PyPy? + +Yes, there is support for PyPy 3.7 and higher. + +## Why does Black not detect syntax errors in my code? -For formatting, yes! [Install](getting_started.md#installation) with the `python2` extra -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. +_Black_ is an autoformatter, not a Python linter or interpreter. Detecting all syntax +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.