supplier-meesho.webflow 1.0.0

package/GitRepos/black/docs/guides/using_black_with_other_tools.md

@@ -0,0 +1,278 @@
+# Using _Black_ with other tools
+
+## Black compatible configurations
+
+All of Black's changes are harmless (or at least, they should be), but a few do conflict
+against other tools. It is not uncommon to be using other tools alongside _Black_ like
+linters and type checkers. Some of them need a bit of tweaking to resolve the conflicts.
+Listed below are _Black_ compatible configurations in various formats for the common
+tools out there.
+
+**Please note** that _Black_ only supports the TOML file format for its configuration
+(e.g. `pyproject.toml`). The provided examples are to only configure their corresponding
+tools, using **their** supported file formats.
+
+Compatible configuration files can be
+[found here](https://github.com/psf/black/blob/main/docs/compatible_configs/).
+
+### isort
+
+[isort](https://pypi.org/p/isort/) helps to sort and format imports in your Python code.
+_Black_ also formats imports, but in a different way from isort's defaults which leads
+to conflicting changes.
+
+#### Profile
+
+Since version 5.0.0, isort supports
+[profiles](https://pycqa.github.io/isort/docs/configuration/profiles/) to allow easy
+interoperability with common code styles. You can set the black profile in any of the
+[config files](https://pycqa.github.io/isort/docs/configuration/config_files/) supported
+by isort. Below, an example for `pyproject.toml`:
+
+```toml
+[tool.isort]
+profile = "black"
+```
+
+#### Custom Configuration
+
+If you're using an isort version that is older than 5.0.0 or you have some custom
+configuration for _Black_, you can tweak your isort configuration to make it compatible
+with _Black_. Below, an example for `.isort.cfg`:
+
+```
+multi_line_output = 3
+include_trailing_comma = True
+force_grid_wrap = 0
+use_parentheses = True
+ensure_newline_before_comments = True
+line_length = 88
+```
+
+#### Why those options above?
+
+_Black_ wraps imports that surpass `line-length` by moving identifiers into their own
+indented line. If that still doesn't fit the bill, it will put all of them in separate
+lines and put a trailing comma. A more detailed explanation of this behaviour can be
+[found here](../the_black_code_style/current_style.md#how-black-wraps-lines).
+
+isort's default mode of wrapping imports that extend past the `line_length` limit is
+"Grid".
+
+```py3
+from third_party import (lib1, lib2, lib3,
+                         lib4, lib5, ...)
+```
+
+This style is incompatible with _Black_, but isort can be configured to use a different
+wrapping mode called "Vertical Hanging Indent" which looks like this:
+
+```py3
+from third_party import (
+    lib1,
+    lib2,
+    lib3,
+    lib4,
+)
+```
+
+This style is _Black_ compatible and can be achieved by `multi-line-output = 3`. Also,
+as mentioned above, when wrapping long imports _Black_ puts a trailing comma and uses
+parentheses. isort should follow the same behaviour and passing the options
+`include_trailing_comma = True` and `use_parentheses = True` configures that.
+
+The option `force_grid_wrap = 0` is just to tell isort to only wrap imports that surpass
+the `line_length` limit.
+
+Finally, isort should be told to wrap imports when they surpass _Black_'s default limit
+of 88 characters via `line_length = 88` as well as
+`ensure_newline_before_comments = True` to ensure spacing import sections with comments
+works the same as with _Black_.
+
+**Please note** `ensure_newline_before_comments = True` only works since isort >= 5 but
+does not break older versions so you can keep it if you are running previous versions.
+
+#### Formats
+
+<details>
+<summary>.isort.cfg</summary>
+
+```cfg
+[settings]
+profile = black
+```
+
+</details>
+
+<details>
+<summary>setup.cfg</summary>
+
+```cfg
+[isort]
+profile = black
+```
+
+</details>
+
+<details>
+<summary>pyproject.toml</summary>
+
+```toml
+[tool.isort]
+profile = 'black'
+```
+
+</details>
+
+<details>
+<summary>.editorconfig</summary>
+
+```ini
+[*.py]
+profile = black
+```
+
+</details>
+
+### Flake8
+
+[Flake8](https://pypi.org/p/flake8/) is a code linter. It warns you of syntax errors,
+possible bugs, stylistic errors, etc. For the most part, Flake8 follows
+[PEP 8](https://www.python.org/dev/peps/pep-0008/) when warning about stylistic errors.
+There are a few deviations that cause incompatibilities with _Black_.
+
+#### Configuration
+
+```
+max-line-length = 88
+extend-ignore = E203
+```
+
+#### Why those options above?
+
+In some cases, as determined by PEP 8, _Black_ will enforce an equal amount of
+whitespace around slice operators. Due to this, Flake8 will raise
+`E203 whitespace before ':'` warnings. Since this warning is not PEP 8 compliant, Flake8
+should be configured to ignore it via `extend-ignore = E203`.
+
+When breaking a line, _Black_ will break it before a binary operator. This is compliant
+with PEP 8 as of
+[April 2016](https://github.com/python/peps/commit/c59c4376ad233a62ca4b3a6060c81368bd21e85b#diff-64ec08cc46db7540f18f2af46037f599).
+There's a disabled-by-default warning in Flake8 which goes against this PEP 8
+recommendation called `W503 line break before binary operator`. It should not be enabled
+in your configuration.
+
+Also, as like with isort, flake8 should be configured to allow lines up to the length
+limit of `88`, _Black_'s default. This explains `max-line-length = 88`.
+
+#### Formats
+
+<details>
+<summary>.flake8</summary>
+
+```ini
+[flake8]
+max-line-length = 88
+extend-ignore = E203
+```
+
+</details>
+
+<details>
+<summary>setup.cfg</summary>
+
+```cfg
+[flake8]
+max-line-length = 88
+extend-ignore = E203
+```
+
+</details>
+
+<details>
+<summary>tox.ini</summary>
+
+```ini
+[flake8]
+max-line-length = 88
+extend-ignore = E203
+```
+
+</details>
+
+### Pylint
+
+[Pylint](https://pypi.org/p/pylint/) is also a code linter like Flake8. It has the same
+checks as flake8 and more. In particular, it has more formatting checks regarding style
+conventions like variable naming. With so many checks, Pylint is bound to have some
+mixed feelings about _Black_'s formatting style.
+
+#### Configuration
+
+```
+disable = C0330, C0326
+max-line-length = 88
+```
+
+#### Why those options above?
+
+When _Black_ is folding very long expressions, the closing brackets will
+[be dedented](../the_black_code_style/current_style.md#how-black-wraps-lines).
+
+```py3
+ImportantClass.important_method(
+    exc, limit, lookup_lines, capture_locals, callback
+)
+```
+
+Although this style is PEP 8 compliant, Pylint will raise
+`C0330: Wrong hanging indentation before block (add 4 spaces)` warnings. Since _Black_
+isn't configurable on this style, Pylint should be told to ignore these warnings via
+`disable = C0330`.
+
+Also, since _Black_ deals with whitespace around operators and brackets, Pylint's
+warning `C0326: Bad whitespace` should be disabled using `disable = C0326`.
+
+And as usual, Pylint should be configured to only complain about lines that surpass `88`
+characters via `max-line-length = 88`.
+
+#### Formats
+
+<details>
+<summary>pylintrc</summary>
+
+```ini
+[MESSAGES CONTROL]
+disable = C0330, C0326
+
+[format]
+max-line-length = 88
+```
+
+</details>
+
+<details>
+<summary>setup.cfg</summary>
+
+```cfg
+[pylint]
+max-line-length = 88
+
+[pylint.messages_control]
+disable = C0330, C0326
+```
+
+</details>
+
+<details>
+<summary>pyproject.toml</summary>
+
+```toml
+[tool.pylint.messages_control]
+disable = "C0330, C0326"
+
+[tool.pylint.format]
+max-line-length = "88"
+```
+
+</details>

package/GitRepos/black/docs/index.rst

@@ -0,0 +1,120 @@
+.. black documentation master file, created by
+   sphinx-quickstart on Fri Mar 23 10:53:30 2018.
+
+The uncompromising code formatter
+=================================
+
+By using *Black*, you agree to cede control over minutiae of
+hand-formatting. In return, *Black* gives you speed, determinism, and
+freedom from `pycodestyle` nagging about formatting. You will save time
+and mental energy for more important matters.
+
+*Black* makes code review faster by producing the smallest diffs
+possible. Blackened code looks the same regardless of the project
+you're reading. Formatting becomes transparent after a while and you
+can focus on the content instead.
+
+Try it out now using the `Black Playground <https://black.vercel.app>`_.
+
+.. admonition:: Note - this is a beta product
+
+   *Black* is already `successfully used <https://github.com/psf/black#used-by>`_ by
+   many projects, small and big. *Black* has a comprehensive test suite, with efficient
+   parallel tests, our own auto  formatting and parallel Continuous Integration runner.
+   However, *Black* is still beta. Things will probably be wonky for a while. This is
+   made explicit by the "Beta" trove classifier, as well as by the "b" in the version
+   number. What this means for you is that **until the formatter becomes stable, you
+   should expect some formatting to change in the future**. That being said, no drastic
+   stylistic changes are planned, mostly responses to bug reports.
+
+   Also, as a safety measure which slows down processing, *Black* will check that the
+   reformatted code still produces a valid AST that is effectively equivalent to the
+   original (see the
+   `Pragmatism <./the_black_code_style/current_style.html#pragmatism>`_
+   section for details). If you're feeling confident, use ``--fast``.
+
+.. note::
+   :doc:`Black is licensed under the MIT license <license>`.
+
+Testimonials
+------------
+
+**Dusty Phillips**, `writer <https://smile.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Daps&field-keywords=dusty+phillips>`_:
+
+   *Black is opinionated so you don't have to be.*
+
+**Hynek Schlawack**, creator of `attrs <https://www.attrs.org/>`_, core
+developer of Twisted and CPython:
+
+   *An auto-formatter that doesn't suck is all I want for Xmas!*
+
+**Carl Meyer**, `Django <https://www.djangoproject.com/>`_ core developer:
+
+   *At least the name is good.*
+
+**Kenneth Reitz**, creator of `requests <http://python-requests.org/>`_
+and `pipenv <https://docs.pipenv.org/>`_:
+
+   *This vastly improves the formatting of our code. Thanks a ton!*
+
+
+Show your style
+---------------
+
+Use the badge in your project's README.md:
+
+.. code-block:: md
+
+   [![Code style: black](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/psf/black)
+
+
+Using the badge in README.rst:
+
+.. code-block:: rst
+
+   .. image:: https://img.shields.io/badge/code%20style-black-000000.svg
+      :target: https://github.com/psf/black
+
+Looks like this:
+
+.. image:: https://img.shields.io/badge/code%20style-black-000000.svg
+   :target: https://github.com/psf/black
+
+Contents
+--------
+
+.. toctree::
+   :maxdepth: 3
+   :includehidden:
+
+   the_black_code_style/index
+
+.. toctree::
+   :maxdepth: 3
+   :includehidden:
+
+   getting_started
+   usage_and_configuration/index
+   integrations/index
+   guides/index
+
+.. toctree::
+   :maxdepth: 3
+   :includehidden:
+
+   contributing/index
+   change_log
+   authors
+
+.. toctree::
+   :hidden:
+
+   GitHub ↪ <https://github.com/psf/black>
+   PyPI ↪ <https://pypi.org/project/black>
+   IRC ↪ <https://webchat.freenode.net/?channels=%23blackformatter>
+
+Indices and tables
+==================
+
+* :ref:`genindex`
+* :ref:`search`