Merge commit '882d8795c6ff65c02f2657e596391748d1b6b7f5'

[etc/vim.git] / .vim / bundle / black / docs / the_black_code_style / static / gitweb.js

diff --git a/docs/the_black_code_style/index.md b/docs/the_black_code_style/index.md
deleted file mode 100644 (file)
index 1719347..0000000
--- a/docs/the_black_code_style/index.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# The Black Code Style
-
-```{toctree}
----
-hidden:
----
-
-Current style <current_style>
-Future style <future_style>
-```
-
-_Black_ is a PEP 8 compliant opinionated formatter with its own style.
-
-While keeping the style unchanged throughout releases has always been a goal, the
-_Black_ code style isn't set in stone. It evolves to accommodate for new features in the
-Python language and, occasionally, in response to user feedback. Large-scale style
-preferences presented in {doc}`current_style` are very unlikely to change, but minor
-style aspects and details might change according to the stability policy presented
-below. Ongoing style considerations are tracked on GitHub with the
-[style](https://github.com/psf/black/labels/T%3A%20style) issue label.
-
-(labels/stability-policy)=
-
-## Stability Policy
-
-The following policy applies for the _Black_ code style, in non pre-release versions of
-_Black_:
-
-- If code has been formatted with _Black_, it will remain unchanged when formatted with
-  the same options using any other release in the same calendar year.
-
-  This means projects can safely use `black ~= 22.0` without worrying about formatting
-  changes disrupting their project in 2022. We may still fix bugs where _Black_ crashes
-  on some code, and make other improvements that do not affect formatting.
-
-  In rare cases, we may make changes affecting code that has not been previously
-  formatted with _Black_. For example, we have had bugs where we accidentally removed
-  some comments. Such bugs can be fixed without breaking the stability policy.
-
-- The first release in a new calendar year _may_ contain formatting changes, although
-  these will be minimised as much as possible. This is to allow for improved formatting
-  enabled by newer Python language syntax as well as due to improvements in the
-  formatting logic.
-
-- The `--preview` flag is exempt from this policy. There are no guarantees around the
-  stability of the output with that flag passed into _Black_. This flag is intended for
-  allowing experimentation with the proposed changes to the _Black_ code style.
-
-Documentation for both the current and future styles can be found:
-
-- {doc}`current_style`
-- {doc}`future_style`