From 12ef43c8d01032ab0991365f631f7d79a434f85a Mon Sep 17 00:00:00 2001 From: Sebastian Rittau Date: Tue, 29 Apr 2025 01:04:45 +0200 Subject: [PATCH] Rename "Preparing Changes" to "Making Changes" (#13901) And integrate the "Code Style" chapter there. This makes the actual chapter structure follow the overview structure. --- CONTRIBUTING.md | 48 +++++++++++++++++++++++------------------------- 1 file changed, 23 insertions(+), 25 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 5ebfae6b4..e6645ede6 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -9,7 +9,7 @@ are important to the project's success. 1. [Prepare your environment](#preparing-the-environment). 2. Find out [where to make your changes](#where-to-make-changes). -3. [Prepare your changes](#preparing-changes): +3. [Making your changes](#making-changes): * Small fixes and additions can be submitted directly as pull requests, but [contact us](README.md#discussion) before starting significant work. * Create your stubs, considering [what to include](#what-to-include) and @@ -112,29 +112,6 @@ as it's currently excluded from the requirements file: -## Code formatting - -The code is formatted using [`Black`](https://github.com/psf/black). -Various other autofixes and lint rules are -also performed by [`Ruff`](https://github.com/astral-sh/ruff) and -[`Flake8`](https://github.com/pycqa/flake8), -with plugin [`flake8-pyi`](https://github.com/pycqa/flake8-pyi). - -The repository is equipped with a [pre-commit.ci](https://pre-commit.ci/) -configuration file. This means that you don't *need* to do anything yourself to -run the code formatters or linters. When you push a commit, a bot will run -those for you right away and add any autofixes to your PR. Anything -that can't be autofixed will show up as a CI failure, hopefully with an error -message that will make it clear what's gone wrong. - -That being said, if you *want* to run the formatters and linters locally -when you commit, you're free to do so. To use the same configuration as we use -in CI, we recommend doing this via pre-commit: - -```bash -(.venv)$ pre-commit run --all-files -``` - ## Where to make changes ### Standard library stubs @@ -260,7 +237,7 @@ The format of all `METADATA.toml` files can be checked by running `python3 ./tests/check_typeshed_structure.py`. -## Preparing Changes +## Making Changes ### Before you begin @@ -275,6 +252,27 @@ Each Python module is represented by a .pyi "stub file". This is a syntactically Typeshed follows the standard type system guidelines for [stub content](https://typing.readthedocs.io/en/latest/guides/writing_stubs.html#stub-content) and [coding style](https://typing.readthedocs.io/en/latest/guides/writing_stubs.html#style-guide). +The code is formatted using [`Black`](https://github.com/psf/black). +Various other autofixes and lint rules are +also performed by [`Ruff`](https://github.com/astral-sh/ruff) and +[`Flake8`](https://github.com/pycqa/flake8), +with plugin [`flake8-pyi`](https://github.com/pycqa/flake8-pyi). + +The repository is equipped with a [pre-commit.ci](https://pre-commit.ci/) +configuration file. This means that you don't *need* to do anything yourself to +run the code formatters or linters. When you push a commit, a bot will run +those for you right away and add any autofixes to your PR. Anything +that can't be autofixed will show up as a CI failure, hopefully with an error +message that will make it clear what's gone wrong. + +That being said, if you *want* to run the formatters and linters locally +when you commit, you're free to do so. To use the same configuration as we use +in CI, we recommend doing this via pre-commit: + +```bash +(.venv)$ pre-commit run --all-files +``` + ### What to include Stubs should include the complete interface (classes, functions,