diff --git a/.editorconfig b/.editorconfig new file mode 100644 index 0000000000..5230b76950 --- /dev/null +++ b/.editorconfig @@ -0,0 +1,15 @@ +root = true + +[*.{py,c,cpp,h,rst,md,yml}] +trim_trailing_whitespace = true +insert_final_newline = true +indent_style = space + +[*.{py,c,cpp,h}] +indent_size = 4 + +[*.rst] +indent_size = 3 + +[*.{css,yml}] +indent_size = 2 diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS new file mode 100644 index 0000000000..06213bdf40 --- /dev/null +++ b/.github/CODEOWNERS @@ -0,0 +1,8 @@ +# See https://help.github.com/articles/about-codeowners/ +# for more info about CODEOWNERS file + +# It uses the same pattern rule for gitignore file +# https://git-scm.com/docs/gitignore#_pattern_format + +# PSRT member list owned by PSRT admins. +developer-workflow/psrt*.csv @warsaw @ewdurbin @ned-deily @sethmlarson diff --git a/.github/CODE_OF_CONDUCT.md b/.github/CODE_OF_CONDUCT.md new file mode 100644 index 0000000000..2353822768 --- /dev/null +++ b/.github/CODE_OF_CONDUCT.md @@ -0,0 +1,12 @@ +Code of Conduct +=============== + +Please note that all interactions on +[Python Software Foundation](https://www.python.org/psf-landing/)-supported +infrastructure is [covered](https://www.python.org/psf/records/board/minutes/2014-01-06/#management-of-the-psfs-web-properties) +by the [PSF Code of Conduct](https://policies.python.org/python.org/code-of-conduct/), +which includes all infrastructure used in the development of Python itself +(for example, mailing lists, issue trackers, GitHub, etc.). + +In general this means everyone is expected to be open, considerate, and +respectful of others no matter what their position is within the project. diff --git a/.github/CODE_OF_CONDUCT.rst b/.github/CODE_OF_CONDUCT.rst deleted file mode 100644 index 05b033db7d..0000000000 --- a/.github/CODE_OF_CONDUCT.rst +++ /dev/null @@ -1,15 +0,0 @@ -:orphan: - -Code of Conduct -=============== - -Please note that all interactions on -`Python Software Foundation `__-supported -infrastructure is `covered -`__ -by the `PSF Code of Conduct `__, -which includes all infrastructure used in the development of Python itself -(e.g. mailing lists, issue trackers, GitHub, etc.). - -In general this means everyone is expected to be open, considerate, and -respectful of others no matter what their position is within the project. diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md new file mode 100644 index 0000000000..c4a7d25457 --- /dev/null +++ b/.github/CONTRIBUTING.md @@ -0,0 +1,44 @@ +# Contributing to the Devguide + +## Thank You + +First off, thanks for contributing to the devguide of the Python programming +language! Even if your contribution is not ultimately accepted, the fact you +put time and effort into helping out is greatly appreciated. + + +## Contribution Guidelines + +Please read this [devguide](https://devguide.python.org/) for +guidance on how to contribute to this project. The documentation covers +everything from how to build the code to submitting a pull request. There are +also suggestions on how you can most effectively help the project. + +Please be aware that our workflow does deviate slightly from the typical GitHub +project. Details on how to properly submit a pull request are covered in +[Lifecycle of a Pull Request](https://devguide.python.org/pullrequest/). +We utilize various bots and status checks to help with this, so do follow the +comments they leave and their "Details" links, respectively. + +The final key part of our workflow is that all discussions that are not +directly related to the code in the pull request should happen on the +[issue tracker](https://devguide.python.org/tracker/), generally in the +pull request's parent issue. + + +## Setting Expectations + +Due to the fact that this project is entirely volunteer-run (that is, no one is paid +to work on Python full-time), we unfortunately can make no guarantees as to if +or when a core developer will get around to reviewing your pull request. +If no core developer has done a review or responded to changes made because of a +"changes requested" review, please consider seeking assistance through the +[Core Development Discourse category](https://discuss.python.org/c/core-dev/23). + + +## Code of Conduct + +All interactions for this project are covered by the +[PSF Code of Conduct](https://policies.python.org/python.org/code-of-conduct/). Everyone is +expected to be open, considerate, and respectful of others no matter their +position within the project. diff --git a/.github/ISSUE_TEMPLATE/bug_report.yml b/.github/ISSUE_TEMPLATE/bug_report.yml new file mode 100644 index 0000000000..f6d55b1247 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/bug_report.yml @@ -0,0 +1,39 @@ +name: "Bug report" +description: Create a report to help us improve the Python devguide +title: "Bug: " +labels: ["type-bug"] +assignees: [] + +body: + - type: markdown + attributes: + value: | + > [!NOTE] + > This repo is for the [Python developer's guide](https://devguide.python.org/). + > If you are reporting a bug for the Python language or + > CPython interpreter, then use the + > [CPython issue tracker](https://github.com/python/cpython/issues) instead. + + - type: textarea + id: bug_description + attributes: + label: "Describe the bug" + description: A clear and concise description of what the bug is and, optionally, what you expected to happen. + validations: + required: true + + - type: textarea + id: screenshots + attributes: + label: "Screenshots" + description: If applicable, add screenshots to help explain your problem. + validations: + required: false + + - type: textarea + id: additional_context + attributes: + label: "Additional context" + description: Add any other context about the problem here. + validations: + required: false diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml new file mode 100644 index 0000000000..cd8c31d2a9 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/config.yml @@ -0,0 +1,14 @@ +blank_issues_enabled: false +contact_links: + - name: CPython Documentation + url: https://docs.python.org/ + about: Official CPython documentation - please check here before opening an issue. + - name: Python Website + url: https://python.org/ + about: For all things Python + - name: PyPI Issues / Support + url: https://github.com/pypi/support + about: For issues with PyPI itself, PyPI accounts, or with packages hosted on PyPI. + - name: CPython Issues + url: https://github.com/python/cpython/issues + about: For issues with the CPython interpreter itself. diff --git a/.github/ISSUE_TEMPLATE/feature_request.yml b/.github/ISSUE_TEMPLATE/feature_request.yml new file mode 100644 index 0000000000..7a7e9ec805 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/feature_request.yml @@ -0,0 +1,39 @@ +name: "Feature request" +description: Suggest an idea for the Python devguide +title: "Feature: <title>" +labels: ["type-feature"] +assignees: [] + +body: + - type: markdown + attributes: + value: | + > [!NOTE] + > This repo is for the [Python developer's guide](https://devguide.python.org/). + > If you are requesting an enhancement for the Python language or + > CPython interpreter, then use the + > [CPython issue tracker](https://github.com/python/cpython/issues) instead. + + - type: textarea + id: feature_description + attributes: + label: "Describe the enhancement or feature you would like" + description: A clear and concise description of what you want to happen. + validations: + required: true + + - type: textarea + id: alternatives + attributes: + label: "Describe alternatives you have considered" + description: A clear and concise description of any alternative solutions or features you have considered. + validations: + required: false + + - type: textarea + id: additional_context + attributes: + label: "Additional context" + description: Add any other context or screenshots about the feature request here. + validations: + required: false diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md new file mode 100644 index 0000000000..b1d63fbf36 --- /dev/null +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -0,0 +1,11 @@ +<!-- +Thanks for your contribution! +Please read this comment in its entirety. It's quite important. + +# Pull Request title + +It should describe the change to be made. + +Most PRs will require an issue number. Trivial changes, like fixing a typo, +do not need an issue. +--> diff --git a/.github/dependabot.yml b/.github/dependabot.yml new file mode 100644 index 0000000000..23f03616cf --- /dev/null +++ b/.github/dependabot.yml @@ -0,0 +1,23 @@ +version: 2 +updates: +- package-ecosystem: "github-actions" + directory: "/" + schedule: + interval: monthly + assignees: + - "ezio-melotti" + groups: + actions: + patterns: + - "*" + +- package-ecosystem: pip + directory: "/" + schedule: + interval: monthly + assignees: + - "ezio-melotti" + groups: + pip: + patterns: + - "*" diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml new file mode 100644 index 0000000000..b85a45c1bb --- /dev/null +++ b/.github/workflows/ci.yml @@ -0,0 +1,25 @@ +name: Tests + +on: [pull_request, push, workflow_dispatch] + +env: + FORCE_COLOR: 1 + +jobs: + test: + name: Check build, markup, and links + runs-on: ubuntu-latest + timeout-minutes: 10 + + steps: + - uses: actions/checkout@v6 + - uses: actions/setup-python@v6 + with: + python-version: "3" + - name: Install uv + uses: hynek/setup-cached-uv@v2 + - name: Build docs + run: make html + - name: Link check + run: make linkcheck + continue-on-error: true diff --git a/.github/workflows/lint.yml b/.github/workflows/lint.yml new file mode 100644 index 0000000000..4622f995aa --- /dev/null +++ b/.github/workflows/lint.yml @@ -0,0 +1,15 @@ +name: Lint + +on: [push, pull_request, workflow_dispatch] + +jobs: + lint: + runs-on: ubuntu-latest + timeout-minutes: 10 + + steps: + - uses: actions/checkout@v6 + - uses: actions/setup-python@v6 + with: + python-version: "3.x" + - uses: pre-commit/action@v3.0.1 diff --git a/.gitignore b/.gitignore index c74e78d0fa..f61a108300 100644 --- a/.gitignore +++ b/.gitignore @@ -9,6 +9,7 @@ __pycache__/ # Distribution / packaging .Python env/ +ENV/ venv/ build/ develop-eggs/ @@ -80,13 +81,14 @@ celerybeat-schedule # dotenv .env -# virtualenv -venv/ -ENV/ -venv/ - # Spyder project settings .spyderproject # Rope project settings .ropeproject + +# Generated CSV and SVG files +include/branches.csv +include/end-of-life.csv +_static/release-cycle.svg +_static/release-cycle-all.svg diff --git a/.hgignore b/.hgignore deleted file mode 100644 index 8e34d3d6a1..0000000000 --- a/.hgignore +++ /dev/null @@ -1,6 +0,0 @@ -syntax: glob - -*.swp -*~ -_build -venv diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml new file mode 100644 index 0000000000..c5beee4a37 --- /dev/null +++ b/.pre-commit-config.yaml @@ -0,0 +1,33 @@ +repos: + - repo: https://github.com/astral-sh/ruff-pre-commit + rev: v0.5.7 + hooks: + - id: ruff + name: Run Ruff (lint) + args: [--exit-non-zero-on-fix] + - id: ruff-format + name: Run Ruff (format) + + - repo: https://github.com/pre-commit/pre-commit-hooks + rev: v4.5.0 + hooks: + - id: check-case-conflict + - id: check-merge-conflict + - id: check-yaml + - id: debug-statements + - id: end-of-file-fixer + - id: trailing-whitespace + + - repo: https://github.com/sphinx-contrib/sphinx-lint + rev: v0.9.1 + hooks: + - id: sphinx-lint + args: [--enable=default-role] + + - repo: meta + hooks: + - id: check-hooks-apply + - id: check-useless-excludes + +ci: + autoupdate_schedule: quarterly diff --git a/.readthedocs.yml b/.readthedocs.yml new file mode 100644 index 0000000000..26e5be9672 --- /dev/null +++ b/.readthedocs.yml @@ -0,0 +1,21 @@ +# Read the Docs configuration file +# See https://docs.readthedocs.io/en/stable/config-file/v2.html for details +# Project page: https://readthedocs.org/projects/cpython-devguide/ + +version: 2 + +sphinx: + builder: dirhtml + configuration: conf.py + +build: + os: ubuntu-22.04 + tools: + python: "3" + + commands: + - asdf plugin add uv + - asdf install uv latest + - asdf global uv latest + - make dirhtml BUILDDIR=_readthedocs + - mv _readthedocs/dirhtml _readthedocs/html diff --git a/.ruff.toml b/.ruff.toml new file mode 100644 index 0000000000..af448e5b6e --- /dev/null +++ b/.ruff.toml @@ -0,0 +1,35 @@ +target-version = "py310" +fix = true +output-format = "full" +line-length = 88 + +[lint] +preview = true +select = [ + "C4", # flake8-comprehensions + "B", # flake8-bugbear + "E", # pycodestyle + "F", # pyflakes + "FA", # flake8-future-annotations + "FLY", # flynt + "FURB", # refurb + "G", # flake8-logging-format + "I", # isort + "ISC", # flake8-implicit-str-concat + "LOG", # flake8-logging + "PERF", # perflint + "PGH", # pygrep-hooks + "PT", # flake8-pytest-style + "TCH", # flake8-type-checking + "UP", # pyupgrade + "W", # pycodestyle + "YTT", # flake8-2020 +] +ignore = [ + "E501", # Ignore line length errors (we use auto-formatting) +] + +[format] +preview = true +quote-style = "preserve" +docstring-code-format = true diff --git a/.travis.yml b/.travis.yml deleted file mode 100644 index 5608206dfe..0000000000 --- a/.travis.yml +++ /dev/null @@ -1,16 +0,0 @@ -language: python -python: 3.6 -cache: pip - -install: python3 -m pip install -U pip -r requirements.txt - -jobs: - include: - - stage: build-docs - script: sphinx-build -n -W -q -b html -d _build/doctrees . _build/html - - - stage: link-check - script: sphinx-build -b linkcheck -d _build/doctrees . _build/linkcheck - - allow_failures: - - stage: link-check diff --git a/LICENSE b/LICENSE index 28289e8791..4594fb7384 100644 --- a/LICENSE +++ b/LICENSE @@ -113,4 +113,4 @@ Affirmer's express Statement of Purpose. CC0 or use of the Work. For more information, please see -<https://creativecommons.org/publicdomain/zero/1.0/> \ No newline at end of file +<https://creativecommons.org/publicdomain/zero/1.0/> diff --git a/Makefile b/Makefile index b9f2a0d9c7..a26ad48e00 100644 --- a/Makefile +++ b/Makefile @@ -2,144 +2,123 @@ # # You can set these variables from the command line. -PYTHON = python3 -SPHINXOPTS = -SPHINXBUILD = ./venv/bin/sphinx-build -PAPER = -BUILDDIR = _build +PYTHON = python3 +VENVDIR = ./venv +UV = uv +SPHINXBUILD = $(VENVDIR)/bin/sphinx-build +# Temporary: while we are using ..include:: to show the reorganization, +# there are duplicate labels. These cause warnings, which prevent the +# build from finishing. Turn off --fail-on-warning so we can see the +# finished results. +#SPHINXOPTS = --fail-on-warning +SPHINXOPTS = +BUILDDIR = _build +BUILDER = html +JOBS = auto +SPHINXLINT = $(VENVDIR)/bin/sphinx-lint +REQUIREMENTS = requirements.txt # Internal variables. -PAPEROPT_a4 = -D latex_paper_size=a4 -PAPEROPT_letter = -D latex_paper_size=letter -ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) . - -.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp \ - devhelp epub latex latexpdf text man changes linkcheck doctest check \ - serve +_ALL_SPHINX_OPTS = --jobs $(JOBS) $(SPHINXOPTS) +_RELEASE_CYCLE = include/branches.csv \ + include/end-of-life.csv \ + _static/release-cycle-all.svg \ + _static/release-cycle.svg +.PHONY: help help: @echo "Please use \`make <target>' where <target> is one of" + @echo " venv to create a venv with necessary tools" @echo " html to make standalone HTML files" - @echo " dirhtml to make HTML files named index.html in directories" - @echo " singlehtml to make a single large HTML file" - @echo " pickle to make pickle files" - @echo " json to make JSON files" - @echo " htmlhelp to make HTML files and a HTML help project" - @echo " qthelp to make HTML files and a qthelp project" - @echo " devhelp to make HTML files and a Devhelp project" - @echo " epub to make an epub" - @echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter" - @echo " latexpdf to make LaTeX files and run them through pdflatex" - @echo " text to make text files" - @echo " man to make manual pages" - @echo " changes to make an overview of all changed/added/deprecated items" @echo " linkcheck to check all external links for integrity" - @echo " doctest to run all doctests embedded in the documentation (if enabled)" + @echo " htmlview to open the index page built by the html target in your browser" + @echo " htmllive to rebuild and reload HTML files in your browser" + @echo " clean to remove the venv and build files" @echo " check to run a check for frequent markup errors" - @echo " serve to serve devguide on the localhost (8000)" + @echo " lint to lint all the files" -clean: +.PHONY: clean +clean: clean-venv -rm -rf $(BUILDDIR)/* + -rm -rf $(_RELEASE_CYCLE) + +.PHONY: clean-venv +clean-venv: + rm -rf $(VENVDIR) +.PHONY: venv venv: - $(PYTHON) -m venv venv - ./venv/bin/python3 -m pip install -r requirements.txt - -html: venv - $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html - @echo - @echo "Build finished. The HTML pages are in $(BUILDDIR)/html." - -dirhtml: venv - $(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml - @echo - @echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml." - -singlehtml: venv - $(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml - @echo - @echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml." - -pickle: venv - $(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle - @echo - @echo "Build finished; now you can process the pickle files." - -json: venv - $(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json - @echo - @echo "Build finished; now you can process the JSON files." - -htmlhelp: venv - $(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp - @echo - @echo "Build finished; now you can run HTML Help Workshop with the" \ - ".hhp project file in $(BUILDDIR)/htmlhelp." - -qthelp: venv - $(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp - @echo - @echo "Build finished; now you can run "qcollectiongenerator" with the" \ - ".qhcp project file in $(BUILDDIR)/qthelp, like this:" - @echo "# qcollectiongenerator $(BUILDDIR)/qthelp/PythonDevelopersGuide.qhcp" - @echo "To view the help file:" - @echo "# assistant -collectionFile $(BUILDDIR)/qthelp/PythonDevelopersGuide.qhc" - -devhelp: venv - $(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp - @echo - @echo "Build finished." - @echo "To view the help file:" - @echo "# mkdir -p $$HOME/.local/share/devhelp/PythonDevelopersGuide" - @echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/PythonDevelopersGuide" - @echo "# devhelp" - -epub: venv - $(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub - @echo - @echo "Build finished. The epub file is in $(BUILDDIR)/epub." - -latex: venv - $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex - @echo - @echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex." - @echo "Run \`make' in that directory to run these through (pdf)latex" \ - "(use \`make latexpdf' here to do that automatically)." - -latexpdf: venv - $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex - @echo "Running LaTeX files through pdflatex..." - make -C $(BUILDDIR)/latex all-pdf - @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex." - -text: venv - $(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text - @echo - @echo "Build finished. The text files are in $(BUILDDIR)/text." - -man: venv - $(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man - @echo - @echo "Build finished. The manual pages are in $(BUILDDIR)/man." - -changes: venv - $(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes - @echo - @echo "The overview file is in $(BUILDDIR)/changes." - -linkcheck: venv - $(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck - @echo - @echo "Link check complete; look for any errors in the above output " \ - "or in $(BUILDDIR)/linkcheck/output.txt." - -doctest: venv - $(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest - @echo "Testing of doctests in the sources finished, look at the " \ - "results in $(BUILDDIR)/doctest/output.txt." - -check: - $(PYTHON) tools/rstlint.py -i tools -i venv - -serve: html - tools/serve.py _build/html + @if [ -d $(VENVDIR) ] ; then \ + echo "venv already exists."; \ + echo "To recreate it, remove it first with \`make clean-venv'."; \ + else \ + $(MAKE) ensure-venv; \ + fi + +.PHONY: ensure-venv +ensure-venv: + @if [ ! -d $(VENVDIR) ] ; then \ + set -e; \ + echo "Creating venv in $(VENVDIR)"; \ + if $(UV) --version >/dev/null 2>&1; then \ + $(UV) venv --python=$(PYTHON) $(VENVDIR); \ + VIRTUAL_ENV=$(VENVDIR) $(UV) pip install -r $(REQUIREMENTS); \ + else \ + $(PYTHON) -m venv $(VENVDIR); \ + $(VENVDIR)/bin/python3 -m pip install --upgrade pip; \ + $(VENVDIR)/bin/python3 -m pip install -r $(REQUIREMENTS); \ + fi; \ + echo "The venv has been created in the $(VENVDIR) directory"; \ + fi + +.PHONY: htmlview +htmlview: html + $(PYTHON) -c "import os, webbrowser; webbrowser.open('file://' + os.path.realpath('_build/html/index.html'))" + +.PHONY: htmllive +htmllive: SPHINXBUILD = $(VENVDIR)/bin/sphinx-autobuild +# Arbitrarily selected ephemeral port between 49152–65535 +# to avoid conflicts with other processes: +htmllive: SPHINXOPTS = --open-browser --delay 0 --port 55301 +htmllive: html + +.PHONY: check +check: ensure-venv + # Ignore the tools and venv dirs and check that the default role is not used. + $(SPHINXLINT) -i tools -i $(VENVDIR) --enable default-role + +.PHONY: _ensure-package +_ensure-package: venv + if $(UV) --version >/dev/null 2>&1; then \ + VIRTUAL_ENV=$(VENVDIR) $(UV) pip install $(PACKAGE); \ + else \ + $(VENVDIR)/bin/python3 -m pip install $(PACKAGE); \ + fi + +.PHONY: _ensure-pre-commit +_ensure-pre-commit: + make _ensure-package PACKAGE=pre-commit + +.PHONY: lint +lint: _ensure-pre-commit + $(VENVDIR)/bin/python3 -m pre_commit run --all-files + +# Generate all release cycle files together with a single script invocation +# Use branches.csv as the primary target, others depend on it +include/branches.csv: + $(VENVDIR)/bin/python3 _tools/generate_release_cycle.py + @echo Release cycle data generated. + +# Other files are generated together with branches.csv +include/end-of-life.csv: include/branches.csv + @: +_static/release-cycle-all.svg: include/branches.csv + @: +_static/release-cycle.svg: include/branches.csv + @: + +# Catch-all target: route all unknown targets to Sphinx using the new +# "make mode" option. +.PHONY: Makefile +%: Makefile ensure-venv $(_RELEASE_CYCLE) + $(SPHINXBUILD) -M $@ "." "$(BUILDDIR)" $(_ALL_SPHINX_OPTS) diff --git a/README.rst b/README.rst index 2b4e26dd16..e2f0c5617c 100644 --- a/README.rst +++ b/README.rst @@ -1,15 +1,15 @@ The CPython Developer's Guide ============================= -|ReadTheDocs| |Zulip| |Codestyle| +|ReadTheDocs| |Discourse| |Codestyle| .. |ReadTheDocs| image:: https://readthedocs.org/projects/cpython-devguide/badge/ :target: https://devguide.python.org :alt: Documentation Status -.. |Zulip| image:: https://img.shields.io/badge/zulip-join_chat-brightgreen.svg - :alt: Python Zulip chat - :target: https://python.zulipchat.com +.. |Discourse| image:: https://img.shields.io/badge/discourse-join_chat-brightgreen.svg + :alt: Python Discourse chat + :target: https://discuss.python.org/ .. |Codestyle| image:: https://img.shields.io/badge/code%20style-black-000000.svg :target: https://github.com/psf/black @@ -17,16 +17,21 @@ The CPython Developer's Guide This guide covers how to contribute to CPython. It is known by the -nickname of "the devguide" by the Python core developers. +nickname of "the devguide" by the Python core team. The official home of this guide is https://devguide.python.org. -Compilation +Render HTML ----------- -For the compilation of the devguide, you need to use a version of Python which -supports the ``venv`` module, because the ``make html`` command will create a -virtual environment and will install the ``Sphinx`` package:: +To render the devguide to HTML under ``_build/html``, run:: make html +To render the devguide to HTML, and open the result in a browser, run:: + + make htmlview + +To maintain a live view of edits as they are saved, run:: + + make htmllive diff --git a/_static/activate_tab.js b/_static/activate_tab.js new file mode 100644 index 0000000000..8b5fcbabd9 --- /dev/null +++ b/_static/activate_tab.js @@ -0,0 +1,42 @@ +// Based on https://stackoverflow.com/a/38241481/724176 +function getOS() { + const userAgent = window.navigator.userAgent, + platform = + window.navigator?.userAgentData?.platform || window.navigator.platform, + macosPlatforms = ["macOS", "Macintosh", "MacIntel", "MacPPC", "Mac68K"], + windowsPlatforms = ["Win32", "Win64", "Windows", "WinCE"], + iosPlatforms = ["iPhone", "iPad", "iPod"]; + + if (macosPlatforms.includes(platform)) { + return "macOS"; + } else if (iosPlatforms.includes(platform)) { + return "iOS"; + } else if (windowsPlatforms.includes(platform)) { + return "Windows"; + } else if (/Android/.test(userAgent)) { + return "Android"; + } else if (/Linux/.test(platform)) { + return "Unix"; + } + + return "unknown"; +} + +function activateTab(tabName) { + // Find all label elements containing the specified tab name + const labels = document.querySelectorAll(".tab-label"); + + labels.forEach((label) => { + if (label.textContent.includes(tabName)) { + // Find the associated input element using the 'for' attribute + const tabInputId = label.getAttribute("for"); + const tabInput = document.getElementById(tabInputId); + + // Check if the input element exists before attempting to set the "checked" attribute + if (tabInput) { + // Activate the tab by setting its "checked" attribute to true + tabInput.checked = true; + } + } + }); +} diff --git a/_static/devguide_overrides.css b/_static/devguide_overrides.css new file mode 100644 index 0000000000..625a9dda2d --- /dev/null +++ b/_static/devguide_overrides.css @@ -0,0 +1,29 @@ +/* Style overrides for the devguide */ + +/* Make the site logo smaller */ +.sidebar-logo { + width: 111px; + height: 110px; +} + +.good pre { + border-left: 3px solid rgba(74, 182, 93, 1); +} +.bad pre { + border-left: 3px solid rgb(244, 76, 78); +} + +.extlink-cpy-file, +.extlink-gh-label { + border: 1px solid var(--color-background-border); + border-radius: .2em; + font-family: var(--font-stack--monospace); + font-size: var(--font-size--small--2); + padding: .1em .2em; +} + +/* Table cells should always top-align */ + +table.docutils td { + vertical-align: top; +} diff --git a/_static/favicon.png b/_static/favicon.png new file mode 100644 index 0000000000..462cfedd1f Binary files /dev/null and b/_static/favicon.png differ diff --git a/_static/og-image-200x200.png b/_static/og-image-200x200.png new file mode 100644 index 0000000000..0e80751e74 Binary files /dev/null and b/_static/og-image-200x200.png differ diff --git a/_static/psrt-coordinator-report.html b/_static/psrt-coordinator-report.html new file mode 100644 index 0000000000..d1e3c9d695 --- /dev/null +++ b/_static/psrt-coordinator-report.html @@ -0,0 +1,31 @@ +<!-- Centering a div --> +<div style="width: 100%; text-align: center;"> +<div style="display: inline-block; text-align: left;"> +<code><pre> + ┌────────────────────────┐ + │ Received a report... │ + └──┬──────────────────┬──┘ + │ │ +┌────────────▼──────────────┐ ┌─▼──────────┐ +│ ..via security@python.org │ │ ..via GHSA │ +└────────────┬──────────────┘ └─┬──────────┘ + │ │ +┌────────────▼──────────────┐ │ +│ PSRT admin reviews email │ │ +└───┬───────────────────┬───┘ │ + │ │ │ +┌───▼────┐ ┌────▼───┐ │ +│ Reject │ │ Accept │ │ +└────────┘ └────┬───┘ │ + │ │ +┌───────────────────────▼───┐ │ +│ PSRT asks reporter to │ │ +│ open via GHSA │ │ +└────────────┬──────────────┘ │ + │ │ + ┌──▼──────────────────▼──┐ + │ GHSA in state 'Triage' │ + └────────────────────────┘ +</pre></code> +</div> +</div> diff --git a/_static/psrt-coordinator-triage.html b/_static/psrt-coordinator-triage.html new file mode 100644 index 0000000000..af5936a6cb --- /dev/null +++ b/_static/psrt-coordinator-triage.html @@ -0,0 +1,40 @@ +<!-- Centering a div --> +<div style="width: 100%; text-align: center;"> +<div style="display: inline-block; text-align: left;"> +<code><pre> + ┌────────────────────────┐ + │ GHSA in state 'Triage' │ + └─┬────────────────────┬─┘ + │ │ +┌──────────────────▼─────────┐ ┌────────▼───────────────────┐ +│ │ │ After 3 days idle, │ +│ PSRT member volunteers │ │ Coordinator is assigned │ +│ as Coordinator │ │ automatically by bot │ +└──────────────────┬─────────┘ └────────┬───────────────────┘ + │ │ + ┌─▼────────────────────▼─┐ + │ GHSA update 'Credit' │ + │ field to Coordinator │ + └────────────┬───────────┘ + │ + ┌────────────▼───────────┐ + │ Coordinator determines │ + ┌───┤ whether report... ┼───┐ + │ └────────────┬───────────┘ │ + │ │ │ +┌────────────▼─┐ ┌────────────▼───────────┐ ┌─▼─────────────┐ +│..is a invalid│ │ ..is a bug, but not │ │..is a security│ +│ or non-issue│ │ security relevant │ │ issue │ +└────────────┬─┘ └────────────┬───────────┘ └─┬─────────────┘ + │ │ │ + │ ┌────────────▼───────────┐ │ + │ │ Coordinator opens a │ │ + │ │ public GitHub issue │ │ + │ └─┬──────────────────────┘ │ + │ │ │ + ┌──────────▼─────▼───────┐ ┌────────────▼───────────┐ + │ Close the GHSA ticket │ │ GHSA in state 'Draft' │ + └────────────────────────┘ └────────────────────────┘ +</pre></code> +</div> +</div> diff --git a/_static/python-logo.svg b/_static/python-logo.svg new file mode 100644 index 0000000000..f69d24a746 --- /dev/null +++ b/_static/python-logo.svg @@ -0,0 +1,18 @@ +<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110.4 109.8"> + <defs> + <linearGradient id="Y" x1="89.1" x2="147.8" y1="111.9" y2="168.1" gradientUnits="userSpaceOnUse"> + <stop offset="0" stop-color="#ffe052"/> + <stop offset="1" stop-color="#ffc331"/> + </linearGradient> + <linearGradient id="B" x1="55.5" x2="110.1" y1="77.1" y2="131.9" gradientUnits="userSpaceOnUse"> + <stop offset="0" stop-color="#387eb8"/> + <stop offset="1" stop-color="#366994"/> + </linearGradient> + </defs> + <path fill="url(#B)" + d="M99.8 67.5c-28 0-26.3 12.1-26.3 12.1v12.6h26.8V96H62.9s-18-2-18 26.3 15.7 27.2 15.7 27.2h9.3v-13s-.5-15.7 15.4-15.7H112s14.9.2 14.9-14.5V82.1s2.2-14.6-27-14.6zM85 75.9a4.8 4.8 0 1 1 0 9.7 4.8 4.8 0 1 1 0-9.7z" + transform="translate(-45 -67.5)"/> + <path fill="url(#Y)" + d="M100.5 177.3c28 0 26.3-12.1 26.3-12.1v-12.6H100v-3.8h37.4s18 2 18-26.3-15.7-27.2-15.7-27.2h-9.3v13s.5 15.7-15.4 15.7H88.4s-14.9-.2-14.9 14.4v24.3s-2.2 14.6 27 14.6zm14.8-8.5a4.8 4.8 0 1 1 0-9.6 4.8 4.8 0 1 1 0 9.6z" + transform="translate(-45 -67.5)"/> +</svg> diff --git a/_templates/page.html b/_templates/page.html new file mode 100644 index 0000000000..d1c9a515a4 --- /dev/null +++ b/_templates/page.html @@ -0,0 +1,8 @@ +{% extends "!page.html" %} + +{% block extrahead %} +{{ super() }} +{% if not is_deployment_preview %} +<script defer data-domain="devguide.python.org" src="https://analytics.python.org/js/script.outbound-links.js"></script> +{% endif %} +{% endblock %} diff --git a/_tools/generate_release_cycle.py b/_tools/generate_release_cycle.py new file mode 100644 index 0000000000..24dfa03e74 --- /dev/null +++ b/_tools/generate_release_cycle.py @@ -0,0 +1,218 @@ +"""Read in a JSON and generate two CSVs and an SVG file.""" + +from __future__ import annotations + +import argparse +import calendar +import csv +import datetime as dt +import json +from functools import cache +from pathlib import Path +from urllib.request import urlopen + +import jinja2 + + +def csv_date(date_str: str, now_str: str) -> str: + """Format a date for CSV.""" + if date_str > now_str: + # Future, add italics + return f"*{date_str}*" + return date_str + + +def parse_date(date_str: str, *, last: bool = False) -> dt.date: + if len(date_str) == len("yyyy-mm"): + # We need a full yyyy-mm-dd, so let's approximate + if last: + # Last day of month + year, month = map(int, date_str.split("-")) + last_day = calendar.monthrange(year, month)[1] + return dt.date(year, month, last_day) + else: + return dt.date.fromisoformat(date_str + "-01") + + return dt.date.fromisoformat(date_str) + + +def parse_version(ver: str) -> list[int]: + return [int(i) for i in ver["key"].split(".")] + + +@cache +def get_versions() -> dict[str, dict[str, str | int]]: + with urlopen("https://peps.python.org/api/release-cycle.json") as in_file: + return json.loads(in_file.read().decode("utf-8")) + + +class Versions: + """For converting JSON to CSV and SVG.""" + + def __init__(self, *, limit_to_active=False, special_py27=False) -> None: + self.versions = get_versions() + + # Generate a few additional fields + for key, version in self.versions.items(): + version["key"] = key + ver_info = parse_version(version) + if ver_info >= [3, 13]: + full_years = 2 + else: + full_years = 1.5 + version["first_release_date"] = r1 = parse_date(version["first_release"]) + version["start_security_date"] = r1 + dt.timedelta(days=full_years * 365) + version["end_of_life_date"] = parse_date(version["end_of_life"], last=True) + + self.cutoff = min(ver["first_release_date"] for ver in self.versions.values()) + + if limit_to_active: + self.cutoff = min( + version["first_release_date"] + for version in self.versions.values() + if version["status"] != "end-of-life" + ) + self.versions = { + key: version + for key, version in self.versions.items() + if version["end_of_life_date"] >= self.cutoff + or (special_py27 and key == "2.7") + } + if special_py27: + self.cutoff = min(self.cutoff, dt.date(2019, 8, 1)) + self.id_key = "active" + else: + self.id_key = "all" + + self.sorted_versions = sorted( + self.versions.values(), + key=parse_version, + reverse=True, + ) + + # Set the row (Y coordinate) for the chart, to allow a gap between 2.7 + # and the rest + y = len(self.sorted_versions) + (1 if special_py27 else 0) + for version in self.sorted_versions: + if special_py27 and version["key"] == "2.7": + y -= 1 + version["y"] = y + y -= 1 + + def write_csv(self) -> None: + """Output CSV files.""" + now_str = str(dt.datetime.now(dt.timezone.utc)) + + versions_by_category = {"branches": {}, "end-of-life": {}} + headers = None + for details in self.sorted_versions: + row = { + "Branch": details["branch"], + "Schedule": f":pep:`{details['pep']}`", + "Status": details["status"], + "First release": csv_date(details["first_release"], now_str), + "End of life": csv_date(details["end_of_life"], now_str), + "Release manager": details["release_manager"], + } + headers = row.keys() + cat = "end-of-life" if details["status"] == "end-of-life" else "branches" + versions_by_category[cat][details["key"]] = row + + for cat, versions in versions_by_category.items(): + with open(f"include/{cat}.csv", "w", encoding="UTF-8", newline="") as file: + csv_file = csv.DictWriter(file, fieldnames=headers, lineterminator="\n") + csv_file.writeheader() + csv_file.writerows(versions.values()) + + def write_svg(self, today: str, out_path: str) -> None: + """Output SVG file.""" + env = jinja2.Environment( + loader=jinja2.FileSystemLoader("_tools/"), + autoescape=True, + lstrip_blocks=True, + trim_blocks=True, + undefined=jinja2.StrictUndefined, + ) + template = env.get_template("release_cycle_template.svg.jinja") + + # Scale. Should be roughly the pixel size of the font. + # All later sizes are multiplied by this, so you can think of all other + # numbers being multiples of the font size, like using `em` units in + # CSS. + # (Ideally we'd actually use `em` units, but SVG viewBox doesn't take + # those.) + + # Uppercase sizes are un-scaled + SCALE = 18 + + # Width of the drawing and main parts + DIAGRAM_WIDTH = 46 + LEGEND_WIDTH = 7 + RIGHT_MARGIN = 0.5 + + # Height of one line. If you change this you'll need to tweak + # some positioning numbers in the template as well. + LINE_HEIGHT = 1.5 + + first_date = self.cutoff + last_date = max(ver["end_of_life_date"] for ver in self.sorted_versions) + + def date_to_x(date: dt.date) -> float: + """Convert datetime.date to an SVG X coordinate""" + num_days = (date - first_date).days + total_days = (last_date - first_date).days + ratio = num_days / total_days + x = ratio * (DIAGRAM_WIDTH - LEGEND_WIDTH - RIGHT_MARGIN) + return (x + LEGEND_WIDTH) * SCALE + + def year_to_x(year: int) -> float: + """Convert year number to an SVG X coordinate of 1st January""" + return date_to_x(dt.date(year, 1, 1)) + + def format_year(year: int) -> str: + """Format year number for display""" + return f"'{year % 100:02}" + + with open(out_path, "w", encoding="UTF-8", newline="\n") as f: + template.stream( + SCALE=SCALE, + diagram_width=DIAGRAM_WIDTH * SCALE, + diagram_height=(self.sorted_versions[0]["y"] + 2) * LINE_HEIGHT * SCALE, + years=range(first_date.year, last_date.year + 1), + line_height=LINE_HEIGHT * SCALE, + legend_width=LEGEND_WIDTH * SCALE, + right_margin=RIGHT_MARGIN * SCALE, + versions=list(reversed(self.sorted_versions)), + today=dt.datetime.strptime(today, "%Y-%m-%d").date(), + year_to_x=year_to_x, + date_to_x=date_to_x, + format_year=format_year, + id_key=self.id_key, + ).dump(f) + + +def main() -> None: + parser = argparse.ArgumentParser( + description=__doc__, formatter_class=argparse.ArgumentDefaultsHelpFormatter + ) + parser.add_argument( + "--today", + default=str(dt.date.today()), + metavar=" YYYY-MM-DD", + help="Override today for testing", + ) + args = parser.parse_args() + + versions = Versions() + assert len(versions.versions) > 10 + Path("include").mkdir(exist_ok=True) + + versions.write_csv() + versions.write_svg(args.today, "_static/release-cycle-all.svg") + + versions = Versions(limit_to_active=True, special_py27=True) + versions.write_svg(args.today, "_static/release-cycle.svg") + + +if __name__ == "__main__": + main() diff --git a/_tools/release_cycle_template.svg.jinja b/_tools/release_cycle_template.svg.jinja new file mode 100644 index 0000000000..ffc54919e7 --- /dev/null +++ b/_tools/release_cycle_template.svg.jinja @@ -0,0 +1,317 @@ +<?xml version="1.0" encoding="UTF-8"?> +<svg + xmlns="http://www.w3.org/2000/svg" + class="release-cycle-chart" + viewBox="0 0 {{ diagram_width }} {{ diagram_height }}" +> + <style> + /* Embedded styles for standalone viewing */ + .release-cycle-chart { + color-scheme: light; + + {# Copy vars from Furo theme if present #} + {% for varname, default in { + 'color-foreground-primary': 'light-dark(#333, #fff)', + 'color-background-primary': 'light-dark(#fff, #333)', + 'color-brand-primary': '#4B8BBE', + 'color-background-item': '#e0e0e0', + }.items() %} + --svg-{{varname}}: var(--{{varname}}, {{default}}); + {% endfor %} + + font-family: var( + --font-stack, + -apple-system, BlinkMacSystemFont, Segoe UI, Helvetica, + Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji); + width: 100%; + + --blob-border-width: 1.6px; + + --status-bg-color: #CCC; + --status-border-color: #888; + } + .background { + fill: var(--svg-color-background-primary); + } + .release-cycle-year-line { + stroke: var(--svg-color-foreground-primary); + stroke-width: 0.8px; + opacity: 75%; + } + .release-cycle-today-line { + stroke: var(--svg-color-brand-primary); + stroke-width: var(--blob-border-width); + } + .release-cycle-row-shade { + fill: var(--svg-color-background-item); + opacity: 50%; + } + .release-cycle-blob { + stroke-width: var(--blob-border-width); + } + .text-main { + fill: var(--svg-color-foreground-primary); + + /* use specific colours on known backgrounds */ + &.release-cycle-status-security, + &.release-cycle-status-bugfix { + fill: black; + } + } + .text-outline { + /* an outline of the background color, in case it's not set + correctly */ + fill: transparent; + stroke: var(--svg-color-background-primary); + stroke-width: var(--blob-border-width); + + /* use specific colours on known backgrounds */ + &.release-cycle-status-security, + &.release-cycle-status-bugfix { + stroke: var(--status-bg-color); + } + } + .release-cycle-status-end-of-life { + --status-bg-color: #DD2200; + --status-border-color: #FF8888; + } + .release-cycle-status-security { + --status-bg-color: #FFDD44; + --status-border-color: #FF8800; + } + .release-cycle-status-bugfix { + --status-bg-color: #00DD22; + --status-border-color: #008844; + } + .release-cycle-status-prerelease { + --status-bg-color: teal; + --status-border-color: darkgreen; + } + .release-cycle-status-feature { + --status-bg-color: #2222EE; + --status-border-color: #008888; + } + .release-cycle-status-planned { + /* Use grey defaults */ + } + .release-cycle-blob { + fill: var(--status-bg-color); + stroke: transparent; + } + .release-cycle-blob-full { + fill: var(--status-bg-color); + stroke: var(--status-border-color); + } + .release-cycle-border { + fill: transparent; + stroke: var(--status-border-color); + stroke-width: var(--blob-border-width); + } + </style> + <defs> + <linearGradient id="release-cycle-mask-gradient-{{ id_key }}"> + <stop stop-color="black" offset="0%" /> + <stop stop-color="white" offset="100%" /> + </linearGradient> + </defs> + + <rect + class="background" + x="0" + y="0" + width="{{ diagram_width }}" + height="{{ diagram_height }}" + /> + + {% for version in versions %} + {% set y = version.y * line_height %} + {% if version.y % 2 %} + <!-- Row shading --> + <rect + class="release-cycle-row-shade" + x="0em" + y="{{ y - 1.125 * SCALE }}" + width="{{ diagram_width }}" + height="{{ line_height }}" + /> + {% endif %} + {% endfor %} + + {% for year in years %} + <text + class="release-cycle-year-text text-main" + x="{{ (year_to_x(year) + year_to_x(year + 1)) / 2 }}" + y="{{ diagram_height - line_height }}" + font-size="{{ SCALE * 0.75 }}" + text-anchor="middle" + > + {{ format_year(year) }} + </text> + {% if not loop.last %} + <line + class="release-cycle-year-line" + x1="{{ year_to_x(year + 1) }}" + x2="{{ year_to_x(year + 1) }}" + y1="0" + y2="{{ diagram_height - line_height }}" + font-size="{{ SCALE }}" + /> + {% endif %} + {% endfor %} + + <!-- Gradient mask to fade out end-of-life versions --> + <mask id="release-cycle-mask-{{ id_key }}"> + <rect + x="0" + y="0" + width="{{ legend_width }}" + height="{{ diagram_height }}" + fill="black" + /> + <rect + x="{{ legend_width - right_margin }}" + y="0" + width="{{ right_margin }}" + height="{{ diagram_height }}" + fill="url(#release-cycle-mask-gradient-{{ id_key }})" + /> + <rect + x="{{ legend_width }}" + y="0" + width="{{ diagram_width }}" + height="{{ diagram_height }}" + fill="white" + /> + </mask> + + {% for version in versions %} + <!-- Colourful blob. --> + + {% set top_y = version.y * line_height - 1 * SCALE %} + {% set height = 1.25 * SCALE %} + {% set start_x = date_to_x(version.first_release_date) %} + {% set end_x = date_to_x(version.end_of_life_date) %} + {% set radius = 0.25 * SCALE %} + + <!-- bugfix/security blobs need to be split between the two phases. + Draw the rectangle with two path elements instead. + Thanks Claude.ai for the initial conversion. + --> + {% set middle_x = ([end_x, date_to_x(version.start_security_date)]|min) %} + {% set left_width = (middle_x - start_x) %} + {% set right_width = (end_x - middle_x) %} + + {% if version.status != "end-of-life" %} + <!-- Split the blob using path operations + (Move-to, Vertical/Horizontal, Arc, Z=close shape; + lowercase means relative to the last point.) + We start drawing from the top of the straight boundary + between the half-blobs. + --> + <path + class="release-cycle-blob release-cycle-status-bugfix" + d=" + M{{ middle_x }},{{ top_y }} {#- start -#} + v{{ height }} {#- down -#} + H{{ start_x + radius }} {#- left -#} + a{{ radius }},{{ radius }} 90 0 1 {#- rounded corner -#} + {{ -radius }} {{ -radius }} + v{{ -height + 2*radius }} {#- up -#} + a{{ radius }},{{ radius }} 90 0 1 {#- rounded corner -#} + {{ radius }} {{ -radius }} + Z {#- right -#} + " + /> + <path + class="release-cycle-blob release-cycle-status-security" + d=" + M{{ middle_x }},{{ top_y }} {#- start -#} + v{{ height }} {#- down -#} + H{{ end_x - radius }} {#- right -#} + a{{ radius }},{{ radius }} 90 0 0 {#- rounded corner -#} + {{ radius }} {{ -radius }} + v{{ -height + 2*radius }} {#- up -#} + a{{ radius }},{{ radius }} 90 0 0 {#- rounded corner -#} + {{ -radius }} {{ -radius }} + Z {#- left -#} + " + /> + <!-- Add a common border --> + <rect + class="release-cycle-border release-cycle-status-{{ version.status }}" + x="{{ start_x }}" + y="{{ top_y }}" + width="{{ (end_x - start_x) }}" + height="{{ height }}" + rx="{{ radius }}" + ry="{{ radius }}" + /> + {% else %} + <!-- For EOL releases, use a single rounded rectangle --> + <rect + class="release-cycle-blob release-cycle-blob-full + release-cycle-status-{{ version.status }}" + x="{{ start_x }}" + y="{{ top_y }}" + width="{{ (end_x - start_x) }}" + height="{{ height }}" + rx="{{ radius }}" + ry="{{ radius }}" + mask="url(#release-cycle-mask-{{ id_key }})" + /> + {% endif %} + {% endfor %} + + <!-- A line for today --> + <line + class="release-cycle-today-line" + x1="{{ date_to_x(today) }}" + x2="{{ date_to_x(today) }}" + y1="0" + y2="{{ diagram_height - line_height }}" + font-size="{{ SCALE }}" + /> + + {% for version in versions %} + <!-- Label for colourful blob --> + + {% set start_x = date_to_x(version.first_release_date) %} + {% set end_x = date_to_x(version.end_of_life_date) %} + {% set middle_x = ([end_x, date_to_x(version.start_security_date)]|min) %} + {% set small_text_y = version.y * line_height - 0.1 * SCALE %} + + <!-- Add text before/after/inside the blob --> + {% for cls in ('text-outline', 'text-main') %} + <text + class="release-cycle-blob-label {{cls}} release-cycle-status-{{ version.status }}" + font-size="{{ SCALE * 0.75 }}" + y="{{ small_text_y }}" + {% if version.status == "bugfix" %} + x="{{ (start_x + middle_x) / 2 }}" + text-anchor="middle" + {% elif version.status == "security" %} + x="{{ (middle_x + end_x) / 2 }}" + text-anchor="middle" + {% elif version.status == "end-of-life" %} + x="{{ end_x + (0.25 * SCALE) }}" + text-anchor="start" + {% else %} + x="{{ start_x - (0.25 * SCALE) }}" + text-anchor="end" + {% endif %} + > + {{ version.status }} + </text> + {% endfor %} + + <!-- Legend on the left --> + <text + class="release-cycle-version-label text-main" + x="{{ 0.5 * SCALE }}" + y="{{ version.y * line_height }}" + font-size="{{ SCALE }}" + > + Python {{ version.key }} + </text> + {% endfor %} +</svg> diff --git a/appendix.rst b/appendix.rst deleted file mode 100644 index f2db2ac2e1..0000000000 --- a/appendix.rst +++ /dev/null @@ -1,67 +0,0 @@ -Appendix: Topics -================ - -Basics for contributors ------------------------ - -.. note:: **Recommended reading** - - - :doc:`setup` - - :doc:`pullrequest` - -* :doc:`help` -* :doc:`communication` - -Core developers ---------------- - -.. note:: **Recommended reading** - - * :doc:`setup` - * :doc:`pullrequest` - * :doc:`committing` - -* :doc:`coredev` -* :doc:`developers` -* :doc:`motivations` -* :doc:`experts` - -Development workflow for contributors -------------------------------------- - -* :doc:`devcycle` -* :doc:`pullrequest` -* :doc:`fixingissues` - -Documenting Python and style guide ----------------------------------- - -* :doc:`docquality` -* :doc:`documenting` - -Issue tracking and triaging ---------------------------- - -* :doc:`tracker` -* :doc:`triaging` - -Language development in depth ------------------------------ - -* :doc:`exploring` -* :doc:`grammar` -* :doc:`compiler` -* :doc:`stdlibchanges` -* :doc:`langchanges` -* :doc:`porting` - -Testing and continuous integration ----------------------------------- - -* :doc:`runtests` -* :doc:`coverage` -* :doc:`silencewarnings` -* :doc:`buildbots` -* :doc:`buildworker` -* :doc:`coverity` - \ No newline at end of file diff --git a/buildbots.rst b/buildbots.rst deleted file mode 100644 index c37b1355bc..0000000000 --- a/buildbots.rst +++ /dev/null @@ -1,236 +0,0 @@ -.. _buildbots: - -Continuous Integration -====================== - -.. highlight:: bash - -To assert that there are no regressions in the :doc:`development and maintenance -branches <devcycle>`, Python has a set of dedicated machines (called *buildbots* -or *build workers*) used for continuous integration. They span a number of -hardware/operating system combinations. Furthermore, each machine hosts -several *builders*, one per active branch: when a new change is pushed -to this branch on the public `GitHub repository <https://github.com/python/cpython>`_, all corresponding builders -will schedule a new build to be run as soon as possible. - -The build steps run by the buildbots are the following: - -* Checkout of the source tree for the changeset which triggered the build -* Compiling Python -* Running the test suite using :ref:`strenuous settings <strenuous_testing>` -* Cleaning up the build tree - -It is your responsibility, as a core developer, to check the automatic -build results after you push a change to the repository. It is therefore -important that you get acquainted with the way these results are presented, -and how various kinds of failures can be explained and diagnosed. - -Checking results of automatic builds ------------------------------------- - -There are three ways of visualizing recent build results: - -* The Web interface for each branch at https://www.python.org/dev/buildbot/, - where the so-called "waterfall" view presents a vertical rundown of recent - builds for each builder. When interested in one build, you'll have to - click on it to know which changesets it corresponds to. Note that - the buildbot web pages are often slow to load, be patient. - -* The command-line ``bbreport.py`` client, which you can get from - https://code.google.com/archive/p/bbreport. Installing it is trivial: just add - the directory containing ``bbreport.py`` to your system path so that - you can run it from any filesystem location. For example, if you want - to display the latest build results on the development ("master") branch, - type:: - - bbreport.py -q 3.x - -* The buildbot "console" interface at http://buildbot.python.org/all/#/console - This works best on a wide, high resolution - monitor. Clicking on the colored circles will allow you to open a new page - containing whatever information about that particular build is of interest to - you. You can also access builder information by clicking on the builder - status bubbles in the top line. - -If you like IRC, having an IRC client open to the #python-dev channel on -irc.freenode.net is useful. Any time a builder changes state (last build -passed and this one didn't, or vice versa), a message is posted to the channel. -Keeping an eye on the channel after pushing a changeset is a simple way to get -notified that there is something you should look in to. - -Some buildbots are much faster than others. Over time, you will learn which -ones produce the quickest results after a build, and which ones take the -longest time. - -Also, when several changesets are pushed in a quick succession in the same -branch, it often happens that a single build is scheduled for all these -changesets. - -Stability ---------- - -A subset of the buildbots are marked "stable". They are taken into account -when making a new release. The rule is that all stable builders must be free of -persistent failures when the release is cut. It is absolutely **vital** -that core developers fix any issue they introduce on the stable buildbots, -as soon as possible. - -This does not mean that other builders' test results can be taken lightly, -either. Some of them are known for having platform-specific issues that -prevent some tests from succeeding (or even terminating at all), but -introducing additional failures should generally not be an option. - -Flags-dependent failures ------------------------- - -Sometimes, while you have run the :doc:`whole test suite <runtests>` before -committing, you may witness unexpected failures on the buildbots. One source -of such discrepancies is if different flags have been passed to the test runner -or to Python itself. To reproduce, make sure you use the same flags as the -buildbots: they can be found out simply by clicking the **stdio** link for -the failing build's tests. For example:: - - ./python.exe -Wd -E -bb ./Lib/test/regrtest.py -uall -rwW - -.. note:: - Running ``Lib/test/regrtest.py`` is exactly equivalent to running - ``-m test``. - -Ordering-dependent failures ---------------------------- - -Sometimes the failure is even subtler, as it relies on the order in which -the tests are run. The buildbots *randomize* test order (by using the ``-r`` -option to the test runner) to maximize the probability that potential -interferences between library modules are exercised; the downside is that it -can make for seemingly sporadic failures. - -The ``--randseed`` option makes it easy to reproduce the exact randomization -used in a given build. Again, open the ``stdio`` link for the failing test -run, and check the beginning of the test output proper. - -Let's assume, for the sake of example, that the output starts with: - -.. code-block:: none - :emphasize-lines: 6 - - ./python -Wd -E -bb Lib/test/regrtest.py -uall -rwW - == CPython 3.3a0 (default:22ae2b002865, Mar 30 2011, 13:58:40) [GCC 4.4.5] - == Linux-2.6.36-gentoo-r5-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_4400+-with-gentoo-1.12.14 little-endian - == /home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/build/test_python_29628 - Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, verbose=0, bytes_warning=2, quiet=0) - Using random seed 2613169 - [ 1/353] test_augassign - [ 2/353] test_functools - -You can reproduce the exact same order using:: - - ./python -Wd -E -bb -m test -uall -rwW --randseed 2613169 - -It will run the following sequence (trimmed for brevity): - -.. code-block:: none - - [ 1/353] test_augassign - [ 2/353] test_functools - [ 3/353] test_bool - [ 4/353] test_contains - [ 5/353] test_compileall - [ 6/353] test_unicode - -If this is enough to reproduce the failure on your setup, you can then -bisect the test sequence to look for the specific interference causing the -failure. Copy and paste the test sequence in a text file, then use the -``--fromfile`` (or ``-f``) option of the test runner to run the exact -sequence recorded in that text file:: - - ./python -Wd -E -bb -m test -uall -rwW --fromfile mytestsequence.txt - -In the example sequence above, if ``test_unicode`` had failed, you would -first test the following sequence: - -.. code-block:: none - - [ 1/353] test_augassign - [ 2/353] test_functools - [ 3/353] test_bool - [ 6/353] test_unicode - -And, if it succeeds, the following one instead (which, hopefully, shall -fail): - -.. code-block:: none - - [ 4/353] test_contains - [ 5/353] test_compileall - [ 6/353] test_unicode - -Then, recursively, narrow down the search until you get a single pair of -tests which triggers the failure. It is very rare that such an interference -involves more than **two** tests. If this is the case, we can only wish you -good luck! - -.. note:: - You cannot use the ``-j`` option (for parallel testing) when diagnosing - ordering-dependent failures. Using ``-j`` isolates each test in a - pristine subprocess and, therefore, prevents you from reproducing any - interference between tests. - - -Transient failures ------------------- - -While we try to make the test suite as reliable as possible, some tests do -not reach a perfect level of reproducibility. Some of them will sometimes -display spurious failures, depending on various conditions. Here are common -offenders: - -* Network-related tests, such as ``test_poplib``, ``test_urllibnet``, etc. - Their failures can stem from adverse network conditions, or imperfect - thread synchronization in the test code, which often has to run a - server in a separate thread. - -* Tests dealing with delicate issues such as inter-thread or inter-process - synchronization, or Unix signals: ``test_multiprocessing``, - ``test_threading``, ``test_subprocess``, ``test_threadsignals``. - -When you think a failure might be transient, it is recommended you confirm by -waiting for the next build. Still, even if the failure does turn out sporadic -and unpredictable, the issue should be reported on the bug tracker; even -better if it can be diagnosed and suppressed by fixing the test's -implementation, or by making its parameters - such as a timeout - more robust. - - -Custom builders ---------------- - -.. highlight:: console - -When working on a platform-specific issue, you may want to test your changes on -the buildbot fleet rather than just on Travis and AppVeyor. To do so, you can -make use of the `custom builders -<http://buildbot.python.org/all/#/builders?tags=custom.unstable&tags=custom.stable>`_. -These builders track the ``buildbot-custom`` short-lived branch of the -``python/cpython`` repository, which is only accessible to core developers. - -To start a build on the custom builders, push the commit you want to test to -the ``buildbot-custom`` branch:: - - $ git push upstream <local_branch_name>:buildbot-custom - -You may run into conflicts if another developer is currently using the custom -builders or forgot to delete the branch when they finished. In that case, make -sure the other developer is finished and either delete the branch or force-push -(add the ``-f`` option) over it. - -When you have gotten the results of your tests, delete the branch:: - - $ git push upstream :buildbot-custom # or use the GitHub UI - -If you are interested in the results of a specific test file only, we -recommend you change (temporarily, of course) the contents of the -``buildbottest`` clause in ``Makefile.pre.in``; or, for Windows builders, -the ``Tools/buildbot/test.bat`` script. - -.. seealso:: - :ref:`buildworker` diff --git a/buildworker.rst b/buildworker.rst deleted file mode 100644 index 3e5deabe1f..0000000000 --- a/buildworker.rst +++ /dev/null @@ -1,353 +0,0 @@ - -.. _buildworker: - -Running a buildbot worker -========================= - -.. highlight:: bash - -Python's :ref:`buildbots` system was discussed earlier. We sometimes refer to -the collection of *build workers* as our "buildbot fleet". The machines that -comprise the fleet are voluntarily contributed resources. Many are run by -individual volunteers out of their own pockets and time, while others are -supported by corporations. Even the corporate sponsored buildbots, however, -tend to exist because some individual championed them, made them a reality, and -is committed to maintaining them. - -Anyone can contribute a buildbot to the fleet. This chapter describes how -to go about setting up a buildbot worker, getting it added, and some hints about -buildbot maintenance. - -Anyone running a buildbot that is part of the fleet should subscribe to the -`python-buildbots <https://mail.python.org/mailman/listinfo/python-buildbots>`_ -mailing list. This mailing list is also the place to contact if you want to -contribute a buildbot but have questions. - -As for what kind of buildbot to run...take a look at our `current fleet -<http://buildbot.python.org/all/#/workers>`_. Pretty much anything that isn't -on that list would be interesting: different Linux/UNIX distributions, -different versions of the various OSes, other OSes if you or someone are -prepared to make the test suite actually pass on that new OS. Even if you only -want to run an OS that's already on our list there may be utility in setting it -up; we also need to build and test python under various alternate build -configurations. Post to the mailing list and talk about what you'd like to -contribute. - - -Preparing for buildbot worker setup ------------------------------------ - -Since the goal is to build Python from source, the system will need to have -everything required to do normal python development: a compiler, a linker, and -(except on windows) the "development" headers for any of the optional modules -(zlib, OpenSSL, etc) supported by the platform. Follow the steps outlined in -:ref:`setup` for the target platform, all the way through to having a working -compiled python. - -In order to set up the buildbot software, you will need to obtain an identifier -and password for your worker so it can join the fleet. Email -python-buildbots@python.org to discuss adding your worker and to obtain the -needed workername and password. You can do some of the steps that follow -before having the credentials, but it is easiest to have them before -the "buildbot worker" step below. - - -Setting up the buildbot worker ------------------------------- - -Conventional always-on machines -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You need a recent version of the `buildbot <https://buildbot.net/>`_ software, -and you will probably want a separate 'buildbot' user to run the buildbot -software. You may also want to set the buildbot up using a virtual -environment, depending on how you manage your system. We won't cover how to that -here; it doesn't differ from setting up a virtual environment for any other -software, but you'll need to modify the sequence of steps below as appropriate -if you choose that path. - -For Linux: - - * If your package manager provides the buildbot worker software, that is - probably the best way to install it; it may create the buildbot user for - you, in which case you can skip that step. Otherwise, do ``pip install - buildbot-worker``. - * Create a ``buildbot`` user (using, eg: ``useradd``) if necessary. - * Log in as the buildbot user. - -For Mac: - - * Create a buildbot user using the OS/X control panel user admin. It - should be a "standard" user. - * Log in as the buildbot user. - * Install the buildbot worker [#]_ by running ``pip install buildbot-worker``. - -For Windows: - - * Create a buildbot user as a "standard" user. - * Install the latest version of Python from python.org. - * Open a Command Prompt. - * Execute ``python -m pip install pypiwin32 buildbot-worker`` (note that - ``python.exe`` is not added to ``PATH`` by default, making the - ``python`` command accessible is left as an exercise for the user). - -In a terminal window for the buildbot user, issue the following commands (you -can put the ``buildarea`` wherever you want to):: - - mkdir buildarea - buildbot-worker create-worker buildarea buildbot.python.org:9020 workername workerpasswd - -(Note that on Windows, the ``buildbot-worker`` command will be in the -:file:`Scripts` directory of your Python installation.) - -Once this initial worker setup completes, you should edit the files -``buildarea/info/admin`` and ``buildarea/info/host`` to provide your contact -info and information on the host configuration, respectively. This information -will be presented in the buildbot web pages that display information about the -builders running on your worker. - -You will also want to make sure that the worker is started when the -machine reboots: - -For Linux: - - * Add the following line to ``/etc/crontab``:: - - @reboot buildbot-worker restart /path/to/buildarea - - Note that we use ``restart`` rather than ``start`` in case a crash has - left a ``twistd.pid`` file behind. - -For OSX: - - * Create a bin directory for your buildbot user:: - - mkdir bin - - * Place the following script, named ``run_worker.sh``, into that directory:: - - #!/bin/bash - export PATH=/usr/local/bin:/Library/Frameworks/Python.framework/Versions/2.7/bin:$PATH - export LC_CTYPE=en_US.utf-8 - cd /Users/buildbot/buildarea - twistd --nodaemon --python=buildbot.tac --logfile=buildbot.log --prefix=worker - - If you use pip with Apple's system python, add '/System' to the front of - the path to the Python bin directory. - - * Place a file with the following contents into ``/Library/LaunchDaemons``: - - .. code-block:: xml - - <?xml version="1.0" encoding="UTF-8"?> - <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" - "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> - <plist version="1.0"> - <dict> - <key>Label</key> - <string>net.buildbot.worker</string> - <key>UserName</key> - <string>buildbot</string> - <key>WorkingDirectory</key> - <string>/Users/buildbot/buildarea</string> - <key>ProgramArguments</key> - <array> - <string>/Users/buildbot/bin/run_worker.sh</string> - </array> - <key>StandardOutPath</key> - <string>twistd.log</string> - <key>StandardErrorPath</key> - <string>twistd.log</string> - <key>KeepAlive</key> - <true/> - <key>SessionCreate</key> - <true/> - </dict> - </plist> - - The recommended name for the file is ``net.buildbot.worker``. - -For Windows: - - * Add a Scheduled Task to run ``buildbot-worker start buildarea`` as the - buildbot user "when the computer starts up". It is best to provide - absolute paths to the ``buildbot-worker`` command and the :file:`buildarea` - directory. It is also recommended to set the task to run in the - directory that contains the :file:`buildarea` directory. - - * Alternatively (note: don't do both!), set up the worker - service as described in the `buildbot documentation - <http://trac.buildbot.net/wiki/RunningBuildbotOnWindows#Service>`_. - -To start the worker running for your initial testing, you can do:: - - buildbot-worker start buildarea - -Then you can either wait for someone to make a commit, or you can pick a -builder associated with your worker from the `list of builders -<http://buildbot.python.org/all/#/builders>`_ and force a build. - -In any case you should initially monitor builds on your builders to make sure -the tests are passing and to resolve any platform issues that may be revealed -by tests that fail. Unfortunately we do not currently have a way to notify you -only of failures on your builders, so doing periodic spot checks is also a good -idea. - - -Latent workers -^^^^^^^^^^^^^^ - -We also support running `latent workers -<http://docs.buildbot.net/current/manual/cfg-workers.html#latent-workers>`_ -on the AWS EC2 service. To set up such a worker: - - * Start an instance of your chosen base AMI and set it up as a - conventional worker. - * After the instance is fully set up as a conventional worker (including - worker name and password, and admin and host information), create an AMI - from the instance and stop the instance. - * Contact the buildmaster administrator who gave you your worker - name and password and give them the following information: - - * Instance size (such as ``m4.large``) - * Full region specification (such as ``us-west-2``) - * AMI ID (such as ``ami-1234beef``) - * An Access Key ID and Access Key. It is recommended to set up - a separate IAM user with full access to EC2 and provide the access key - information for that user rather than for your main account. - -The buildmaster cannot guarantee that it will always shut down your -instance(s), so it is recommended to periodically check and make sure -there are no "zombie" instances running on your account, created by the -buildbot master. Also, if you notice that your worker seems to have been -down for an unexpectedly long time, please ping the `python-buildbots -<https://mail.python.org/mailman/listinfo/python-buildbots>`_ list to -request that the master be restarted. - -Latent workers should also be updated periodically to include operating system -or other software updates, but when to do such maintenance is largely up to you -as the worker owner. There are a couple different options for doing such -updates: - - * Start an instance from your existing AMI, do updates on that instance, - and save a new AMI from the updated instance. Note that (especially for - Windows workers) you should do at least one restart of the instance after - doing updates to be sure that any post-reboot update work is done before - creating the new AMI. - * Create an entirely new setup from a newer base AMI using your existing - worker name and password. - -Whichever way you choose to update your AMI, you'll need to provide the -buildmaster administrators with the new AMI ID. - - -Buildbot worker operation -------------------------- - -Most of the time, running a worker is a "set and forget" operation, -depending on the level of involvement you want to have in resolving bugs -revealed by your builders. There are, however, times when it is helpful or -even necessary for you to get involved. As noted above, you should be -subscribed to ``python-buildbots@python.org`` so that you will be made -aware of any fleet-wide issues. - -Necessary tasks include, obviously, keeping the buildbot running. Currently -the system for notifying buildbot owners when their workers go offline is not -working; this is something we hope to resolve. So currently it is helpful if -you periodically check the status of your worker. We will also contact you -via your contact address in ``buildarea/info/admin`` when we notice there is a -problem that has not been resolved for some period of time and you have -not responded to a posting on the python-buildbots list about it. - -We currently do not have a minimum version requirement for the worker -software. However, this is something we will probably establish as we tune the -fleet, so another task will be to occasionally upgrade the buildbot worker software. -Coordination for this will be done via ``python-buildbots@python.org``. - -The most interesting extra involvement is when your worker reveals a unique -or almost-unique problem: a test that is failing on your system but not on -other systems. In this case you should be prepared to offer debugging help to -the people working on the bug: running tests by hand on the worker machine -or, if possible, providing ssh access to a committer to run experiments to try -to resolve the issue. - - -Required Ports --------------- - -The worker operates as a *client* to the *buildmaster*. This means that -all network connections are *outbound*. This is true also for the network -tests in the test suite. Most consumer firewalls will allow any outbound -traffic, so normally you do not need to worry about what ports the buildbot -uses. However, corporate firewalls are sometimes more restrictive, so here is -a table listing all of the outbound ports used by the buildbot and the python -test suite (this list may not be complete as new tests may have been added -since this table was last vetted): - -======= =================== ================================================ -Port Host Description -======= =================== ================================================ -20, 21 ftp.debian.org test_urllib2net -53 your DNS server test_socket, and others implicitly -80 python.org (several tests) - example.com -119 news.gmane.org test_nntplib -443 (various) test_ssl -465 smtp.gmail.com test_smtpnet -587 smtp.gmail.com test_smtpnet -9020 python.org connection to buildmaster -======= =================== ================================================ - -Many tests will also create local TCP sockets and connect to them, usually -using either ``localhost`` or ``127.0.0.1``. - - -Required Resources ------------------- - -Based on the last time we did a `survey -<https://mail.python.org/pipermail/python-dev/2012-March/117978.html>`_ on -buildbot requirements, the recommended resource allocations for a python -buildbot are at least: - - * 2 CPUs - * 512 MB RAM - * 30 GB free disk space - -The bigmem tests won't run in this configuration, since they require -substantially more memory, but these resources should be sufficient to ensure -that Python compiles correctly on the platform and can run the rest of the test -suite. - - -Security Considerations ------------------------ - -We only allow builds to be triggered against commits to the -`CPython repository on GitHub <https://github.com/python/cpython>`_. -This means that the code your buildbot will run will have been vetted by a committer. -However, mistakes and bugs happen, as could a compromise, so keep this in mind when -siting your buildbot on your network and establishing the security around it. -Treat the buildbot like you would any resource that is public facing and might -get hacked (use a VM and/or jail/chroot/solaris zone, put it in a DMZ, etc). -While the buildbot does not have any ports open for inbound traffic (and is not -public facing in that sense), committer mistakes do happen, and security flaws -are discovered in both released and unreleased code, so treating the buildbot -as if it were fully public facing is a good policy. - -Code runs differently as privileged and unprivileged users. We would love to -have builders running as privileged accounts, but security considerations do -make that difficult, as access to root can provide access to surprising -resources (such as spoofed IP packets, changes in MAC addresses, etc) even on a -VM setup. But if you are confident in your setup, we'd love to have a buildbot -that runs python as root. - -Note that the above is a summary of a `discussion -<https://mail.python.org/pipermail/python-dev/2011-October/113935.html>`_ on -python-dev about buildbot security that includes examples of the tests for -which privilege matters. There was no final consensus, but the information is -useful as a point of reference. - -.. [#] If the buildbot is going to do Framework builds, it is better to - use the Apple-shipped Python so as to avoid any chance of the buildbot - picking up components from the installed python.org python. diff --git a/committing.rst b/committing.rst deleted file mode 100644 index 19191b03bd..0000000000 --- a/committing.rst +++ /dev/null @@ -1,317 +0,0 @@ -.. _committing: - -Accepting Pull Requests -======================= - -.. highlight:: none - -This page is aimed to core developers, and covers the steps required to -accept, merge, and possibly backport a pull request on the main repository. - -Is the PR ready to be accepted? -------------------------------- - -Before a PR is accepted, you must make sure it is ready to enter the public -source tree. Use the following as a checklist of what to check for before -merging (details of various steps can be found later in this document): - -#. Has the submitter signed the CLA? - (delineated by a label on the pull request) -#. Did the test suite pass? (delineated by a pull request check) -#. Did code coverage increase or stay the same? - (delineated by a comment on the pull request) -#. Are the changes acceptable? -#. Was ``configure`` regenerated (if necessary)? -#. Was ``pyconfig.h.in`` regenerated (if necessary)? -#. Was the submitter added to ``Misc/ACKS`` (as appropriate)? -#. Was an entry added under ``Misc/NEWS.d/next`` (as appropriate)? -#. Was "What's New" updated (as appropriate)? -#. Were appropriate labels added to signify necessary backporting of the - pull request? -#. Was the pull request first made against the ``master`` branch? - -.. note:: - If you want to share your work-in-progress code on a feature or bugfix, - either open a ``WIP``-prefixed PR, publish patches on the - `issue tracker`_ or create a public fork of the repository. - -.. _issue tracker: https://bugs.python.org - - -Does the test suite still pass? -''''''''''''''''''''''''''''''' - -You must :ref:`run the whole test suite <runtests>` to ensure that it -passes before merging any code changes. - -.. note:: - You really need to run the **entire** test suite. Running a single test - is not enough as the changes may have unforeseen effects on other tests - or library modules. - - Running the entire test suite doesn't guarantee that the changes - will pass the :ref:`continuous integration <buildbots>` tests, as those - will exercise more possibilities still (such as different platforms or - build options). But it will at least catch non-build specific, - non-platform specific errors, therefore minimizing the chance for - breakage. - - -Patch checklist -''''''''''''''' - -You should also :ref:`run patchcheck <patchcheck>` to perform a quick -sanity check on the changes. - - -Handling Others' Code ---------------------- - -As a core developer you will occasionally want to commit a patch created by -someone else. When doing so you will want to make sure of some things. - -First, make sure the patch is in a good state. Both :ref:`patch` and -:ref:`helptriage` -explain what is to be expected of a patch. Typically patches that get cleared by -triagers are good to go except maybe lacking ``Misc/ACKS`` and ``Misc/NEWS.d`` -entries (which a core developer should make sure are updated appropriately). - -Second, make sure the patch does not break backwards-compatibility without a -good reason. This means :ref:`running the entire test suite <runtests>` to -make sure everything still passes. It also means that if semantics do change -there must be a good reason for the breakage of code the change will cause -(and it **will** break someone's code). If you are unsure if the breakage -is worth it, ask on python-dev. - -Third, ensure the patch is attributed correctly with the contributor's -name in ``Misc/ACKS`` if they aren't already there (and didn't add themselves -in their patch) and by mentioning "Patch by <x>" in the ``Misc/NEWS.d`` entry -and the check-in message. If the patch has been heavily modified then "Initial -patch by <x>" is an appropriate alternate wording. GitHub now supports `multiple -authors <https://help.github.com/articles/creating-a-commit-with-multiple-authors/>`_ -in a commit. Add ``Co-authored-by: name <name@example.com>`` at the end of the commit message. - -If you omit correct attribution in the initial check-in, then update ``ACKS`` -and ``NEWS.d`` in a subsequent check-in (don't worry about trying to fix the -original check-in message in that case). - -Finally, make sure that the submitter of the -patch has a CLA in place (indicated by an asterisk following their username -in the `issue tracker`_ or by the "CLA Signed" label on the pull request). -If the submitter lacks a signed CLA and the patch is non-trivial, direct them -to the electronic `Contributor Licensing Agreement`_ -to ensure the PSF has the appropriate authorizations in place to relicense -and redistribute their code. - - -Contributor Licensing Agreements --------------------------------- - -Always get a `Contributor Licensing Agreement`_ (CLA) signed unless the -change has no possible intellectual property associated with it (e.g. fixing -a spelling mistake in documentation). Otherwise it is simply safer from a -legal standpoint to require the contributor to sign the CLA. - -These days, the CLA can be signed electronically through the form linked -above, and this process is strongly preferred to the old mechanism that -involved sending a scanned copy of the signed paper form. - -As discussed on the PSF Contribution_ page, it is the CLA itself that gives -the PSF the necessary relicensing rights to redistribute contributions under -the Python license stack. This is an additional permission granted above and -beyond the normal permissions provided by the chosen open source license. - -Some developers may object to the relicensing permissions granted to the PSF -by the CLA. They're entirely within their rights to refuse to sign the CLA -on that basis, but that refusal *does* mean we **can't accept their patches** -for inclusion. - - -.. _Contribution: https://www.python.org/psf/contrib/ -.. _Contributor Licensing Agreement: - https://www.python.org/psf/contrib/contrib-form/ - - -Checking if the CLA has been received -------------------------------------- - -To check if a contributor's CLA has been received, go to the following website:: - - https://check-python-cla.herokuapp.com/ - -and put in their GitHub username. - -For further questions about the CLA process, write to: contributors@python.org. - - -What's New and News Entries ---------------------------- - -Almost all changes made to the code base deserve an entry in ``Misc/NEWS.d``. -If the change is particularly interesting for end users (e.g. new features, -significant improvements, or backwards-incompatible changes), an entry in -the ``What's New in Python`` document (in ``Doc/whatsnew/``) should be added -as well. Changes that affect documentation only generally do not require -a news entry. - -There are two notable exceptions to this general principle, and they -both relate to changes that *already* have a news entry, and have not yet -been included in any formal release (including alpha and beta releases). -These exceptions are: - -* If a change is reverted prior to release, then the corresponding entry - is simply removed. Otherwise, a new entry must be added noting that the - change has been reverted (e.g. when a feature is released in an alpha and - then cut prior to the first beta). - -* If a change is a fix (or other adjustment) to an earlier unreleased change - and the original news entry remains valid, then no additional entry is - needed. - -Needing a What's New entry almost always means that a change is *not* -suitable for inclusion in a maintenance release. A small number of -exceptions have been made for Python 2.7 due to the long support period - -when implemented, these changes *must* be noted in the "New Additions in -Python 2.7 Maintenance Releases" section of the Python 2.7 What's New -document. - -News entries go into the ``Misc/NEWS.d`` directory as individual files. The -news entry can be created by using `blurb-it <https://blurb-it.herokuapp.com/>`_, -or the `blurb <https://pypi.org/project/blurb/>`_ tool and its ``blurb add`` -command. - -If you are unable to use the tool you can create the news entry file manually. -The ``Misc/NEWS.d`` directory contains a sub-directory named ``next`` which -itself contains various sub-directories representing classifications for what -was affected (e.g. ``Misc/NEWS.d/next/Library`` for changes relating to the -standard library). The file name itself should be of the format -``<datetime>.bpo-<issue-number>.<nonce>.rst``: - -* ``<datetime>`` is today's date joined with a ``-`` to the current - time, in ``YYYY-MM-DD-hh-mm-ss`` format, e.g. ``2017-05-27-16-46-23`` -* ``<issue-number>`` is the issue number the change is for, e.g. ``12345`` - for ``bpo-12345`` -* ``<nonce>`` is some "unique" string to guarantee the file name is - unique across branches, e.g. ``Yl4gI2`` (typically six characters, but it can - be any length of letters and numbers, and its uniqueness can be satisfied by - typing random characters on your keyboard) - -So a file name may be -``Misc/NEWS.d/next/Library/2017-05-27-16-46-23.bpo-12345.Yl4gI2.rst``. - -The contents of a news file should be valid reStructuredText. An 80 character -column width should be used. There is no indentation or leading marker in the -file (e.g. ``-``). There is also no need to start the entry with the issue -number as it's part of the file name itself. You can use -:ref:`inline markups <rest-inline-markup>` too. Example news entry:: - - Fix warning message when :func:`os.chdir` fails inside - :func:`test.support.temp_cwd`. Patch by Chris Jerdonek. - -The inline Sphinx roles like ``:func:`` can be used to assist readers in finding -more information. You can build html and verify that the link target is -appropriate by using :ref:`make html <building-using-make>`. - -While Sphinx roles can be beneficial to readers, they are not required. -Inline ````code blocks```` can be used instead. - - -Working with Git_ ------------------ - -.. seealso:: - :ref:`gitbootcamp` - -As a core developer, the ability to push changes to the official Python -repositories means you have to be more careful with your workflow: - -* You should not push new branches to the main repository. You can still use - them in your fork that you use for development of patches; you can - also push these branches to a **separate** public repository that will be - dedicated to maintenance of the work before the work gets integrated in the - main repository. - -* You should not commit directly into the ``master`` branch, or any of the - maintenance branches (currently ``3.7``, ``3.6``, and ``2.7``). - You should commit against your own feature branch, and create a pull request. - -* For a small change, you can make a quick edit through the GitHub web UI. - If you choose to use the web UI, be aware that GitHub will - create a new branch in the **main** CPython repo (not your fork). Please - delete this newly created branch after it has been merged into the - ``master`` branch or any of the maintenance branches. To keep the CPython - repo tidy, please try to limit the existence of the new branch to, at most, - a few days. - -It is recommended to keep a fork of the main repository around, as it allows -simple reversion of all local changes (even "committed" ones) if your local -clone gets into a state you aren't happy with. - - -.. _Git: https://git-scm.com/ - - -.. _committing-active-branches: - -Active branches -''''''''''''''' - -If you do ``git branch`` you will see a :ref:`list of branches <branchstatus>`. -``master`` is the in-development branch, and is the only branch that receives -new features. The other branches only receive bug fixes or security fixes. - - -.. _branch-merge: - -Backporting Changes to an Older Version -''''''''''''''''''''''''''''''''''''''' - -When it is determined that a pull request needs to be backported into one or -more of the maintenance branches, a core developer can apply the labels -``needs backport to X.Y`` to the pull request. - -After the pull request has been merged, miss-islington (bot) will first try to -do the backport automatically. In case that miss-islington is unable to do it, -then the pull request author or the core developer who merged it should look into -backporting it themselves, using the backport generated by cherry_picker.py_ -as a starting point. - -The commit hash can be obtained from the original pull request, or by using -``git log`` on the ``master`` branch. -To display the 10 most recent commit hashes and their first line of the commit -message:: - - git log -10 --oneline - -.. _backport-pr-title: - -Prefix the backport pull request with the branch, and reference the pull request -number from ``master``, for example:: - - [3.7] bpo-12345: Fix the Spam Module (GH-NNNN) - -Note that cherry_picker.py_ adds the branch prefix automatically. - -Once the backport pull request has been created, remove the -``needs backport to X.Y`` label from the original pull request. (Only Core -Developers can apply labels to GitHub pull requests). - -.. _cherry_picker.py: https://github.com/python/cherry-picker - - -Reverting a Merged Pull Request -''''''''''''''''''''''''''''''' - -To revert a merged pull request, press the ``Revert`` button at the bottom of -the pull request. It will bring up the page to create a new pull request where -the commit can be reverted. It also creates a new branch on the main CPython -repository. Delete the branch once the pull request has been merged. - -Always include the reason for reverting the commit to help others understand -why it was done. The reason should be included as part of the commit message, -for example:: - - Revert bpo-NNNN: Fix Spam Module (GH-111) - - Reverts python/cpython#111. - Reason: This commit broke the buildbot. diff --git a/communication.rst b/communication.rst deleted file mode 100644 index 11c4c5aeb2..0000000000 --- a/communication.rst +++ /dev/null @@ -1,133 +0,0 @@ -.. _communication: - -Following Python's Development -============================== - -Python's development is communicated through a myriad of ways, mostly through -mailing lists, but also other forms. - -.. _mailinglists: - -Mailing Lists -------------- - -python-dev_ is the primary mailing list for discussions about Python's -development. The list is open to the public and is subscribed to by all core -developers plus many people simply interested in following Python's -development. Discussion is focused on issues related to Python's development, -such as how to handle a specific issue, a PEP, etc. - -- Ideas about new functionality should **not** start here and instead - should be sent to python-ideas_. -- Technical support questions should also not be asked here and instead - should go to python-list_ or python-help_. - -Python-ideas_ is a mailing list open to the public to discuss ideas on changing -Python. If a new idea does not start here (or python-list_, discussed below), -it will get redirected here. - -Sometimes people post new ideas to python-list_ to gather community opinion -before heading to python-ideas_. The list is also sometimes known as -comp.lang.python, the name of the newsgroup it mirrors (it is also known by -the abbreviation c.l.py). - -The python-committers_ mailing list is a private mailing list for core -developers (the archives are publicly available). -If something only affects core developers (e.g., the -tree is frozen for commits, etc.), it is discussed here instead of python-dev -to keep traffic down on the latter. - -Python-checkins_ sends out an email for every commit to Python's various -repositories from https://github.com/python/cpython. All core developers -subscribe to this list and are known to reply to these emails to make comments -about various issues they catch in the commit. Replies get redirected to -python-dev. - -There are two mailing lists related to issues on the `issue tracker`_. If you -only want an email for when a new issue is open, subscribe to -new-bugs-announce_. If you would rather receive an email for all changes made -to any issue, subscribe to python-bugs-list_. - -General Python questions should go to `python-list`_ or `tutor`_ -or similar resources, such as StackOverflow_ or the ``#python`` IRC channel -on Freenode_. - -`Core-Workflow <https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/>`_ -mailing list is the place to discuss and work on improvements to the CPython -core development workflow. - -A complete list of Python mailing lists can be found at https://mail.python.org. -Most lists are also mirrored at `GMANE <https://gmane.org>`_ and can be read and -posted to in various ways, including via web browsers, NNTP newsreaders, and -RSS feed readers. - -.. _issue tracker: https://bugs.python.org -.. _new-bugs-announce: https://mail.python.org/mailman/listinfo/new-bugs-announce -.. _python-bugs-list: https://mail.python.org/mailman/listinfo/python-bugs-list -.. _python-checkins: https://mail.python.org/mailman/listinfo/python-checkins -.. _python-committers: https://mail.python.org/mailman/listinfo/python-committers -.. _python-dev: https://mail.python.org/mailman/listinfo/python-dev -.. _python-help: https://mail.python.org/mailman/listinfo/python-help -.. _python-ideas: https://mail.python.org/mailman/listinfo/python-ideas -.. _python-list: https://mail.python.org/mailman/listinfo/python-list -.. _tutor: https://mail.python.org/mailman/listinfo/tutor -.. _StackOverflow: https://stackoverflow.com/ -.. _Freenode: http://freenode.net/ - -Zulip ------ - -We have our own `zulipchat <https://python.zulipchat.com>`_ instance. This should be -used to discuss the development of Python only. - -IRC ---- - -Some core developers enjoy spending time on IRC discussing various issues -regarding Python's development in the ``#python-dev`` channel on -``irc.freenode.net``. This is not a place to ask for help with Python, but to -discuss issues related to Python's own development. You can use Freenode's -`Web interface <https://webchat.freenode.net/>`_ if you don't have an IRC -client. - - -Blogs ------ - -Several core developers are active bloggers and discuss Python's development -that way. You can find their blogs (and various other developers who use Python) -at http://planetpython.org/. - - -Standards of behaviour in these communication channels ------------------------------------------------------- -We try to foster environments of mutual respect, tolerance and encouragement, -as described in the PSF's `Diversity Statement`_. Abiding by the guidelines -in this document and asking questions or posting suggestions in the -appropriate channels are an excellent way to get started on the mutual respect -part, greatly increasing the chances of receiving tolerance and encouragement -in return. - -.. _Diversity Statement: https://www.python.org/psf/diversity/ - -Setting Expectations for Open Source Participation --------------------------------------------------- - -Burn-out is common in open source due to a misunderstanding of what users, contributors, -and maintainers should expect from each other. Brett Cannon gave a `talk <https://youtu.be/-Nk-8fSJM6I>`_ -about this topic that sets out to help everyone set reasonable expectations of each other in -order to make open source pleasant for everyone involved. - -Additional Repositories ------------------------ - -`Python Core Workflow`_ hosts the codebase for tools such as `cherry_picker`_ -and `blurb`_. - -Python `Performance Benchmark`_ project is intended to be an authoritative -source of benchmarks for all Python implementations. - -.. _Python Core Workflow: https://github.com/python/core-workflow -.. _cherry_picker: https://pypi.org/project/cherry-picker/ -.. _blurb: https://pypi.org/project/blurb -.. _Performance Benchmark: https://github.com/python/performance diff --git a/compiler.rst b/compiler.rst deleted file mode 100644 index 3338cef4ee..0000000000 --- a/compiler.rst +++ /dev/null @@ -1,591 +0,0 @@ -.. _compiler: - -Design of CPython's Compiler -============================ - -.. highlight:: none - -Abstract --------- - -In CPython, the compilation from source code to bytecode involves several steps: - -1. Parse source code into a parse tree (:file:`Parser/pgen.c`) -2. Transform parse tree into an Abstract Syntax Tree (:file:`Python/ast.c`) -3. Transform AST into a Control Flow Graph (:file:`Python/compile.c`) -4. Emit bytecode based on the Control Flow Graph (:file:`Python/compile.c`) - -The purpose of this document is to outline how these steps of the process work. - -This document does not touch on how parsing works beyond what is needed -to explain what is needed for compilation. It is also not exhaustive -in terms of the how the entire system works. You will most likely need -to read some source to have an exact understanding of all details. - - -Parse Trees ------------ - -Python's parser is an LL(1) parser mostly based off of the -implementation laid out in the Dragon Book [Aho86]_. - -The grammar file for Python can be found in :file:`Grammar/Grammar` with the -numeric value of grammar rules stored in :file:`Include/graminit.h`. The -list of types of tokens (literal tokens, such as ``:``, numbers, etc.) can -be found in :file:`Grammar/Tokens` with the numeric value stored in -:file:`Include/token.h`. The parse tree is made up -of ``node *`` structs (as defined in :file:`Include/node.h`). - -Querying data from the node structs can be done with the following -macros (which are all defined in :file:`Include/node.h`): - -``CHILD(node *, int)`` - Returns the nth child of the node using zero-offset indexing -``RCHILD(node *, int)`` - Returns the nth child of the node from the right side; use - negative numbers! -``NCH(node *)`` - Number of children the node has -``STR(node *)`` - String representation of the node; e.g., will return ``:`` for a - ``COLON`` token -``TYPE(node *)`` - The type of node as specified in :file:`Include/graminit.h` -``REQ(node *, TYPE)`` - Assert that the node is the type that is expected -``LINENO(node *)`` - Retrieve the line number of the source code that led to the - creation of the parse rule; defined in :file:`Python/ast.c` - -For example, consider the rule for 'while': - -.. productionlist:: - while_stmt: "while" `expression` ":" `suite` : ["else" ":" `suite`] - -The node representing this will have ``TYPE(node) == while_stmt`` and -the number of children can be 4 or 7 depending on whether there is an -'else' statement. ``REQ(CHILD(node, 2), COLON)`` can be used to access -what should be the first ``:`` and require it be an actual ``:`` token. - - -Abstract Syntax Trees (AST) ---------------------------- - - -.. sidebar:: Green Tree Snakes - - See also `Green Tree Snakes - the missing Python AST docs - <https://greentreesnakes.readthedocs.io/en/latest/>`_ by Thomas Kluyver. - -The abstract syntax tree (AST) is a high-level representation of the -program structure without the necessity of containing the source code; -it can be thought of as an abstract representation of the source code. The -specification of the AST nodes is specified using the Zephyr Abstract -Syntax Definition Language (ASDL) [Wang97]_. - -The definition of the AST nodes for Python is found in the file -:file:`Parser/Python.asdl`. - -Each AST node (representing statements, expressions, and several -specialized types, like list comprehensions and exception handlers) is -defined by the ASDL. Most definitions in the AST correspond to a -particular source construct, such as an 'if' statement or an attribute -lookup. The definition is independent of its realization in any -particular programming language. - -The following fragment of the Python ASDL construct demonstrates the -approach and syntax:: - - module Python - { - stmt = FunctionDef(identifier name, arguments args, stmt* body, - expr* decorators) - | Return(expr? value) | Yield(expr? value) - attributes (int lineno) - } - -The preceding example describes two different kinds of statements and an -expression: function definitions, return statements, and yield expressions. -All three kinds are considered of type ``stmt`` as shown by ``|`` separating -the various kinds. They all take arguments of various kinds and amounts. - -Modifiers on the argument type specify the number of values needed; ``?`` -means it is optional, ``*`` means 0 or more, while no modifier means only one -value for the argument and it is required. ``FunctionDef``, for instance, -takes an ``identifier`` for the *name*, ``arguments`` for *args*, zero or more -``stmt`` arguments for *body*, and zero or more ``expr`` arguments for -*decorators*. - -Do notice that something like 'arguments', which is a node type, is -represented as a single AST node and not as a sequence of nodes as with -stmt as one might expect. - -All three kinds also have an 'attributes' argument; this is shown by the -fact that 'attributes' lacks a '|' before it. - -The statement definitions above generate the following C structure type: - -.. code-block:: c - - typedef struct _stmt *stmt_ty; - - struct _stmt { - enum { FunctionDef_kind=1, Return_kind=2, Yield_kind=3 } kind; - union { - struct { - identifier name; - arguments_ty args; - asdl_seq *body; - } FunctionDef; - - struct { - expr_ty value; - } Return; - - struct { - expr_ty value; - } Yield; - } v; - int lineno; - } - -Also generated are a series of constructor functions that allocate (in -this case) a ``stmt_ty`` struct with the appropriate initialization. The -``kind`` field specifies which component of the union is initialized. The -``FunctionDef()`` constructor function sets 'kind' to ``FunctionDef_kind`` and -initializes the *name*, *args*, *body*, and *attributes* fields. - - -Memory Management ------------------ - -Before discussing the actual implementation of the compiler, a discussion of -how memory is handled is in order. To make memory management simple, an arena -is used. This means that a memory is pooled in a single location for easy -allocation and removal. What this gives us is the removal of explicit memory -deallocation. Because memory allocation for all needed memory in the compiler -registers that memory with the arena, a single call to free the arena is all -that is needed to completely free all memory used by the compiler. - -In general, unless you are working on the critical core of the compiler, memory -management can be completely ignored. But if you are working at either the -very beginning of the compiler or the end, you need to care about how the arena -works. All code relating to the arena is in either :file:`Include/pyarena.h` or -:file:`Python/pyarena.c`. - -``PyArena_New()`` will create a new arena. The returned ``PyArena`` structure -will store pointers to all memory given to it. This does the bookkeeping of -what memory needs to be freed when the compiler is finished with the memory it -used. That freeing is done with ``PyArena_Free()``. This only needs to be -called in strategic areas where the compiler exits. - -As stated above, in general you should not have to worry about memory -management when working on the compiler. The technical details have been -designed to be hidden from you for most cases. - -The only exception comes about when managing a PyObject. Since the rest -of Python uses reference counting, there is extra support added -to the arena to cleanup each PyObject that was allocated. These cases -are very rare. However, if you've allocated a PyObject, you must tell -the arena about it by calling ``PyArena_AddPyObject()``. - - -Parse Tree to AST ------------------ - -The AST is generated from the parse tree (see :file:`Python/ast.c`) using the -function ``PyAST_FromNode()``. - -The function begins a tree walk of the parse tree, creating various AST -nodes as it goes along. It does this by allocating all new nodes it -needs, calling the proper AST node creation functions for any required -supporting functions, and connecting them as needed. - -Do realize that there is no automated nor symbolic connection between -the grammar specification and the nodes in the parse tree. No help is -directly provided by the parse tree as in yacc. - -For instance, one must keep track of which node in the parse tree -one is working with (e.g., if you are working with an 'if' statement -you need to watch out for the ':' token to find the end of the conditional). - -The functions called to generate AST nodes from the parse tree all have -the name :samp:`ast_for_{xx}` where *xx* is the grammar rule that the function -handles (``alias_for_import_name`` is the exception to this). These in turn -call the constructor functions as defined by the ASDL grammar and -contained in :file:`Python/Python-ast.c` (which was generated by -:file:`Parser/asdl_c.py`) to create the nodes of the AST. This all leads to a -sequence of AST nodes stored in ``asdl_seq`` structs. - -Function and macros for creating and using ``asdl_seq *`` types as found -in :file:`Python/asdl.c` and :file:`Include/asdl.h` are as follows: - -``_Py_asdl_seq_new(Py_ssize_t, PyArena *)`` - Allocate memory for an ``asdl_seq`` for the specified length -``asdl_seq_GET(asdl_seq *, int)`` - Get item held at a specific position in an ``asdl_seq`` -``asdl_seq_SET(asdl_seq *, int, stmt_ty)`` - Set a specific index in an ``asdl_seq`` to the specified value -``asdl_seq_LEN(asdl_seq *)`` - Return the length of an ``asdl_seq`` - -If you are working with statements, you must also worry about keeping -track of what line number generated the statement. Currently the line -number is passed as the last parameter to each ``stmt_ty`` function. - - -Control Flow Graphs -------------------- - -A control flow graph (often referenced by its acronym, CFG) is a -directed graph that models the flow of a program using basic blocks that -contain the intermediate representation (abbreviated "IR", and in this -case is Python bytecode) within the blocks. Basic blocks themselves are -a block of IR that has a single entry point but possibly multiple exit -points. The single entry point is the key to basic blocks; it all has -to do with jumps. An entry point is the target of something that -changes control flow (such as a function call or a jump) while exit -points are instructions that would change the flow of the program (such -as jumps and 'return' statements). What this means is that a basic -block is a chunk of code that starts at the entry point and runs to an -exit point or the end of the block. - -As an example, consider an 'if' statement with an 'else' block. The -guard on the 'if' is a basic block which is pointed to by the basic -block containing the code leading to the 'if' statement. The 'if' -statement block contains jumps (which are exit points) to the true body -of the 'if' and the 'else' body (which may be ``NULL``), each of which are -their own basic blocks. Both of those blocks in turn point to the -basic block representing the code following the entire 'if' statement. - -CFGs are usually one step away from final code output. Code is directly -generated from the basic blocks (with jump targets adjusted based on the -output order) by doing a post-order depth-first search on the CFG -following the edges. - - -AST to CFG to Bytecode ----------------------- - -With the AST created, the next step is to create the CFG. The first step -is to convert the AST to Python bytecode without having jump targets -resolved to specific offsets (this is calculated when the CFG goes to -final bytecode). Essentially, this transforms the AST into Python -bytecode with control flow represented by the edges of the CFG. - -Conversion is done in two passes. The first creates the namespace -(variables can be classified as local, free/cell for closures, or -global). With that done, the second pass essentially flattens the CFG -into a list and calculates jump offsets for final output of bytecode. - -The conversion process is initiated by a call to the function -``PyAST_CompileObject()`` in :file:`Python/compile.c`. This function does both the -conversion of the AST to a CFG and outputting final bytecode from the CFG. -The AST to CFG step is handled mostly by two functions called by -``PyAST_CompileObject()``; ``PySymtable_BuildObject()`` and ``compiler_mod()``. The former -is in :file:`Python/symtable.c` while the latter is in :file:`Python/compile.c`. - -``PySymtable_BuildObject()`` begins by entering the starting code block for the -AST (passed-in) and then calling the proper :samp:`symtable_visit_{xx}` function -(with *xx* being the AST node type). Next, the AST tree is walked with -the various code blocks that delineate the reach of a local variable -as blocks are entered and exited using ``symtable_enter_block()`` and -``symtable_exit_block()``, respectively. - -Once the symbol table is created, it is time for CFG creation, whose -code is in :file:`Python/compile.c`. This is handled by several functions -that break the task down by various AST node types. The functions are -all named :samp:`compiler_visit_{xx}` where *xx* is the name of the node type (such -as ``stmt``, ``expr``, etc.). Each function receives a ``struct compiler *`` -and :samp:`{xx}_ty` where *xx* is the AST node type. Typically these functions -consist of a large 'switch' statement, branching based on the kind of -node type passed to it. Simple things are handled inline in the -'switch' statement with more complex transformations farmed out to other -functions named :samp:`compiler_{xx}` with *xx* being a descriptive name of what is -being handled. - -When transforming an arbitrary AST node, use the ``VISIT()`` macro. -The appropriate :samp:`compiler_visit_{xx}` function is called, based on the value -passed in for <node type> (so :samp:`VISIT({c}, expr, {node})` calls -:samp:`compiler_visit_expr({c}, {node})`). The ``VISIT_SEQ()`` macro is very similar, -but is called on AST node sequences (those values that were created as -arguments to a node that used the '*' modifier). There is also -``VISIT_SLICE()`` just for handling slices. - -Emission of bytecode is handled by the following macros: - -``ADDOP(struct compiler *, int)`` - add a specified opcode -``ADDOP_I(struct compiler *, int, Py_ssize_t)`` - add an opcode that takes an integer argument -``ADDOP_O(struct compiler *, int, PyObject *, TYPE)`` - add an opcode with the proper argument based on the position of the - specified PyObject in PyObject sequence object, but with no handling of - mangled names; used for when you - need to do named lookups of objects such as globals, consts, or - parameters where name mangling is not possible and the scope of the - name is known; *TYPE* is the name of PyObject sequence - (``names`` or ``varnames``) -``ADDOP_N(struct compiler *, int, PyObject *, TYPE)`` - just like ``ADDOP_O``, but steals a reference to PyObject -``ADDOP_NAME(struct compiler *, int, PyObject *, TYPE)`` - just like ``ADDOP_O``, but name mangling is also handled; used for - attribute loading or importing based on name -``ADDOP_LOAD_CONST(struct compiler *, PyObject *)`` - add the `LOAD_CONST` opcode with the proper argument based on the - position of the specified PyObject in the consts table. -``ADDOP_LOAD_CONST_NEW(struct compiler *, PyObject *)`` - just like ``ADDOP_LOAD_CONST_NEW``, but steals a reference to PyObject -``ADDOP_JABS(struct compiler *, int, basicblock *)`` - create an absolute jump to a basic block -``ADDOP_JREL(struct compiler *, int, basicblock *)`` - create a relative jump to a basic block - -Several helper functions that will emit bytecode and are named -:samp:`compiler_{xx}()` where *xx* is what the function helps with (``list``, -``boolop``, etc.). A rather useful one is ``compiler_nameop()``. -This function looks up the scope of a variable and, based on the -expression context, emits the proper opcode to load, store, or delete -the variable. - -As for handling the line number on which a statement is defined, this is -handled by ``compiler_visit_stmt()`` and thus is not a worry. - -In addition to emitting bytecode based on the AST node, handling the -creation of basic blocks must be done. Below are the macros and -functions used for managing basic blocks: - -``NEXT_BLOCK(struct compiler *)`` - create an implicit jump from the current block - to the new block -``compiler_new_block(struct compiler *)`` - create a block but don't use it (used for generating jumps) -``compiler_use_next_block(struct compiler *, basicblock *block)`` - set a previously created block as a current block - -Once the CFG is created, it must be flattened and then final emission of -bytecode occurs. Flattening is handled using a post-order depth-first -search. Once flattened, jump offsets are backpatched based on the -flattening and then a ``PyCodeObject`` is created. All of this is -handled by calling ``assemble()``. - - -Introducing New Bytecode ------------------------- - -Sometimes a new feature requires a new opcode. But adding new bytecode is -not as simple as just suddenly introducing new bytecode in the AST -> -bytecode step of the compiler. Several pieces of code throughout Python depend -on having correct information about what bytecode exists. - -First, you must choose a name and a unique identifier number. The official -list of bytecode can be found in :file:`Lib/opcode.py`. If the opcode is to -take an argument, it must be given a unique number greater than that assigned to -``HAVE_ARGUMENT`` (as found in :file:`Lib/opcode.py`). - -Once the name/number pair has been chosen and entered in :file:`Lib/opcode.py`, -you must also enter it into :file:`Doc/library/dis.rst`, and regenerate -:file:`Include/opcode.h` and :file:`Python/opcode_targets.h` by running -``make regen-opcode regen-opcode-targets``. - -With a new bytecode you must also change what is called the magic number for -.pyc files. The variable ``MAGIC_NUMBER`` in -:file:`Lib/importlib/_bootstrap_external.py` contains the number. -Changing this number will lead to all .pyc files with the old ``MAGIC_NUMBER`` -to be recompiled by the interpreter on import. Whenever ``MAGIC_NUMBER`` is -changed, the ranges in the ``magic_values`` array in :file:`PC/launcher.c` -must also be updated. Changes to :file:`Lib/importlib/_bootstrap_external.py` -will take effect only after running ``make regen-importlib``. Running this -command before adding the new bytecode target to :file:`Python/ceval.c` will -result in an error. You should only run ``make regen-importlib`` after the new -bytecode target has been added. - -Finally, you need to introduce the use of the new bytecode. Altering -:file:`Python/compile.c` and :file:`Python/ceval.c` will be the primary places -to change. You must add the case for a new opcode into the 'switch' -statement in the ``stack_effect()`` function in :file:`Python/compile.c`. -If the new opcode has a jump target, you will need to update macros and -'switch' statements in :file:`Python/peephole.c`. If it affects a control -flow or the block stack, you may have to update the ``frame_setlineno()`` -function in :file:`Objects/frameobject.c`. :file:`Lib/dis.py` may need -an update if the new opcode interprets its argument in a special way (like -``FORMAT_VALUE`` or ``MAKE_FUNCTION``). - -If you make a change here that can affect the output of bytecode that -is already in existence and you do not change the magic number constantly, make -sure to delete your old .py(c|o) files! Even though you will end up changing -the magic number if you change the bytecode, while you are debugging your work -you will be changing the bytecode output without constantly bumping up the -magic number. This means you end up with stale .pyc files that will not be -recreated. -Running ``find . -name '*.py[co]' -exec rm -f '{}' +`` should delete all .pyc -files you have, forcing new ones to be created and thus allow you test out your -new bytecode properly. Run ``make regen-importlib`` for updating the -bytecode of frozen importlib files. You have to run ``make`` again after this -for recompiling generated C files. - - -Code Objects ------------- - -The result of ``PyAST_CompileObject()`` is a ``PyCodeObject`` which is defined in -:file:`Include/code.h`. And with that you now have executable Python bytecode! - -The code objects (byte code) are executed in :file:`Python/ceval.c`. This file -will also need a new case statement for the new opcode in the big switch -statement in ``_PyEval_EvalFrameDefault()``. - - -Important Files ---------------- - -+ Parser/ - - Python.asdl - ASDL syntax file - - asdl.py - Parser for ASDL definition files. Reads in an ASDL description - and parses it into an AST that describes it. - - asdl_c.py - "Generate C code from an ASDL description." Generates - :file:`Python/Python-ast.c` and :file:`Include/Python-ast.h`. - -+ Python/ - - Python-ast.c - Creates C structs corresponding to the ASDL types. Also - contains code for marshalling AST nodes (core ASDL types have - marshalling code in :file:`asdl.c`). "File automatically generated by - :file:`Parser/asdl_c.py`". This file must be committed separately - after every grammar change is committed since the ``__version__`` - value is set to the latest grammar change revision number. - - asdl.c - Contains code to handle the ASDL sequence type. Also has code - to handle marshalling the core ASDL types, such as number and - identifier. Used by :file:`Python-ast.c` for marshalling AST nodes. - - ast.c - Converts Python's parse tree into the abstract syntax tree. - - ast_opt.c - Optimizes the AST. - - ast_unparse.c - Converts the AST expression node back into a string - (for string annotations). - - ceval.c - Executes byte code (aka, eval loop). - - compile.c - Emits bytecode based on the AST. - - symtable.c - Generates a symbol table from AST. - - peephole.c - Optimizes the bytecode. - - pyarena.c - Implementation of the arena memory manager. - - wordcode_helpers.h - Helpers for generating bytecode. - - opcode_targets.h - One of the files that must be modified if :file:`Lib/opcode.py` is. - -+ Include/ - - Python-ast.h - Contains the actual definitions of the C structs as generated by - :file:`Python/Python-ast.c`. - "Automatically generated by :file:`Parser/asdl_c.py`". - - asdl.h - Header for the corresponding :file:`Python/ast.c`. - - ast.h - Declares ``PyAST_FromNode()`` external (from :file:`Python/ast.c`). - - code.h - Header file for :file:`Objects/codeobject.c`; contains definition of - ``PyCodeObject``. - - symtable.h - Header for :file:`Python/symtable.c`. ``struct symtable`` and - ``PySTEntryObject`` are defined here. - - pyarena.h - Header file for the corresponding :file:`Python/pyarena.c`. - - opcode.h - One of the files that must be modified if :file:`Lib/opcode.py` is. - -+ Objects/ - - codeobject.c - Contains PyCodeObject-related code (originally in - :file:`Python/compile.c`). - - frameobject.c - Contains the ``frame_setlineno()`` function which should determine - whether it is allowed to make a jump between two points in a bytecode. - -+ Lib/ - - opcode.py - Master list of bytecode; if this file is modified you must modify - several other files accordingly (see "`Introducing New Bytecode`_") - - importlib/_bootstrap_external.py - Home of the magic number (named ``MAGIC_NUMBER``) for bytecode - versioning. - - -Known Compiler-related Experiments ----------------------------------- - -This section lists known experiments involving the compiler (including -bytecode). - -Skip Montanaro presented a paper at a Python workshop on a peephole optimizer -[#skip-peephole]_. - -Michael Hudson has a non-active SourceForge project named Bytecodehacks -[#Bytecodehacks]_ that provides functionality for playing with bytecode -directly. - -An opcode to combine the functionality of ``LOAD_ATTR``/``CALL_FUNCTION`` was -created named ``CALL_ATTR`` [#CALL_ATTR]_. Currently only works for classic -classes and for new-style classes rough benchmarking showed an actual slowdown -thanks to having to support both classic and new-style classes. - - - -References ----------- - -.. [Aho86] Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman. - `Compilers: Principles, Techniques, and Tools`, - https://www.amazon.com/exec/obidos/tg/detail/-/0201100886/104-0162389-6419108 - -.. [Wang97] Daniel C. Wang, Andrew W. Appel, Jeff L. Korn, and Chris - S. Serra. `The Zephyr Abstract Syntax Description Language.`_ - In Proceedings of the Conference on Domain-Specific Languages, pp. - 213--227, 1997. - -.. _The Zephyr Abstract Syntax Description Language.: - https://www.cs.princeton.edu/research/techreps/TR-554-97 - -.. [#skip-peephole] Skip Montanaro's Peephole Optimizer Paper - (https://drive.google.com/open?id=0B2InO7qBBGRXQXlDM3FVdWZxQWc) - -.. [#Bytecodehacks] Bytecodehacks Project - (http://bytecodehacks.sourceforge.net/bch-docs/bch/index.html) - -.. [#CALL_ATTR] CALL_ATTR opcode - (https://bugs.python.org/issue709744) diff --git a/conf.py b/conf.py index 6c0cff11d1..1d88937227 100644 --- a/conf.py +++ b/conf.py @@ -1,243 +1,289 @@ -# -*- coding: utf-8 -*- -# -# Python Developer's Guide documentation build configuration file, created by -# sphinx-quickstart on Tue Jan 4 10:34:03 2011. -# -# This file is execfile()d with the current directory set to its containing dir. -# -# Note that not all possible configuration values are present in this -# autogenerated file. -# -# All configuration values have a default; values that are commented out -# serve to show the default. - +import json import os -import sys -import time - -# If extensions (or modules to document with autodoc) are in another directory, -# add these directories to sys.path here. If the directory is relative to the -# documentation root, use os.path.abspath to make it absolute, like shown here. -#sys.path.insert(0, os.path.abspath('.')) - -sys.path.append(os.path.abspath('tools')) - -# -- General configuration ----------------------------------------------------- - -# If your documentation needs a minimal Sphinx version, state it here. -#needs_sphinx = '1.0' - -# Add any Sphinx extension module names here, as strings. They can be extensions -# coming with Sphinx (named 'sphinx.ext.*') or your custom ones. -extensions = ['sphinx.ext.intersphinx', 'sphinx.ext.todo'] -intersphinx_mapping = {'python': ('https://docs.python.org/3', None)} -todo_include_todos = True - -# The suffix of source filenames. -source_suffix = '.rst' - -# The encoding of source files. -#source_encoding = 'utf-8-sig' +from urllib.request import urlopen + +extensions = [ + 'linklint.ext', + 'notfound.extension', + 'sphinx.ext.extlinks', + 'sphinx.ext.intersphinx', + 'sphinx.ext.todo', + 'sphinx_copybutton', + 'sphinx_inline_tabs', + 'sphinxext.opengraph', + 'sphinxext.rediraffe', +] # The master toctree document. master_doc = 'index' # General information about the project. -project = 'Python Developer\'s Guide' -copyright = '2011-%s, Python Software Foundation' % time.strftime('%Y') - -# The version info for the project you're documenting, acts as replacement for -# |version| and |release|, also used in various other places throughout the -# built documents. -# -# The short X.Y version. -version = '' -# The full version, including alpha/beta/rc tags. -release = '' - -# The language for content autogenerated by Sphinx. Refer to documentation -# for a list of supported languages. -#language = None - -# There are two options for replacing |today|: either, you set today to some -# non-false value, then it is used: -#today = '' -# Else, today_fmt is used as the format for a strftime call. -#today_fmt = '%B %d, %Y' +project = "Python Developer's Guide" +copyright = '2011 Python Software Foundation' # List of patterns, relative to source directory, that match files and # directories to ignore when looking for source files. -exclude_patterns = ['_build', 'venv*', 'env*', 'README.rst'] - -# The reST default role (used for this markup: `text`) to use for all documents. -#default_role = None - -# If true, '()' will be appended to :func: etc. cross-reference text. -#add_function_parentheses = True - -# If true, the current module name will be prepended to all description -# unit titles (such as .. function::). -#add_module_names = True - -# If true, sectionauthor and moduleauthor directives will be shown in the -# output. They are ignored by default. -#show_authors = False - -# The name of the Pygments (syntax highlighting) style to use. -pygments_style = 'sphinx' - -# A list of ignored prefixes for module index sorting. -#modindex_common_prefix = [] +exclude_patterns = [ + '_build', + 'venv*', + 'env*', + 'README.rst', + '.github', +] +nitpicky = True -# -- Options for HTML output --------------------------------------------------- -# Use the upstream python-docs-theme -html_theme = 'python_docs_theme' +html_theme = 'furo' html_theme_options = { - 'collapsiblesidebar': True, - 'issues_url': 'https://github.com/python/devguide/issues/new', -} - - -# The name for this set of Sphinx documents. If None, it defaults to -# "<project> v<release> documentation". -html_title = "%s %s" % (project, release) - -# Path to find HTML templates. -templates_path = ['tools/templates'] - -# Custom sidebar templates, filenames relative to this file. -html_sidebars = { - # Defaults taken from http://www.sphinx-doc.org/en/stable/config.html#confval-html_sidebars - # Removes the quick search block - '**': ['localtoc.html', 'globaltoc.html', 'relations.html', 'customsourcelink.html'], + "source_repository": "https://github.com/python/devguide", + "source_branch": "main", } - -# Additional static files. -html_static_path = ['tools/static'] - -# A shorter title for the navigation bar. Default is the same as html_title. -#html_short_title = None - -# The name of an image file (relative to this directory) to place at the top -# of the sidebar. -#html_logo = None - -# The name of an image file (within the static path) to use as favicon of the -# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 -# pixels large. -#html_favicon = None - -# If not '', a 'Last updated on:' timestamp is inserted at every page bottom, -# using the given strftime format. -html_last_updated_fmt = '%b %d, %Y' - -# If true, SmartyPants will be used to convert quotes and dashes to -# typographically correct entities. -#html_use_smartypants = True - -# Additional templates that should be rendered to pages, maps page names to -# template names. -#html_additional_pages = {} - -# If false, no module index is generated. -#html_domain_indices = True - -# If false, no index is generated. -#html_use_index = True - -# If true, the index is split into individual pages for each letter. -#html_split_index = False - -# If true, links to the reST sources are added to the pages. -#html_show_sourcelink = True - -# If true, "Created using Sphinx" is shown in the HTML footer. Default is True. -#html_show_sphinx = True - -# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True. -#html_show_copyright = True - -# If true, an OpenSearch description file will be output, and all pages will -# contain a <link> tag referring to it. The value of this option must be the -# base URL from which the finished HTML is served. -#html_use_opensearch = '' - -# This is the file name suffix for HTML files (e.g. ".xhtml"). -#html_file_suffix = None - -# Output file base name for HTML help builder. -htmlhelp_basename = 'PythonDevelopersGuidedoc' - - -# -- Options for LaTeX output -------------------------------------------------- - -# The paper size ('letter' or 'a4'). -#latex_paper_size = 'letter' - -# The font size ('10pt', '11pt' or '12pt'). -#latex_font_size = '10pt' - -# Grouping the document tree into LaTeX files. List of tuples -# (source start file, target name, title, author, documentclass [howto/manual]). -latex_documents = [ - ( - 'index', - 'PythonDevelopersGuide.tex', - 'Python Developer\'s Guide Documentation', - 'Brett Cannon', - 'manual', - ), +templates_path = ['_templates'] +html_static_path = ['_static'] +html_css_files = [ + 'devguide_overrides.css', ] +html_js_files = [ + "activate_tab.js", +] +html_logo = "_static/python-logo.svg" +html_favicon = "_static/favicon.png" -# The name of an image file (relative to this directory) to place at the top of -# the title page. -#latex_logo = None - -# For "manual" documents, if this is true, then toplevel headings are parts, -# not chapters. -#latex_use_parts = False - -# If true, show page references after internal links. -#latex_show_pagerefs = False - -# If true, show URL addresses after external links. -#latex_show_urls = False - -# Additional stuff for the LaTeX preamble. -#latex_preamble = '' - -# Documents to append as an appendix to all manuals. -#latex_appendices = [] - -# If false, no module index is generated. -#latex_domain_indices = True +# Set to '' to prevent appending "documentation" to the site title +html_title = "" +# Deployment preview information +# (See .readthedocs.yaml and https://docs.readthedocs.io/en/stable/reference/environment-variables.html) +is_deployment_preview = os.getenv("READTHEDOCS_VERSION_TYPE") == "external" -# -- Options for manual page output -------------------------------------------- +html_context = { + "is_deployment_preview": is_deployment_preview, +} -# One entry per manual page. List of tuples -# (source start file, name, description, authors, manual section). -man_pages = [ - ( - 'index', - 'pythondevelopersguide', - "Python Developer's Guide Documentation", - ['Brett Cannon'], - 1, - ), -] +linkcheck_allowed_redirects = { + # Edit page + r"https://docs.google.com/document/d/.*/": r"https://docs.google.com/document/d/.*/edit", # noqa: E501 + # Canonical + r"https://docs.python.org/": r"https://docs.python.org/3/", + # Translations with country codes + r"https://docs.python.org/[a-z-]+/": r"https://docs.python.org/[a-z-]+/3/", + # Personal /my/ links redirect to login page + r"https://discuss.python.org/my/.*": r"https://discuss.python.org/login-preferences", # noqa: E501 + # Category number URL to full slug + r"https://discuss.python.org/c/\d+": r"https://discuss.python.org/c/.*", + # Login page + r"https://github.com/python/buildmaster-config/issues/new.*": r"https://github.com/login.*", # noqa: E501 + r"https://github.com/python/core-workflow/issues/new.*": r"https://github.com/login.*", # noqa: E501 + r"https://github.com/orgs/python/teams.*": r"https://github.com/login.*", # noqa: E501 + # Archive redirect + r"https://github.com/python/cpython/archive/main.zip": r"https://codeload.github.com/python/cpython/zip/refs/heads/main", # noqa: E501 + # Blob to tree + r"https://github.com/python/cpython/blob/.*": r"https://github.com/python/cpython/tree/.*", # noqa: E501 + # HackMD shortcuts + r"https://hackmd.io/s/.*": r"https://hackmd.io/@.*", + # Read the Docs + r"https://python-docs-tr.readthedocs.io/": r"https://python-docs-tr.readthedocs.io/tr/.*", # noqa: E501 + r"https://virtualenv.pypa.io/": r"https://virtualenv.pypa.io/en/latest/", + r"https://www.sphinx-doc.org/": r"https://www.sphinx-doc.org/en/master/", + # Cookie consent + r"https://www.youtube.com/playlist.*": r"https://consent.youtube.com/.*", +} # ignore linkcheck anchors for /#/$ANCHOR since it is used for # dynamic pages such as http://buildbot.python.org/all/#/console # http://www.sphinx-doc.org/en/stable/config.html?highlight=linkcheck#confval-linkcheck_anchors_ignore linkcheck_anchors_ignore = [ # match any anchor that starts with a '/' since this is an invalid HTML anchor - '\/.*', + r'\/.*', +] + +linkcheck_ignore = [ + # Checks fail due to rate limits + r'https://github.com/.*', + r'https://www.gnu.org/software/autoconf/', + # The Discourse groups are private unless you are logged in + 'https://discuss.python.org/groups/staff', + 'https://discuss.python.org/groups/moderators', + 'https://discuss.python.org/groups/admins', + # "Anchor not found": + r'https://packaging.python.org/.*#', + # "-rate limited-", causing a timeout + r'https://stackoverflow.com/.*', + # Discord doesn't allow robot crawlers: "403 Client Error: Forbidden" + r'https://support.discord.com/hc/en-us/articles/219070107-Server-Nicknames', + # Patreon also gives 403 to the GHA linkcheck runner + r'https://www.patreon.com/.*', ] -# Use our custom CSS stylesheet to differentiate us from the official python -# docs. -def setup(app): - app.add_stylesheet('custom.css') +rediraffe_redirects = { + # Development Tools + "clang.rst": "development-tools/clang.rst", + "gdb.rst": "development-tools/gdb.rst", + # Advanced Tools was renamed Development Tools in gh-1149 + "advanced-tools/clang.rst": "development-tools/clang.rst", + "advanced-tools/gdb.rst": "development-tools/gdb.rst", + # Core team + "coredev.rst": "core-team/join-team.rst", + "committing.rst": "core-team/committing.rst", + "developers.rst": "core-team/team-log.rst", + "experts.rst": "core-team/experts.rst", + "motivations.rst": "core-team/motivations.rst", + # core-developers/ -> core-team/ + "core-developers/become-core-developer.rst": "core-team/join-team.rst", + "core-developers/committing.rst": "core-team/committing.rst", + "core-developers/developer-log.rst": "core-team/team-log.rst", + "core-developers/experts.rst": "core-team/experts.rst", + "core-developers/index.rst": "core-team/index.rst", + "core-developers/memorialization.rst": "core-team/memorialization.rst", + "core-developers/motivations.rst": "core-team/motivations.rst", + "core-developers/responsibilities.rst": "core-team/responsibilities.rst", + # Developer Workflow + "c-api.rst": "developer-workflow/c-api.rst", + "communication.rst": "developer-workflow/communication-channels.rst", + "devcycle.rst": "developer-workflow/development-cycle.rst", + "extensions.rst": "developer-workflow/extension-modules.rst", + "grammar.rst": "developer-workflow/grammar.rst", + "langchanges.rst": "developer-workflow/lang-changes.rst", + "porting.rst": "developer-workflow/porting.rst", + "stdlibchanges.rst": "developer-workflow/stdlib.rst", + # Documentation + "docquality.rst": "documentation/help-documenting.rst", + "documenting.rst": "documentation/start-documenting.rst", + # Translating + "documentation/translating.rst": "documentation/translations/translating.rst", + "translating.rst": "documentation/translations/translating.rst", + "coordinating.rst": "documentation/translations/coordinating.rst", + # Getting Started + "fixingissues.rst": "getting-started/fixing-issues.rst", + "help.rst": "getting-started/getting-help.rst", + "gitbootcamp.rst": "getting-started/git-boot-camp.rst", + "pullrequest.rst": "getting-started/pull-request-lifecycle.rst", + "setup.rst": "getting-started/setup-building.rst", + # CPython Internals + "compiler.rst": "internals.rst", + "exploring.rst": "internals.rst", + "garbage_collector.rst": "internals.rst", + "parser.rst": "internals.rst", + "internals/compiler.rst": "internals.rst", + "internals/exploring.rst": "internals.rst", + "internals/garbage_collector.rst": "internals.rst", + "internals/parser.rst": "internals.rst", + # Testing and Buildbots + "buildbots.rst": "testing/buildbots.rst", + "coverage.rst": "testing/coverage.rst", + "buildworker.rst": "testing/new-buildbot-worker.rst", + "runtests.rst": "testing/run-write-tests.rst", + "silencewarnings.rst": "testing/silence-warnings.rst", + # Issues and Triaging + "gh-faq.rst": "triage/github-bpo-faq.rst", + "tracker.rst": "triage/issue-tracker.rst", + "gh-labels.rst": "triage/labels.rst", + "triaging.rst": "triage/triaging.rst", + # Contributing guide draft pages + "contrib/code/git.rst": "getting-started/git-boot-camp.rst", + "contrib/code/pull-request-lifecycle.rst": "getting-started/pull-request-lifecycle.rst", + "contrib/code/setup.rst": "getting-started/setup-building.rst", + "contrib/code/testing.rst": "testing/index.rst", + "contrib/code/developer-workflow.rst": "developer-workflow/index.rst", + "contrib/code/index.rst": "index.rst", + "contrib/code/development-tools.rst": "development-tools/index.rst", + "contrib/doc/devguide.rst": "documentation/devguide.rst", + "contrib/doc/help-documenting.rst": "documentation/help-documenting.rst", + "contrib/doc/markup.rst": "documentation/markup.rst", + "contrib/doc/pull-request-lifecycle.rst": "getting-started/pull-request-lifecycle.rst", + "contrib/doc/start-documenting.rst": "documentation/start-documenting.rst", + "contrib/doc/style-guide.rst": "documentation/style-guide.rst", + "contrib/doc/translating.rst": "documentation/translations/index.rst", + "contrib/doc/index.rst": "documentation/index.rst", + "contrib/intro/index.rst": "index.rst", + "contrib/project/channels.rst": "developer-workflow/communication-channels.rst", + "contrib/project/conduct.rst": "index.rst", + "contrib/project/github.rst": "index.rst", + "contrib/project/governance.rst": "index.rst", + "contrib/project/roles.rst": "index.rst", + "contrib/project/generative-ai.rst": "getting-started/generative-ai.rst", + "contrib/project/outreach.rst": "index.rst", + "contrib/project/directory-structure.rst": "getting-started/setup-building.rst", + "contrib/project/index.rst": "index.rst", + "contrib/security.rst": "index.rst", + "contrib/triage/issue-tracker.rst": "triage/issue-tracker.rst", + "contrib/triage/labels.rst": "triage/labels.rst", + "contrib/triage/reviewing.rst": "triage/triaging.rst", + "contrib/triage/triage-team.rst": "triage/triage-team.rst", + "contrib/triage/triaging.rst": "triage/triaging.rst", + "contrib/triage/index.rst": "triage/index.rst", + "contrib/user-success.rst": "index.rst", + "contrib/core-team/committing.rst": "core-team/committing.rst", + "contrib/core-team/experts.rst": "core-team/experts.rst", + "contrib/core-team/index.rst": "core-team/index.rst", + "contrib/core-team/join-team.rst": "core-team/join-team.rst", + "contrib/core-team/motivations.rst": "core-team/motivations.rst", + "contrib/core-team/responsibilities.rst": "core-team/responsibilities.rst", + "contrib/core-team/team-log.rst": "core-team/team-log.rst", + "contrib/workflows/codespaces.rst": "getting-started/setup-building.rst", + "contrib/workflows/compile.rst": "getting-started/setup-building.rst", + "contrib/workflows/get-source.rst": "getting-started/setup-building.rst", + "contrib/workflows/index.rst": "getting-started/setup-building.rst", + "contrib/workflows/install-dependencies.rst": "getting-started/setup-building.rst", + "contrib/workflows/install-git.rst": "getting-started/setup-building.rst", + "contrib/workflows/regenerate.rst": "getting-started/setup-building.rst", + "contrib/workflows/troubleshooting.rst": "getting-started/setup-building.rst", + "contrib/index.rst": "index.rst", +} + +intersphinx_mapping = { + 'python': ('https://docs.python.org/3', None), + 'diataxis': ('https://diataxis.fr/', None), +} + +todo_include_todos = True + +# sphinx-notfound-page +notfound_urls_prefix = "/" + +# Dynamically expose the Python version associated with the "main" branch. +# Exactly one entry in ``release-cycle.json`` should have ``"branch": "main"``. +with urlopen("https://peps.python.org/api/release-cycle.json") as _f: + _cycle = json.loads(_f.read().decode("utf-8")) + +_main_version = next( + version for version, data in _cycle.items() if data.get("branch") == "main" +) + +# prolog and epilogs +rst_prolog = f""" + +.. |main_version| replace:: {_main_version} + +""" + +# sphinx.ext.extlinks +# This config is a dictionary of external sites, +# mapping unique short aliases to a base URL and a prefix. +# https://www.sphinx-doc.org/en/master/usage/extensions/extlinks.html +_repo = "https://github.com/python/cpython" +extlinks = { + "cpy-file": (f"{_repo}/blob/main/%s", "%s"), + "gh-label": (f"{_repo}/labels/%s", "%s"), + "github": ("https://github.com/%s", "%s"), + "github-user": ("https://github.com/%s", "@%s"), + "pypi": ("https://pypi.org/project/%s/", "%s"), + "pypi-org": ("https://pypi.org/org/%s/", "%s"), +} + +# sphinxext-opengraph config +ogp_site_url = "https://devguide.python.org/" +ogp_site_name = "Python Developer's Guide" +ogp_image = "_static/og-image-200x200.png" +ogp_custom_meta_tags = ( + '<meta property="og:image:width" content="200">', + '<meta property="og:image:height" content="200">', + '<meta name="theme-color" content="#3776ab">', +) + +# Strip the dollar prompt when copying code +# https://sphinx-copybutton.readthedocs.io/en/latest/use.html#strip-and-configure-input-prompts-for-code-cells +copybutton_prompt_text = "$ " +# https://sphinx-copybutton.readthedocs.io/en/latest/use.html#honor-line-continuation-characters-when-copying-multline-snippets +copybutton_line_continuation_character = "\\" diff --git a/core-team/committing.rst b/core-team/committing.rst new file mode 100644 index 0000000000..c606df3839 --- /dev/null +++ b/core-team/committing.rst @@ -0,0 +1,185 @@ +.. _committing: + +Accepting pull requests +======================= + +.. highlight:: none + +This page is a step-by-step guide for the core team to assess, +merge, and possibly backport a pull request on the main repository. + +Assessing a pull request +------------------------ + +Before you can accept a pull request, you need to make sure that it is ready +to enter the public source tree. Ask yourself the following questions: + +* **Are there ongoing discussions at the issue tracker?** + Read the linked issue. If there are ongoing discussions, then + we need to have a resolution there before we can merge the pull request. + +* **Was the pull request first made against the appropriate branch?** + The only branch that receives new features is ``main``, the + in-development branch. Pull requests should only target bug-fix branches + if an issue appears in only that version and possibly older versions. + +* **Are the changes acceptable?** + If you want to share your work-in-progress code on a feature or bugfix, + then you can open a ``WIP``-prefixed pull request, publish patches on + the `issue tracker`_, or create a public fork of the repository. + +* **Do the checks on the pull request show that the test suite passes?** + Make sure that all of the status checks are passing. + +* **Is the pull request in a good state?** + Check :ref:`pull-request-lifecycle` and :ref:`helptriage` to review what + is expected of a pull request. + +* **Does the change break backwards-compatibility without a strong reason?** + :ref:`Run the entire test suite <runtests>` to make sure that everything + still passes. If there is a change to the semantics, then there needs to + be a strong reason, because it will cause some peoples' code to break. + If you are unsure if the breakage is worth it, then ask + on the `Core Development Discourse category + <https://discuss.python.org/c/core-dev/23>`__. + +* **Does documentation need to be updated?** + If the pull request introduces backwards-incompatible changes (for example, + deprecating or removing a feature), then make sure that those changes + are reflected in the documentation before you merge the pull request. + +* **Were appropriate labels added to signify necessary backporting of the pull request?** + If it is determined that a pull request needs to be + backported into one or more of the maintenance branches, then a core + developer can apply the label ``needs backport to X.Y`` to the pull + request. Once the backport pull request has been created, remove the + ``needs backport to X.Y`` label from the original pull request. (Only + the core team and members of the :ref:`Python Triage Team <triage-team>` + can apply labels to GitHub pull requests). + +* **Does the pull request pass a check indicating that the submitter has signed the CLA?** + Make sure that the contributor has signed a `Contributor + Licensing Agreement <https://www.python.org/psf/contrib/contrib-form/>`__ + (CLA), unless their change has no possible intellectual property + associated with it (for example, fixing a spelling mistake in documentation). + The `Python Software Foundation Contributor License Agreement Management Bot + <https://github.com/psf/clabot>`__ + checks whether the author has signed the CLA, and replies in the PR + if they haven't. For further questions about the CLA + process, write to contributors@python.org. + +* **Were** ``What's New in Python`` **and** ``Misc/NEWS.d/next`` **updated?** + If the change is particularly interesting for end users (for example, new features, + significant improvements, or backwards-incompatible changes), then an + entry in the ``What's New in Python`` document (in ``Doc/whatsnew/``) should + be added as well. Changes that affect only documentation generally do not + require a ``NEWS`` entry. + + .. seealso:: + :ref:`what-s-new-and-news-entries` + + +Working with Git_ +----------------- + +.. seealso:: + :ref:`gitbootcamp` + +As a core team member, you have the ability to push changes to the official +Python repositories, so you need to be careful with your workflow: + +* **You should not push new branches to the main repository.** You can + still use them in the fork that you use for your own development. + You can also push these branches to a separate public repository + for maintenance work before it is integrated into the main repository. + +* **You should not commit directly into the** ``main`` **branch, or any of the maintenance branches.** + You should commit against your own feature branch, and then create a + pull request. + +* **For a small change, you can make a quick edit through the GitHub web UI.** + If you choose to use the web UI, be aware that GitHub will + create a new branch in the main CPython repository rather than in your fork. + Delete this newly created branch after it has been merged into the + ``main`` branch or any of the maintenance branches. To keep the CPython + repository tidy, remove the new branch within a few days. + +Keep a fork of the main repository, since it will allow you to revert all +local changes (even committed ones) if you're not happy with your local +clone. + + +.. _Git: https://git-scm.com/ + + +.. _committing-active-branches: + +Seeing active branches +^^^^^^^^^^^^^^^^^^^^^^ + +If you use ``git branch``, then you will see a :ref:`list of branches +<branchstatus>`. The only branch that receives new features is +``main``, the in-development branch. The other branches receive only +bug fixes or security fixes. In almost all cases the fixes should first +originate on ``main`` and then be ported back to older branches. + + +.. _branch-merge: + +Backporting changes to an older version +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If it is determined that a pull request needs to be backported into one or +more of the maintenance branches, then a core team member can apply the label +``needs backport to X.Y`` to the pull request. + +After the pull request has been merged, miss-islington (bot) will first try to +do the backport automatically. If miss-islington is unable to do it, +then the pull request author or the core team member who merged it should look into +backporting it themselves, using the backport generated by cherry_picker.py_ +as a starting point. + +You can get the commit hash from the original pull request, or you can use +``git log`` on the ``main`` branch. To display the 10 most recent commit +hashes and their first line of the commit, use the following command:: + + git log -10 --oneline + +.. _backport-pr-title: + +You can prefix the backport pull request with the branch, and reference +the pull request number from ``main``. Here is an example:: + + [3.9] gh-12345: Fix the Spam Module (GH-NNNN) + +Here "gh-12345" is the GitHub *issue* number, and "GH-NNNN" is the +number of the original *pull request*. +Note that cherry_picker.py_ adds the branch prefix automatically. + +Once the backport pull request has been created, remove the +``needs backport to X.Y`` label from the original pull request. (Only +members of the core team and :ref:`Python Triage Team <triage-team>` +can apply labels to GitHub pull requests). + +.. _cherry_picker.py: https://github.com/python/cherry-picker + + +Reverting a merged pull request +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To revert a merged pull request, press the :guilabel:`Revert` button at the +bottom of the pull request. That will bring up the page to create a +new pull request where the commit can be reverted. It will also create +a new branch on the main CPython repository. Delete the branch once +the pull request has been merged. + +Always include the reason for reverting the commit to help others +understand why it was done. The reason should be included as part of +the commit message. Here is an example:: + + Revert gh-NNNN: Fix Spam Module (GH-111) + + Reverts python/cpython#111. + Reason: This commit broke the buildbot. + +.. _issue tracker: https://github.com/python/cpython/issues diff --git a/core-team/core-team.csv b/core-team/core-team.csv new file mode 100644 index 0000000000..46dfd81530 --- /dev/null +++ b/core-team/core-team.csv @@ -0,0 +1,207 @@ +Stan Ulbrych,StanFromIreland,2026-03-26,, +Itamar Oren,itamaro,2026-02-16,, +Emma Smith,emmatyping,2025-07-31,, +Tomas Roun,tomasr8,2025-06-16,, +Peter Bierma,ZeroIntensity,2025-06-16,, +Diego Russo,diegorusso,2025-05-13,, +Bénédikt Tran,picnixz,2025-01-10,, +Savannah Ostrowski,savannahostrowski,2024-11-13,, +Matt Page,mpage,2024-10-10,, +Kirill Podoprigora,Eclips4,2024-09-20,, +Ned Batchelder,nedbat,2024-07-16,, +Tian Gao,gaogaotiantian,2024-06-06,, +Michael Droettboom,mdboom,2024-06-06,, +Russell Keith-Magee,freakboy3742,2024-05-30,, +Sam Gross,colesbury,2024-02-06,, +Nikita Sobolev,sobolevn,2024-02-06,, +Adam Turner,AA-Turner,2023-10-10,, +C.A.M. Gerlach,CAM-Gerlach,2023-04-19,, +Barney Gale,barneygale,2023-03-21,, +Carl Meyer,carljm,2023-02-28,, +Pradyun Gedam,pradyunsg,2023-01-30,, +Shantanu Jain,hauntsaninja,2022-12-19,, +Kumar Aditya,kumaraditya303,2022-11-21,, +Hugo van Kemenade,hugovk,2022-11-21,, +Alex Waygood,AlexWaygood,2022-10-18,, +Filipe Laíns,FFY00,2022-10-17,, +Erlend Egeberg Aasland,erlend-aasland,2022-05-05,, +Jelle Zijlstra,JelleZijlstra,2022-02-15,, +Dennis Sweeney,sweeneyde,2022-02-02,, +Ken Jin,Fidget-Spinner,2021-08-26,, +Ammar Askar,ammaraskar,2021-07-30,, +Irit Katriel,iritkatriel,2021-05-10,, +Batuhan Taskaya,isidentical,2020-11-08,, +Brandt Bucher,brandtbucher,2020-09-14,, +Lysandros Nikolaou,lysnikolaou,2020-06-29,, +Kyle Stanley,aeros,2020-04-14,, +Donghee Na,corona10,2020-04-08,, +Karthikeyan Singaravelan,tirkarthi,2019-12-31,, +Joannah Nanjekye,nanjekyejoannah,2019-09-23,, +Abhilash Raj,maxking,2019-08-06,2022-11-30,Privileges relinquished on 2022-11-30 +Paul Ganssle,pganssle,2019-06-15,, +Stéphane Wirtel,matrixise,2019-04-08,, +Stefan Behnel,scoder,2019-04-08,, +Cheryl Sabella,csabella,2019-02-19,, +Lisa Roach,lisroach,2018-09-14,, +Emily Morehouse,emilyemorehouse,2018-09-14,, +Pablo Galindo,pablogsal,2018-06-06,, +Mark Shannon,markshannon,2018-05-15,, +Petr Viktorin,encukou,2018-04-16,, +Nathaniel J. Smith,njsmith,2018-01-25,, +Julien Palard,JulienPalard,2017-12-08,, +Ivan Levkivskyi,ilevkivskyi,2017-12-06,, +Carol Willing,willingc,2017-05-24,, +Mariatta,Mariatta,2017-01-27,, +Xiang Zhang,zhangyangyu,2016-11-21,, +Inada Naoki,methane,2016-09-26,, +Xavier de Gaye,xdegaye,2016-06-03,2018-01-25,Privileges relinquished on 2018-01-25 +Davin Potts,applio,2016-03-06,, +Martin Panter,vadmium,2015-08-10,2020-11-26, +Paul Moore,pfmoore,2015-03-15,, +Robert Collins,rbtcollins,2014-10-16,2021-11-30,To work on unittest; privileges relinquished on 2021-11-30 +Berker Peksağ,berkerpeksag,2014-06-26,, +Steve Dower,zooba,2014-05-10,, +Kushal Das,kushaldas,2014-04-14,, +Steven D'Aprano,stevendaprano,2014-02-08,,For statistics module +Yury Selivanov,1st1,2014-01-23,, +Zachary Ware,zware,2013-11-02,, +Donald Stufft,dstufft,2013-08-14,, +Ethan Furman,ethanfurman,2013-05-11,, +Serhiy Storchaka,serhiy-storchaka,2012-12-26,, +Chris Jerdonek,cjerdonek,2012-09-24,, +Eric Snow,ericsnowcurrently,2012-09-05,, +Peter Moody,,2012-05-20,2017-02-10,For ipaddress module; did not make GitHub transition +Hynek Schlawack,hynek,2012-05-14,, +Richard Oudkerk,,2012-04-29,2017-02-10,For multiprocessing module; did not make GitHub transition +Andrew Svetlov,asvetlov,2012-03-13,,At PyCon sprint +Petri Lehtinen,akheron,2011-10-22,2020-11-12, +Meador Inge,meadori,2011-09-19,, +Jeremy Kloth,jkloth,2011-09-12,, +Sandro Tosi,sandrotosi,2011-08-01,, +Alex Gaynor,alex,2011-07-18,,For PyPy compatibility (since expanded scope) +Charles-François Natali,,2011-05-19,2017-02-10,Did not make GitHub transition +Nadeem Vawda,,2011-04-10,2017-02-10,Did not make GitHub transition +CF Bolz-Tereick,cfbolz,2011-03-21,,for stdlib compatibility work for PyPy +Jason R. Coombs,jaraco,2011-03-14,,For sprinting on distutils2 +Ross Lagerwall,,2011-03-13,2017-02-10,Did not make GitHub transition +Eli Bendersky,eliben,2011-01-11,2020-11-26,Relinquished privileges on 2020-11-26 +Ned Deily,ned-deily,2011-01-09,, +David Malcolm,davidmalcolm,2010-10-27,2020-11-12,relinquished privileges on 2020-11-12 +Tal Einat,taleinat,2010-10-04,,Initially for IDLE +Łukasz Langa,ambv,2010-09-08,, +Daniel Stutzbach,,2010-08-22,2017-02-10,Did not make GitHub transition +Éric Araujo,merwok,2010-08-10,, +Brian Quinlan,brianquinlan,2010-07-26,,For work related to PEP 3148 +Alexander Belopolsky,abalkin,2010-05-25,, +Tim Golden,tjguk,2010-04-21,, +Giampaolo Rodolà,giampaolo,2010-04-17,, +Jean-Paul Calderone,,2010-04-06,2017-02-10,Did not make GitHub transition +Brian Curtin,briancurtin,2010-03-24,, +Florent Xicluna,,2010-02-25,2017-02-10,Did not make GitHub transition +Dino Viehland,DinoV,2010-02-23,,For IronPython compatibility +Larry Hastings,larryhastings,2010-02-22,, +Victor Stinner,vstinner,2010-01-30,, +Stefan Krah,skrah,2010-01-05,2020-10-07,For the decimal module +Doug Hellmann,dhellmann,2009-09-20,2020-11-11,For documentation; relinquished privileges on 2020-11-11 +Frank Wierzbicki,,2009-08-02,2017-02-10,For Jython compatibility; did not make GitHub transition +Ezio Melotti,ezio-melotti,2009-06-07,,For documentation +Philip Jenvey,pjenvey,2009-05-07,2020-11-26,For Jython compatibility +Michael Foord,voidspace,2009-04-01,2025-01-24,For IronPython compatibility; deceased +R\. David Murray,bitdancer,2009-03-30,, +Chris Withers,cjw296,2009-03-08,, +Tarek Ziadé,tarekziade,2008-12-21,2017-02-10,For distutils module +Hirokazu Yamamoto,,2008-08-12,2017-02-10,For Windows build; did not make GitHub transition +Armin Ronacher,mitsuhiko,2008-07-23,,For documentation toolset and ast module +Antoine Pitrou,pitrou,2008-07-16,, +Senthil Kumaran,orsenthil,2008-06-16,, +Jesse Noller,,2008-06-16,2017-02-10,For multiprocessing module; did not make GitHub transition +Jesús Cea,jcea,2008-05-13,,For bsddb module +Guilherme Polo,,2008-04-24,2017-02-10,Did not make GitHub transition +Jeroen Ruigrok van der Werven,,2008-04-12,2017-02-10,For documentation; did not make GitHub transition +Benjamin Peterson,benjaminp,2008-03-25,,For bug triage +David Wolever,wolever,2008-03-17,2020-11-21,For 2to3 module +Trent Nelson,tpn,2008-03-17,, +Mark Dickinson,mdickinson,2008-01-06,2024-08-13,For maths-related work +Amaury Forgeot d'Arc,amauryfa,2007-11-09,2020-11-26,Relinquished privileges on 2020-11-26 +Christian Heimes,tiran,2007-10-31,, +Bill Janssen,,2007-08-28,2017-02-10,For ssl module; did not make GitHub transition +Jeffrey Yasskin,,2007-08-09,2017-02-10,Did not make GitHub transition +Mark Summerfield,,2007-08-01,2017-02-10,For documentation; did not make GitHub transition +Alexandre Vassalotti,avassalotti,2007-05-21,2020-11-12,For GSoC +Travis E. Oliphant,,2007-04-17,2017-02-10,Did not make GitHub transition +Eric V. Smith,ericvsmith,2007-02-28,,For PEP 3101 in a sandbox +Josiah Carlson,josiahcarlson,2007-01-06,2017-02-10,For asyncore and asynchat modules +Collin Winter,,2007-01-05,2017-02-10,For PEP access; did not make GitHub transition +Richard Jones,,2006-05-23,2017-02-10,For Need for Speed sprint; did not make GitHub transition +Kristján Valur Jónsson,,2006-05-17,2017-02-10,For Need for Speed sprint; did not make GitHub transition +Jack Diederich,jackdied,2006-05-17,2020-11-26,For Need for Speed sprint +Steven Bethard,,2006-04-27,2017-02-10,For PEP access and SourceForge maintenance; did not make GitHub transition +Gerhard Häring,,2006-04-23,2017-02-10,Did not make the GitHub transition +George Yoshida,,2006-04-17,2017-02-10,For tracker administration; did not make GitHub transition +Ronald Oussoren,ronaldoussoren,2006-03-03,,For Mac-related work +Alyssa Coghlan,ncoghlan,2005-10-16,,Also contributed as Nick Coghlan (prior to 2023-08-04) +Georg Brandl,birkenfeld,2005-05-28,, +Terry Jan Reedy,terryjreedy,2005-04-07,, +Bob Ippolito,etrepum,2005-03-02,2017-02-10,For Mac-related work +Peter Astrand,,2004-10-21,2017-02-10,Did not make GitHub transition +Facundo Batista,facundobatista,2004-10-16,, +Sean Reifschneider,,2004-09-17,2017-02-10,Did not make GitHub transition +Johannes Gijsbers,,2004-08-14,2005-07-27,Privileges relinquished on 2005-07-27 +Matthias Klose,doko42,2004-08-04,, +PJ Eby,pjeby,2004-03-24,2020-11-26,Relinquished privileges on 2020-11-26 +Vinay Sajip,vsajip,2004-02-20,, +Hye-Shik Chang,hyeshik,2003-12-10,2025-02-28,Privileges relinquished on 2025-02-28 +Armin Rigo,,2003-10-24,2012-06-01,Privileges relinquished in 2012 +Andrew McNamara,,2003-06-09,2017-02-10,Did not make GitHub transition +Samuele Pedroni,,2003-05-16,2017-02-10,Did not make GitHub transition +Alex Martelli,aleaxit,2003-04-22,, +Brett Cannon,brettcannon,2003-04-18,, +David Goodger,,2003-01-02,2017-02-10,Did not make GitHub transition +Gustavo Niemeyer,,2002-11-05,2017-02-10,Did not make GitHub transition +Tony Lownds,,2002-09-22,2017-02-10,Did not make GitHub transition +Steve Holden,holdenweb,2002-06-14,2017-02-10,"Relinquished privileges on 2005-04-07, + but granted again for Need for Speed sprint; did not make GitHub transition" +Christian Tismer,ctismer,2002-05-17,,For Need for Speed sprint +Jason Tishler,,2002-05-15,2017-02-10,Did not make GitHub transition +Walter Dörwald,doerwalter,2002-03-21,2021-11-16,Relinquished privileges on 2021-11-16 +Andrew MacIntyre,,2002-02-17,2016-01-02,Privileges relinquished 2016-01-02 +Gregory P. Smith,gpshead,2002-01-08,, +Anthony Baxter,,2001-12-21,2017-02-10,Did not make GitHub transition +Neal Norwitz,,2001-12-19,2017-02-10,Did not make GitHub transition +Raymond Hettinger,rhettinger,2001-12-10,, +Chui Tey,,2001-10-31,2017-02-10,Did not make GitHub transition +Michael W. Hudson,,2001-08-27,2017-02-10,Did not make GitHub transition +Finn Bock,,2001-08-23,2005-04-13,Privileges relinquished on 2005-04-13 +Piers Lauder,,2001-07-20,2017-02-10,Did not make GitHub transition +Kurt B. Kaiser,kbkaiser,2001-07-03,, +Steven M. Gava,,2001-06-25,2017-02-10,Did not make GitHub transition +Steve Purcell,,2001-03-22,2017-02-10,Did not make GitHub transition +Jim Fulton,,2000-10-06,2017-02-10,Did not make GitHub transition +Ka-Ping Yee,,2000-10-03,2017-02-10,Did not make GitHub transition +Lars Gustäbel,gustaebel,2000-09-21,2020-11-26,For tarfile module +Neil Schemenauer,nascheme,2000-09-15,, +Martin v. Löwis,,2000-09-08,2017-02-10,Did not make GitHub transition +Thomas Heller,theller,2000-09-07,2020-11-18, +Moshe Zadka,,2000-07-29,2005-04-08,Privileges relinquished on 2005-04-08 +Thomas Wouters,Yhg1s,2000-07-14,, +Peter Schneider-Kamp,,2000-07-10,2017-02-10,Did not make GitHub transition +Paul Prescod,,2000-07-01,2005-04-30,Privileges relinquished on 2005-04-30 +Tim Peters,tim-one,2000-06-30,, +Skip Montanaro,smontanaro,2000-06-30,2015-04-21,Privileges relinquished 2015-04-21 +Fredrik Lundh,,2000-06-29,2017-02-10,Did not make GitHub transition +Mark Hammond,mhammond,2000-06-09,, +Marc-André Lemburg,malemburg,2000-06-07,, +Trent Mick,,2000-06-06,2017-02-10,Did not make GitHub transition +Eric S. Raymond,,2000-06-02,2017-02-10,Did not make GitHub transition +Greg Stein,,1999-11-07,2017-02-10,Did not make GitHub transition +Just van Rossum,,1999-01-22,2017-02-10,Did not make GitHub transition +Greg Ward,,1998-12-18,2017-02-10,Did not make GitHub transition +Andrew Kuchling,akuchling,1998-04-09,2022-11-09,Privileges relinquished 2022-11-09 +Ken Manheimer,,1998-03-03,2005-04-08,Privileges relinquished on 2005-04-08 +Jeremy Hylton,jeremyhylton,1997-08-13,, +Roger E. Masse,,1996-12-09,2017-02-10,Did not make GitHub transition +Fred Drake,freddrake,1996-07-23,, +Barry Warsaw,warsaw,1994-07-25,, +Jack Jansen,jackjansen,1992-08-13,, +Sjoerd Mullender,sjoerdmullender,1992-08-04,2020-11-14, +Guido van Rossum,gvanrossum,1989-12-25,, diff --git a/core-team/experts.rst b/core-team/experts.rst new file mode 100644 index 0000000000..47e1d76107 --- /dev/null +++ b/core-team/experts.rst @@ -0,0 +1,468 @@ +.. _experts: + +============= +Experts index +============= + +This document has tables that list Python Modules, Tools, Platforms and +Interest Areas and GitHub names for each item that indicate a maintainer or +an expert in the field. This list is intended to be used by issue submitters, +issue triage people, and other issue participants to find people to @mention +or add as reviewers to issues and pull requests. People on this list may be +asked to render final judgment on a feature or bug. If no active maintainer +is listed for a given module, then questionable changes should be discussed +on the `Core Development Discourse category +<https://discuss.python.org/c/core-dev/23>`__, +while any other issues can and should be decided by any committer. + +Developers can choose to follow labels, so if a label that they are +following is added to an issue or pull request, they will be notified +automatically. The :cpy-file:`.github/CODEOWNERS` file is also used to indicate +maintainers that will be automatically added as reviewers to pull requests. + +Names followed by a '*' may be assigned issues involving the module or topic. +Unless a name is followed by a '*', you should never assign an issue to +that person. + +The Platform and Interest Area tables list broader fields in which various +people have expertise. These people can also be contacted for help, +opinions, and decisions when issues involve their areas. + +If a listed maintainer does not respond to requests for comment for an +extended period (three weeks or more), they should be marked as inactive +in this list by placing the word 'inactive' in parenthesis behind their +tracker id. They are of course free to remove that inactive mark at +any time. + +Committers should update these tables as their areas of expertise widen. +New topics may be added to the Interest Area table at will. + +The existence of this list is not meant to indicate that these people +*must* be contacted for decisions; it is, rather, a resource to be used +by non-committers to find responsible parties, and by committers who do +not feel qualified to make a decision in a particular context. + + +Stdlib +====== + +==================== ============================================= +Module Maintainers +==================== ============================================= +__main__ gvanrossum, ncoghlan +annotationlib JelleZijlstra* +argparse savannahostrowski*, serhiy-storchaka* +ast benjaminp, pablogsal, isidentical, JelleZijlstra, eclips4 +asyncio 1st1, asvetlov, gvanrossum, graingert, kumaraditya303, willingc +bisect rhettinger* +codecs malemburg +collections rhettinger* +collections.abc rhettinger* +compileall carljm +compression.zlib Yhg1s, gpshead*, emmatyping +compression.zstd emmatyping* +concurrent.futures pitrou, gpshead* +configparser ambv* +contextlib ncoghlan, 1st1 +copy serhiy-storchaka* +copyreg serhiy-storchaka* +csv serhiy-storchaka* +curses Yhg1s +dataclasses ericvsmith*, carljm +datetime pganssle, StanFromIreland +decimal facundobatista, rhettinger +dis 1st1 +email warsaw, bitdancer* +encodings malemburg +ensurepip ncoghlan, dstufft, pradyunsg, pfmoore +enum warsaw, ethanfurman* +errno Yhg1s +faulthandler vstinner, gpshead, ZeroIntensity* +fcntl Yhg1s +fnmatch serhiy-storchaka* +ftplib giampaolo* +functools rhettinger* +gc pitrou, pablogsal, nascheme +getopt serhiy-storchaka* +getpath FFY00* +gettext tomasr8 +glob serhiy-storchaka* +hashlib tiran, gpshead*, picnixz +heapq rhettinger* +hmac tiran, gpshead*, picnixz +html ezio-melotti* +idlelib terryjreedy*, taleinat +importlib brettcannon, FFY00* +inspect 1st1 +io benjaminp +itertools rhettinger* +json ezio-melotti, rhettinger, serhiy-storchaka* +locale malemburg +logging vsajip +math rhettinger +mmap Yhg1s +modulefinder FFY00 +multiprocessing pitrou, gpshead* +optparse serhiy-storchaka* +os.path serhiy-storchaka* +parser pablogsal +pathlib barneygale* +pdb gaogaotiantian +pickle serhiy-storchaka* +pickletools serhiy-storchaka* +pkgutil FFY00* +platform malemburg +posix larryhastings, gpshead +pty Yhg1s* +py_compile carljm +pyclbr isidentical +pydoc AA-Turner, serhiy-storchaka* +queue rhettinger* +random rhettinger +re ezio-melotti, serhiy-storchaka* +readline Yhg1s +resource Yhg1s +runpy ncoghlan, FFY00 +selectors giampaolo +shutil giampaolo +signal gpshead +site FFY00* +socket gpshead +sqlite3 erlend-aasland* +ssl tiran, dstufft, alex +stat tiran +statistics rhettinger +subprocess giampaolo, gpshead* +symtable benjaminp +sysconfig FFY00* +tempfile serhiy-storchaka* +termios Yhg1s +test ezio-melotti, serhiy-storchaka* +threading pitrou, gpshead +time pganssle, StanFromIreland +tkinter serhiy-storchaka* +tomllib hauntsaninja* +traceback iritkatriel +tracemalloc vstinner +tty Yhg1s* +turtle willingc +turtledemo terryjreedy* +types 1st1 +typing gvanrossum, JelleZijlstra*, AlexWaygood*, carljm, sobolevn* +unicodedata malemburg, ezio-melotti +unittest ezio-melotti, gpshead, serhiy-storchaka* +urllib orsenthil +venv vsajip, FFY00* +weakref nascheme +xml.etree scoder +zipapp pfmoore +zipfile serhiy-storchaka, Yhg1s, gpshead +zipimport Yhg1s* +zoneinfo pganssle, StanFromIreland +==================== ============================================= + + +Tools +===== + +================== =========== +Tool Maintainers +================== =========== +Argument Clinic larryhastings, AlexWaygood*, erlend-aasland, + serhiy-storchaka* +Deepfreeze gvanrossum, kumaraditya303 +PEG Generator gvanrossum, pablogsal, lysnikolaou +================== =========== + + +.. _platform-experts: + +Platforms +========= + +For official contacts for supported platforms, see :pep:`11`. + +Platforms listed here are not necessarily supported by CPython. +Some of the experts listed here maintain and distribute Python +for “their” platform as a third-party project. + +=================== =========== +Platform Maintainers +=================== =========== +AIX ayappanec +Android mhsmith +Emscripten hoodmane, pmp-p, rdb, rth, ryanking13 +iOS freakboy3742, ned-deily +macOS ronaldoussoren, ned-deily, freakboy3742 +Solaris/OpenIndiana jcea, kulikjak +Windows tjguk, zooba, pfmoore +=================== =========== + + +Miscellaneous +============= + +================== ========================================================== +Interest area Maintainers +================== ========================================================== +algorithms rhettinger*, serhiy-storchaka +argument clinic larryhastings, AlexWaygood*, erlend-aasland, + serhiy-storchaka* +AST/compiler benjaminp, 1st1, pablogsal, markshannon, isidentical, brandtbucher, carljm, iritkatriel +autoconf/makefiles Yhg1s*, emmatyping +issue tracker ezio-melotti +buildbots zware, pablogsal +bytecode benjaminp, 1st1, markshannon, brandtbucher, carljm, iritkatriel +context managers ncoghlan +core workflow Mariatta, ezio-melotti, hugovk, AA-Turner +cryptography gpshead, dstufft, picnixz +database malemburg +devguide merwok, ezio-melotti, willingc, Mariatta, hugovk, + AA-Turner, StanFromIreland +documentation ezio-melotti, merwok, JulienPalard, willingc, hugovk, + AA-Turner, AlexWaygood*, StanFromIreland +emoji Mariatta +extension modules encukou, ncoghlan, FFY00 +frozen modules ericsnowcurrently, gvanrossum, kumaraditya303, FFY00 +f-strings ericvsmith* +i18n malemburg, merwok, tomasr8, StanFromIreland +import machinery brettcannon, ncoghlan, ericsnowcurrently, FFY00* +initialization FFY00* +io benjaminp, gpshead +JIT brandtbucher*, savannahostrowski* +locale malemburg +mathematics malemburg, rhettinger, serhiy-storchaka +memory management tim-one, malemburg, Yhg1s, nascheme +networking gpshead +object model benjaminp, Yhg1s +packaging malemburg, merwok, dstufft, pfmoore, emmatyping, FFY00 +pattern matching brandtbucher* +PEG parser gvanrossum, pablogsal, lysnikolaou +performance vstinner, serhiy-storchaka*, 1st1, rhettinger, markshannon, + brandtbucher, carljm, Fidget-Spinner, AlexWaygood*, nascheme +pip ncoghlan, dstufft, pfmoore, pradyunsg +release management malemburg, benjaminp, warsaw, + gvanrossum, merwok, ned-deily, + JulienPalard, hugovk +runtime lifecycle ericsnowcurrently, kumaraditya303, zooba, ZeroIntensity, nascheme, FFY00 +str.format ericvsmith* +subinterpreters ericsnowcurrently, kumaraditya303, ZeroIntensity* +symbol table JelleZijlstra, carljm +testing ezio-melotti +threads gpshead +time and dates malemburg, pganssle, StanFromIreland +Unicode malemburg, ezio-melotti, benjaminp +version control merwok, ezio-melotti +================== ========================================================== + + +Experts emeritus +================ + +Names followed by a '^' indicate old bugs.python.org usernames, for people +that did not transition to GitHub. + +Stdlib +------ + +.. list-table:: + + * - Module + - Expert + + * - codecs + - doerwalter + + * - collections.abc + - stutzbach^ + + * - concurrent.futures + - brianquinlan + + * - copy + - avassalotti + + * - copyreg + - avassalotti + + * - csv + - smontanaro + + * - ctypes + - theller, abalkin, amauryfa, meadori + + * - datetime + - abalkin + + * - difflib + - tim-one + + * - doctest + - tim-one + + * - email + - maxking + + * - enum + - eliben + + * - heapq + - stutzbach + + * - idlelib + - kbkaiser, serwy + + * - io + - stutzbach^ + + * - ipaddress + - pmoody^ + + * - json + - etrepum + + * - math + - stutzbach^ + + * - modulefinder + - theller, jvr^ + + * - multiprocessing + - applio, jnoller^, sbt^ + + * - optparse + - mitsuhiko + + * - pickle + - avassalotti + + * - pickletools + - avassalotti + + * - pprint + - freddrake + + * - selectors + - neologix^ + + * - shutil + - tarekziade + + * - sqlite3 + - ghaering^ + + * - ssl + - jackjansen + + * - statistics + - stevendaprano + + * - struct + - meadori + + * - subprocess + - astrand^ + + * - syslog + - jafo^ + + * - tabnanny + - tim-one + + * - tarfile + - gustaebel + + * - time + - abalkin + + * - tkinter + - gpolo^ + + * - tokenize + - meadori + + * - trace + - abalkin + + * - turtle + - gregorlingl^ + + * - unittest + - rbtcollins + + * - weakref + - freddrake + + * - winreg + - stutzbach^ + + * - wsgiref + - pjenvey + + * - xml.etree + - eliben + + * - zipfile + - alanmcintyre^ + +Platforms +--------- + +.. list-table:: + + * - Platform + - Expert + + * - AIX + - edelsohn + + * - Cygwin + - jlt63^, stutzbach^ + + * - JVM/Java + - frank.wierzbicki^ + + * - OS2/EMX + - aimacintyre^ + + +Miscellaneous +------------- + +.. list-table:: + + * - Interest Area + - Expert + + * - filesystem + - giampaolo + + * - io + - stutzbach^ + + * - mathematics + - stutzbach^ + + * - networking + - giampaolo + + * - packaging + - tarekziade, alexis^ + + * - pip + - Marcus.Smith^ + + * - release management + - tarekziade, anthonybaxter^, birkenfeld + + * - time and dates + - abalkin + + +Documentation translations +========================== + +Translations are within the charter of +`Editorial Board <https://python.github.io/editorial-board/>`__. +For a list of translations and their coordinators, see +:ref:`this table of translations <translation-coordinators>`. diff --git a/core-team/index.rst b/core-team/index.rst new file mode 100644 index 0000000000..f8dafe05ee --- /dev/null +++ b/core-team/index.rst @@ -0,0 +1,17 @@ +.. _core-dev: +.. _core-team: + +========= +Core team +========= + +.. toctree:: + :maxdepth: 5 + + responsibilities + committing + experts + team-log + motivations + join-team + memorialization diff --git a/core-team/join-team.rst b/core-team/join-team.rst new file mode 100644 index 0000000000..20ce9e4c98 --- /dev/null +++ b/core-team/join-team.rst @@ -0,0 +1,116 @@ +.. _become-core-developer: +.. _coredev: +.. _join-core-team: + +========================= +How to join the core team +========================= + +What it takes +============= + +When you have consistently made contributions which meet quality standards +without requiring extensive rewrites prior to being committed, +you may qualify for commit privileges and join the core team of Python. +You must also work well with other core team members (and people in general) +as you become an ambassador for the Python project. + +Typically a core team member will offer you the chance to gain commit privilege. +The person making the offer will become your mentor and watch your commits for +a while to make sure you understand the development process. If other core +developers agree that you should gain commit privileges you are then extended +an official offer. How core team members come to that agreement are outlined in +:pep:`13`. + + +Gaining commit privileges +========================= + +After a candidate has demonstrated consistent contributions, commit privileges +are granted through these steps: + +#. A core team member (submitter, usually the mentor) starts a poll + (see the :ref:`template <coredev-template>` below) in + the `Committers category`_ on the `Python Discourse`_. + + - open for 7 days + - results shown only upon closing + +#. If the candidate receives at least two-thirds positive votes when the poll closes + (as per :pep:`13`), the submitter `emails the steering council + <mailto:steering-council@python.org>`_ with the candidate's email address + requesting that the council either accept or reject the proposed membership. Technically, the + council may only `veto a positive vote <https://peps.python.org/pep-0013/#membership>`__. + +#. Assuming the steering council does not veto the positive vote, a member of the council or its + delegate (approver, usually in practice a :ref:`Developer-in-Residence <current owners>`) will + email the candidate: + + - A request for account details as required by + `🔒 python/voters <https://github.com/python/voters>`__. + - A reminder about the `Code of Conduct`_ and guidance on reporting issues + to the PSF Conduct WG. + +#. Once the candidate has provided the pertinent details, the approver will: + + - Enable the various new privileges. + - Remove the new committer from the triage team, if applicable. + - Add their details to `🔒 python/voters <https://github.com/python/voters>`__. + - Once the python/voters update is merged, regenerate the public team membership + list at :ref:`developers`. + See "Public list of members" in the ``voters`` README. + - Post an announcement in the `Committers Discourse category + <https://discuss.python.org/c/committers/5>`__. The past few announcements + were in the form of a separate post on the already open topic with + the poll. + +Getting a python.org email address +---------------------------------- + +Members of the core team can get an email address on the python.org domain. +For more details refer to the `python.org email policy +<https://www.python.org/psf/records/board/policies/email/>`__. + + +Poll template +============= + +.. _coredev-template: + +While Discourse uses Markdown for formatting, the poll functionality is +custom and somewhat resembles BBcode. There's a creator for polls in the +UI (click the cog icon in the edit box toolbar and choose "Build Poll"). +Here's what it outputs, you can copy and paste it for your poll: + +.. code-block:: bbcode + + [poll type=regular results=on_close public=false chartType=bar groups=committers close=2024-07-15T21:15:00.000Z] + * Promote Basil Fawlty + * Do not promote + [/poll] + +The important options in the poll builder set to get this result: + +- Show who voted: **disabled** (``public=false``) +- Limit voting to these groups: **committers** (``groups=committers``) +- Automatically close poll: **in 7 days** (``close=...``) +- Show results: **When poll is closed** (``results=on_close``) + +.. raw:: html + + <script> + for (let span of document.querySelectorAll('span')) { + if (span.textContent === '2024-07-15T21:15:00.000Z') { + const nextWeek = new Date(); + nextWeek.setDate(nextWeek.getDate() + 7); + nextWeek.setSeconds(0); + nextWeek.setMilliseconds(0); + span.textContent = nextWeek.toISOString(); + break; + } + } + </script> + +.. _Code of Conduct: https://policies.python.org/python.org/code-of-conduct/ +.. _Committers category: https://discuss.python.org/c/committers/5 +.. _Python Discourse: https://discuss.python.org diff --git a/core-team/memorialization.rst b/core-team/memorialization.rst new file mode 100644 index 0000000000..3d893a3029 --- /dev/null +++ b/core-team/memorialization.rst @@ -0,0 +1,159 @@ +.. _memorialize-core-developer: +.. _memorialize-core-team-member: + +=============== +Memorialization +=============== + +Rationale +========= + +When a core team member passes away, memorializing accounts helps create +a space for remembering the contributor and protects against attempted +logins and fraudulent activity. + +The process +=========== + +The memorialization process is performed by a member of the PSF staff +with administrative access to current and historical systems where +the core team has access. + +After the status of the core team member in question is confirmed, +access to the systems listed below is revoked and some changes are +made to how the user displays to others. + +To respect the choices that someone made while alive, we aim to preserve +content of their accounts without changes after they've passed away. +To support the bereaved, in some instances, we may remove or change +certain content when the legacy contact or family members request it. + +GitHub +------ + +* The user is removed from the `python/ <https://github.com/orgs/python/>`__ + organization on GitHub; +* The user is removed from the `psf/ <https://github.com/orgs/psf/>`__ + organization on GitHub; +* The user is removed from the `pypa/ <https://github.com/orgs/pypa/>`__ + organization on GitHub. + +The PSF staff does not follow up with GitHub with regards to GitHub account +cancellation as this action is reserved for next-of-kin or designated by +the deceased GitHub user to act as an account successor. + +The general policy regarding deceased users on GitHub is described on their +`Deceased User Policy <https://docs.github.com/en/site-policy/other-site-policies/github-deceased-user-policy>`__ +page. + +Repositories in the organization +-------------------------------- + +* The user's GitHub handle is removed from ``/.github/CODEOWNERS``. + To see all that need action, perform + `this query <https://github.com/search?q=org%3Apython+path%3A**%2F.github%2FCODEOWNERS+USERNAME&type=code>`__. +* The user is marked as deceased in the private + `voters/python-core.toml <https://github.com/python/voters/blob/main/python-core.toml>`__ + file with the ``left=`` field set to the day of passing, if known. + +discuss.python.org +------------------ + +* The user's "custom status" is set to 🕊 ``in memoriam``; +* The user's "about me" is amended with ``$firstname passed away on $date. [In memoriam.]($in_memoriam_post_url)``; +* In the user's security "recently used devices" the staff member + chooses "Log out all"; +* In the user's permissions the staff member chooses "Deactivate account"; +* The user's trust level is reset to ``1: basic user`` (trust level 0 + doesn't allow links in "About Me"); +* The user's "associated accounts" (like GitHub) that provide an + alternative login method, are all disconnected; +* The user's API keys are revoked; +* The user's admin or moderator right is revoked; +* The user's primary email address is reset to + ``USERNAME@in-memoriam.invalid`` and secondary email addresses are + removed (this step requires the administrator to contact Discourse.org + staff via ``team@discourse.org``). + +The "in memoriam" Discourse topic mentioned above is best created by +a community member close to the deceased. + +The general best practice for deceased community members on +Discourse-powered forums is described on their +`Best practices for deceased community members <https://meta.discourse.org/t/best-practices-for-deceased-community-members/146210>`__ +page. + +python.org email account +------------------------ + +The PSF staff member emails ``postmaster@python.org`` to ask the email +administrator to: + +* remove SMTP access from ``USERNAME@python.org``; +* reset the password to POP3/IMAP for ``USERNAME@python.org``; +* disable email forwarding, if set up, for ``USERNAME@python.org`` and + leave a record permanently as "in memoriam" to avoid future account + name reuse; +* remove this email from all mailing lists under ``@python.org``; +* remove any known alternate emails for the same user from all mailing + lists under ``@python.org``. + +In case the email shutdown causes issues for the estate executors, the +PSF will reasonably try to help if contacted directly. + +python.org admin +---------------- + +* The user's account (``/admin/users/user``) is deactivated (NOT deleted) + and their staff and superuser status is unchecked; +* The user's password is reset to a long random string; +* The user's primary email address is set to + ``USERNAME@in-memoriam.invalid`` and set as unverified; +* The user's secondary email addresses are deleted; +* The user's API keys (both on the account and ``tastypie``) are deleted; +* The user's "I would like to be a PSF Voting Member" field is cleared. + +devguide.python.org +------------------- + +* The user is marked as deceased in `core-team.csv <https://github.com/python/devguide/blob/main/core-team/core-team.csv>`__; +* The user is removed from the `experts index <https://github.com/python/devguide/blob/main/core-team/experts.rst>`__. + +bugs.python.org +--------------- + +While the issue tracker was migrated to GitHub, the Roundup instance +is still up for historical purposes. + +* the PSF staff member logs into ``bugs.nyc1.psf.io``; +* the PSF staff member runs ``roundup-admin`` to set the user's email + address to ``USERNAME@in-memoriam.invalid``; +* the user's alternate emails are removed; +* the user's password is reset to a long random string; +* the PSF staff member removes any active login sessions from Postgres. + +Other PSF-related infrastructure +-------------------------------- + +* The PSF staff member notifies administrators of the Python Core Devs + Discord server to remove the user from the server. The PSF staff + does not follow up with Discord with regards to Discord account + cancellation. The general policy regarding deceased users on Discord + is available on their `Deceased or Incapacitated Users <https://support.discord.com/hc/en-us/articles/19872987802263--Deceased-or-Incapacitated-Users>`__ + page. + +* The user is removed from Salt configuration for the PSF infrastructure + in `/pillar/base/users <https://github.com/python/psf-salt/tree/main/pillar/base/users>`__ + that allows SSH access to PSF-controlled servers. + +* The user might have ran a buildbot worker. The PSF staff member will + look for that in the + `buildmaster-config <https://github.com/search?q=repo%3Apython%2Fbuildmaster-config%20USERNAME&type=code>`__ + repository. + +PyPI +---- + +* The PSF staff member notifies PyPI admins by emailing them at + ``admin@pypi.org`` to mark the user as inactive, remove their email + addresses, prohibit their password resets, and revoke all API keys. diff --git a/motivations.rst b/core-team/motivations.rst similarity index 67% rename from motivations.rst rename to core-team/motivations.rst index e5ed47930d..d0e5a0cc18 100644 --- a/motivations.rst +++ b/core-team/motivations.rst @@ -1,24 +1,25 @@ .. _motivations: -Core Developer Motivations and Affiliations -=========================================== +============================ +Motivations and affiliations +============================ -CPython core developers participate in the core development process for a -variety of reasons. Being accepted as a core developer indicates that +CPython core team members participate in the core development process for a +variety of reasons. Being accepted as a core team member indicates that an individual is interested in acquiring those responsibilities, has the -ability to collaborate effectively with existing core developers, and has had +ability to collaborate effectively with existing core team members, and has had the time available to demonstrate both that interest and that ability. -This page allows core developers that choose to do so to provide more +This page allows core team members that choose to do so to provide more information to the rest of the Python community regarding their personal situation (such as their general location and professional affiliations), as well as any personal motivations that they consider particularly relevant. -Core developers that wish to provide this additional information add a new +Core team members that wish to provide this additional information add a new entry to the :ref:`published-motivations` section below. Guidelines relating to content and layout are included as comments in the source code for this page. -Core developers that are available for training, consulting, contract, or +Core team members who are available for training, consulting, contract, or full-time work, or are seeking crowdfunding support for their community contributions, may also choose to provide that information here (including linking out to commercial sites with the relevant details). @@ -29,9 +30,9 @@ For more information on the origins and purpose of this page, see .. _published-motivations: Published entries ------------------ +================= -The following core developers have chosen to provide additional details +The following core team members have chosen to provide additional details regarding their professional affiliations and (optionally) other reasons for participating in the CPython core development process: @@ -42,7 +43,7 @@ participating in the CPython core development process: Topic headings should be in the form of "Name (Country)" or "Name (Continent)" to help give some indication as to the geographic - distribution of core developers. + distribution of core team members. NOTE: The rest of these guidelines are highly provisional - we can evolve them as people add entries, and we decide on the style we like. The @@ -79,7 +80,7 @@ participating in the CPython core development process: country of residence. Include a "Crowdfunding" bullet point with a link if you'd like to highlight - crowdfunding services (e.g. Patreon) that folks can use to support your core + crowdfunding services (for example, Patreon) that folks can use to support your core development work. Include additional bullet points (without links) for any other affiliations @@ -87,46 +88,51 @@ participating in the CPython core development process: If there's a kind of link you'd like to include in your entry that isn't already covered by the categories mentioned above, please start a discussion - about that on the python-committers mailing list. + about that on the Committers category on the Python Discourse + (discuss.python.org). - python-committers is also the appropriate point of contact for any other + The Committers Discourse category + is also the appropriate point of contact for any other questions or suggestions relating to this page. .. topic:: Brett Cannon (Canada) - * Personal site: `snarky.ca <https://snarky.ca/>`_ - * `Extended bio <https://stackoverflow.com/cv/DrBrettCannon>`__ + * Personal site: `snarky.ca <https://snarky.ca/>`__ * Microsoft (Software Developer) * Python Software Foundation (Fellow) -.. topic:: Nick Coghlan (Australia) +.. topic:: Alyssa Coghlan (Australia) - * Personal site: `Curious Efficiency <https://www.curiousefficiency.org/>`_ + * Personal site: `Curious Efficiency <https://www.curiousefficiency.org/>`__ * `Extended bio <https://www.curiousefficiency.org/pages/about>`__ - * `Tritium <https://www.tritium.com.au/>`__ (Software Developer) * Python Software Foundation (Fellow, Packaging Working Group) + * Westpac (Principal Python Engineer) - Nick began using Python as a testing and prototyping language while working - for Boeing Defence Australia, and continues to use it for that purpose today. + Alyssa began using Python as a testing and prototyping language while working + for Boeing Defence Australia, and now works for Westpac, supporting their + use of Python for a range of purposes. - As a core developer, he is primarily interested in helping to ensure Python's + As a core team member, she is primarily interested in helping to ensure Python's continued suitability for educational, testing and data analysis use cases, as well as in encouraging good architectural practices when assembling Python applications and test harnesses from open source components. + Note: prior to August 2023, Alyssa used her birth name (Nick Coghlan). Some records + (for example, mailing list archives, version control history) will still reference that name. + .. topic:: Steve Dower (United States/Australia) * Microsoft (Software Developer) - * Personal site: `stevedower.id.au <https://stevedower.id.au/>`_ - * Speaking: `stevedower.id.au/speaking <https://stevedower.id.au/speaking/>`_ - * Work blog: `aka.ms/pythonblog <https://aka.ms/pythonblog>`_ + * Personal site: `stevedower.id.au <https://stevedower.id.au/>`__ + * Speaking: `stevedower.id.au/speaking <https://stevedower.id.au/speaking>`__ + * Work blog: `devblogs.microsoft.com/python/ <https://devblogs.microsoft.com/python/>`__ * Email address: steve.dower@python.org Steve started with Python while automating a test harness for medical devices, and now works for Microsoft on anything that makes Python more accessible to developers on any platform. - As a core developer, his focus is on maintaining the already excellent + As a core team member, his focus is on maintaining the already excellent Windows support and improving Python's ability to be embedded in other applications. @@ -137,25 +143,25 @@ participating in the CPython core development process: .. topic:: Mariatta (Canada) - * Personal site: `mariatta.ca <http://mariatta.ca>`_ - * Works as a `Software Engineer <https://www.linkedin.com/in/mariatta/>`_ + * Personal site: `mariatta.ca <https://mariatta.ca>`__ + * Works as a `Software Engineer <https://www.linkedin.com/in/mariatta/>`__ in Vancouver, helps organize `Vancouver PyLadies - <https://www.meetup.com/PyLadies-Vancouver/>`_ meetup on the side, and - sometimes `speaks <http://mariatta.ca/pages/talk-chronology.html#talk-chronology>`_ + <https://www.meetup.com/PyLadies-Vancouver/>`__ meetup on the side, and + sometimes `speaks <https://mariatta.ca/posts/talks/>`__ at conferences. * Email address: mariatta@python.org - * `Sponsor Mariatta on GitHub <https://github.com/users/Mariatta/sponsorship>`_ - * `Patreon <https://www.patreon.com/Mariatta>`_ + * `Sponsor Mariatta on GitHub <https://github.com/sponsors/Mariatta>`__ + * `Patreon <https://www.patreon.com/Mariatta>`__ - Support Mariatta by `becoming a sponsor <https://github.com/users/Mariatta/sponsorship>`_, - sending her a `happiness packet <https://www.happinesspackets.io/send/>`_, - or `paypal <https://www.paypal.me/mariatta>`_. + Support Mariatta by `becoming a sponsor <https://github.com/sponsors/Mariatta>`__, + sending her a `happiness packet <https://www.happinesspackets.io/send/>`__, + or `paypal <https://www.paypal.com/paypalme/mariatta>`__. .. topic:: R. David Murray (United States) - * Personal site: `bitdance.com <http://www.bitdance.com>`_ + * Personal site: `bitdance.com <https://www.bitdance.com>`__ * Available for `Python and Internet Services Consulting - and Python contract programming <http://www.murrayandwalker.com/>`_ + and Python contract programming <https://www.murrayandwalker.com/>`__ David has been involved in the Internet since the days when the old IBM BITNET and the ARPANet got cross connected, and in Python programming since @@ -164,16 +170,16 @@ participating in the CPython core development process: business started declining) to being a full time independent consultant, David started contributing directly to CPython development. He became a committer in 2009. He subsequently took over primary maintenance of the - email package from Barry Warsaw, and contributed the unicode oriented API. + email package from Barry Warsaw, and contributed the Unicode oriented API. David is also active in mentoring new contributors and, when time is available, working on the infrastructure that supports CPython development, specifically the Roundup-based bug tracker and the buildbot system. David currently does both proprietary and open source development work, primarily in Python, through the company in which he is a partner, `Murray & - Walker, Inc <http://www.murrayandwalker.com>`_. He has done contract work + Walker, Inc <https://www.murrayandwalker.com>`__. He has done contract work focused specifically on CPython development both through the PSF (the - kickstart of the email unicode API development) and directly funded by + kickstart of the email Unicode API development) and directly funded by interested corporations (additional development work on email funded by QNX, and work on CPython ICC support funded by Intel). He would like to spend more of his (and his company's) time on open source work, and so is @@ -181,24 +187,24 @@ participating in the CPython core development process: .. topic:: Antoine Pitrou (France) - * LinkedIn: `<https://www.linkedin.com/in/pitrou/>`_ (Senior Software Engineer) - * Independent (currently Ursa Labs / R Studio) + * LinkedIn: `<https://www.linkedin.com/in/pitrou/>`__ (Senior Software Engineer) + * QuantStack * Python Software Foundation (Fellow) - * Available for open source contract work * Email address: antoine@python.org Antoine started working with Python in 2005 in order to implement a decentralized virtual world protocol. He started contributing to CPython - in 2007 and became a core developer in 2008. His motivations have been + in 2007 and became a core team member in 2008. His motivations have been driven both by the abstract desire to make Python better for the whole world, and by the concrete roadblocks he was hitting in professional settings. Topics of choice have included interpreter optimizations, garbage collection, network programming, system programming and - concurrent programming (such as maintaining ``multiprocessing``). + concurrent programming. As a professional, Antoine has been first specializing in network - programming, and more lately in open source data science infrastructure - such as Dask, Numba, Apache Arrow. + programming, and more lately in open source data science infrastructure. + He has made numerous contributions to Numba, Dask and is currently working + full time on Apache Arrow as a technical leader at QuantStack. .. topic:: Victor Stinner (France) @@ -207,7 +213,7 @@ participating in the CPython core development process: Victor is paid by Red Hat to maintain Python upstream and downstream (RHEL, CentOS, Fedora & Software collections). See `Victor's contributions to - Python <http://vstinner.readthedocs.io/python_contrib.html>`_. + Python <https://vstinner.readthedocs.io/python_contrib.html>`__. .. topic:: Kushal Das (India) @@ -217,25 +223,23 @@ participating in the CPython core development process: .. topic:: Barry Warsaw (United States) - * `LinkedIn: <https://www.linkedin.com/in/barry-warsaw/>`_ (Senior Staff - Software Engineer - Python Foundation team) - * Personal site: `barry.warsaw.us <https://barry.warsaw.us/>`_ - * Blog: `We Fear Change <https://www.wefearchange.org/>`_ + * NVIDIA, Principal System Software Engineer, Open Source Python Ecosystem + * Personal site: `barry.warsaw.us <https://barry.warsaw.us/>`__ + * Blog: `We Fear Change <https://www.wefearchange.org/>`__ + * `LinkedIn <https://www.linkedin.com/in/barry-warsaw/>`__ + * `Bluesky <https://bsky.app/profile/pumpichank.bsky.social>`__ * Email address: barry@python.org * Python Software Foundation (Fellow) Barry has been working in, with, and on Python since 1994. He attended the - first Python workshop at NBS (now `NIST <https://www.nist.gov/>`_) in - Gaithersburg, MD in 1994, where he met Guido and several other early Python - adopters. Barry subsequently worked with Guido for 8 years while at `CNRI - <http://cnri.reston.va.us/>`_. From 2007 until 2017, Barry worked for - `Canonical <https://www.canonical.com/>`_, corporate sponsor of `Ubuntu - <https://www.ubuntu.com/>`_ Linux, primarily on the Python ecosystem, and - is both an Ubuntu and a `Debian <http://www.debian.org/>`_ uploading - developer. Barry has served as Python's postmaster, webmaster, release - manager, Language Summit co-chair, `Jython <http://www.jython.org/>`_ - project leader, `GNU Mailman <http://www.list.org/>`_ project leader, and - probably lots of other things he shouldn't admit to. + first Python workshop at `NIST <https://www.nist.gov/>`__ in Gaithersburg, + MD in 1994, where he met Guido and several other early Python adopters. + Barry subsequently worked with Guido for 8 years while at `CNRI + <http://cnri.reston.va.us/>`__. Barry has served as Python's postmaster, + webmaster, release manager, Language Summit co-chair, `Jython + <https://www.jython.org/>`__ project leader, `GNU Mailman + <https://www.list.org/>`__ project leader, and Python Steering Council + member in 2019, 2020, 2021, 2024, and 2025. .. topic:: Eric Snow (United States) @@ -244,42 +248,43 @@ participating in the CPython core development process: .. topic:: Dino Viehland (United States) - * Microsoft: `<https://notebooks.azure.com/>`_ (Software Engineer) - * Email address: dinov@microsoft.com + * Meta (Software Engineer) + * Email address: dinoviehland@gmail.com Dino started working with Python in 2005 by working on IronPython, an implementation of Python running on .NET. He was one of the primary developers on the project for 6 years. After that he started the Python Tools for Visual Studio project focusing on providing advanced code completion and debugging features for Python. Today he works on - `Azure Notebooks <http://notebooks.azure.com/>`_ bringing the Python based - Jupyter notebook as a hosted on-line service. + `Cinder <https://github.com/facebookincubator/cinder/>`__ improving Python + performance for Instagram. .. topic:: Carol Willing (United States) - * Personal site: `Willing Consulting <https://www.willingconsulting.com/>`_ + * Noteable (VP Engineering) + * Personal site: `Willing Consulting <https://www.willingconsulting.com/>`__ * `Extended bio <https://www.willingconsulting.com/about/>`__ - * Project Jupyter, Cal Poly SLO (Research Software Engineer) + * Project Jupyter (Software Council, Core Team for JupyterHub/Binder) * Python Software Foundation (Fellow) Carol is focused on Python's usage in education and scientific research. - She is interested in organizational development, operational workflows, - and sustainability of open source projects. + She is interested in distributed computing, organizational development, + operational workflows, and sustainability of open source projects. .. _goals-of-the-motivations-page: Goals of this page ------------------- +================== The `issue metrics`_ automatically collected by the CPython issue tracker strongly suggest that the current core development process is bottlenecked on -core developer time - this is most clearly indicated in the first metrics graph, -which shows both the number of open issues and the number of patches awaiting +core team time. This is most clearly indicated in the first metrics graph, +which shows both the number of open issues and the number of pull requests awaiting review growing steadily over time, despite CPython being one of the most active open source projects in the world. This bottleneck then impacts not only -resolving open issues and applying submitted patches, but also the process of -identifying, nominating and mentoring new core developers. +resolving open issues and accepting submitted pull requests, but also the process of +identifying, nominating and mentoring new core team members. The core commit statistics monitored by sites like `OpenHub`_ provide a good record as to *who* is currently handling the bulk of the review and maintenance @@ -288,13 +293,13 @@ people's ability to spend time on reviewing proposed changes, or mentoring new contributors. This page aims to provide at least some of that missing data by encouraging -core developers to highlight professional affiliations in the following two +core team members to highlight professional affiliations in the following two cases (even if not currently paid for time spent participating in the core development process): -* developers working for vendors that distribute a commercially supported +* members working for vendors that distribute a commercially supported Python runtime -* developers working for Sponsor Members of the Python Software Foundation +* members working for Sponsor Members of the Python Software Foundation These are cases where documenting our affiliations helps to improve the overall transparency of the core development process, as well as making it @@ -302,44 +307,44 @@ easier for staff at these organisations to locate colleagues that can help them to participate in and contribute effectively to supporting the core development process. -Core developers working for organisations with a vested interest in the +Core team members working for organisations with a vested interest in the sustainability of the CPython core development process are also encouraged to seek opportunities to spend work time on mentoring potential new core developers, whether through the general `core mentorship program`_, through mentoring colleagues, or through more targeted efforts like Outreachy's paid `internships`_ and Google's `Summer of Code`_. -Core developers that are available for consulting or contract work on behalf of +Core team members who are available for consulting or contract work on behalf of the Python Software Foundation or other organisations are also encouraged to provide that information here, as this will help the PSF to better facilitate funding of core development work by organisations that don't -directly employ any core developers themselves. +directly employ any core team members themselves. -Finally, some core developers seeking to increase the time they have available +Finally, some core team members seeking to increase the time they have available to contribute to CPython may wish to pursue crowdfunding efforts that allow their contributions to be funded directly by the community, rather than relying on institutional sponsors allowing them to spend some or all of their work time contributing to CPython development. .. _issue metrics: https://bugs.python.org/issue?@template=stats -.. _OpenHub: https://www.openhub.net/p/python/contributors +.. _OpenHub: https://openhub.net/p/python/contributors .. _core mentorship program: https://www.python.org/dev/core-mentorship/ -.. _internships: https://www.gnome.org/outreachy/ +.. _internships: https://www.outreachy.org/ .. _Summer of Code: https://wiki.python.org/moin/SummerOfCode/2016 Limitations on scope --------------------- +==================== -* Specific technical areas of interest for core developers should be captured in +* Specific technical areas of interest for core team members should be captured in the :ref:`Experts Index <experts>`. -* This specific listing is limited to CPython core developers (since it's - focused on the specific constraint that is core developer time), but it +* This specific listing is limited to CPython core team members (since it's + focused on the specific constraint that is core team member time), but it would be possible to create a more expansive listing on the Python wiki that - also covers issue triagers, and folks seeking to become core developers. + also covers issue triagers, and folks seeking to join the core team. -* Changes to the software and documentation maintained by core developers, +* Changes to the software and documentation maintained by the core team, together with related design discussions, all take place in public venues, and hence are inherently subject to full public review. Accordingly, core developers are NOT required to publish their motivations and affiliations if diff --git a/core-team/responsibilities.rst b/core-team/responsibilities.rst new file mode 100644 index 0000000000..9f5c62b728 --- /dev/null +++ b/core-team/responsibilities.rst @@ -0,0 +1,130 @@ +.. _responsibilities: + +================ +Responsibilities +================ + +As contributors to the CPython project, our shared responsibility is to +collaborate constructively with other contributors, including core team members. +This responsibility covers all forms of contribution, whether that's submitting +pull requests to the implementation or documentation, reviewing other peoples' +pull requests, triaging issues on the issue tracker, or discussing design and +development ideas on the core +:ref:`communication channels <communication-channels>`. + +Core team members accept key additional responsibilities around the ongoing +management of the project: + +* core team members bear the additional responsibility of handling the + consequences of accepting a change into the code base or documentation. + That includes reverting or fixing it if it causes problems in the + Buildbot fleet or someone spots a problem in post-commit review, as well + as helping out the release manager in resolving any problems found during + the pre-release testing cycle. While all contributors are free to help out + with this part of the process, and it is most welcome when they do, the + actual responsibility rests with the core team member that merged the change +* core team members also bear the primary responsibility for deciding when + changes proposed on the issue tracker should be escalated to + the appropriate :ref:`Discourse <communication-discourse>` category + for wider discussion, as well as suggesting the use of the + Python Enhancement Proposal process to manage the design and justification + of complex changes, or changes with a potentially significant impact on + end users + +As a result of the additional responsibilities they accept, core team members +gain the privilege of being able to approve proposed changes, as well as being +able to reject them as inappropriate. Core team members are also able to request +that even already merged changes be escalated to +:ref:`Discourse <communication-discourse>` for further discussion, +and potentially even reverted prior to release. + +Joining the core team isn't a binary "all-or-nothing" status - CPython +is a large project, and different core team members accept responsibility for +making design and development decisions in different areas (as documented +in the :ref:`experts` and :ref:`developers`). + + +Communication channels and bug notifications +============================================ + +Mailing lists have generally been replaced by the +`Discourse forum <https://discuss.python.org/>`__ (``discuss.python.org``). +Refer to the :ref:`mailinglists` and :ref:`communication-discourse` sections +for more information. + +If you want notification of new issues, you can use the appropriate GitHub notification +settings for the `python/cpython <https://github.com/python/cpython>`__ repository — +follow the link and click on the :guilabel:`Watch` button to set your notification options. + + +.. _contributor_agreement: + +Sign a contributor agreement +============================ + +Submitting a `contributor form for Python`_ licenses any code you contribute to +the Python Software Foundation. While you retain the copyright, giving the PSF +the ability to license your code means it can be put under the PSF license so +it can be legally distributed with Python. + +This is a very important step! Hopefully you have already submitted a +contributor agreement if you have been submitting pull requests. But if you have not +done this yet, it is best to do this ASAP, probably before you even do your +first commit so as to not forget. Also do not forget to enter your GitHub +username into your details on the issue tracker. + + +.. _contributor form for Python: https://www.python.org/psf/contrib/ + + +Pull request merging +==================== + +Once you have your commit privileges on GitHub you will be able to accept +pull requests on GitHub. You should plan to continue to submit your own +changes through pull requests as if you weren't a core team member to benefit +from various things such as automatic integration testing, but you +can accept your own pull requests if you feel comfortable doing so. + + +Expectations +============ + +As a core team member, there are certain things that are expected of you. + +First and foremost, be a good person. This might sound melodramatic, but you +are now a member of the Python project and thus represent the project and your +fellow core team members whenever you discuss Python with anyone. We have a +reputation for being a very nice group of people and we would like to keep it +that way. Core team responsibilities include following the `PSF Code of +Conduct`_. + +Second, please be prompt in responding to questions. Many contributors to Python +are volunteers so what little free time they can dedicate to Python should be +spent being productive. If you have been asked to respond to an issue or answer +a question and you put it off it ends up stalling other people's work. It is +completely acceptable to say you are too busy, but you need to say that instead +of leaving people waiting for an answer. This also applies to anything you +do on the issue tracker. + +Third, please list what areas you want to be considered an expert in the +:ref:`experts`. This allows triagers to direct issues to you which involve +an area you are an expert in. But, as stated in the second point above, if you +do not have the time to answer questions promptly then please remove yourself as +needed from the file so that you will not be bothered in the future. Once again, +we all understand how life gets in the way, so no one will be insulted if you +remove yourself from the list. + +Fourth, please consider whether or not you wish to add your name to the +:ref:`motivations` list. Core contributor participation in the list helps the +wider Python community to better appreciate the perspectives currently +represented amongst the core team, the Python Software Foundation +to better assess the sustainability of current contributions to CPython core +development, and also serves as a referral list for organisations seeking +commercial Python support from the core development community. + +And finally, enjoy yourself! Contributing to open source software should be fun +(overall). If you find yourself no longer enjoying the work then either take a +break or figure out what you need to do to make it enjoyable again. + +.. _PSF Code of Conduct: https://policies.python.org/python.org/code-of-conduct/ diff --git a/developers.rst b/core-team/team-log.rst similarity index 72% rename from developers.rst rename to core-team/team-log.rst index 5b61c706c2..77639ebf1d 100644 --- a/developers.rst +++ b/core-team/team-log.rst @@ -1,18 +1,20 @@ +.. _developer-log: .. _developers: +.. _team-log: -Developer Log -============= +Team log +======== -This page lists the historical members of the Python development team. (The +This page lists the historical members of the Python core team. (The master list is kept in a private repository due to containing sensitive contact information.) .. csv-table:: - :header: "Name", "Joined" - :file: developers.csv + :header: "Name", "GitHub username", "Joined", "Left", "Notes" + :file: core-team.csv :encoding: "utf-8" -Procedure for Granting or Dropping Access +Procedure for granting or dropping access ----------------------------------------- To be granted the ability to manage who is a committer, you must be a diff --git a/coredev.rst b/coredev.rst deleted file mode 100644 index a6810f6628..0000000000 --- a/coredev.rst +++ /dev/null @@ -1,179 +0,0 @@ -.. _coredev: - -How to Become a Core Developer -============================== - -What it Takes -------------- - -When you have consistently contributed patches which meet quality standards -without requiring extensive rewrites prior to being committed, -you may qualify for commit privileges and become a core developer of Python. -You must also work well with other core developers (and people in general) -as you become an ambassador for the Python project. - -Typically a core developer will offer you the chance to gain commit privilege. -The person making the offer will become your mentor and watch your commits for -a while to make sure you understand the development process. If other core -developers agree that you should gain commit privileges you are then extended -an official offer. - -What it Means -------------- - -As contributors to the CPython project, our shared responsibility is to -collaborate constructively with other contributors, including core developers. -This responsibility covers all forms of contribution, whether that's submitting -patches to the implementation or documentation, reviewing other peoples' -patches, triaging issues on the issue tracker, or discussing design and -development ideas on the core mailing lists. - -Core developers accept key additional responsibilities around the ongoing -management of the project: - -* core developers bear the additional responsibility of handling the - consequences of accepting a change into the code base or documentation. - That includes reverting or fixing it if it causes problems in the - Buildbot fleet or someone spots a problem in post-commit review, as well - as helping out the release manager in resolving any problems found during - the pre-release testing cycle. While all contributors are free to help out - with this part of the process, and it is most welcome when they do, the - actual responsibility rests with the core developer that merged the change -* core developers also bear the primary responsibility for deciding when - changes proposed on the issue tracker should be escalated to python-ideas - or python-dev for wider discussion, as well as suggesting the use of the - Python Enhancement Proposal process to manage the design and justification - of complex changes, or changes with a potentially significant impact on - end users - -As a result of the additional responsibilities they accept, core developers -gain the privilege of being able to approve proposed changes, as well as being -able to reject them as inappropriate. Core developers are also able to request -that even already merged changes be escalated to python-dev for further -discussion, and potentially even reverted prior to release. - -Becoming a core developer isn't a binary "all-or-nothing" status - CPython -is a large project, and different core developers accept responsibility for -making design and development decisions in different areas (as documented -in the :ref:`experts` and :ref:`developers`). - -Gaining Commit Privileges -------------------------- - -When you have been extended an official offer to become a Python core -developer, there are several things you must do. - -Mailing Lists -''''''''''''' - -You are expected to subscribe to python-committers, python-dev, -python-checkins, and one of new-bugs-announce or python-bugs-list. See -:ref:`communication` for links to these mailing lists. - - -Issue Tracker -''''''''''''' - -If you did not gain the Developer role in the `issue tracker`_ before gaining -commit privileges, please say so. The role allows issues to be assigned to you, -and it allows you to triage (e.g. close or reassign) issues. - -A tracker admin should also flip your "is committer" bit in the tracker's -account screen. This will add the Python logo next to your name in discussions -on the tracker. Note that this is separate from the Developer role. - -It is expected that on the issue tracker you have a username in the form of -"first_name.last_name". If your initial issue tracker username is not of this -form, please change it. This is so that it is easier to assign issues to the -right person. - - -GitHub -'''''' - -You will be added to the ``Python core team`` on GitHub. This will give you -rights to commit to various repositories under the `Python organization`_ -on GitHub. When you are initially added you will be emailed by GitHub with -an invitation to join the team. Please accept the invite in the email or -go to https://github.com/python and accept the invite there. - -An entry in the :ref:`developers` should also be entered for you. -Typically the person who sponsored your application to become a core developer -makes sure an entry is created for you. - -.. _Python organization: https://github.com/python - - -.. _contributor_agreement: - -Sign a Contributor Agreement -'''''''''''''''''''''''''''' - -Submitting a `contributor form for Python`_ licenses any code you contribute to -the Python Software Foundation. While you retain the copyright, giving the PSF -the ability to license your code means it can be put under the PSF license so -it can be legally distributed with Python. - -This is a very important step! Hopefully you have already submitted a -contributor agreement if you have been submitting patches. But if you have not -done this yet, it is best to do this ASAP, probably before you even do your -first commit so as to not forget. Also do not forget to enter your GitHub -username into your details on the issue tracker. - - -.. _contributor form for Python: https://www.python.org/psf/contrib/ - - - -Pull Request merging -'''''''''''''''''''' - -Once you have your commit privileges on GitHub you will be able to accept -pull requests on GitHub. You should plan to continue to submit your own -changes through pull requests as if you weren't a core developer to benefit -from various things such as automatic integration testing, but you -can accept your own pull requests if you feel comfortable doing so. - - -Responsibilities ----------------- - -As a core developer, there are certain things that are expected of you. - -First and foremost, be a good person. This might sound melodramatic, but you -are now a member of the Python project and thus represent the project and your -fellow core developers whenever you discuss Python with anyone. We have a -reputation for being a very nice group of people and we would like to keep it -that way. Core developers responsibilities include following the `PSF Code of -Conduct`_. - -Second, please be prompt in responding to questions. Many contributors to Python -are volunteers so what little free time they can dedicate to Python should be -spent being productive. If you have been asked to respond to an issue or answer -a question and you put it off it ends up stalling other people's work. It is -completely acceptable to say you are too busy, but you need to say that instead -of leaving people waiting for an answer. This also applies to anything you -do on the issue tracker. - -Third, please list what areas you want to be considered an expert in the -:ref:`experts`. This allows triagers to direct issues to you which involve -an area you are an expert in. But, as stated in the second point above, if you -do not have the time to answer questions promptly then please remove yourself as -needed from the file so that you will not be bothered in the future. Once again, -we all understand how life gets in the way, so no one will be insulted if you -remove yourself from the list. - -Fourth, please consider whether or not you wish to add your name to the -:ref:`motivations` list. Core contributor participation in the list helps the -wider Python community to better appreciate the perspectives currently -represented amongst the core development team, the Python Software Foundation -to better assess the sustainability of current contributions to CPython core -development, and also serves as a referral list for organisations seeking -commercial Python support from the core development community. - -And finally, enjoy yourself! Contributing to open source software should be fun -(overall). If you find yourself no longer enjoying the work then either take a -break or figure out what you need to do to make it enjoyable again. - - -.. _PSF Code of Conduct: https://www.python.org/psf/codeofconduct/ diff --git a/coverity.rst b/coverity.rst deleted file mode 100644 index 8de943aefa..0000000000 --- a/coverity.rst +++ /dev/null @@ -1,153 +0,0 @@ -============= -Coverity Scan -============= - -.. _coverity: - -Coverity Scan is a free service for static code analysis of Open Source -projects. It is based on Coverity's commercial product and is able to analyze -C, C++ and Java code. - -Coverity's static code analysis doesn't run the code. Instead of that it uses -abstract interpretation to gain information about the code's control flow and -data flow. It's able to follow all possible code paths that a program may -take. For example the analyzer understands that ``malloc()`` returns a memory -that must be freed with ``free()`` later. It follows all branches and function -calls to see if all possible combinations free the memory. The analyzer is -able to detect all sorts of issues like resource leaks (memory, file -descriptors), NULL dereferencing, use after free, unchecked return values, -dead code, buffer overflows, integer overflows, uninitialized variables, and -many more. - - -Access to analysis reports -========================== - -The results are available on the `Coverity Scan`_ website. In order to -access the results you have to create an account yourself. Then go to -*Projects using Scan* and add yourself to the Python project. New members must -be approved by an admin (see `Contact`_). - -Access is restricted to Python core developers only. Other individuals may be -given access at our own discretion, too. Every now and then Coverity detects a -critical issue in Python's code -- new analyzers may even find new bugs in -mature code. We don't want to disclose issues prematurely. - - -Building and uploading analysis -=============================== - -The process is automated. A script checks out the code, runs -``cov-build`` and uploads the latest analysis to Coverity. Since Coverity has -limited the maximum number of builds per week Python is analyzed every second -day. The build runs on a dedicated virtual machine on PSF's infrastructure at -OSU Open Source Labs. The process is maintained by Christian Heimes (see -`Contact`_). At present only the tip is analyzed with the 64bit Linux tools. - - -Known limitations -================= - -Some aspects of Python's C code are not yet understood by Coverity. - -False positives ---------------- - -``Py_BuildValue("N", PyObject*)`` - Coverity doesn't understand that ``N`` format char passes the object along - without touching its reference count. On this ground the analyzer detects - a resource leak. CID 719685 - -``PyLong_FromLong()`` for negative values - Coverity claims that ``PyLong_FromLong()`` and other ``PyLong_From*()`` - functions cannot handle a negative value because the value might be used as - an array index in ``get_small_int()``. CID 486783 - -``PyLong_FromLong()`` for n in [-5 ... +255] - For integers in the range of Python's small int cache the ``PyLong_From*()`` - function can never fail and never returns NULL. CID 1058291 - -``PyArg_ParseTupleAndKeywords(args, kwargs, "s#", &data, &length)`` - Some functions use the format char combination such as ``s#``, ``u#`` or - ``z#`` to get data and length of a character array. Coverity doesn't - recognize the relation between data and length. Sometimes it detects a buffer - overflow if data is written to a fixed size buffer although - ``length <= sizeof(buffer)``. CID 486613 - -``path_converter()`` dereferencing after null check - The ``path_converter()`` function in ``posixmodule.c`` makes sure that - either ``path_t.narrow`` or ``path_t.wide`` is filled unless - ``path_t.nullable`` is explicitly enabled. CID 719648 - - -Intentionally -------------- - -``Py_VA_COPY()`` - Python is written in C89 (ANSI C), therefore it can't use C99 features such - as ``va_copy()``. Python's own variant ``Py_VA_COPY()`` uses ``memcpy()`` - to make a copy of a ``va_list`` variable. Coverity detects two issues in - this approach: "Passing argument "lva" of type "va_list" and sizeof(va_list) - to function memcpy() is suspicious." CID 486405 and "Uninitialized pointer - read" CID 486630. - - -Modeling -======== - -Modeling is explained in the *Coverity Help Center* which is available in -the help menu of `Coverity Connect`_. `coverity_model.c`_ contains a copy of -Python's modeling file for Coverity. Please keep the copy in sync with the -model file in *Analysis Settings* of `Coverity Scan`_. - - -Workflow -======== - -False positive and intentional issues -------------------------------------- - -If the problem is listed under `Known limitations`_ then please set the -classification to either "False positive" or "Intentional", the action to -"Ignore", owner to your own account and add a comment why the issue -is considered false positive or intentional. - -If you think it's a new false positive or intentional then please contact an -admin. The first step should be an updated to Python's `Modeling`_ file. - - -Positive issues ---------------- - -You should always create an issue unless it's really a trivial case. Please -add the full url to the ticket under *Ext. Reference* and add the CID -(Coverity ID) to both the ticket and the checkin message. It makes it much -easier to understand the relation between tickets, fixes and Coverity issues. - - -Contact -======= - -Please include both Brett and Christian in any mail regarding Coverity. Mails -to Coverity should go through Brett or Christian, too. - -Christian Heimes <christian (at) python (dot) org> - admin, maintainer of build machine, intermediary between Python and Coverity - -Brett Cannon <brett (at) python (dot) org> - co-admin - -Dakshesh Vyas <scan-admin@coverity.com> - Technical Manager - Coverity Scan - - -.. seealso:: - - `Coverity Scan FAQ <https://scan.coverity.com/faq/>`_ - - -.. _Coverity Scan: https://scan.coverity.com/ - -.. _Coverity Connect: https://scan.coverity.com/projects/python - -.. _coverity_model.c: https://github.com/python/cpython/blob/master/Misc/coverity_model.c diff --git a/devcycle.rst b/devcycle.rst deleted file mode 100644 index 608e6ddeb7..0000000000 --- a/devcycle.rst +++ /dev/null @@ -1,337 +0,0 @@ -.. _devcycle: - -Development Cycle -================= - -The responsibilities of a core developer shift based on what kind of branch of -Python a developer is working on and what stage the branch is in. - -To clarify terminology, Python uses a ``major.minor.micro`` nomenclature -for production-ready releases. So for Python 3.1.2 final, that is a *major -version* of 3, a *minor version* of 1, and a *micro version* of 2. - -* new *major versions* are exceptional; they only come when strongly - incompatible changes are deemed necessary, and are planned very long - in advance; - -* new *minor versions* are feature releases; they get released roughly - every 18 months, from the current :ref:`in-development <indevbranch>` - branch; - -* new *micro versions* are bugfix releases; they get released roughly - every 6 months, although they can come more often if necessary; they are - prepared in :ref:`maintenance <maintbranch>` branches. - -We also publish non-final versions which get an additional qualifier: -:ref:`alpha`, :ref:`beta`, :ref:`release candidate <rc>`. These versions -are aimed at testing by advanced users, not production use. - -Each release of Python is tagged in the source repo with a tag of the form -``vX.Y.ZTN``, where ``X`` is the major version, ``Y`` is the -minor version, ``Z`` is the micro version, ``T`` is the release level -(``a`` for alpha releases, ``b`` for beta, ``rc`` release candidate, -and *null* for final releases), and ``N`` is the release serial number. -Some examples of release tags: ``v3.7.0a1``, ``v3.6.3``, ``v2.7.14rc1``. - -Branches -'''''''' - -There is a branch for each *feature version*, whether released or not (e.g. -2.7, 3.7, 3.8). Development is handled separately for Python 2 and Python 3: -no merging happens between 2.x and 3.x branches. - - -.. _indevbranch: - -In-development (main) branch ----------------------------- - -The ``master`` branch is the branch for the next feature release; it is -under active development for all kinds of changes: new features, semantic -changes, performance improvements, bug fixes. - -At some point during the life-cycle of a release, a -new :ref:`maintenance branch <maintbranch>` is created to host all bug fixing -activity for further micro versions in a feature version (3.8.1, 3.8.2, etc.). - -For versions 3.4 and before, this was conventionally done when the final -release was cut (for example, 3.4.0 final). - -Starting with the 3.5 release, we create the release maintenance branch -(e.g. 3.5) at the time we enter beta (3.5.0 beta 1). This allows -feature development for the release 3.n+1 to occur within the master -branch alongside the beta and release candidate stabilization periods -for release 3.n. - -.. _maintbranch: - -Maintenance branches --------------------- - -A branch for a previous feature release, currently being maintained for bug -fixes. There are usually two maintenance branches at any given time: one for -Python 3.x and one for Python 2.x. Only during the beta/rc phase of a new -minor/feature release will there be three active maintenance branches, e.g. -during the beta phase for Python 3.8 there are master, 3.8, 3.7, and 2.7 -branches open. At some point in the future, Python 2.x will be closed for bug -fixes and there will be only one maintenance branch left. Releases -produced from a maintenance branch are called **maintenance** or **bugfix** -releases; the terms are used interchangeably. These releases have a -**micro version** number greater than zero. - -The only changes allowed to occur in a maintenance branch without debate are -bug fixes. Also, a general rule for maintenance branches is that compatibility -must not be broken at any point between sibling minor releases (3.5.1, 3.5.2, -etc.). For both rules, only rare exceptions are accepted and **must** be -discussed first. - -Sometime after a new maintenance branch is created (after a new *minor version* -is released), the old maintenance branch on that major version will go into -:ref:`security mode <secbranch>`, -usually after one last maintenance release at the discretion of the -release manager. For example, the 3.4 maintenance branch was put into -:ref:`security mode <secbranch>` after the 3.4.4 final maintenance release -following the release of 3.5.1. - -.. _secbranch: - -Security branches ------------------ - -A branch less than 5 years old but no longer in maintenance mode is a security -branch. - -The only changes made to a security branch are those fixing issues exploitable -by attackers such as crashes, privilege escalation and, optionally, other -issues such as denial of service attacks. Any other changes are -**not** considered a security risk and thus not backported to a security branch. -You should also consider fixing hard-failing tests in open security branches -since it is important to be able to run the tests successfully before releasing. - -Commits to security branches are to be coordinated with the release manager -for the corresponding feature version, as listed in the :ref:`branchstatus`. -Any release made from a security branch is source-only and done only when actual -security patches have been applied to the branch. These releases have a -**micro version** number greater than the last **bugfix** release. - -.. _eolbranch: - -End-of-life branches --------------------- - -The code base for a release cycle which has reached end-of-life status -is frozen and no longer has a branch in the repo. The final state of -the end-of-lifed branch is recorded as a tag with the same name as the -former branch, e.g. ``3.3`` or ``2.6``. - -For reference, here are the Python versions that most recently reached their end-of-life: - -+------------------+--------------+----------------+----------------+----------------------------------+ -| Branch | Schedule | First release | End-of-life | Release manager | -+==================+==============+================+================+==================================+ -| 3.4 | :pep:`429` | 2014-03-16 | 2019-03-18 | Larry Hastings | -+------------------+--------------+----------------+----------------+----------------------------------+ -| 3.3 | :pep:`398` | 2012-09-29 | 2017-09-29 | Georg Brandl, Ned Deily (3.3.7+) | -+------------------+--------------+----------------+----------------+----------------------------------+ -| 3.2 | :pep:`392` | 2011-02-20 | 2016-02-20 | Georg Brandl | -+------------------+--------------+----------------+----------------+----------------------------------+ -| 3.1 | :pep:`375` | 2009-06-27 | 2012-04-09 | Benjamin Peterson | -+------------------+--------------+----------------+----------------+----------------------------------+ -| 3.0 | :pep:`361` | 2008-12-03 | 2009-01-13 | Barry Warsaw | -+------------------+--------------+----------------+----------------+----------------------------------+ -| 2.6 | :pep:`361` | 2008-10-01 | 2013-10-29 | Barry Warsaw | -+------------------+--------------+----------------+----------------+----------------------------------+ - -The latest release for each Python version can be found on the `download page -<https://www.python.org/downloads/>`_. - -.. _stages: - -Stages -'''''' - -Based on what stage the :ref:`in-development <indevbranch>` version of Python -is in, the responsibilities of a core developer change in regards to commits -to the :abbr:`VCS (version control system)`. - - -Pre-alpha ---------- - -The branch is in this stage when no official release has been done since -the latest final release. There are no special restrictions placed on -commits, although the usual advice applies (getting patches reviewed, avoiding -breaking the buildbots). - -.. _alpha: - -Alpha ------ - -Alpha releases typically serve as a reminder to core developers that they -need to start getting in changes that change semantics or add something to -Python as such things should not be added during a Beta_. Otherwise no new -restrictions are in place while in alpha. - -.. _beta: - -Beta ----- - -After a first beta release is published, no new features are accepted. Only -bug fixes can now be committed. This is when core developers should concentrate -on the task of fixing regressions and other new issues filed by users who have -downloaded the alpha and beta releases. - -Being in beta can be viewed much like being in RC_ but without the extra -overhead of needing commit reviews. - -Please see the note in the `In-development (main) branch`_ section above for -new information about the creation of the 3.5 maintenance branch during beta. - - -.. _rc: - -Release Candidate (RC) ----------------------- - -A branch preparing for an RC release can only have bugfixes applied that have -been reviewed by other core developers. Generally, these issues must be -severe enough (e.g. crashes) that they deserve fixing before the final release. -All other issues should be deferred to the next development cycle, since -stability is the strongest concern at this point. - -You **cannot** skip the peer review during an RC, no matter how small! Even if -it is a simple copy-and-paste change, **everything** requires peer review from -a core developer. - -.. _final: - -Final ------ - -When a final release is being cut, only the release manager (RM) can make -changes to the branch. After the final release is published, the full -:ref:`development cycle <stages>` starts again for the next minor version. - - -Repository Administration -''''''''''''''''''''''''' - -The source code is currently hosted on `GitHub -<https://github.com/python/cpython>`_ in the `Python organization <https://github.com/python/>`_. - -Organization Repository Policy ------------------------------- - -Within the `Python organization <https://github.com/python/>`_, repositories are expected to fall within these general categories: - -1. The reference implementation of Python and related repositories (i.e. `CPython <https://github.com/python/cpython>`_) -2. Reference implementations of PEPs (e.g. `mypy <https://github.com/python/mypy>`_) -3. Tooling and support around CPython and the language (e.g. `python.org repository <https://github.com/python/pythondotorg>`_) -4. PSF-related repositories (e.g. the `Code of Conduct <https://github.com/python/pycon-code-of-conduct>`_) -5. PSF Infrastructure repositories (e.g. the `PSF Infrastructure Salt configurations <https://github.com/python/psf-salt>`_) - -For any repository which does not explicitly and clearly fall under one of these categories, permission should be sought -from the `Python steering council <https://github.com/python/steering-council>`_. - -Organization Owner Policy -------------------------- - -The GitHub Organization Owner role allows for full management of all aspects of -the Python organization. Allowing for visibility and management of all aspects -at all levels including organization membership, team membership, access -control, and merge privileges on all repositories. For full details of the -permission levels see `GitHub's documentation on Organization permission -levels -<https://help.github.com/articles/permission-levels-for-an-organization/#permission-levels-for-an-organization>`_. -This role is paramount to the security of the Python Language, Community, and -Infrastructure. - -The Executive Director of the Python Software Foundation delegates authority on -GitHub Organization Owner Status to Ernest W. Durbin III - Python Software -Foundation Director of Infrastructure. Common reasons for this role are: -Infrastructure Staff Membership, Python Software Foundation General Counsel, -and Python Software Foundation Staff as fallback. - -Inactive or unreachable members may be removed with or without notice. Members -who no longer necessitate this level of access will be removed with notice. - -Multi-Factor Authentication must be enabled by the user in order to remain an -Owner of the Python Organization. - -Current Owners --------------- - -+----------------------+--------------------------------+-----------------+ -| Name | Role | GitHub Username | -+======================+================================+=================+ -| Benjamin Peterson | Infrastructure Staff | benjaminp | -+----------------------+--------------------------------+-----------------+ -| Noah Kantrowitz | Infrastructure Staff | coderanger | -+----------------------+--------------------------------+-----------------+ -| Donald Stufft | Infrastructure Staff | dstufft | -+----------------------+--------------------------------+-----------------+ -| Ewa Jodlowska | PSF Executive Director | ejodlowska | -+----------------------+--------------------------------+-----------------+ -| Ernest W. Durbin III | PSF Director of Infrastructure | ewdurbin | -+----------------------+--------------------------------+-----------------+ -| Van Lindberg | PSF General Counsel | VanL | -+----------------------+--------------------------------+-----------------+ - -Repository Administrator Role Policy ------------------------------------- - -The Administrator role on the repository allows for managing all aspects -including collaborators, access control, integrations, webhooks, and branch -protection. For full details of the permission levels see `GitHub's -documentation on Repository permission levels -<https://help.github.com/articles/repository-permission-levels-for-an-organization/>`_. -Common reasons for this role are: maintenance of Core Developer -Workflow tooling, Release Managers for all :ref:`in-development <indevbranch>`, -:ref:`maintenance <maintbranch>`, and :ref:`security mode <secbranch>` -releases, and additional Python Core Developers as necessary for redundancy. -Occasional temporary administrator access is acceptable as necessary for Core -Developer workflow projects. - -Inactive or unreachable members may be removed with or without notice. Members -who no longer necessitate this level of access will be removed with notice. - -Multi-Factor Authentication must be enabled by the user in order to remain an -Administrator of the repository. - -Current Administrators ----------------------- - -+-------------------+----------------------------------------------------------+-----------------+ -| Name | Role | GitHub Username | -+===================+==========================================================+=================+ -| Łukasz Langa | Python 3.8 and 3.9 Release Manager | ambv | -+-------------------+----------------------------------------------------------+-----------------+ -| Benjamin Peterson | Python 2.7 Release Manager | benjaminp | -+-------------------+----------------------------------------------------------+-----------------+ -| Ned Deily | Python 3.7 Release Manager | ned-deily | -+-------------------+----------------------------------------------------------+-----------------+ -| Lary Hastings | Python 3.5 Release Manager | larryhastings | -+-------------------+----------------------------------------------------------+-----------------+ -| Berker Peksag | Maintainer of bpo-linkify and cpython-emailer-webhook | berkerpeksag | -+-------------------+----------------------------------------------------------+-----------------+ -| Brett Cannon | Maintainer of bedevere and the-knights-who-say-ni | brettcannon | -+-------------------+----------------------------------------------------------+-----------------+ -| Ezio Melotti | Maintainer of bugs.python.org GitHub webhook integration | ezio-melotti | -+-------------------+----------------------------------------------------------+-----------------+ -| Mariatta Wijaya | Maintainer of blurb_it and miss-islington | Mariatta | -+-------------------+----------------------------------------------------------+-----------------+ - -Repository Release Manager Role Policy --------------------------------------- - -Release Managers for :ref:`in-development <indevbranch>`, :ref:`maintenance -<maintbranch>`, and :ref:`security mode <secbranch>` Python releases are -granted Administrator privileges on the repository. Once a release branch has -entered :ref:`end-of-life <eolbranch>`, the Release Manager for that branch is -removed as an Administrator and granted sole privileges (out side of repository -administrators) to merge changes to that branch. - -Multi-Factor Authentication must be enabled by the user in order to retain -access as a Release Manager of the branch. diff --git a/developer-workflow/c-api.rst b/developer-workflow/c-api.rst new file mode 100644 index 0000000000..427d9fd96a --- /dev/null +++ b/developer-workflow/c-api.rst @@ -0,0 +1,453 @@ +.. _c-api: + +======================= +Changing Python's C API +======================= + +The C API is divided into these tiers: + +1. The internal, private API, available with ``Py_BUILD_CORE`` defined. + Ideally declared in ``Include/internal/``. Any API named with a leading + underscore is also considered private. +2. The Unstable C API, identified by the ``PyUnstable_`` name prefix. + Ideally declared in :cpy-file:`Include/cpython/` along with the general public API. +3. The “general” public C API, available when :cpy-file:`Include/Python.h` is included normally. + Ideally declared in ``Include/cpython/``. +4. The Limited C API, available with :c:macro:`Py_LIMITED_API` defined. + Ideally declared directly under ``Include/``. + +Each tier has different stability and maintenance requirements to consider +when you add or change definitions in it. + +The public backwards compatibility guarantees for public C API are explained +in the user documentation, ``Doc/c-api/stable.rst`` (:ref:`python:stable`). +C language compatibility guarantees are in ``Doc/c-api/intro.rst`` +(:ref:`python:api-intro`). + +As core developers, we need to be more careful about compatibility than what +we promise publicly. See :ref:`public-capi` for details. + + +The internal API +================ + +Internal API is defined in ``Include/internal/`` and is only available +for building CPython itself, as indicated by a macro like ``Py_BUILD_CORE``. + +While internal API can be changed at any time, it's still good to keep it +stable: other API or other CPython developers may depend on it. +For users, internal API is sometimes the best workaround for a thorny problem +--- though those use cases should be discussed on the +`C API Discourse category <https://discuss.python.org/c/30>`__ +or an issue so we can try to find a supported way to serve them. + + +With PyAPI_FUNC or PyAPI_DATA +----------------------------- + +Functions or structures in ``Include/internal/`` defined with +``PyAPI_FUNC`` or ``PyAPI_DATA`` are internal functions which are +exposed only for specific use cases like debuggers and profilers. +Ideally, these should be migrated to the :ref:`unstable-capi`. + + +With the extern keyword +----------------------- + +Functions in ``Include/internal/`` defined with the ``extern`` keyword +*must not and can not* be used outside the CPython code base. Only +built-in stdlib extensions (built with the ``Py_BUILD_CORE_BUILTIN`` +macro defined) can use such functions. + +When in doubt, new internal C functions should be defined in +``Include/internal`` using the ``extern`` keyword. + +Private names +------------- + +Any API named with a leading underscore is also considered internal. +There is currently only one main use case for using such names rather than +putting the definition in :cpy-file:`Include/internal/` (or directly in a ``.c`` file): + +* Internal helpers for other public APIs, which users should not call directly. + +Note that historically, underscores were used for APIs that are better served by +the :ref:`unstable-capi`: + +* “provisional” APIs, included in a Python release to test real-world + usage of new APIs; +* APIs for very specialized uses like JIT compilers. + + +Internal API tests +------------------ + +C tests for the internal C API live in ``Modules/_testinternalcapi.c``. +Functions named ``test_*`` are used as tests directly. +Python parts of the tests live in various places in ``Lib/test``. + + +.. _public-capi: + +Public C API +============ + +CPython's public C API is available when ``Python.h`` is included normally +(that is, without defining macros to select the other variants). + +It should be defined in ``Include/cpython/`` (unless part of the Limited API, +see below). + +Before adding new public API, please ask in the `decisions repo`_ of +the :pep:`C API workgroup <731>`. +This helps us ensure *newly added* API is consistent and maintainable. + +Also check with the C API WG before requiring a C feature not present in C99. +While the *public* docs only promise compatibility with C11, in practice +we only introduce C11 features individually as needed. + +.. _decisions repo: https://github.com/capi-workgroup/decisions/issues + + +.. _public-api-guidelines: + +Guidelines for expanding/changing the public API +------------------------------------------------ + +- Make sure the new API follows reference counting conventions. + (Following them makes the API easier to reason about, and easier use + in other Python implementations.) + + - Functions *must not* steal references + - Functions *must not* return borrowed references + - Functions returning references *must* return a strong reference + +- Make sure the ownership rules and lifetimes of all applicable struct + fields, arguments and return values are well defined. + +- Functions returning ``PyObject *`` must return a valid pointer on success, + and ``NULL`` with an exception raised on error. + Most other API must return ``-1`` with an exception raised on error, + and ``0`` on success. + +- APIs with lesser and greater results must return ``0`` for the lesser result, + and ``1`` for the greater result. + Consider a lookup function with a three-way return: + + - ``return -1``: internal error or API misuse; exception raised + - ``return 0``: lookup succeeded; no item was found + - ``return 1``: lookup succeeded; item was found + +Please start a public discussion if these guidelines won't work for your API. + +.. note:: + + By *return value*, we mean the value returned by the *C return statement*. + +C API tests +----------- + +Tests for the public C API live in the ``_testcapi`` module. +Functions named ``test_*`` are used as tests directly. +Tests that need Python code (or are just easier to partially write in Python) +live in ``Lib/test``, mainly in :cpy-file:`Lib/test/test_capi`. + +Due to its size, the ``_testcapi`` module is defined in several source +files. +To add a new set of tests (or extract a set out of the monolithic +:cpy-file:`Modules/_testcapimodule.c`): + +- Create a C file named ``Modules/_testcapi/yourfeature.c`` + +- The file should define a module as usual, except: + + - Instead of ``<Python.h>``, include ``"parts.h"``. + - Instead of ``PyInit_modname``, define a ``_PyTestCapi_Init_yourfeature`` + function that *takes* the ``_testcapi`` module and adds functions/classes + to it. (You can use ``PyModule_AddFunctions`` to add functions.) + +- Add the ``_PyTestCapi_Init_*`` function to ``Modules/_testcapi/parts.h`` + +- Call the ``_PyTestCapi_Init_*`` from ``PyInit__testcapi`` in + ``Modules/_testcapimodule.c``. + +- Add the new C file to :cpy-file:`Modules/Setup.stdlib.in`, + :cpy-file:`PCbuild/_testcapi.vcxproj` and + :cpy-file:`PCbuild/_testcapi.vcxproj.filters`, + alongside the other ``_testcapi/*.c`` entries. + +Note that all ``Modules/_testcapi/*.c`` sources initialize the same module, +so be careful about name collisions. + +When moving existing tests, feel free to replace ``TestError`` with +``PyExc_AssertionError`` unless actually testing custom exceptions. + + +.. _unstable-capi: + +Unstable C API +============== + +The unstable C API tier is meant for extensions that need tight integration +with the interpreter, like debuggers and JIT compilers. +Users of this tier may need to change their code with every feature release. + +In many ways, this tier is like the general C API: + +- it's available when ``Python.h`` is included normally, +- it should be defined in :cpy-file:`Include/cpython/`, +- it requires tests, so we don't break it unintentionally +- it requires docs, so both we and the users, + can agree on the expected behavior, +- it is tested and documented in the same way. + +The differences are: + +- Names of functions structs, macros, etc. start with the ``PyUnstable_`` + prefix. This defines what's in the unstable tier. +- The unstable API can change in feature releases, without any deprecation + period. +- A stability note appears in the docs. + This happens automatically, based on the name + (via :cpy-file:`Doc/tools/extensions/c_annotations.py`). + +Despite being “unstable”, there are rules to make sure third-party code can +use this API reliably: + +* Changes and removals can be done in feature releases + (:samp:`3.{x}.0`, including Alphas and Betas for :samp:`3.{x}.0`). +* Adding a new unstable API *for an existing feature* is allowed even after + Beta feature freeze, up until the first Release Candidate. + Consensus on the `Core Development Discourse <https://discuss.python.org/c/core-dev/23>`__ + is needed in the Beta period. +* Backwards-incompatible changes should make existing C callers fail to compile. + For example, arguments should be added/removed, or a function should be + renamed. +* When moving an API into or out of the Unstable tier, the old name + should continue to be available (but deprecated) until an incompatible + change is made. In other words, while we're allowed to break calling code, + we shouldn't break it *unnecessarily*. + + +Moving an API from the public tier to Unstable +---------------------------------------------- + +* Expose the API under its new name, with the ``PyUnstable_`` prefix. + The ``PyUnstable_`` prefix must be used for all symbols (functions, macros, + variables, etc.). +* Make the old name an alias (for example, a ``static inline`` function calling the + new function). +* Deprecate the old name, typically using :c:macro:`Py_DEPRECATED`. +* Announce the change in the "What's New". + +The old name should continue to be available until an incompatible change is +made. Per Python’s backwards compatibility policy (:pep:`387`), +this deprecation needs to last at least two releases +(modulo Steering Council exceptions). + +The rules are relaxed for APIs that were introduced in Python versions +before 3.12, when the official Unstable tier was added. +You can make an incompatible change (and remove the old name) +as if the function was already part of the Unstable tier +for APIs introduced before Python 3.12 that are either: + +* Documented to be less stable than default. +* Named with a leading underscore. + +Moving an API from the private tier to unstable +----------------------------------------------- + +* Expose the API under its new name, with the ``PyUnstable_`` prefix. +* If the old name is documented, or widely used externally, + make it an alias and deprecate it (typically with :c:macro:`Py_DEPRECATED`). + It should continue to be available until an incompatible change is made, + as if it was previously public. + + This applies even to underscored names. Python wasn't always strict with + the leading underscore. +* Announce the change in What's New. + +Moving an API from unstable to public +------------------------------------- + +* Expose the API under its new name, without the ``PyUnstable_`` prefix. +* Make the old ``PyUnstable_*`` name be an alias (for example, a ``static inline`` + function calling the new function). +* Announce the change in What's New. + +The old name should remain available until the +new public name is deprecated or removed. +There's no need to deprecate the old name (it was unstable to begin with), +but there's also no need to break working code just because some function +is now ready for a wider audience. + + +Limited API +=========== + +The Limited API is a subset of the C API designed to guarantee ABI +stability across Python 3 versions. +Defining the macro ``Py_LIMITED_API`` will limit the exposed API to +this subset. + +No changes that break the Stable ABI are allowed. + +The Limited API should be defined in ``Include/``, excluding the +``cpython`` and ``internal`` subdirectories. + + +Guidelines for changing the Limited API, and removing items from it +------------------------------------------------------------------- + +While the *Stable ABI* must not be broken, the existing Limited API can be +changed, and items can be removed from it, if: + +- the Backwards Compatibility Policy (:pep:`387`) is followed, and +- the Stable ABI is not broken -- that is, extensions compiled with + Limited API of older versions of Python continue to work on + newer versions of Python. + +This is tricky to do and requires careful thought. +Some examples: + +- Functions, structs etc. accessed by macros in *any version* of the + Limited API are part of the Stable ABI, even if they are named with + an underscore. They must not be removed and their signature must not change. + (Their implementation may change, though.) +- Structs members cannot be rearranged if they were part of any version of + the Limited API. +- If the Limited API allows users to allocate a struct directly, + its size must not change. +- Exported symbols (functions and data) must continue to be available + as exported symbols. Specifically, a function can only be converted + to a ``static inline`` function (or macro) if Python also continues to + provide the actual function. + For an example, see the ``Py_NewRef`` `macro`_ and `redefinition`_ in 3.10. + +.. _macro: https://github.com/python/cpython/blob/2cd268a3a9340346dd86b66db2e9b428b3f878fc/Include/object.h#L592-L596 +.. _redefinition: https://github.com/python/cpython/blob/2cd268a3a9340346dd86b66db2e9b428b3f878fc/Objects/object.c#L2303-L2313 + +It is possible to remove items marked as part of the Stable ABI, but only +if there was no way to use them in any past version of the Limited API. + + +.. _limited-api-guidelines: + +Guidelines for adding to the Limited API +---------------------------------------- + +- Guidelines for the general :ref:`public-capi` apply. + See :ref:`public-api-guidelines`. + +- New Limited API should only be defined if ``Py_LIMITED_API`` is set + to the version the API was added in or higher. + (See below for the proper ``#if`` guard.) + +- All parameter types, return values, struct members, etc. need to be part + of the Limited API. + + - Functions that deal with ``FILE*`` (or other types with ABI portability + issues) should not be added. + +- Think twice when defining macros. + + - Macros should not expose implementation details + - Functions must be exported as actual functions, not (only) + as functions-like macros. + - If possible, avoid macros. This makes the Limited API more usable in + languages that don't use the C preprocessor. + +- Please start a public discussion before expanding the Limited API + +- The Limited API and must follow standard C, not just features of currently + supported platforms. The exact C dialect is described in :pep:`7`. + + - Documentation examples (and more generally: the intended use of the API) + should also follow standard C. + - In particular, do not cast a function pointer to ``void*`` (a data pointer) + or vice versa. + +- Think about ease of use for the user. + + - In C, ease of use itself is not very important; what is useful is + reducing boilerplate code needed to use the API. Bugs like to hide in + boiler plates. + + - If a function will be often called with specific value for an argument, + consider making it default (used when ``NULL`` is passed in). + - The Limited API needs to be well documented. + +- Think about future extensions + + - If it's possible that future Python versions will need to add a new + field to your struct, make sure it can be done. + - Make as few assumptions as possible about implementation details that + might change in future CPython versions or differ across C API + implementations. The most important CPython-specific implementation + details involve: + + - The GIL + - Garbage collection + - Memory layout of PyObject, lists/tuples and other structures + +If following these guidelines would hurt performance, add a fast function +(or macro) to the non-limited API and a stable equivalent to the Limited +API. + +If anything is unclear, or you have a good reason to break the guidelines, +consider discussing the change in the `C API category +<https://discuss.python.org/c/core-dev/c-api/>`__ on Discourse. + +Adding a new definition to the Limited API +------------------------------------------ + +- Add the declaration to a header file directly under ``Include/``, into a + block guarded with the following: + + .. code-block:: c + + #if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 >= 0x03yy0000 + + with the ``yy`` corresponding to the target CPython version, for example, + ``0x030A0000`` for Python 3.10. +- Append an entry to the Stable ABI manifest, ``Misc/stable_abi.toml`` +- Regenerate the autogenerated files using ``make regen-limited-abi``. + On platforms without ``make``, run this command directly: + + .. code-block:: shell + + ./python ./Tools/build/stable_abi.py --generate-all ./Misc/stable_abi.toml + +- Build Python and check the using ``make check-limited-abi``. + On platforms without ``make``, run this command directly: + + .. code-block:: shell + + ./python ./Tools/build/stable_abi.py --all ./Misc/stable_abi.toml + +- Add tests -- see below. + + +Limited API tests +----------------- + +Since Limited API is a subset of the C API, there's no need to test the +behavior of individual functions. Rather, the tests could verify that some +task is possible using the exposed subset, or exercise a feature that was +removed from the current Limited API but still needs to be supported for +older Limited API/Stable ABI versions. + +To add a test file: + +- Add a C file ``Modules/_testcapi/yourfeature_limited.c``. If that file + already exists but its ``Py_LIMITED_API`` version is too low, add a version + postfix, for example, ``yourfeature_limited_3_12.c`` for Python 3.12+. +- ``#define Py_LIMITED_API`` to the minimum limited API version needed. +- ``#include "parts.h"`` after the ``Py_LIMITED_API`` definition +- Enclose the entire rest of the file in ``#ifdef LIMITED_API_AVAILABLE``, + so it's skipped on incompatible builds. +- Follow the general instructions for `C API tests`_. All additions go in the + sections guarded by ``#ifdef LIMITED_API_AVAILABLE``. + +Use the ``test.support.requires_limited_api`` decorator for Python tests +in ``Lib/test``, so they're skipped on incompatible builds. diff --git a/developer-workflow/communication-channels.rst b/developer-workflow/communication-channels.rst new file mode 100644 index 0000000000..78fbf21dff --- /dev/null +++ b/developer-workflow/communication-channels.rst @@ -0,0 +1,275 @@ +.. _communication-channels: +.. _communication: + +============================== +Following Python's development +============================== + +Python's development is communicated through a myriad of ways, +primarily :ref:`Discourse <communication-discourse>` along with other platforms. + + +Standards of behaviour in these communication channels +====================================================== + +We try to foster environments of mutual respect, tolerance and encouragement, +as described in the PSF's `Diversity Statement`_. Abiding by the guidelines +in this document and asking questions or posting suggestions in the +appropriate channels are an excellent way to get started on the mutual respect +part, greatly increasing the chances of receiving tolerance and encouragement +in return. + +.. _Diversity Statement: https://www.python.org/psf/diversity/ + + +.. _mailinglists: + +Mailing lists +============= + +.. note:: + + Mailing lists have generally been replaced by the `Discourse`_ forum. + Specifically, + + * The python-dev list is superseded by the `Core Development`_ + and `PEPs`_ categories on Discourse. + * The python-ideas list is superseded by posts in the `Ideas`_ + category on Discourse. + + Discussion in :guilabel:`Core Development` is focused on issues related to Python's + own development, such as how to handle a specific issue, a PEP, etc. + + - Ideas about new functionality should **not** start here, and instead + should be discussed in `Ideas`_. + - Technical support questions should also not be asked here, and instead + should go to the `Python Help`_ category on Discourse or the python-list_. + + Previous threads on the python-dev_, python-committers_, and python-ideas_ + mailing lists can be accessed through the `online archive + <https://mail.python.org/archives/>`__. + + .. _python-committers: https://mail.python.org/mailman3/lists/python-committers.python.org/ + .. _python-dev: https://mail.python.org/mailman3/lists/python-dev.python.org/ + .. _python-ideas: https://mail.python.org/archives/list/python-ideas@python.org/ + +General Python questions should go to `python-list`_ or `tutor`_ +or similar resources, such as `Stack Overflow`_ or the ``#python`` IRC channel +on Libera.Chat_. + +The `core-workflow <https://github.com/python/core-workflow/issues>`__ +issue tracker is the place to discuss and work on improvements to the CPython +core development workflow. + +A complete list of Python mailing lists can be found at +https://mail.python.org/mailman3/. Some lists may also +be mirrored at `GMANE <https://gmane.io/>`__ and can be read and posted to in various +ways, including via web browsers, NNTP newsreaders, and RSS feed readers. + +.. _python-list: https://mail.python.org/mailman3/lists/python-list.python.org/ +.. _tutor: https://mail.python.org/mailman3/lists/tutor.python.org/ +.. _Stack Overflow: https://stackoverflow.com/ +.. _Libera.Chat: https://libera.chat/ + + +.. _communication-discourse: + +Discourse (discuss.python.org web forum) +======================================== + +We have our own `Discourse`_ forum for both developers and users. +It has different categories and most core development discussions +take place in the open forum categories for `PEPs`_ and `Core Development`_ +(these are the Discourse equivalents to the python-dev mailing list). +All categories are open for users to read and post with the exception of +the `Committers`_ category, where posting is restricted to the `CPython +<https://github.com/python/cpython>`__ core team. + +The Committers category is often used for announcements and notifications. +It is also the designated venue for the core team promotion votes. + +Tutorials for new users +----------------------- + +To start a topic or participate in any discussions in the forum, sign up and +create an account using an email address or GitHub account. You can do so by +clicking the :guilabel:`Sign Up` button on the top right hand corner of the +`Discourse`_ main page. + +The Python Discourse `Quick Start <https://discuss.python.org/t/python-discourse-quick-start/116>`__ +compiled by `Carol Willing <https://discuss.python.org/u/willingc/>`__ gives you +a quick overview on how to kick off Python Discourse. + +We recommend new users getting familiarised with the forum by going through Discobot tutorials. +These tutorials can be activated by replying to a welcome message from "discourse +Greetings!" received under Notifications and Messages in your user account. + +* Click on your personal account found on the top right hand corner of the page. +* The dropdown menu will show four different icons: + :guilabel:`🔔` (Notifications), + :guilabel:`🔖` (Bookmarks), + :guilabel:`✉️` (Messages), and + :guilabel:`👤` (Preferences). +* Select either Notifications or Messages. +* Open the "Greetings!" message sent by Discobot to start the tutorial. + +Ensure that you read through the `Python Code of Conduct <https://discuss.python.org/faq>`__. +We are to be open, considerate and respectful to all users in the community. +You can report messages that don't respect the CoC by clicking on the three +dots under the message and then on the :guilabel:`⚐` icon. You can also mention the +`@staff <https://discuss.python.org/groups/staff>`__, +`@moderators <https://discuss.python.org/groups/moderators>`__, or +`@admins <https://discuss.python.org/groups/admins>`__ groups in a message. + + + +Reading topics +-------------- + +Click a topic title and read down the list of replies in chronological order, +following links or previewing replies and quotes as you go. Use your mouse to +scroll the screen, or use the timeline scroll bar on the right which also shows +you how far through the conversation you've read. On smaller screens, select the +bottom progress bar to expand it. + + +Notifications +------------- + +Following categories (category notifications) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Notifications can be set for individual categories and topics. To change any of these +defaults, you can either go to your user preferences, or visit the category +page, and use the notification button :guilabel:`🔔` above the topic list, +on the top right hand corner of the category page beside the +:guilabel:`+ New Topic` button. + +Clicking on the notification control :guilabel:`🔔` will show a drop-down panel with 5 +different options: Watching, Tracking, Watching First Post, Normal, and Muted. +All categories are set by default in Normal mode where you will only be notified +if someone mentions your @name or replies to you. + +Following individual threads (topic notifications) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To follow any individual topics or threads, you can adjust your notifications +through the notification button :guilabel:`🔔` found on the right of the topic at the end +of the timeline. You can also do so at the bottom of each topic. +Select "Watching" and you will be notified when there is any new updated reply +from that particular thread. + +Customising notifications on user preference +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To get a bird's eye view of all your customised notifications, you can +go to `Preferences of your account <https://discuss.python.org/my/preferences/categories>`__. +This allows you to make adjustments according to categories, users, and tags. + +Enabling mailing list mode +-------------------------- + +In mailing list mode, you will receive one email per post, as happens with +traditional mailing lists. This is desirable if you prefer to interact via email, +without visiting the forum website. +To activate the mailing list mode, go to the `email preferences +<https://discuss.python.org/my/preferences/emails>`__, check "Enable +mailing list mode" and save changes. + +.. _Discourse: https://discuss.python.org/ +.. _PEPs: https://discuss.python.org/c/peps/19 +.. _Core Development: https://discuss.python.org/c/core-dev/23 +.. _Committers: https://discuss.python.org/c/committers/5 +.. _Ideas: https://discuss.python.org/c/ideas/6 +.. _Python Help: https://discuss.python.org/c/help/7 + + +Discord (private chat server) +============================= + +For more real-time discussions, the core development team have a private Discord +server available. Core team members, Steering Council members, triagers, and +documentarians on the project are eligible to join the server. Joining the +Discord server is entirely optional, as all essential communications occur on +the mailing lists and Discourse forums. + +For core team members, a long-lived multiple-use invitation link for this server +can be found in the private core team only section of the Discourse forum. + +For triagers and documentarians joining the Discord server, a single use invitation +link should be generated and sent to them directly. + +When first joining the server, new users will only have access to the ``#welcome`` +and ``#rules-and-info`` channels. To link their Discord ID with their project +role, core team members may update their Steering Council 🔒 `voter record`_ with +their Discord ID before posting in the ``#welcome`` channel to request access +to the rest of the server channels. Triagers, documentarians, and core team members +that would prefer not to add their Discord ID to their Steering Council voter +record may instead be vouched for by an existing member of the Discord server. + +As a private, non-archived, forum, final decisions on design and development +questions should not be made on Discord. Any conclusions from Discord discussions +should be summarised and posted to the issue tracker, Discourse forum, or +mailing list (the appropriate venue for sharing conclusions will depend on the +specific discussion). + +Note: existing Discord users may want to right click on their username in the +automatic Discord welcome message and choose "Edit Server Profile" in order to +set a specific `Server Nickname`_ + +.. _voter record: https://github.com/python/voters/blob/main/python-core.toml +.. _Server Nickname: https://support.discord.com/hc/en-us/articles/219070107-Server-Nicknames + + +IRC +=== + +Some core team members still participate in the ``#python-dev`` IRC channel on +``irc.libera.chat``. This is not a place to ask for help with Python, but to +discuss issues related to Python's own development. See also the +``#python-dev-notifs`` channel for bots notifications. + + +Blogs +===== + +Several core team members are active bloggers and discuss Python's development +that way. You can find their blogs (and various other developers who use Python) +at `Planet Python <https://planetpython.org/>`__. + + +Setting expectations for open source participation +================================================== + +Burn-out is common in open source due to a misunderstanding of what users, contributors, +and maintainers should expect from each other. Brett Cannon gave a `talk <https://www.youtube.com/watch?v=-Nk-8fSJM6I>`__ +about this topic that sets out to help everyone set reasonable expectations of each other in +order to make open source pleasant for everyone involved. + +Additional repositories +======================= + +`Python Core Workflow`_ hosts an issue tracker for workflow discussions. + +Some core workflow tools are: + +* `cherry_picker`_ (:pypi:`PyPI <cherry_picker>`) +* `bedevere`_ +* `blurb`_ (:pypi:`PyPI <blurb>`) +* `blurb_it`_ +* `miss-islington`_ +* `clabot`_ +* `webhook-mailer`_ + +Python `Performance Benchmark`_ project is intended to be an authoritative +source of benchmarks for all Python implementations. + +.. _Python Core Workflow: https://github.com/python/core-workflow +.. _cherry_picker: https://github.com/python/cherry-picker +.. _bedevere: https://github.com/python/bedevere +.. _blurb: https://github.com/python/blurb +.. _blurb_it: https://github.com/python/blurb_it +.. _miss-islington: https://github.com/python/miss-islington +.. _clabot: https://github.com/psf/clabot +.. _webhook-mailer: https://github.com/python/webhook-mailer +.. _Performance Benchmark: https://github.com/python/pyperformance diff --git a/developer-workflow/development-cycle.rst b/developer-workflow/development-cycle.rst new file mode 100644 index 0000000000..af198a4007 --- /dev/null +++ b/developer-workflow/development-cycle.rst @@ -0,0 +1,427 @@ +.. _development-cycle: +.. _devcycle: + +Development cycle +================= + +The responsibilities of a core team member shift based on what kind of branch of +Python a developer is working on and what stage the branch is in. + +To clarify terminology, Python uses a ``major.minor.micro`` nomenclature +for production-ready releases. So for Python 3.1.2 final, that is a *major +version* of 3, a *minor version* of 1, and a *micro version* of 2. + +* new *major versions* are exceptional; they only come when strongly + incompatible changes are deemed necessary, and are planned very long + in advance; + +* new *minor versions* are feature releases; they get released annually, + from the current :ref:`in-development <indevbranch>` branch; + +* new *micro versions* are bugfix releases; they get released roughly + every 2 months; they are prepared in :ref:`maintenance <maintbranch>` + branches. + +We also publish non-final versions which get an additional qualifier: +:ref:`alpha`, :ref:`beta`, :ref:`release candidate <rc>`. These versions +are aimed at testing by advanced users, not production use. + +Each release of Python is tagged in the source repo with a tag of the form +``vX.Y.ZTN``, where ``X`` is the major version, ``Y`` is the +minor version, ``Z`` is the micro version, ``T`` is the release level +(``a`` for alpha releases, ``b`` for beta, ``rc`` release candidate, +and *null* for final releases), and ``N`` is the release serial number. +Some examples of release tags: ``v3.7.0a1``, ``v3.6.3``, ``v2.7.14rc1``. + +Branches +-------- + +There is a branch for each *feature version*, whether released or not (for +example, 3.12, 3.13). + + +.. _indevbranch: + +In-development (main) branch +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The ``main`` branch is the branch for the next feature release; it is +under active development for all kinds of changes: new features, semantic +changes, performance improvements, bug fixes. + +At some point during the life-cycle of a release, a +new :ref:`maintenance branch <maintbranch>` is created to host all bug fixing +activity for further micro versions in a feature version (3.12.1, 3.12.2, and so +on). + +We create the release maintenance branch +(``3.14``) at the time we enter beta (3.14.0 beta 1). This allows +feature development for the release 3.n+1 to occur within the main +branch alongside the beta and release candidate stabilization periods +for release 3.n. + +.. _maintbranch: + +Maintenance branches +^^^^^^^^^^^^^^^^^^^^ + +A branch for a previous feature release, currently being maintained for bug +fixes, or for the next feature release in its +:ref:`beta <beta>` or :ref:`release candidate <rc>` stages. +There are usually either one or two maintenance branches at any given time. +After the final release of a new minor version (3.x.0), releases +produced from a maintenance branch are called **bugfix** or **maintenance** +releases; the terms are used interchangeably. These releases have a +**micro version** number greater than zero. + +The only changes allowed to occur in a maintenance branch without debate are +bug fixes, test improvements, and edits to the documentation. +Also, a general rule for maintenance branches is that compatibility +must not be broken at any point between sibling micro releases (3.12.1, 3.12.2, +etc.). For both rules, only rare exceptions are accepted and **must** be +discussed first. + +Backporting changes reduces the risk of future conflicts. +For documentation, it increases the visibility of improvements, +since most readers access the `stable documentation <https://docs.python.org/3/>`__ +rather than the `development documentation <https://docs.python.org/dev/>`__. + +A new maintenance branch is normally created when the next feature release +cycle reaches feature freeze, that is, at its first beta pre-release. +From that point on, changes intended for remaining pre-releases, the final +release (3.x.0), and subsequent bugfix releases are merged to +that maintenance branch. + +Sometime following the final release (3.x.0), the maintenance branch for +the previous minor version will go into :ref:`security mode <secbranch>`, +usually after at least one more bugfix release at the discretion of the +release manager. For example, the 3.11 maintenance branch was put into +:ref:`security mode <secbranch>` after the 3.11.9 bugfix release +which followed the release of 3.12.2. + +.. _secbranch: + +Security branches +^^^^^^^^^^^^^^^^^ + +A branch less than 5 years old but no longer in bugfix mode is a security +branch. + +The only changes made to a security branch are those fixing issues exploitable +by attackers such as crashes, privilege escalation and, optionally, other +issues such as denial of service attacks. Any other changes are +**not** considered a security risk and thus not backported to a security branch. +You should also consider fixing hard-failing tests in open security branches +since it is important to be able to run the tests successfully before releasing. + +Commits to security branches are to be coordinated with the release manager +for the corresponding feature version, as listed in the :ref:`branchstatus`. +Merging of pull requests to security branches is restricted to release managers. +Any release made from a security branch is source-only and done only when actual +security fixes have been applied to the branch. These releases have a +**micro version** number greater than the last **bugfix** release. + +.. _eolbranch: + +End-of-life branches +^^^^^^^^^^^^^^^^^^^^ + +The code base for a release cycle which has reached end-of-life status +is frozen and no longer has a branch in the repo. The final state of +the end-of-lifed branch is recorded as a tag with the same name as the +former branch, for example, ``3.8`` or ``2.7``. + +The :ref:`versions` page contains list of active and end-of-life branches. + +The latest release for each Python version can be found on the `download page +<https://www.python.org/downloads/>`__. + +.. _stages: + +Stages +------ + +Based on what stage the :ref:`in-development <indevbranch>` version of Python +is in, the responsibilities of a core team member change in regards to commits +to the :abbr:`VCS (version control system)`. + + +Pre-alpha +^^^^^^^^^ + +The branch is in this stage when no official release has been done since +the latest final release. There are no special restrictions placed on +commits, although the usual advice applies (getting pull requests reviewed, +avoiding breaking the buildbots). + +.. _alpha: + +Alpha +^^^^^ + +Alpha releases typically serve as a reminder to the core team that they +need to start getting in changes that change semantics or add something to +Python as such things should not be added during a Beta_. Otherwise no new +restrictions are in place while in alpha. + +.. _beta: + +Beta +^^^^ + +After a first beta release is published, no new features are accepted. Only +bug fixes and improvements to documentation and tests can now be committed. +This is when the core team should concentrate on the task of fixing +regressions and other new issues filed by users who have downloaded the alpha +and beta releases. + +Being in beta can be viewed much like being in RC_ but without the extra +overhead of needing commit reviews. + + +.. _rc: + +Release Candidate (RC) +^^^^^^^^^^^^^^^^^^^^^^ + +A branch preparing for an RC release can only have bugfixes applied that have +been reviewed by other core team members. Generally, these issues must be +severe enough (for example, crashes) that they deserve fixing before the final release. +All other issues should be deferred to the next development cycle, since +stability is the strongest concern at this point. + +While the goal is to have no code changes between an RC and a final release, +there may be a need for final documentation or test fixes. Any such proposed +changes should be discussed first with the release manager. + +You **cannot** skip the peer review during an RC, no matter how small! Even if +it is a simple copy-and-paste change, **everything** requires peer review from +a core team member. + +.. _final: + +Final +^^^^^ + +When a final release is being cut, only the release manager (RM) can make +changes to the branch. + + +Repository administration +------------------------- + +The source code is currently hosted on `GitHub +<https://github.com/python/cpython>`__ in the `Python organization <https://github.com/python/>`__. + +Organization repository policy +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Within the `GitHub Python organization <https://github.com/python/>`__, +repositories are expected to relate to the Python language, the CPython +reference implementation, their documentation and their development workflow. +This includes, for example: + +* The reference implementation of Python and related repositories: `CPython <https://github.com/python/cpython>`__. +* Tooling and support around CPython development: `pyperformance <https://github.com/python/pyperformance>`__, `Bedevere <https://github.com/python/bedevere>`__. +* Helpers and backports for Python/CPython features: `typing_extensions <https://github.com/python/typing_extensions>`__, `typeshed <https://github.com/python/typeshed>`__, `tzdata <https://github.com/python/tzdata>`__, `pythoncapi-compat <https://github.com/python/pythoncapi-compat>`__. +* Organization-related repositories: the `Code of Conduct <https://github.com/python/pycon-code-of-conduct>`__, `.github <https://github.com/python/.github>`__. +* Documentation and websites for all the above: `python.org repository <https://github.com/python/pythondotorg>`__, `PEPs <https://github.com/python/peps>`__, `Devguide <https://github.com/python/devguide>`__, docs translations. +* Infrastructure for all the above: `docsbuild-scripts <https://github.com/python/docsbuild-scripts>`__, `buildmaster-config <https://github.com/python/buildmaster-config>`__. +* Discussions and notes around official development-related processes and events: `steering-council <https://github.com/python/steering-council>`__, `core-sprint <https://github.com/python/core-sprint>`__. + +Before adding a new repository to the organization, open a discussion to seek consensus +in the `Committers Discourse category <https://discuss.python.org/c/committers/5>`__. +Once people are satisfied with that, ask the `Python steering council <https://github.com/python/steering-council>`__ +to grant permission. Note that this process is not necessary for +:ref:`docs translations <translation-repo>` following +:pep:`PEP 545 <545#repository-for-po-files>`, which can be added at a +core team member’s discretion. + +Note that several repositories remain in the organization for historic reasons, +and would probably not be appropriate to add today. + +Generally, new repositories should start their life under personal GitHub +accounts or other GitHub orgs. It is relatively easy to move a repository to +the organization once it is mature. For example, this would now apply to +experimental features like `asyncio <https://github.com/python/asyncio>`__, +`exceptiongroups <https://github.com/python/exceptiongroups>`__, +and drafts of new guides and other documentation (for example, `redistributor-guide +<https://github.com/python/redistributor-guide>`__). + +General-use tools and libraries (for example, `mypy <https://github.com/python/mypy>`__ +or `Black <https://github.com/psf/black>`__) should also be developed outside +the ``python`` organization, unless core devs (as represented by the SC) +specifically want to “bless” one implementation (as with +`typeshed <https://github.com/python/typeshed>`__, +`tzdata <https://github.com/python/tzdata>`__, or +`pythoncapi-compat <https://github.com/python/pythoncapi-compat>`__). + + +Organization owner policy +^^^^^^^^^^^^^^^^^^^^^^^^^ + +The GitHub Organization Owner role allows for full management of all aspects of +the Python organization. Allowing for visibility and management of all aspects +at all levels including organization membership, team membership, access +control, and merge privileges on all repositories. For full details of the +permission levels see `GitHub's documentation on Organization permission +levels +<https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles>`__. +This role is paramount to the security of the Python Language, Community, and +Infrastructure. + +The Executive Director of the Python Software Foundation delegates authority on +GitHub Organization Owner Status to Jacob Coffee - Python Software +Foundation Infrastructure Engineer. Common reasons for this role are: +Infrastructure Staff Membership, Python Software Foundation General Counsel, +and Python Software Foundation Staff as fallback. + +Inactive or unreachable members may be removed with or without notice. Members +who no longer necessitate this level of access will be removed with notice. + +Multi-Factor Authentication must be enabled by the user in order to remain an +Owner of the Python Organization. + +.. _current owners: + +Current owners +^^^^^^^^^^^^^^ + ++----------------------+--------------------------------+-----------------+ +| Name | Role | GitHub Username | ++======================+================================+=================+ +| Benjamin Peterson | Infrastructure Staff | benjaminp | ++----------------------+--------------------------------+-----------------+ +| Noah Kantrowitz | Infrastructure Staff | coderanger | ++----------------------+--------------------------------+-----------------+ +| Donald Stufft | Infrastructure Staff | dstufft | ++----------------------+--------------------------------+-----------------+ +| Ee Durbin | Infrastructure Staff | ewdurbin | ++----------------------+--------------------------------+-----------------+ +| Jacob Coffee | PSF Infrastructure Engineer | JacobCoffee | ++----------------------+--------------------------------+-----------------+ +| Łukasz Langa | CPython Developer in Residence | ambv | ++----------------------+--------------------------------+-----------------+ + +Certain actions (blocking spam accounts, inviting new users, adjusting +organization-level settings) can only `be performed`_ by owners of the Python +organization on GitHub. The ``@python/organization-owners`` team can be +mentioned to request assistance from an organization owner. + +.. _be performed: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles + +Repository administrator role policy +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The Administrator role on the repository allows for managing all aspects +including collaborators, access control, integrations, webhooks, and branch +protection. For full details of the permission levels see `GitHub's +documentation on repository permission levels +<https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles>`__. +Common reasons for this role are: maintenance of core +workflow tooling, Release Managers for all :ref:`in-development <indevbranch>`, +:ref:`maintenance <maintbranch>`, and :ref:`security mode <secbranch>` +releases, and additional Python core team members as necessary for redundancy. +Occasional temporary administrator access is acceptable as necessary for core +workflow projects. + +Inactive or unreachable members may be removed with or without notice. Members +who no longer necessitate this level of access will be removed with notice. + +Multi-Factor Authentication must be enabled by the user in order to remain an +Administrator of the repository. + +Current administrators +^^^^^^^^^^^^^^^^^^^^^^ + ++--------------------+----------------------------------------------------------+-------------------+ +| Name | Role | GitHub Username | ++====================+==========================================================+===================+ +| Savannah Ostrowski | Python 3.16 and 3.17 Release Manager | savannahostrowski | ++--------------------+----------------------------------------------------------+-------------------+ +| Hugo van Kemenade | Python 3.14 and 3.15 Release Manager | hugovk | ++--------------------+----------------------------------------------------------+-------------------+ +| Thomas Wouters | Python 3.12 and 3.13 Release Manager | Yhg1s | ++--------------------+----------------------------------------------------------+-------------------+ +| Pablo Galindo | Python 3.10 and 3.11 Release Manager, | pablogsal | +| | Maintainer of buildbot.python.org | | ++--------------------+----------------------------------------------------------+-------------------+ +| Łukasz Langa | PSF CPython Developer in Residence 2021-present | ambv | ++--------------------+----------------------------------------------------------+-------------------+ +| Brett Cannon | | brettcannon | ++--------------------+----------------------------------------------------------+-------------------+ +| Ezio Melotti | Maintainer of bugs.python.org GitHub webhook integration | ezio-melotti | ++--------------------+----------------------------------------------------------+-------------------+ +| Mariatta Wijaya | Maintainer of bedevere, blurb_it and miss-islington | Mariatta | ++--------------------+----------------------------------------------------------+-------------------+ +| Seth Larson | PSF Security Developer-in-Residence | sethmlarson | ++--------------------+----------------------------------------------------------+-------------------+ + +Repository release manager role policy +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Release Managers for :ref:`in-development <indevbranch>`, :ref:`maintenance +<maintbranch>`, and :ref:`security mode <secbranch>` Python releases are +granted Administrator privileges on the repository. Once a release branch has +entered :ref:`end-of-life <eolbranch>`, the Release Manager for that branch +creates a final tag and deletes the branch. After this, they are +removed as an Administrator. + +Multi-Factor Authentication must be enabled by the user in order to retain +access as a Release Manager of the branch. + +PyPI organization policy +^^^^^^^^^^^^^^^^^^^^^^^^ + +The Python core team owns the :pypi-org:`cpython` and :pypi-org:`python` +organizations on PyPI for publishing packages. +The main benefits of adding packages to these organizations: + +* Visibility: we can see our packages under a PyPI org page +* Maintainability: we can share granular PyPI access to improve the bus factor + +The general policy on which organization to use: + +* :pypi-org:`cpython`: + for development tools that are tied fairly closely to CPython development. + For example, :pypi:`blurb` and :pypi:`cherry-picker`. + Users generally shouldn’t have to care except for developing CPython itself + (although that doesn’t mean the tools necessarily have to be unusable for + anyone else). +* :pypi-org:`python`: + for general-audience projects that are maintained by the Python core team. + For example, :pypi:`pyperformance`, :pypi:`python-docs-theme` and + :pypi:`tzdata`. + + +Governance +---------- + +The Python Steering Council has overall authority over Python and has delegated +some of its responsibilities to other groups. + +This table lists the PEPs defining each group's responsibilities, +and the repository where you can open an issue to ask for a decision. + +.. list-table:: + :header-rows: 1 + + * - Name + - PEP + - Contact repo + * - Steering Council + - :pep:`13` + - :github:`python/steering-council` + * - C API Working Group + - :pep:`731` + - :github:`capi-workgroup/decisions` + * - Documentation Editorial Board + - :pep:`732` + - :github:`python/editorial-board` + * - Typing Council + - :pep:`729` + - :github:`python/typing-council` + +.. seealso:: + + All governance PEPs: https://peps.python.org/topic/governance/ diff --git a/developer-workflow/extension-modules.rst b/developer-workflow/extension-modules.rst new file mode 100644 index 0000000000..4d8c0ffca1 --- /dev/null +++ b/developer-workflow/extension-modules.rst @@ -0,0 +1,669 @@ +.. _extension-modules: +.. _extensions: + +================================== +Standard library extension modules +================================== + +In this section, we explain how to configure and compile the CPython project +with a C :term:`extension module`. We will not explain how to write a C +extension module and prefer to give you some links where you can read good +documentation: + +* https://docs.python.org/dev/c-api/ +* https://docs.python.org/dev/extending/ +* :pep:`399` +* https://pythonextensionpatterns.readthedocs.io/en/latest/ + +Some modules in the standard library, such as :mod:`datetime` or :mod:`pickle`, +have identical implementations in C and Python; the C implementation, when +available, is expected to improve performance (such extension modules are +commonly referred to as *accelerator modules*). + +Other modules mainly implemented in Python may import a C helper extension +providing implementation details (for instance, the :mod:`csv` module uses +the internal :mod:`!_csv` module defined in :cpy-file:`Modules/_csv.c`). + +Classifying extension modules +============================= + +Extension modules can be classified into two categories: + +* A *built-in* extension module is a module built and shipped with + the Python interpreter. A built-in module is *statically* linked + into the interpreter, thereby lacking a :attr:`!__file__` attribute. + + .. seealso:: :data:`sys.builtin_module_names` --- names of built-in modules. + + Built-in modules are built with the :c:macro:`!Py_BUILD_CORE_BUILTIN` + macro defined. + +* A *shared* (or *dynamic*) extension module is built as a shared library + (``.so`` or ``.dll`` file) and is *dynamically* linked into the interpreter. + + In particular, the module's :attr:`!__file__` attribute contains the path + to the ``.so`` or ``.dll`` file. + + Shared modules are built with the :c:macro:`!Py_BUILD_CORE_MODULE` + macro defined. Using the :c:macro:`!Py_BUILD_CORE_BUILTIN` macro + instead causes an :exc:`ImportError` when importing the module. + +.. note:: + + Informally, built-in extension modules can be regarded as *required* + while shared extension modules are *optional* in the sense that they + might be supplied, overridden or disabled externally. + + Usually, accelerator modules are built as *shared* extension modules, + especially if they already have a pure Python implementation. + +According to :pep:`399`, *new* extension modules MUST provide a working and +tested pure Python implementation, unless a special dispensation from +the :github:`Steering Council <python/steering-council>` is given. + +Adding an extension module to CPython +===================================== + +Assume that the standard library contains a pure Python module :mod:`!foo` +with the following :func:`!foo.greet` function: + +.. code-block:: python + :caption: Lib/foo.py + + def greet(): + return "Hello World!" + +Instead of using the Python implementation of :func:`!foo.greet`, we want to +use its corresponding C extension implementation exposed in the :mod:`!_foo` +module. Ideally, we want to modify ``Lib/foo.py`` as follows: + +.. code-block:: python + :caption: Lib/foo.py + + try: + # use the C implementation if possible + from _foo import greet + except ImportError: + # fallback to the pure Python implementation + def greet(): + return "Hello World!" + +.. note:: + + Accelerator modules should *never* be imported directly. The convention is + to mark them as private implementation details with the underscore prefix + (namely, :mod:`!_foo` in this example). + +In order to incorporate the accelerator module, we need to determine: + +- where to update the CPython project tree with the extension module source code, +- which files to modify to configure and compile the CPython project, and +- which ``Makefile`` rules to invoke at the end. + +Updating the CPython project tree +--------------------------------- + +Usually, accelerator modules are added in the :cpy-file:`Modules` directory of +the CPython project. If more than one file is needed for the extension module, +it is more convenient to create a sub-directory in :cpy-file:`Modules`. + +In the simplest example where the extension module consists of one file, it may +be placed in :cpy-file:`Modules` as ``Modules/_foomodule.c``. For a non-trivial +example of the extension module :mod:`!_foo`, we consider the following working +tree: + +- :ref:`Modules/_foo/_foomodule.c` --- the extension module implementation. +- :ref:`Modules/_foo/helper.h` --- the extension helpers declarations. +- :ref:`Modules/_foo/helper.c` --- the extension helpers implementations. + +By convention, the source file containing the extension module implementation +is called ``<NAME>module.c``, where ``<NAME>`` is the name of the module that +will be later imported (in our case :mod:`!_foo`). In addition, the directory +containing the implementation should also be named similarly. + +.. code-block:: c + :caption: Modules/_foo/helper.h + :name: Modules/_foo/helper.h + + #ifndef _FOO_HELPER_H + #define _FOO_HELPER_H + + #include "Python.h" + + typedef struct { + /* ... */ + } foomodule_state; + + static inline foomodule_state * + get_foomodule_state(PyObject *module) + { + void *state = PyModule_GetState(module); + assert(state != NULL); + return (foomodule_state *)state; + } + + /* Helper used in Modules/_foo/_foomodule.c + * but implemented in Modules/_foo/helper.c. + */ + extern PyObject * + _Py_greet_fast(void); + + #endif // _FOO_HELPER_H + +.. tip:: + + Functions or data that do not need to be shared across different C source + files should be declared ``static`` to avoid exporting their symbols from + ``libpython``. + + If symbols need to be exported, their names must start with ``Py`` or + ``_Py``. This can be verified by ``make smelly``. For more details, + please refer to the section on :ref:`Changing Python's C API <c-api>`. + +.. code-block:: c + :caption: Modules/_foo/helper.c + :name: Modules/_foo/helper.c + + #include "_foomodule.h" + + PyObject *_Py_greet_fast(void) { + return PyUnicode_FromString("Hello World!"); + } + +.. code-block:: c + :caption: Modules/_foo/_foomodule.c + :name: Modules/_foo/_foomodule.c + + #include "helper.h" + #include "clinic/_foomodule.c.h" + + /* Functions for the extension module's state */ + static int + foomodule_exec(PyObject *module) + { + // imports, static attributes, exported classes, etc + return 0; + } + + static int + foomodule_traverse(PyObject *m, visitproc visit, void *arg) + { + foomodule_state *st = get_foomodule_state(m); + // call Py_VISIT() on the state attributes + return 0; + } + + static int + foomodule_clear(PyObject *m) + { + foomodule_state *st = get_foomodule_state(m); + // call Py_CLEAR() on the state attributes + return 0; + } + + static void + foomodule_free(void *m) { + (void)foomodule_clear((PyObject *)m); + } + + /* Implementation of publicly exported functions. */ + + /*[clinic input] + module foo + [clinic start generated code]*/ + /*[clinic end generated code: output=... input=...]*/ + + /*[clinic input] + foo.greet -> object + + [clinic start generated code]*/ + + static PyObject * + foo_greet_impl(PyObject *module) + /*[clinic end generated code: output=... input=...]*/ + { + return _Py_greet_fast(); + } + + /* Exported module's data */ + + static PyMethodDef foomodule_methods[] = { + // macro in 'clinic/_foomodule.c.h' after running 'make clinic' + FOO_GREET_METHODDEF + {NULL, NULL} + }; + + static struct PyModuleDef_Slot foomodule_slots[] = { + // 'foomodule_exec' may be NULL if the state is trivial + {Py_mod_exec, foomodule_exec}, + {Py_mod_multiple_interpreters, Py_MOD_PER_INTERPRETER_GIL_SUPPORTED}, + {Py_mod_gil, Py_MOD_GIL_NOT_USED}, + {0, NULL}, + }; + + static struct PyModuleDef foomodule = { + PyModuleDef_HEAD_INIT, + .m_name = "_foo", + .m_doc = "some doc", // or NULL if not needed + .m_size = sizeof(foomodule_state), + .m_methods = foomodule_methods, + .m_slots = foomodule_slots, + .m_traverse = foomodule_traverse, // or NULL if the state is trivial + .m_clear = foomodule_clear, // or NULL if the state is trivial + .m_free = foomodule_free, // or NULL if the state is trivial + }; + + PyMODINIT_FUNC + PyInit__foo(void) + { + return PyModuleDef_Init(&foomodule); + } + +.. tip:: + + Recall that the ``PyInit_<NAME>`` function must be suffixed by the + module name ``<NAME>`` used in import statements (here ``_foo``), + and which usually coincides with :c:member:`PyModuleDef.m_name`. + + Other identifiers such as those used in :ref:`Argument Clinic <clinic>` + inputs do not have such naming requirements. + +Configuring the CPython project +------------------------------- + +Now that we have added our extension module to the CPython source tree, +we need to update some configuration files in order to compile the CPython +project on different platforms. + +Updating ``Modules/Setup.{bootstrap,stdlib}.in`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Depending on whether the extension module is required to get a functioning +interpreter or not, we update :cpy-file:`Modules/Setup.bootstrap.in` or +:cpy-file:`Modules/Setup.stdlib.in`. In the former case, the extension +module is necessarily built as a built-in extension module. + +.. tip:: + + For accelerator modules, :cpy-file:`Modules/Setup.stdlib.in` should be + preferred over :cpy-file:`Modules/Setup.bootstrap.in`. + +For built-in extension modules, update :cpy-file:`Modules/Setup.bootstrap.in` +by adding the following line after the ``*static*`` marker: + +.. code-block:: text + :caption: :cpy-file:`Modules/Setup.bootstrap.in` + :emphasize-lines: 3 + + *static* + ... + _foo _foo/_foomodule.c _foo/helper.c + ... + +The syntax is ``<NAME> <SOURCES>`` where ``<NAME>`` is the name of the +module used in :keyword:`import` statements and ``<SOURCES>`` is the list +of space-separated source files. + +For other extension modules, update :cpy-file:`Modules/Setup.stdlib.in` +by adding the following line after the ``*@MODULE_BUILDTYPE@*`` marker +but before the ``*shared*`` marker: + +.. code-block:: text + :caption: :cpy-file:`Modules/Setup.stdlib.in` + :emphasize-lines: 3 + + *@MODULE_BUILDTYPE@* + ... + @MODULE__FOO_TRUE@_foo _foo/_foomodule.c _foo/helper.c + ... + *shared* + +The ``@MODULE_<NAME_UPPER>_TRUE@<NAME>`` marker expects ``<NAME_UPPER>`` to +be the upper-cased form of ``<NAME>``, where ``<NAME>`` has the same meaning +as before (in our case, ``<NAME_UPPER>`` and ``<NAME>`` are ``_FOO`` and +``_foo`` respectively). The marker is followed by the list of source files. + +If the extension module must be built as a *shared* module, put the +``@MODULE__FOO_TRUE@_foo`` line after the ``*shared*`` marker: + +.. code-block:: text + :caption: :cpy-file:`Modules/Setup.stdlib.in` + :emphasize-lines: 4 + + ... + *shared* + ... + @MODULE__FOO_TRUE@_foo _foo/_foomodule.c _foo/helper.c + +Updating :cpy-file:`configure.ac` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. add section about configuration variable afterwards + +* Locate the ``SRCDIRS`` variable and add the following line: + + .. code-block:: text + :caption: :cpy-file:`configure.ac` + :emphasize-lines: 4 + + AC_SUBST([SRCDIRS]) + SRCDIRS="\ + ... + Modules/_foo \ + ..." + + .. note:: + + This step is only needed when adding new source directories to + the CPython project. + +* Find the section containing ``PY_STDLIB_MOD`` and ``PY_STDLIB_MOD_SIMPLE`` + usages and add the following line: + + .. code-block:: text + :caption: :cpy-file:`configure.ac` + :emphasize-lines: 3 + + dnl always enabled extension modules + ... + PY_STDLIB_MOD_SIMPLE([_foo], [-I\$(srcdir)/Modules/_foo], []) + ... + + The ``PY_STDLIB_MOD_SIMPLE`` macro takes as arguments: + + * the module name ``<NAME>`` used in :keyword:`import` statements, + * the compiler flags (CFLAGS), and + * the linker flags (LDFLAGS). + + If the extension module may not be enabled or supported depending on the + host configuration, use the ``PY_STDLIB_MOD`` macro instead, which takes + as arguments: + + * the module name ``<NAME>`` used in :keyword:`import` statements, + * a boolean indicating whether the extension is **enabled** or not, + * a boolean indicating whether the extension is **supported** or not, + * the compiler flags (CFLAGS), and + * the linker flags (LDFLAGS). + + For instance, enabling the :mod:`!_foo` extension on Linux platforms, but + only providing support for 32-bit architecture, is achieved as follows: + + .. code-block:: text + :caption: :cpy-file:`configure.ac` + :emphasize-lines: 2, 3 + + PY_STDLIB_MOD([_foo], + [test "$ac_sys_system" = "Linux"], + [test "$ARCH_RUN_32BIT" = "true"], + [-I\$(srcdir)/Modules/_foo], []) + + More generally, the host's configuration status of the extension is + determined as follows: + + +-----------+-----------------+----------+ + | Enabled | Supported | Status | + +===========+=================+==========+ + | true | true | yes | + +-----------+-----------------+----------+ + | true | false | missing | + +-----------+-----------------+----------+ + | false | true or false | disabled | + +-----------+-----------------+----------+ + + The extension status is ``n/a`` if the extension is marked unavailable + by the ``PY_STDLIB_MOD_SET_NA`` macro. To mark an extension as unavailable, + find the usages of ``PY_STDLIB_MOD_SET_NA`` in :cpy-file:`configure.ac` and + add the following line: + + .. code-block:: text + :caption: :cpy-file:`configure.ac` + :emphasize-lines: 4 + + dnl Modules that are not available on some platforms + AS_CASE([$ac_sys_system], + ... + [PLATFORM_NAME], [PY_STDLIB_MOD_SET_NA([_foo])], + ... + ) + +.. tip:: + + Consider reading the comments and configurations for existing modules + in :cpy-file:`configure.ac` for guidance on adding new external build + dependencies for extension modules that need them. + +Updating :cpy-file:`Makefile.pre.in` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If needed, add the following line to the section for module dependencies: + +.. code-block:: text + :caption: :cpy-file:`Makefile.pre.in` + :emphasize-lines: 4 + + ########################################################################## + # Module dependencies and platform-specific files + ... + MODULE__FOO_DEPS=$(srcdir)/Modules/_foo/helper.h + ... + +The ``MODULE_<NAME_UPPER>_DEPS`` variable follows the same naming +requirements as the ``@MODULE_<NAME_UPPER>_TRUE@<NAME>`` marker. + +Updating MSVC project files +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +We describe the minimal steps for compiling on Windows using MSVC. + +* Update :cpy-file:`PC/config.c`: + + .. code-block:: c + :caption: :cpy-file:`PC/config.c` + :emphasize-lines: 3, 8 + + ... + // add the entry point prototype + extern PyObject* PyInit__foo(void); + ... + // update the entry points table + struct _inittab _PyImport_Inittab[] = { + ... + {"_foo", PyInit__foo}, + ... + {0, 0} + }; + ... + + Each item in ``_PyImport_Inittab`` consists of the module name to import, + here :mod:`!_foo`, with the corresponding ``PyInit_*`` function correctly + suffixed. + +* Update :cpy-file:`PCbuild/pythoncore.vcxproj`: + + .. code-block:: xml + :caption: :cpy-file:`PCbuild/pythoncore.vcxproj` + :emphasize-lines: 4, 11-12 + + <!-- group with header files ..\Modules\<MODULE>.h --> + <ItemGroup> + ... + <ClInclude Include="..\Modules\_foo\helper.h" /> + ... + </ItemGroup> + + <!-- group with source files ..\Modules\<MODULE>.c --> + <ItemGroup> + ... + <ClCompile Include="..\Modules\_foo\_foomodule.c" /> + <ClCompile Include="..\Modules\_foo\helper.c" /> + ... + </ItemGroup> + +* Update :cpy-file:`PCbuild/pythoncore.vcxproj.filters`: + + .. code-block:: xml + :caption: :cpy-file:`PCbuild/pythoncore.vcxproj.filters` + :emphasize-lines: 4-6, 13-18 + + <!-- group with header files ..\Modules\<MODULE>.h --> + <ItemGroup> + ... + <ClInclude Include="..\Modules\_foo\helper.h"> + <Filter>Modules\_foo</Filter> + </ClInclude> + ... + </ItemGroup> + + <!-- group with source files ..\Modules\<MODULE>.c --> + <ItemGroup> + ... + <ClCompile Include="..\Modules\_foo\_foomodule.c"> + <Filter>Modules\_foo</Filter> + </ClCompile> + <ClCompile Include="..\Modules\_foo\helper.c"> + <Filter>Modules\_foo</Filter> + </ClCompile> + ... + <ItemGroup> + +.. tip:: + + Header files use ``<ClInclude>`` tags, whereas + source files use ``<ClCompile>`` tags. + + +Compiling the CPython project +----------------------------- + +Now that the configuration is in place, it remains to compile the project: + +.. code-block:: shell + + make regen-configure + ./configure + make regen-all + make regen-stdlib-module-names + make + +.. tip:: + + Use ``make -jN`` to speed-up compilation by utilizing as many CPU cores + as possible, where *N* is as many CPU cores you want to spare (and have + memory for). Be careful using ``make -j`` with no argument, as this puts + no limit on the number of jobs, and compilation can sometimes use up a + lot of memory (like when building with LTO). + +* ``make regen-configure`` updates the :cpy-file:`configure` script. + + The :cpy-file:`configure` script must be generated using a specific version + of ``autoconf``. To that end, the :cpy-file:`Tools/build/regen-configure.sh` + script which the ``regen-configure`` rule is based on either requires Docker + or Podman, the latter being assumed by default. + + .. tip:: + + We recommend installing `Podman <https://podman.io/docs/installation>`__ + instead of Docker since the former does not require a background service + and avoids creating files owned by the ``root`` user in some cases. + +* ``make regen-all`` is responsible for regenerating header files and + invoking other scripts, such as :ref:`Argument Clinic <clinic>`. + Execute this rule if you do not know which files should be updated. + +* ``make regen-stdlib-module-names`` updates the standard module names, making + :mod:`!_foo` discoverable and importable via ``import _foo``. + +* The final ``make`` step is generally not needed since the previous ``make`` + invocations may completely rebuild the project, but it could be needed in + some specific cases. + +Troubleshooting +--------------- + +This section addresses common issues that you may face when following +this example of adding an extension module. + +No rule to make target ``regen-configure`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This usually happens after running ``make distclean`` (which removes +the ``Makefile``). The solution is to regenerate the :cpy-file:`configure` +script as follows: + +.. code-block:: shell + + ./configure # for creating the 'Makefile' file + make regen-configure # for updating the 'configure' script + ./configure # for updating the 'Makefile' file + +If missing, the :cpy-file:`configure` script can be regenerated +by executing :cpy-file:`Tools/build/regen-configure.sh`: + +.. code-block:: shell + + ./Tools/build/regen-configure.sh # create an up-to-date 'configure' + ./configure # create an up-to-date 'Makefile' + +``make regen-configure`` and missing permissions with Docker +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If Docker complains about missing permissions, this Stack Overflow post +could be useful in solving the issue: `How to fix docker: permission denied +<https://stackoverflow.com/q/48957195/9579194>`__. Alternatively, you may try +using `Podman <https://podman.io/docs/installation>`__. + +Missing ``Py_BUILD_CORE`` define when using internal headers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +By default, the CPython :ref:`Stable ABI <stable-abi>` is exposed via +:code:`#include "Python.h"`. In some cases, this may be insufficient +and internal headers from :cpy-file:`Include/internal` are needed; +in particular, those headers require the :c:macro:`!Py_BUILD_CORE` +macro to be defined. + +To that end, one should define the :c:macro:`!Py_BUILD_CORE_BUILTIN` +or the :c:macro:`!Py_BUILD_CORE_MODULE` macro depending on whether the +extension module is built-in or shared. Using either of the two macros +implies :c:macro:`!Py_BUILD_CORE` and gives access to CPython internals: + +.. code-block:: c + :caption: Definition of :c:macro:`!Py_BUILD_CORE_BUILTIN` + + #ifndef Py_BUILD_CORE_MODULE + # define Py_BUILD_CORE_BUILTIN 1 + #endif + +.. code-block:: c + :caption: Definition of :c:macro:`!Py_BUILD_CORE_MODULE` + + #ifndef Py_BUILD_CORE_BUILTIN + # define Py_BUILD_CORE_MODULE 1 + #endif + +Tips +---- + +In this section, we give some tips for improving the quality of +extension modules meant to be included in the standard library. + +Restricting to the Limited API +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In order for non-CPython implementations to benefit from new extension modules, +it is recommended to use the :ref:`Limited API <limited-c-api>`. Instead of +exposing the entire Stable ABI, define the :c:macro:`Py_LIMITED_API` macro +*before* the :code:`#include "Python.h"` directive: + +.. code-block:: c + :caption: Using the 3.13 Limited API. + :emphasize-lines: 3, 6 + + #include "pyconfig.h" // Py_GIL_DISABLED + #ifndef Py_GIL_DISABLED + # define Py_LIMITED_API 0x030d0000 + #endif + + #include "Python.h" + +This makes the extension module non-CPython implementation-friendly by +removing the dependencies to CPython internals. diff --git a/developer-workflow/grammar.rst b/developer-workflow/grammar.rst new file mode 100644 index 0000000000..bd314c61e3 --- /dev/null +++ b/developer-workflow/grammar.rst @@ -0,0 +1,8 @@ +.. _grammar: + +========================== +Changing CPython's grammar +========================== + +This document is now part of the +`CPython Internals Docs <https://github.com/python/cpython/blob/main/InternalDocs/changing_grammar.md>`__. diff --git a/developer-workflow/index.rst b/developer-workflow/index.rst new file mode 100644 index 0000000000..9919398e62 --- /dev/null +++ b/developer-workflow/index.rst @@ -0,0 +1,19 @@ +.. _dev-workflow: + +==================== +Development workflow +==================== + +.. toctree:: + :maxdepth: 5 + + communication-channels + lang-changes + development-cycle + stdlib + extension-modules + c-api + grammar + porting + sbom + psrt diff --git a/developer-workflow/lang-changes.rst b/developer-workflow/lang-changes.rst new file mode 100644 index 0000000000..0b2c613fa7 --- /dev/null +++ b/developer-workflow/lang-changes.rst @@ -0,0 +1,176 @@ +.. _lang-changes: +.. _langchanges: + +Changing Python +=============== + +On occasion people come up with an idea for changing or improving the Python +language or standard library. +This page explains how to propose changes and what to expect during the +process. + + +Considerations +-------------- + +First, understand that changes to Python +are difficult to make. When the language changes, +**every** Python programmer and all Python programmers to +come will end up eventually learning about the change you want to propose. +Books will need updating, code will be changed, and a new way to do things will +need to be learned. Changes to Python are never taken +lightly. + +Backward compatibility is a significant concern. Existing Python code has to +continue to work. There are exceptions to this rule, but they are very rare +and are only allowed when the benefits of the change greatly outweigh the costs +of breaking existing code. + +Because of the seriousness of changing the language, any change must be +beneficial to many Python users. If the change only helps a small percentage of +Python developers then the change will not be made. A good way to see if your +idea would work for a large portion of the Python community is to discuss it in +the `Ideas category in Discourse <ideas_>`_. You can also look in Python's standard +library to find examples of code which would benefit from your proposed change. + +.. important:: + For all of these reasons, most proposed changes to Python are rejected. This + doesn't mean you shouldn't suggest them. It can be useful to explore + alternatives and to get feedback from the community. Just be aware that + getting a change accepted is difficult. Don't take it personally. + +.. index:: + single: PEP process + +.. _suggesting-changes: + +Suggesting new features and language changes +-------------------------------------------- + +Proposing a change involves the following steps: + +- Describe your idea in detail. + +- Engage in discussion about the idea. + +- Rarely, the idea will advance to a formal proposal stage. + + +Describe your idea +^^^^^^^^^^^^^^^^^^ + +The `Ideas category in Discourse <ideas_>`_ is specifically intended for discussion +of new features and language changes. Make your proposal as a `new topic +<ideas_>`_ there. + +Your proposal needs to be **detailed**. Describe the change you want to make, +why you want to make it, and what benefits it will bring to Python users. Be +specific. Show that you have considered the effect of the change on existing +code. + +Some things you should **not** do: + +- **Don't** format your idea as a Python Enhancement Proposal (PEP). + It's good to use the PEP template as a guide for what information to include, + but don't try to write a full PEP until the idea has been accepted for + further consideration. + +- **Don't** create a list of proposed changes. Each idea needs its own + discussion. Proposing a change is significant work. You will need to spend + time on each proposal. A tossed-off list will not be taken seriously. + +When justifying your idea, these are **not good reasons** to make a change: + +- "Other languages work this way." Languages are different. What works well + in one language may not work well in Python, or Python may already have a + way to do a similar thing. + +- "It would be nice." This is too vague. Be specific about the benefits + your change will bring, and consider the costs as well. + +Some things you **should** do: + +- Research whether your idea has been proposed before. There are many + suggestions that have been made and rejected in the past. If your idea has a + history, read the discussion to see why it was rejected. Previously rejected + ideas are especially unlikely to get accepted. If you can address the + concerns raised in the previous discussion, mention that in your proposal. + +- Read other ideas to see how they are presented. This will help you flesh out + your proposal. + +- Read other ideas to understand the kinds of concerns that are raised and + objections that must be answered. Your proposal will be stronger if you can + address these concerns up front. + +- Provide enough detail to fully explain your idea, and to show that you have + considered all the implications of the change. Strike the right balance + between brevity and completeness. A shorter proposal will be easier to + discuss, so long as it includes all the necessary information. + + +Engage in discussion +^^^^^^^^^^^^^^^^^^^^ + +Once you post your proposal, people will respond. You need to continue +the discussion, answer questions, and address objections. This is an important +part of the process. Other people's perspectives will help explore the full +impact of the idea and find strengths or weaknesses you may not have +considered. + +You will almost always get at least some push-back. Don't be disappointed, +and don't take it personally. +As the long list of :pep:`Withdrawn and Rejected PEPs +<0#rejected-superseded-and-withdrawn-peps>` in the :pep:`PEP Index <0>` +attests, and as befits a mature programming language, getting significant +changes into Python isn't a simple task. + +Engage in good faith. The goal of the discussion is to find the best balance +between competing concerns. If your idea has merit, the discussion will help +refine it and make it stronger. If your idea has flaws, the discussion will +help identify them so you can address them or move on. Keep the discussion +productive and focused on the issues, not on personalities. + +It is especially useful to discuss with core team members since +they know the language and design considerations well. +If your proposal makes it to the PEP stage, +you'll need a core team member as a sponsor. +Sometimes they will differ in opinion, or merely be unconvinced. When there +isn't a clear positive sentiment, the `Status Quo Wins a Stalemate`_. + +Even if your idea is not accepted, the discussion can help you and others +understand the design of Python better, and help inform future proposals. + + +Formal proposal +^^^^^^^^^^^^^^^ + +If the idea gets positive discussion, someone will suggest posting it as a +feature request on the `issue tracker`_, or, for larger changes, writing it up +as PEP following the :ref:`lang-changes-pep-process`. Congratulations! + + +.. index:: PEP process + +.. _lang-changes-pep-process: + +PEP process +----------- + +Once you have a proposal which will appeal to +the general Python community, you can begin the PEP +process to officially propose the change. +This starts with finding a sponsor from the core team. +See :pep:`1` for +information on PEPs and the PEP process, and the :pep:`PEP Index <0>` for +examples. + +If the PEP is accepted, then your language change will be introduced in a +future release of Python. Otherwise, your PEP will be recorded as rejected +along with an explanation, to inform others who may propose a similar language +change in the future. + + +.. _issue tracker: https://github.com/python/cpython/issues +.. _ideas: https://discuss.python.org/c/ideas/6 +.. _Status Quo Wins a Stalemate: https://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate/ diff --git a/porting.rst b/developer-workflow/porting.rst similarity index 81% rename from porting.rst rename to developer-workflow/porting.rst index fdf01eef91..f308e6c14b 100644 --- a/porting.rst +++ b/developer-workflow/porting.rst @@ -1,7 +1,8 @@ .. _porting: -Porting Python to a new platform --------------------------------- +========================= +Porting to a new platform +========================= The first step is to familiarize yourself with the development toolchain on the platform in question, notably the C compiler. Make sure you can compile and @@ -11,12 +12,12 @@ Next, learn how to compile and run the Python interpreter on a platform to which it has already been ported; preferably Unix, but Windows will do, too. The build process for Python, in particular the ``Makefile`` in the source distribution, will give you a hint on which files to compile -for Python. Not all source files are relevant: some are platform -specific, others are only used in emergencies (e.g. ``getopt.c``). +for Python. Not all source files are relevant: some are platform-specific, +and others are only used in emergencies (for example, ``getopt.c``). -It is not recommended to start porting Python without at least medium-level -understanding of your target platform; i.e. how it is generally used, how to -write platform specific apps, etc. Also, some Python knowledge is required, or +It is not recommended to start porting Python without at least a medium-level +understanding of your target platform; how it is generally used, how to +write platform-specific apps, and so on. Also, some Python knowledge is required, or you will be unable to verify that your port is working correctly. You will need a ``pyconfig.h`` file tailored for your platform. You can diff --git a/developer-workflow/psrt-emeritus.csv b/developer-workflow/psrt-emeritus.csv new file mode 100644 index 0000000000..f9d26bfba4 --- /dev/null +++ b/developer-workflow/psrt-emeritus.csv @@ -0,0 +1,10 @@ +Anthony Baxter,,Release Manager +Christian Heimes,tiran, +Georg Brandl,birkenfeld, +Huzaifa Sidhpurwala,, +Jesse Noller,, +Kushal Das,kushaldas, +Mark Hammond,mhammond, +Nam Nguyen,, +Neal Norwitz,, +Trent Mick,, diff --git a/developer-workflow/psrt.csv b/developer-workflow/psrt.csv new file mode 100644 index 0000000000..da67432d9b --- /dev/null +++ b/developer-workflow/psrt.csv @@ -0,0 +1,27 @@ +Adam Turner,AA-Turner, +Barry Warsaw,warsaw,Admin +Bénédikt Tran,picnixz, +Benjamin Peterson,benjaminp, +Donald Stufft,dstufft, +Dustin Ingram,di, +Ee Durbin,ewdurbin,Admin +Emma Smith,emmatyping, +Glyph Lefkowitz,glyph, +Gregory P. Smith,gpshead, +Hugo van Kemenade,hugovk,Release Manager +Jacob Coffee,JacobCoffee, +Larry Hastings,larryhastings, +Łukasz Langa,ambv,Release Manager +Ned Deily,ned-deily,"Admin, Release Manager" +Pablo Galindo Salgado,pablogsal,Release Manager +Paul McMillan,paulmcmillan, +Petr Viktorin,encukou, +Pradyun Gedam,pradyunsg, +Savannah Ostrowski,savannahostrowski,Release Manager +Serhiy Storchaka,serhiy-storchaka, +Seth Larson,sethmlarson,Admin +Stan Ulbrych,StanFromIreland, +Steve Dower,zooba,Release Manager +Thomas Wouters,Yhg1s,Release Manager +Tim Peters,tim-one, +William Woodruff,woodruffw, diff --git a/developer-workflow/psrt.rst b/developer-workflow/psrt.rst new file mode 100644 index 0000000000..c2501e44b7 --- /dev/null +++ b/developer-workflow/psrt.rst @@ -0,0 +1,360 @@ +Python Security Response Team (PSRT) +==================================== + +The Python Security Response Team (PSRT) is responsible for handling +vulnerability reports for CPython and pip. + +Members +------- + +The PSRT publishes a full +list of members and admins, included in the table below: + +.. csv-table:: + :header: "Name", "GitHub username", "Notes" + :file: psrt.csv + :encoding: "utf-8" + +See also the :ref:`members emeritus list <psrt-members-emeritus>`. + +How can I join the PSRT? +~~~~~~~~~~~~~~~~~~~~~~~~ + +Anyone can join the PSRT following a nomination process +`similar to core team nominations`_. Nomination for a new member +is brought to the PSRT by an existing PSRT member and then +this nomination is voted on by existing PSRT members. +The nomination succeeds if the nomination receives at least +two-thirds positive votes from a vote of existing PSRT members +that is open for one week and not vetoed by the Steering Council. + +Once per year the Steering Council will receive a report of inactive members +of the PSRT with the recommendation to remove the inactive users from the PSRT. +“Inactive” is defined as a member who hasn’t coordinated or commented on a +vulnerability report in the past year since the last report was generated. +The Steering Council may remove members of the PSRT with a simple vote. + +Members of the PSRT who are a Release Manager or Steering Council member may +remain in the PSRT regardless of inactivity in vulnerability reports. + +.. _similar to core team nominations: https://devguide.python.org/core-team/join-team/ + +Responsibilities of PSRT members +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Below are the responsibilities of PSRT members: + +* Being knowledgeable about typical software vulnerability report handling + processes, such as CVE IDs, patches, coordinated disclosure, embargoes. +* Not sharing or acting on embargoed information about the reported + vulnerability. Examples of disallowed behavior include sharing information + with colleagues or publicly deploying unpublished mitigations or patches ahead + of the advisory publication date. +* Acting as a “Coordinator” of vulnerability reports that are submitted to + projects. A Coordinator’s responsibility is to move a report through the PSRT + process to a “finished” state, either rejected or as a published advisory and + mitigation, within the industry standard timeline of 90 days. +* As a Coordinator, involving relevant core team members or triagers where + necessary to make a determination whether a report is a vulnerability and + developing a patch. Coordinators are encouraged to involve members of the core + team to make the best decision for each report rather than working in isolation. +* As a Coordinator, calculating the severity using CVSSv4 and authoring advisories + to be shared on `security-announce@python.org`_. These advisories are used for + CVE records by the `PSF CVE Numbering Authority`_. +* Coordinators that can no longer move a report forwards for any reason must + delegate their Coordinator role to someone else in the PSRT. + +.. _security-announce@python.org: https://mail.python.org/archives/list/security-announce@python.org/ +.. _PSF CVE Numbering Authority: https://www.python.org/cve-numbering-authority/ + +Responsibilities of PSRT admins +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +PSRT members who are designated as admins by the Steering Council have the +following additional responsibilities: + +* Triaging the ``security@python.org`` mailing list. +* Managing PSRT membership access including the GitHub team, the mailing list, + and Discord channel, to ensure they are synchronized with the canonical list + of PSRT members. +* On a yearly basis, providing the Steering Council with a report including a + list of inactive PSRT members. +* Running nomination elections, including counting final votes and giving + the Steering Council an opportunity to veto nominations via email. + +Triaging a vulnerability report +------------------------------- + +PSRT members coordinate reports from when they are first submitted +to a "finished" state. Finished states include +marking a report as a "non-issue", opening a public issue on GitHub, +or a merged patch with an accompanying CVE and advisory to +``security-announce@python.org``. Reports should reach a finished +state within 90 days of being received by the PSRT. + +Reports enter the system through ``security@python.org`` or +on a project GitHub Security Advisory (GHSA) ticketing system. +For projects that use GHSA, reports to ``security@python.org`` +should have reporters :ref:`re-open their report using GHSA <submit-using-ghsa>`. + +.. raw:: html + :file: ../_static/psrt-coordinator-report.html + +New report in GitHub Security Advisories (GHSA) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Once a report is in GHSA, a "Coordinator" must be assigned +to be responsible for moving the report through the process. +The "Coordinator" role is assigned using a "Credit" in a GHSA ticket +(Select 'Edit' > 'Credit' > Add GitHub username and the role 'Coordinator'). + +.. warning:: + Assigning the "Coordinator" role to each GHSA ticket is important, + as this metadata records whether a PSRT member is + `"active" according to PEP 811`_ to avoid being removed due to inactivity. + +.. _"active" according to PEP 811: https://peps.python.org/pep-0811/#psrt-membership-policy + +If a GHSA ticket is idle for three days without a coordinator +assigned a PSRT member who is not a Release Manager +or Steering Council member will be automatically assigned +as coordinator by the PSRT bot. +If a coordinator can't complete the process +they must find a replacement coordinator in the PSRT +and re-assign the GHSA ticket. + +.. raw:: html + :file: ../_static/psrt-coordinator-triage.html + +Determining whether a report is a vulnerability +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The coordinator will make a determination about a report, either +marking the ticket as a non-issue, as an issue that isn't a security +vulnerability, or as a security vulnerability. If the Coordinator needs +help from core team experts in making the determination, the +experts may be added as 'Collaborators' to the GHSA ticket. +Accepted security vulnerabilities will be moved to the 'Draft' state in GHSA. + +If the report isn't a vulnerability, coordinators close the GHSA ticket +after optionally opening a public GitHub issue. Note that reporters often +will not open a GitHub issue on their own, as there is no longer an incentive +for them to do so without a CVE being assigned. + +Remediating a vulnerability report +---------------------------------- + +Once a report has been accepted as a vulnerability, the remediation +development process begins. Coordinators move the GHSA ticket to a 'Draft' +state using the green 'Accept as Draft' button. Once in this state, +the PSRT bot will automatically assign a CVE ID from the Python Software +Foundation CVE Numbering Authority. + +Once a vulnerability has been accepted there are three things +the Coordinator must prepare before sending an advisory and +closing the GHSA ticket: + +* Severity calculated using CVSSv4. +* Pull request containing the fix merged with a public GitHub issue. +* Advisory title and short description of the vulnerability. + +Severity scoring +~~~~~~~~~~~~~~~~ + +Severity of a vulnerability can be difficult to assess +objectively due to not knowing how software is used +in all situations. Severity is calculated from expected +or known use, not from worst-case hypothetical scenarios. + +The PSRT and PSF CNA use `CVSSv4`_ for calculating +the severity of a vulnerability. GHSA tickets provide a +CVSSv4 calculator within the ticket UI. Note that GitHub defaults to CVSSv3, +change the scoring algorithm to CVSSv4 before scoring in the ticket UI. +As with all aspects of PSRT operations, coordinators are encouraged to ask +for help in calculating a severity from other PSRT members. + +.. _CVSSv4: https://www.first.org/cvss/v4.0/ + +Developing a patch privately +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Patch development can initially be done privately by selecting the +'Start a temporary private fork' button within the GHSA ticket. Note that +due to the size of Git repositories, this fork repository may +take several minutes to create. Once the fork has been created any PSRT member +or GHSA collaborator can clone the fork and develop a fix and push a branch: + +.. code-block:: shell + + git clone https://github.com/python/cpython-ghsa-abcd-efgh-ijkl.git + cd cpython-ghsa-abcd-efgh-ijkl + git checkout -b advisory-fix-1 + + # (develop a fix) + + git add ... + git commit -m "Fix" + git push origin advisory-fix-1 + +From here a pull request can be opened within the GHSA ticket +to be reviewed privately. The coordinator can add core team experts +as collaborators as necessary to the GHSA to develop the patch and to review +the patch if the expertise for patch development or review +aren't available within PSRT. Coordinators are not necessarily responsible +for developing patches themselves: only with seeing that a patch is +developed in a timely fashion by involving experts as necessary. + +Once the patch has been approved +a public GitHub issue and pull request can be opened. +Generate a blurb in the category ``Security`` for the public pull request. +Public issues and pull requests for security fixes should use the +:gh-label:`type-security` label. + +To quickly pull a patch file from a GHSA pull request, you +can append ``.patch`` to the pull request URL, like so: + +.. code-block:: shell + + curl https://github.com/python/cpython-ghsa-abcd-efgh-ijkl/pull/1.patch \ + --output ghsa-abcd-efgh-ijkl.patch + +This patch can then be applied and pushed to the public GitHub repository: + +.. code-block:: shell + + git remote -v + origin ssh://git@github.com/.../cpython (fetch) + origin ssh://git@github.com/.../cpython (fetch) + + git checkout -b branch-name + git apply ./ghsa-abcd-efgh-ijkl.patch + git push origin branch-name + +.. warning:: **IMPORTANT:** CPython's backport infrastructure + is used for tracking backported patches. Use **one GitHub issue + per CVE** to accurately track backports of vulnerability fixes. + For new CVEs, even when related to a previous issue, **open a + new GitHub issue** to accurately track fixed versions. + +.. warning:: **IMPORTANT:** Don't select the green 'Merge pull request' + or 'Publish advisory' buttons within GHSA. Advisories are published + to the mailing list, and the 'Merge pull request' button within + GHSA bypasses all continuous integration and branch protection + steps. Use a public pull request instead. + +Publishing an advisory +~~~~~~~~~~~~~~~~~~~~~~ + +Once the vulnerability fix has been merged into the main branch via a +public GitHub pull request, an advisory must be published. +The advisory requires the severity, +a title, and a short description of the vulnerable module, functions, +behavior and fix. This short description can optionally include mitigation steps +if applying the patch isn't the only way to mitigate the vulnerability. + +* Send an email to the ``security-announce@python.org`` mailing list + using the `advisory template`_, including title, severity, description. +* The advisory email will be received by PSF CVE Numbering Authority + operators and used to publish a CVE record. +* Begin the backporting process for all Python branches still receiving + security updates. Add the :gh-label:`type-security` and :gh-label:`release-blocker` labels + to each backport pull request so that release managers can find them prior + to releasing. + +After an advisory email is sent, the GHSA ticket can be closed. + +.. _advisory template: #advisory-email + +Handling code signing certificate reports +----------------------------------------- + +Python signs binaries using Azure Trusted Signing and Apple Developer ID +certificates. If a code signing certificate is reported as "compromised" or +"malware signed with certificate", the Python Security Response Team must +request the following information from the reporter: + +* Checksum(s) of binaries signed by certificate. +* Signature(s) of binaries signed by certificate. + +To avoid unnecessary user confusion and churn around revoking code signing +certificates, any reports **must be verifiable independently by the PSRT before +taking destructive actions**, such as revoking certificates. With this +information the PSRT can take investigative steps to verify the report, such as: + +* Downloading and checking artifacts from the associated Azure Pipelines + executions against the reported list of checksums. +* Verifying the validity of the signatures. `Past reports + <https://discuss.python.org/t/103356/2>`__ have contained signatures that + purported to be from Python code signing certificates, but were not valid. +* Checking the Azure Pipelines and Azure Trusted Signing audit logs for signs of + compromise. + +If any signs of compromise or incorrectly signed binaries are discovered by the +PSRT, only then will certificates be revoked and an advisory published. +If compromise is reported, the following non-destructive actions can be taken by +the PSRT without verifying the reported information as a precaution, if +relevant: + +* Rotating secrets associated with code signing (``TrustedSigningSecret`` for + Azure Trusted Publishing). +* Resetting passwords for accounts with access to signing certificates. + +Template responses +------------------ + +These template responses should be used as guidance for messaging +in various points in the process above. They are not required to be sent as-is, +please feel free to adapt them as needed for the current context. + +.. _submit-using-ghsa: + +Submit using GitHub Security Advisories +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. highlight:: none + +:: + + Thanks for submitting this report. + We use GitHub Security Advisories for triaging vulnerability reports, + please submit your report here: + + https://github.com/python/cpython/security/advisories/new + +Rejecting a vulnerability report +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +:: + + Thanks for your report. We've determined that the report doesn't constitute + a vulnerability. Let us know if you disagree with this determination. + If you are interested in working on this further, you can optionally open a + public issue on GitHub. + +Advisory email +~~~~~~~~~~~~~~ + +:: + + Title: [{CVE-YYYY-XXXX}] {title} + + There is a {LOW, MEDIUM, HIGH, CRITICAL} severity vulnerability affecting {project}. + + {description} + + Please see the linked CVE ID for the latest information on affected versions: + + * https://www.cve.org/CVERecord?id={CVE-YYYY-XXXX} + * {pull request URL} + +.. _psrt-members-emeritus: + +Members emeritus +---------------- + +Members who have previously served on the PSRT. + +.. csv-table:: + :header: "Name", "GitHub username", "Notes" + :file: psrt-emeritus.csv + :encoding: "utf-8" diff --git a/developer-workflow/sbom.rst b/developer-workflow/sbom.rst new file mode 100644 index 0000000000..c8a2facd14 --- /dev/null +++ b/developer-workflow/sbom.rst @@ -0,0 +1,109 @@ +Software Bill-of-Materials (SBOM) +================================= + +Software Bill-of-Materials (abbreviated as "SBOM") is a document for sharing +information about software and how it's been composed. This format is used +most often in the security space for checking software and its dependencies +for vulnerabilities using vulnerability databases like +`CVE <https://www.cve.org/>`__ and `OSV <https://osv.dev/>`__. The SBOM format +that the CPython project uses is `SPDX <https://spdx.github.io/spdx-spec/v2.3/>`__ +which can be transformed into other formats if necessary by consumers. + +There are multiple sources of third-party dependencies for CPython. +Some are vendored into the source code of CPython itself (like ``mpdecimal`` +vendored at :cpy-file:`Modules/_decimal/libmpdec`) or they could be optionally pulled +in during builds like Windows using dependencies from the +`python/cpython-source-deps <https://github.com/python/cpython-source-deps>`__ +repository. + +Whenever adding or updating a third-party dependency, an update will likely +need to be done to the SBOM in order to track the version and software identifiers. + +Updating a dependency +--------------------- + +The SBOM for CPython's bundled dependencies is kept at +:cpy-file:`Misc/sbom.spdx.json`. When updating a dependency to a new version +you'll need to edit the version and other metadata about this dependency in +the SBOM. + +The recommended workflow is: + +1. Download the new dependency as an archive. Take note of the new version, download + URL, and checksum of the downloaded archive. +2. Update the vendored code in the CPython source tree. +3. Edit :cpy-file:`Misc/sbom.spdx.json` to add the new ``versionInfo``, + ``downloadLocation``, ``checksums``, and ``externalReferences`` for the + corresponding ``package``. For most of these updates all that's needed is to + update the embedded version within URLs and project identifiers. + Don't update any information in ``files`` and ``relationships`` as this will + be generated automatically by the SBOM tool. +4. Run ``make regen-sbom`` or ``python Tools/build/generate_sbom.py``. + Ensure that this doesn't fail with validation errors. +5. Run ``git diff Misc/sbom.spdx.json`` and check the diff matches the + expected changes. +6. Commit the changes to :cpy-file:`Misc/sbom.spdx.json` along with the + update to the dependency code. + +Adding a new dependency +----------------------- + +When adding a dependency it's important to have the following information: + +* Name, version, and download URL of the project +* License of the project as an `SPDX License Expression <https://spdx.org/licenses/>`__ +* Software identifiers that match values in vulnerability databases + (`CPE <https://nvd.nist.gov/products/cpe>`__ and + `Package URLs <https://github.com/package-url/purl-spec/blob/master/PURL-SPECIFICATION.rst>`__ + or "PURLs") +* Paths to include and exclude in the CPython source tree corresponding to this dependency + +After gathering this information: + +1. Add the information into a new entry in ``packages`` in the file + :cpy-file:`Misc/sbom.spdx.json`. Don't worry about formatting, the tool will + auto-format your manually written JSON. The fields to fill out include: + + * ``name`` for the project name. + * ``SPDXID`` which will be ``"SPDXRef-PACKAGE-{name}"``. + * ``licenseConcluded`` for the SPDX license identifier of the project license. + * ``versionInfo`` for the version of the project. + * ``downloadLocation`` should be an HTTPS URL for the project download as an archive. + * ``checksums[0].checksumValue`` and ``.algorithm`` will be the SHA-256 + checksum of the downloaded archive. + * ``originator`` for the original author information, prefix with either an + ``Organization:`` or ``Person:`` depending on the author/maintenance situation. + * ``primaryPackagePurpose`` will likely be ``"SOURCE"``. + * ``externalReferences`` is a list of one or more project identifiers, + either CPE or Package URL. The value for ``referenceLocator`` must include + the value in ``versionInfo`` to ensure the identifier + corresponds to the correct release of the software. You can read more about + external references in the `SPDX SBOM specification`_. +2. If a new license ID is to be used, add the license expression to + ``ALLOWED_LICENSE_EXPRESSIONS`` in the :cpy-file:`Tools/build/generate_sbom.py`. +3. Add the paths to include and exclude into a ``PackageFiles`` instance + with a key corresponding to the SBOM ID for the package (``SPDXID`` without the + ``SPDXRef-PACKAGE-*`` prefix) in :cpy-file:`Tools/build/generate_sbom.py`. +4. Run the tool with ``make regen-sbom`` or ``python Tools/build/generate_sbom.py``. + Ensure that the tool doesn't fail with any validation errors. +5. Compare the changes to :cpy-file:`Misc/sbom.spdx.json` with ``git diff``, check + that all information appears correct. +6. Commit the changes to :cpy-file:`Misc/sbom.spdx.json` and + :cpy-file:`Tools/build/generate_sbom.py`. + +.. _SPDX SBOM specification: https://spdx.github.io/spdx-spec/v2-draft/external-repository-identifiers/ + +Removing a dependency +--------------------- + +When removing a dependency: + +1. Remove the entry from the :cpy-file:`Misc/sbom.spdx.json` + under the ``packages`` field. +2. Remove the corresponding ``PackageFiles`` entry in :cpy-file:`Tools/build/generate_sbom.py` +3. Run the tool with ``make regen-sbom`` or ``python Tools/build/generate_sbom.py``. + Ensure that the tool doesn't fail with any validation errors. +4. Compare the changes to :cpy-file:`Misc/sbom.spdx.json` with ``git diff``, check + that correct package is removed from the SBOM. +5. Commit the changes to :cpy-file:`Misc/sbom.spdx.json` and + :cpy-file:`Tools/build/generate_sbom.py`. diff --git a/stdlibchanges.rst b/developer-workflow/stdlib.rst similarity index 55% rename from stdlibchanges.rst rename to developer-workflow/stdlib.rst index 970843bd86..b683e55e96 100644 --- a/stdlibchanges.rst +++ b/developer-workflow/stdlib.rst @@ -1,6 +1,7 @@ +.. _stdlib: .. _stdlibchanges: -Adding to the Stdlib +Adding to the stdlib ==================== While the stdlib contains a great amount of useful code, sometimes you want @@ -11,8 +12,6 @@ module. Changes to pre-existing code is not covered as that is considered a bugfix and thus is treated as a bug that should be filed on the `issue tracker`_. -.. _issue tracker: https://bugs.python.org/ - Adding to a pre-existing module ------------------------------- @@ -21,48 +20,47 @@ If you have found that a function, method, or class is useful and you believe it would be useful to the general Python community, there are some steps to go through in order to see it added to the stdlib. -First is you should gauge the usefulness of the code. Typically this is done -by sharing the code publicly. You have a couple of options for this. One is to -post it online at the `Python Cookbook`_. Based on feedback or reviews of the -recipe you can see if others find the functionality as useful as you do. -A search of the issue tracker for previous suggestions related to the proposed -addition may turn up a rejected issue that explains why the suggestion will not -be accepted. -Another is to do a blog post about the code and see what kind of responses you -receive. Posting to python-list (see :ref:`communication` for where to find the -list and other mailing lists) to discuss your code also works. Finally, asking -on a specific :abbr:`SIG (special interest group)` from mail.python.org or -python-ideas is also acceptable. This is not a required step but it is -suggested. +First, you should gauge the usefulness of the code, +which is typically done by sharing the code publicly. +This is not a required step, but it is suggested. +You have a several options for this: + +* Search the `issue tracker`_ for discussion related to the proposed addition. + This may turn up an issue that explains why the suggestion wasn't accepted. +* Open a new thread in the `Ideas Discourse category`_ + to gather feedback directly from the Python core team and community. +* Write a blog post about the code, which may also help gather useful feedback. If you have found general acceptance and usefulness for your code from people, you can open an issue on the `issue tracker`_ with the code attached as a -:ref:`patch <patch>`. If possible, also submit a +:ref:`pull request <pullrequest>`. If possible, also submit a :ref:`contributor agreement <contributor_agreement>`. -If a core developer decides that your code would be useful to the general +If a core team member decides that your code would be useful to the general Python community, they will then commit your code. If your code is not picked -up by a core developer and committed then please do not take this personally. +up by a core team and committed then please do not take this personally. Through your public sharing of your code in order to gauge community support for it you at least can know that others will come across it who may find it useful. -.. _Python Cookbook: https://code.activestate.com/recipes/langs/python/ +.. _Ideas Discourse category: https://discuss.python.org/c/ideas/6 Adding a new module ------------------- + It must be stated upfront that getting a new module into the stdlib is very difficult. Adding any significant amount of code to the stdlib increases the -burden placed upon core developers. It also means that the module somewhat -becomes "sanctioned" by the core developers as a good way to do something, +burden placed upon the core team. It also means that the module somewhat +becomes "sanctioned" by the core team as a good way to do something, typically leading to the rest of the Python community to using the new module over other available solutions. All of this means that additions to the stdlib are not taken lightly. -Acceptable Types of Modules -''''''''''''''''''''''''''' +Acceptable types of modules +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + Typically two types of modules get added to the stdlib. One type is a module which implements something that is difficult to get right. A good example of this is the :py:mod:`multiprocessing` package. Working out the various OS @@ -78,17 +76,18 @@ that the stdlib consists of. While a new stdlib module does not need to appeal to all users of Python, it should be something that a large portion of the community will find useful. -This makes sure that the developer burden placed upon core developers is worth +This makes sure that the developer burden placed upon the core team is worth it. Requirements -'''''''''''' +^^^^^^^^^^^^ + In order for a module to even be considered for inclusion into the stdlib, a couple of requirements must be met. The most basic is that the code must meet -:ref:`standard patch requirements <patch>`. For code that has +:ref:`standard pull request requirements <pullrequest>`. For code that has been developed outside the stdlib typically this means making sure the coding style guides are followed and that the proper tests have been written. @@ -105,46 +104,47 @@ year, a module needs to have established itself as (one of) the top choices by the community for solving the problem the module is intended for. The development of the module must move into Python's -infrastructure (i.e., the module is no longer directly maintained outside of +infrastructure (that is, the module is no longer directly maintained outside of Python). This prevents a divergence between the code that is included in the stdlib and that which is released outside the stdlib (typically done to provide the module to older versions of Python). It also removes the burden of forcing -core developers to have to redirect bug reports or patches to an external issue +the core team to have to redirect bug reports or changes to an external issue tracker and :abbr:`VCS (version control system)`. Someone involved with the development of the module must promise to help maintain the module in the stdlib for two years. -This not only helps out other core developers by alleviating workload from bug +This not only helps out other core team members by alleviating workload from bug reports that arrive from the first Python release containing the module, but also helps to make sure that the overall design of the module continues to be uniform. -Proposal Process -'''''''''''''''' -If the module you want to propose adding to the stdlib meets the proper -requirements, you may propose its inclusion. To start, you should email -python-list or python-ideas to make sure the community in general would support -the inclusion of the module (see :ref:`communication`). - -If the feedback from the community is positive overall, you will need to write -a :abbr:`PEP (Python enhancement proposal)` for the module's inclusion. It -should outline what the module's overall goal is, why it should be included in -the stdlib, and specify the API of the module. See the `PEP index`_ for PEPs -that have been accepted before that proposed a module for inclusion. - -Once your PEP is written, send it to python-ideas for basic vetting. Be -prepared for extensive feedback and lots of discussion (not all of it -positive). This will help make the PEP be of good quality and properly -formatted. - -When you have listened to, responded, and integrated as appropriate the -feedback from python-ideas into your PEP, you may send it to python-dev. You -will once again receive a large amount of feedback and discussion. A PEP -dictator will be assigned who makes the final call on whether the PEP will be -accepted or not. If the PEP dictator agrees to accept your PEP (which typically -means that the core developers end up agreeing in general to accepting -your PEP) then the module will be added to the stdlib once the creators of the -module sign :ref:`contributor agreements <contributor_agreement>`. - -.. _PEP index: https://www.python.org/dev/peps/ +Proposal process +^^^^^^^^^^^^^^^^ + +If the module you want to propose adding to the stdlib meets the requirements, +you may propose its inclusion +by following the :abbr:`PEP (Python Enhancement Proposal)` process. +See :pep:`1` for details, +and the :pep:`PEP index <0>` for previously-accepted PEPs +that have proposed a module for inclusion. + +If the PEP is accepted, then the module will be added to the stdlib +once the authors of the module sign +:ref:`contributor agreements <contributor_agreement>`. + +.. _issue tracker: https://github.com/python/cpython/issues + +Adding a new environment variable +--------------------------------- + +Names of environment variables should be uppercase and, from Python 3.13 +onwards, use underscores for readability and accessibility. + +For example, use ``PYTHON_CPU_COUNT`` instead of ``PYTHONCPUCOUNT``. + +See also: + +* :ref:`python:using-on-envvars` +* `"Change environment variable style" Discourse discussion + <https://discuss.python.org/t/change-environment-variable-style/35180>`__ diff --git a/developers.csv b/developers.csv deleted file mode 100644 index d5b89945e4..0000000000 --- a/developers.csv +++ /dev/null @@ -1,166 +0,0 @@ -Abhilash Raj,2019-08-06 -Paul Ganssle,2019-06-15 -Stéphane Wirtel,2019-04-08 -Stefan Behnel,2019-04-08 -Cheryl Sabella,2019-02-19 -Lisa Roach,2018-09-14 -Emily Morehouse,2018-09-14 -Pablo Galindo,2018-06-06 -Mark Shannon,2018-05-15 -Petr Viktorin,2018-04-16 -Julien Palard,2017-12-08 -Nathaniel J. Smith,2018-01-25 -Ivan Levkivskyi,2017-12-06 -Carol Willing,2017-05-24 -Mariatta,2017-01-27 -Xiang Zhang,2016-11-21 -Inada Naoki,2016-09-26 -Davin Potts,2016-03-06 -Xavier de Gaye,2016-06-03 -Martin Panter,2015-08-10 -Paul Moore,2015-03-15 -Robert Collins,2014-10-16 -Berker Peksağ,2014-06-26 -Steve Dower,2014-05-10 -Kushal Das,2014-04-14 -Steven D'Aprano,2014-02-08 -Yury Selivanov,2014-01-23 -Zachary Ware,2013-11-02 -Donald Stufft,2013-08-14 -Ethan Furman,2013-05-11 -Serhiy Storchaka,2012-12-26 -Chris Jerdonek,2012-09-24 -Eric Snow,2012-09-05 -Peter Moody,2012-05-20 -Hynek Schlawack,2012-05-14 -Richard Oudkerk,2012-04-29 -Andrew Svetlov,2012-03-13 -Petri Lehtinen,2011-10-22 -Meador Inge,2011-09-19 -Jeremy Kloth,2011-09-12 -Sandro Tosi,2011-08-01 -Alex Gaynor,2011-07-18 -Charles-François Natali,2011-05-19 -Nadeem Vawda,2011-04-10 -Jason R. Coombs,2011-03-14 -Ross Lagerwall,2011-03-13 -Eli Bendersky,2011-01-11 -Ned Deily,2011-01-09 -David Malcolm,2010-10-27 -Tal Einat,2010-10-04 -Łukasz Langa,2010-09-08 -Daniel Stutzbach,2010-08-22 -Éric Araujo,2010-08-10 -Brian Quinlan,2010-07-26 -Alexander Belopolsky,2010-05-25 -Tim Golden,2010-04-21 -Giampaolo Rodolà,2010-04-17 -Jean-Paul Calderone,2010-04-06 -Brian Curtin,2010-03-24 -Florent Xicluna,2010-02-25 -Dino Viehland,2010-02-23 -Larry Hastings,2010-02-22 -Victor Stinner,2010-01-30 -Stefan Krah,2010-01-05 -Doug Hellmann,2009-09-20 -Frank Wierzbicki,2009-08-02 -Ezio Melotti,2009-06-07 -Philip Jenvey,2009-05-07 -Michael Foord,2009-04-01 -R. David Murray,2009-03-30 -Chris Withers,2009-03-08 -Tarek Ziadé,2008-12-21 -Hirokazu Yamamoto,2008-08-12 -Armin Ronacher,2008-07-23 -Antoine Pitrou,2008-07-16 -Senthil Kumaran,2008-06-16 -Jesse Noller,2008-06-16 -Jesús Cea,2008-05-13 -Guilherme Polo,2008-04-24 -Jeroen Ruigrok van der Werven,2008-04-12 -Benjamin Peterson,2008-03-25 -David Wolever,2008-03-17 -Trent Nelson,2008-03-17 -Mark Dickinson,2008-01-06 -Amaury Forgeot d'Arc,2007-11-09 -Christian Heimes,2007-10-31 -Bill Janssen,2007-08-28 -Jeffrey Yasskin,2007-08-09 -Mark Summerfield,2007-08-01 -Alexandre Vassalotti,2007-05-21 -Travis E. Oliphant,2007-04-17 -Eric V. Smith,2007-02-28 -Josiah Carlson,2007-01-06 -Collin Winter,2007-01-05 -Richard Jones,2006-05-23 -Kristján Valur Jónsson,2006-05-17 -Jack Diederich,2006-05-17 -Steven Bethard,2006-04-27 -Gerhard Häring,2006-04-23 -George Yoshida,2006-04-17 -Ronald Oussoren,2006-03-03 -Nick Coghlan,2005-10-16 -Georg Brandl,2005-05-28 -Terry Jan Reedy,2005-04-07 -Bob Ippolito,2005-03-02 -Peter Astrand,2004-10-21 -Facundo Batista,2004-10-16 -Sean Reifschneider,2004-09-17 -Johannes Gijsbers,2004-08-14 -Matthias Klose,2004-08-04 -PJ Eby,2004-03-24 -Vinay Sajip,2004-02-20 -Hye-Shik Chang,2003-12-10 -Armin Rigo,2003-10-24 -Andrew McNamara,2003-06-09 -Samuele Pedroni,2003-05-16 -Alex Martelli,2003-04-22 -Brett Cannon,2003-04-18 -David Goodger,2003-01-02 -Gustavo Niemeyer,2002-11-05 -Tony Lownds,2002-09-22 -Steve Holden,2002-06-14 -Christian Tismer,2002-05-17 -Jason Tishler,2002-05-15 -Raymond Hettinger,2001-12-10 -Walter Dörwald,2002-03-21 -Andrew MacIntyre,2002-02-17 -Anthony Baxter,2001-12-21 -Neal Norwitz,2001-12-19 -Chui Tey,2001-10-31 -Michael W. Hudson,2001-08-27 -Finn Bock,2001-08-23 -Piers Lauder,2001-07-20 -Kurt B. Kaiser,2001-07-03 -Steven M. Gava,2001-06-25 -Steve Purcell,2001-03-22 -Jim Fulton,2000-10-06 -Ka-Ping Yee,2000-10-03 -Lars Gustäbel,2000-09-21 -Neil Schemenauer,2000-09-15 -Martin v. Löwis,2000-09-08 -Thomas Heller,2000-09-07 -Moshe Zadka,2000-07-29 -Thomas Wouters,2000-07-14 -Peter Schneider-Kamp,2000-07-10 -Paul Prescod,2000-07-01 -Tim Peters,2000-06-30 -Skip Montanaro,2000-06-30 -Fredrik Lundh,2000-06-29 -Mark Hammond,2000-06-09 -Marc-André Lemburg,2000-06-07 -Trent Mick,2000-06-06 -Eric S. Raymond,2000-06-02 -Gregory P. Smith,2002-01-08 -Greg Stein,1999-11-07 -Just van Rossum,1999-01-22 -Greg Ward,1998-12-18 -Andrew Kuchling,1998-04-09 -Ken Manheimer,1998-03-03 -Jeremy Hylton,1997-08-13 -Roger E. Masse,1996-12-09 -Fred Drake,1996-07-23 -Barry Warsaw,1994-07-25 -Jack Jansen,1992-08-13 -Sjoerd Mullender,1992-08-04 -Guido van Rossum,1989-12-25 diff --git a/clang.rst b/development-tools/clang.rst similarity index 50% rename from clang.rst rename to development-tools/clang.rst index 76afd4786e..149fb7adcf 100644 --- a/clang.rst +++ b/development-tools/clang.rst @@ -1,20 +1,27 @@ -*************************** -Dynamic Analysis with Clang -*************************** +.. _clang: + +=========================== +Dynamic analysis with Clang +=========================== .. highlight:: bash This document describes how to use Clang to perform analysis on Python and its -libraries. In addition to performing the analysis, the document will cover -downloading, building and installing the latest Clang/LLVM combination (which -is currently 3.4). +libraries. This document does not cover interpreting the findings. For a discussion of interpreting results, see Marshall Clow's `Testing libc++ with --fsanitize=undefined <https://cplusplusmusings.wordpress.com/tag/clang/>`_. The +-fsanitize=undefined <https://cplusplusmusings.wordpress.com/tag/clang/>`__. The blog posting is a detailed examinations of issues uncovered by Clang in ``libc++``. +The document focuses on Clang, although most techniques should generally apply +to GCC's sanitizers as well. + +The instructions were tested on Linux, but they should work on macOS as well. +Instructions for Windows are incomplete. + + What is Clang? ============== @@ -23,7 +30,7 @@ front-end provides access to LLVM's optimizer and code generator. The sanitizers - or checkers - are hooks into the code generation phase to instrument compiled code so suspicious behavior is flagged. -What are Sanitizers? +What are sanitizers? ==================== Clang sanitizers are runtime checkers used to identify suspicious and undefined @@ -38,7 +45,7 @@ flags are passed through ``CFLAGS`` and ``CXXFLAGS``, and sometimes through ``CC`` and ``CXX`` (in addition to the compiler). A complete list of sanitizers can be found at `Controlling Code Generation -<https://clang.llvm.org/docs/UsersManual.html#controlling-code-generation>`_. +<https://clang.llvm.org/docs/UsersManual.html#controlling-code-generation>`__. .. note:: @@ -47,177 +54,99 @@ A complete list of sanitizers can be found at `Controlling Code Generation Clang and its sanitizers have strengths (and weaknesses). Its just one tool in the war chest to uncovering bugs and improving code quality. Clang should be -used to compliment other methods, including Code Reviews, Valgrind, Coverity, +used to complement other methods, including Code Reviews, `Valgrind`_, etc. -Clang/LLVM Setup +Clang/LLVM setup ================ -This portion of the document covers downloading, building and installing Clang -and LLVM. There are three components to download and build. They are the LLVM -compiler, the compiler front end and the compiler runtime library. - -In preparation you should create a scratch directory. Also ensure you are using -Python 2 and not Python 3. Python 3 will cause the build to fail. - -Download, Build and Install ---------------------------- - -Perform the following to download, build and install the Clang/LLVM 3.4. :: +Pre-built Clang builds are available for most platforms: - # Download - wget https://llvm.org/releases/3.4/llvm-3.4.src.tar.gz - wget https://llvm.org/releases/3.4/clang-3.4.src.tar.gz - wget https://llvm.org/releases/3.4/compiler-rt-3.4.src.tar.gz +- On macOS, Clang is the default compiler. +- For mainstream Linux distros, you can install a ``clang`` package. + In some cases, you also need to install ``llvm`` separately, otherwise + some tools are not available. +- On Windows, the installer for Visual Studio (not Code) + includes the "C++ clang tools for windows" feature. - # LLVM - tar xvf llvm-3.4.src.tar.gz - cd llvm-3.4/tools +You can also build ``clang`` from source; refer to +`the clang documentation <https://clang.llvm.org/>`__ for details. - # Clang Front End - tar xvf ../../clang-3.4.src.tar.gz - mv clang-3.4 clang - - # Compiler RT - cd ../projects - tar xvf ../../compiler-rt-3.4.src.tar.gz - mv compiler-rt-3.4/ compiler-rt - - # Build - cd .. - ./configure --enable-optimized --prefix=/usr/local - make -j4 - sudo make install - -.. note:: - - If you receive an error ``'LibraryDependencies.inc' file not found``, then - ensure you are utilizing Python 2 and not Python 3. If you encounter the - error after switching to Python 2, then delete everything and start over. - -After ``make install`` executes, the compilers will be installed in -``/usr/local/bin`` and the various libraries will be installed in -``/usr/local/lib/clang/3.4/lib/linux/``: +The installer does not install all the components needed on occasion. For +example, you might want to run a ``scan-build`` or examine the results with +``scan-view``. If this is your case, you can build Clang from source and +copy tools from ``tools/clang/tools`` to a directory on your ``PATH``. -.. code-block:: console +Another reason to build from source is to get the latest version of Clang/LLVM, +if your platform's channels don't provide it yet. +Newer versions of Clang/LLVM introduce new sanitizer checks. - $ ls /usr/local/lib/clang/3.4/lib/linux/ - libclang_rt.asan-x86_64.a libclang_rt.profile-x86_64.a - libclang_rt.dfsan-x86_64.a libclang_rt.san-x86_64.a - libclang_rt.full-x86_64.a libclang_rt.tsan-x86_64.a - libclang_rt.lsan-x86_64.a libclang_rt.ubsan_cxx-x86_64.a - libclang_rt.msan-x86_64.a libclang_rt.ubsan-x86_64.a -On Mac OS X, the libraries are installed in -``/usr/local/lib/clang/3.3/lib/darwin/``: +Python build setup +================== -.. code-block:: console +This portion of the document covers invoking Clang and LLVM with the options +required so the sanitizers analyze Python with under its test suite. - $ ls /usr/local/lib/clang/3.3/lib/darwin/ - libclang_rt.10.4.a libclang_rt.ios.a - libclang_rt.asan_osx.a libclang_rt.osx.a - libclang_rt.asan_osx_dynamic.dylib libclang_rt.profile_ios.a - libclang_rt.cc_kext.a libclang_rt.profile_osx.a - libclang_rt.cc_kext_ios5.a libclang_rt.ubsan_osx.a - libclang_rt.eprintf.a +Set the compiler to Clang, in case it's not the default:: -.. note:: + export CC="clang" - You should never have to add the libraries to a project. Clang will handle - it for you. If you find you cannot pass the ``-fsanitize=XXX`` flag through - ``make``'s implicit variables (``CFLAGS``, ``CXXFLAGS``, ``CC``, - ``CXXFLAGS``, ``LDFLAGS``) during ``configure``, then you should modify the - makefile after configuring to ensure the flag is passed through the - compiler. +If you want to use additional sanitizer options (found in Clang documentation), +add them to the ``CFLAGS`` variable. +For example, you may want the checked process to exit after the first failure:: -The installer does not install all the components needed on occasion. For -example, you might want to run a ``scan-build`` or examine the results with -``scan-view``. You can copy the components by hand with: :: + export CFLAGS="-fno-sanitize-recover" - sudo mkdir /usr/local/bin/scan-build - sudo cp -r llvm-3.4/tools/clang/tools/scan-build /usr/local/bin - sudo mkdir /usr/local/bin/scan-view - sudo cp -r llvm-3.4/tools/clang/tools/scan-view /usr/local/bin +Then, run ``./configure`` with the relevant flags: -.. note:: +* ASan: ``--with-address-sanitizer --without-pymalloc`` +* UBsan: ``--with-undefined-behavior-sanitizer`` - Because the installer does not install all the components needed on - occasion, you should not delete the scratch directory until you are sure - things work as expected. If a library is missing, then you should search for - it in the Clang/LLVM build directory. +The ``--without-pymalloc`` option is not necessary (tests should pass without it), +but disabling pymalloc helps ASan uncover more bugs (ASan does not track +individual allocations done by pymalloc). -Python Build Setup -================== +It is OK to specify both sanitizers. -This portion of the document covers invoking Clang and LLVM with the options -required so the sanitizers analyze Python with under its test suite. Two -checkers are used - ASan and UBSan. +After that, run ``make`` and ``make test`` as usual. +Note that ``make`` itself may fail with a sanitizer failure, +since the just-compiled Python runs during later stages of the build. -Because the sanitizers are runtime checkers, its best to have as many positive -and negative self tests as possible. You can never have enough self tests. -The general idea is to compile and link with the sanitizer flags. At link time, -Clang will include the needed runtime libraries. However, you can't use -``CFLAGS`` and ``CXXFLAGS`` to pass the options through the compiler to the -linker because the makefile rules for ``BUILDPYTHON``, ``_testembed`` and -``_freeze_importlib`` don't use the implicit variables. +Build setup for enabling sanitizers for all code +------------------------------------------------ -As a workaround to the absence of flags to the linker, you can pass the -sanitizer options by way of the compilers - ``CC`` and ``CXX``. Passing the -flags though the compiler is used below, but passing them through ``LDFLAGS`` is -also reported to work. +Some parts of Python (for example, ``_testembed``, ``_freeze_importlib``, +``test_cppext``) may not use the variables set by ``configure``, +and with the above settings they'll be compiled without sanitization. -Building Python ---------------- +As a workaround, you can pass the sanitizer options by way of the *compilers*, +``CC`` (for C) and ``CXX`` (for C++). This is used below. +Passing the options through ``LDFLAGS`` is also reported to work. -To begin, export the variables of interest with the desired sanitizers. Its OK -to specify both sanitizers: :: +For ASan, use:: # ASan - export CC="/usr/local/bin/clang -fsanitize=address" - export CXX="/usr/local/bin/clang++ -fsanitize=address -fno-sanitize=vptr" + export CC="clang -fsanitize=address" + export CXX="clang++ -fsanitize=address -fno-sanitize=vptr" -Or: :: +And for UBSan:: # UBSan - export CC="/usr/local/bin/clang -fsanitize=undefined" - export CXX="/usr/local/bin/clang++ -fsanitize=undefined -fno-sanitize=vptr" - -The ``-fno-sanitize=vptr`` removes vtable checks that are part of UBSan from C++ -projects due to noise. Its not needed with Python, but you will likely need it -for other C++ projects. - -After exporting ``CC`` and ``CXX``, ``configure`` as normal: - -.. code-block:: console - - $ ./configure - checking build system type... x86_64-unknown-linux-gnu - checking host system type... x86_64-unknown-linux-gnu - checking for --enable-universalsdk... no - checking for --with-universal-archs... 32-bit - checking MACHDEP... linux - checking for --without-gcc... no - checking for gcc... /usr/local/bin/clang -fsanitize=undefined - checking whether the C compiler works... yes - ... + export CC="clang -fsanitize=undefined" + export CXX="clang++ -fsanitize=undefined -fno-sanitize=vptr" -Next is a standard ``make`` (formatting added for clarity): +It's OK to specify both sanitizers. -.. code-block:: console +After this, run ``./configure``, ``make`` and ``make test`` as usual. - $ make - /usr/local/bin/clang -fsanitize=undefined -c -Wno-unused-result - -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. - -IInclude -I./Include -DPy_BUILD_CORE -o Modules/python.o - ./Modules/python.c - /usr/local/bin/clang -fsanitize=undefined -c -Wno-unused-result - -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. - -IInclude -I./Include -DPy_BUILD_CORE -o Parser/acceler.o - Parser/acceler.c - ... -Finally is ``make test`` (formatting added for clarity): +Analyzing the output +==================== + +Sanitizer failures will make the process fail and output a diagnostic, +for example: .. code-block:: none @@ -231,8 +160,12 @@ Finally is ``make test`` (formatting added for clarity): ^ ... -If you are using the address sanitizer, its important to pipe the output through -``asan_symbolize.py`` to get a good trace. For example, from Issue 20953 during +If you are using the address sanitizer, an additional tool is needed to +get good traces. Usually, this happens automatically through the +``llvm-symbolizer`` tool. If this tool is not installed on your ``PATH``, +you can set ``ASAN_SYMBOLIZER_PATH`` to the location of the tool, +or pipe test output through ``asan_symbolize.py`` script from the +Clang distribution. For example, from Issue 20953 during compile (formatting added for clarity): .. code-block:: none @@ -300,25 +233,25 @@ compile (formatting added for clarity): .. note:: - ``asan_symbolize.py`` is supposed to be installed during ``make install``. - If its not installed, then look in the Clang/LLVM build directory for it and - copy it to ``/usr/local/bin``. + If ``asan_symbolize.py`` is not installed, build Clang from source, then + look in the Clang/LLVM build directory for it and use it directly or copy + it to a directory on ``PATH``. -Blacklisting (Ignoring) Findings --------------------------------- +Ignoring findings +----------------- .. highlight:: none Clang allows you to alter the behavior of sanitizer tools for certain -source-level by providing a special blacklist file at compile-time. The -blacklist is needed because it reports every instance of an issue, even if the +source-level by providing a special ignorelist file at compile-time. The +ignorelist is needed because it reports every instance of an issue, even if the issue is reported 10's of thousands of time in un-managed library code. -You specify the blacklist with ``-fsanitize-blacklist=XXX``. For example:: +You specify the ignorelist with ``-fsanitize-ignorelist=XXX``. For example:: - -fsanitize-blacklist=my_blacklist.txt + -fsanitize-ignorelist=my_ignorelist.txt -``my_blacklist.txt`` would then contain entries such as the following. The entry +``my_ignorelist.txt`` would then contain entries such as the following. The entry will ignore a bug in ``libc++``'s ``ios`` formatting functions:: fun:_Ios_Fmtflags @@ -340,7 +273,7 @@ findings:: ... One of the function of interest is ``audioop_getsample_impl`` (flagged at line -422), and the blacklist entry would include:: +422), and the ignorelist entry would include:: fun:audioop_getsample_imp @@ -348,7 +281,9 @@ Or, you could ignore the entire file with:: src:Modules/audioop.c -Unfortunately, you won't know what to blacklist until you run the sanitizer. +Unfortunately, you won't know what to ignorelist until you run the sanitizer. The documentation is available at `Sanitizer special case list -<https://clang.llvm.org/docs/SanitizerSpecialCaseList.html>`_. +<https://clang.llvm.org/docs/SanitizerSpecialCaseList.html>`__. + +.. _Valgrind: https://github.com/python/cpython/blob/main/Misc/README.valgrind diff --git a/development-tools/clinic/howto.rst b/development-tools/clinic/howto.rst new file mode 100644 index 0000000000..359c53e903 --- /dev/null +++ b/development-tools/clinic/howto.rst @@ -0,0 +1,1572 @@ +.. _clinic-howtos: + +How-to guides +============= + + +How to rename C functions and variables generated by Argument Clinic +-------------------------------------------------------------------- + +Argument Clinic automatically names the functions it generates for you. +Occasionally this may cause a problem, if the generated name collides with +the name of an existing C function. There's an easy solution: override the names +used for the C functions. Just add the keyword ``"as"`` +to your function declaration line, followed by the function name you wish to use. +Argument Clinic will use that function name for the base (generated) function, +then add ``"_impl"`` to the end and use that for the name of the impl function. + +For example, if we wanted to rename the C function names generated for +:py:meth:`pickle.Pickler.dump`, it'd look like this:: + + /*[clinic input] + pickle.Pickler.dump as pickler_dumper + + ... + +The base function would now be named :c:func:`!pickler_dumper`, +and the impl function would now be named :c:func:`!pickler_dumper_impl`. + + +Similarly, you may have a problem where you want to give a parameter +a specific Python name, but that name may be inconvenient in C. Argument +Clinic allows you to give a parameter different names in Python and in C, +using the same ``"as"`` syntax:: + + /*[clinic input] + pickle.Pickler.dump + + obj: object + file as file_obj: object + protocol: object = NULL + * + fix_imports: bool = True + +Here, the name used in Python (in the signature and the ``keywords`` +array) would be *file*, but the C variable would be named ``file_obj``. + +You can use this to rename the *self* parameter too! + + +How to convert functions using ``PyArg_UnpackTuple`` +---------------------------------------------------- + +To convert a function parsing its arguments with :c:func:`PyArg_UnpackTuple`, +simply write out all the arguments, specifying each as an ``object``. You +may specify the *type* argument to cast the type as appropriate. All +arguments should be marked positional-only (add a ``/`` on a line by itself +after the last argument). + +Currently the generated code will use :c:func:`PyArg_ParseTuple`, but this +will change soon. + + +How to use optional groups +-------------------------- + +Some legacy functions have a tricky approach to parsing their arguments: +they count the number of positional arguments, then use a ``switch`` statement +to call one of several different :c:func:`PyArg_ParseTuple` calls depending on +how many positional arguments there are. (These functions cannot accept +keyword-only arguments.) This approach was used to simulate optional +arguments back before :c:func:`PyArg_ParseTupleAndKeywords` was created. + +While functions using this approach can often be converted to +use :c:func:`!PyArg_ParseTupleAndKeywords`, optional arguments, and default values, +it's not always possible. Some of these legacy functions have +behaviors :c:func:`!PyArg_ParseTupleAndKeywords` doesn't directly support. +The most obvious example is the builtin function :py:func:`!range`, which has +an optional argument on the *left* side of its required argument! +Another example is :py:meth:`curses.window.addch`, which has a group of two +arguments that must always be specified together. (The arguments are +called *x* and *y*; if you call the function passing in *x*, +you must also pass in *y* — and if you don't pass in *x* you may not +pass in *y* either.) + +In any case, the goal of Argument Clinic is to support argument parsing +for all existing CPython builtins without changing their semantics. +Therefore Argument Clinic supports +this alternate approach to parsing, using what are called *optional groups*. +Optional groups are groups of arguments that must all be passed in together. +They can be to the left or the right of the required arguments. They +can *only* be used with positional-only parameters. + +.. note:: Optional groups are *only* intended for use when converting + functions that make multiple calls to :c:func:`PyArg_ParseTuple`! + Functions that use *any* other approach for parsing arguments + should *almost never* be converted to Argument Clinic using + optional groups. Functions using optional groups currently + cannot have accurate signatures in Python, because Python just + doesn't understand the concept. Please avoid using optional + groups wherever possible. + +To specify an optional group, add a ``[`` on a line by itself before +the parameters you wish to group together, and a ``]`` on a line by itself +after these parameters. As an example, here's how :py:meth:`curses.window.addch` +uses optional groups to make the first two parameters and the last +parameter optional:: + + /*[clinic input] + + curses.window.addch + + [ + x: int + X-coordinate. + y: int + Y-coordinate. + ] + + ch: object + Character to add. + + [ + attr: long + Attributes for the character. + ] + / + + ... + + +Notes: + +* For every optional group, one additional parameter will be passed into the + impl function representing the group. The parameter will be an int named + ``group_{direction}_{number}``, + where ``{direction}`` is either ``right`` or ``left`` depending on whether the group + is before or after the required parameters, and ``{number}`` is a monotonically + increasing number (starting at 1) indicating how far away the group is from + the required parameters. When the impl is called, this parameter will be set + to zero if this group was unused, and set to non-zero if this group was used. + (By used or unused, I mean whether or not the parameters received arguments + in this invocation.) + +* If there are no required arguments, the optional groups will behave + as if they're to the right of the required arguments. + +* In the case of ambiguity, the argument parsing code + favors parameters on the left (before the required parameters). + +* Optional groups can only contain positional-only parameters. + +* Optional groups are *only* intended for legacy code. Please do not + use optional groups for new code. + + +How to use real Argument Clinic converters, instead of "legacy converters" +-------------------------------------------------------------------------- + +To save time, and to minimize how much you need to learn +to achieve your first port to Argument Clinic, the walkthrough above tells +you to use "legacy converters". "Legacy converters" are a convenience, +designed explicitly to make porting existing code to Argument Clinic +easier. + +However, in the long term we probably want all our blocks to +use Argument Clinic's real syntax for converters. Why? A couple +reasons: + +* The proper converters are far easier to read and clearer in their intent. +* There are some format units that are unsupported as "legacy converters", + because they require arguments, and the legacy converter syntax doesn't + support specifying arguments. +* In the future we may have a new argument parsing library that isn't + restricted to what :c:func:`PyArg_ParseTuple` supports; this flexibility + won't be available to parameters using legacy converters. + +Therefore, if you don't mind a little extra effort, please use the normal +converters instead of legacy converters. + +In a nutshell, the syntax for Argument Clinic (non-legacy) converters +looks like a Python function call. However, if there are no explicit +arguments to the function (all functions take their default values), +you may omit the parentheses. Thus ``bool`` and ``bool()`` are exactly +the same converters. + +All arguments to Argument Clinic converters are keyword-only. +All Argument Clinic converters accept the following arguments: + +*c_default* + The default value for this parameter when defined in C. + Specifically, this will be the initializer for the variable declared + in the "parse function". See :ref:`the section on default values <default_values>` + for how to use this. + Specified as a string. + +*annotation* + The annotation value for this parameter. Not currently supported, + because :pep:`8` mandates that the Python library may not use + annotations. + +*unused* + Wrap the argument with :c:macro:`Py_UNUSED` in the impl function signature. + +In addition, some converters accept additional arguments. Here is a list +of these arguments, along with their meanings: + +*accept* + A set of Python types (and possibly pseudo-types); + this restricts the allowable Python argument to values of these types. + (This is not a general-purpose facility; as a rule it only supports + specific lists of types as shown in the legacy converter table.) + + To accept ``None``, add ``NoneType`` to this set. + +*bitwise* + Only supported for unsigned integers. The native integer value of this + Python argument will be written to the parameter without any range checking, + even for negative values. + +*converter* + Only supported by the ``object`` converter. Specifies the name of a + :ref:`C "converter function" <o_ampersand>` + to use to convert this object to a native type. + +*encoding* + Only supported for strings. Specifies the encoding to use when converting + this string from a Python str (Unicode) value into a C ``char *`` value. + + +*subclass_of* + Only supported for the ``object`` converter. Requires that the Python + value be a subclass of a Python type, as expressed in C. + +*type* + Only supported for the ``object`` and ``self`` converters. Specifies + the C type that will be used to declare the variable. Default value is + ``"PyObject *"``. + +*zeroes* + Only supported for strings. If true, embedded NUL bytes (``'\\0'``) are + permitted inside the value. The length of the string will be passed in + to the impl function, just after the string parameter, as a parameter named + ``<parameter_name>_length``. + +Please note, not every possible combination of arguments will work. +Usually these arguments are implemented by specific :c:func:`PyArg_ParseTuple` +*format units*, with specific behavior. For example, currently you cannot +call ``unsigned_short`` without also specifying ``bitwise=True``. +Although it's perfectly reasonable to think this would work, these semantics don't +map to any existing format unit. So Argument Clinic doesn't support it. (Or, at +least, not yet.) + +Below is a table showing the mapping of legacy converters into real +Argument Clinic converters. On the left is the legacy converter, +on the right is the text you'd replace it with. + +========= ================================================================================= +``'B'`` ``unsigned_char(bitwise=True)`` +``'b'`` ``unsigned_char`` +``'c'`` ``char`` +``'C'`` ``int(accept={str})`` +``'d'`` ``double`` +``'D'`` ``Py_complex`` +``'es'`` ``str(encoding='name_of_encoding')`` +``'es#'`` ``str(encoding='name_of_encoding', zeroes=True)`` +``'et'`` ``str(encoding='name_of_encoding', accept={bytes, bytearray, str})`` +``'et#'`` ``str(encoding='name_of_encoding', accept={bytes, bytearray, str}, zeroes=True)`` +``'f'`` ``float`` +``'h'`` ``short`` +``'H'`` ``unsigned_short(bitwise=True)`` +``'i'`` ``int`` +``'I'`` ``unsigned_int(bitwise=True)`` +``'k'`` ``unsigned_long(bitwise=True)`` +``'K'`` ``unsigned_long_long(bitwise=True)`` +``'l'`` ``long`` +``'L'`` ``long long`` +``'n'`` ``Py_ssize_t`` +``'O'`` ``object`` +``'O!'`` ``object(subclass_of='&PySomething_Type')`` +``'O&'`` ``object(converter='name_of_c_function')`` +``'p'`` ``bool`` +``'S'`` ``PyBytesObject`` +``'s'`` ``str`` +``'s#'`` ``str(zeroes=True)`` +``'s*'`` ``Py_buffer(accept={buffer, str})`` +``'U'`` ``unicode`` +``'u'`` ``wchar_t`` +``'u#'`` ``wchar_t(zeroes=True)`` +``'w*'`` ``Py_buffer(accept={rwbuffer})`` +``'Y'`` ``PyByteArrayObject`` +``'y'`` ``str(accept={bytes})`` +``'y#'`` ``str(accept={robuffer}, zeroes=True)`` +``'y*'`` ``Py_buffer`` +``'Z'`` ``wchar_t(accept={str, NoneType})`` +``'Z#'`` ``wchar_t(accept={str, NoneType}, zeroes=True)`` +``'z'`` ``str(accept={str, NoneType})`` +``'z#'`` ``str(accept={str, NoneType}, zeroes=True)`` +``'z*'`` ``Py_buffer(accept={buffer, str, NoneType})`` +========= ================================================================================= + +As an example, here's our sample ``pickle.Pickler.dump`` using the proper +converter:: + + /*[clinic input] + pickle.Pickler.dump + + obj: object + The object to be pickled. + / + + Write a pickled representation of obj to the open file. + [clinic start generated code]*/ + +One advantage of real converters is that they're more flexible than legacy +converters. For example, the ``unsigned_int`` converter (and all the +``unsigned_`` converters) can be specified without ``bitwise=True``. Their +default behavior performs range checking on the value, and they won't accept +negative numbers. You just can't do that with a legacy converter! + +Argument Clinic will show you all the converters it has +available. For each converter it'll show you all the parameters +it accepts, along with the default value for each parameter. +Just run ``Tools/clinic/clinic.py --converters`` to see the full list. + + +How to use the ``Py_buffer`` converter +-------------------------------------- + +When using the ``Py_buffer`` converter +(or the ``'s*'``, ``'w*'``, ``'*y'``, or ``'z*'`` legacy converters), +you *must* not call :c:func:`PyBuffer_Release` on the provided buffer. +Argument Clinic generates code that does it for you (in the parsing function). + + +.. _clinic-howto-advanced-converters: + +How to use advanced converters +------------------------------ + +Remember those format units you skipped for your first +time because they were advanced? Here's how to handle those too. + +The trick is, all those format units take arguments—either +conversion functions, or types, or strings specifying an encoding. +(But "legacy converters" don't support arguments. That's why we +skipped them for your first function.) The argument you specified +to the format unit is now an argument to the converter; this +argument is either *converter* (for ``O&``), *subclass_of* (for ``O!``), +or *encoding* (for all the format units that start with ``e``). + +When using *subclass_of*, you may also want to use the other +custom argument for ``object()``: *type*, which lets you set the type +actually used for the parameter. For example, if you want to ensure +that the object is a subclass of :c:var:`PyUnicode_Type`, you probably want +to use the converter ``object(type='PyUnicodeObject *', subclass_of='&PyUnicode_Type')``. + +One possible problem with using Argument Clinic: it takes away some possible +flexibility for the format units starting with ``e``. When writing a +:c:func:`!PyArg_Parse*` call by hand, you could theoretically decide at runtime what +encoding string to pass to that call. But now this string must +be hard-coded at Argument-Clinic-preprocessing-time. This limitation is deliberate; +it made supporting this format unit much easier, and may allow for future optimizations. +This restriction doesn't seem unreasonable; CPython itself always passes in static +hard-coded encoding strings for parameters whose format units start with ``e``. + + +.. _clinic-howto-default-values: +.. _default_values: + +How to assign default values to parameter +----------------------------------------- + +Default values for parameters can be any of a number of values. +At their simplest, they can be string, int, or float literals: + +.. code-block:: none + + foo: str = "abc" + bar: int = 123 + bat: float = 45.6 + +They can also use any of Python's built-in constants: + +.. code-block:: none + + yep: bool = True + nope: bool = False + nada: object = None + +There's also special support for a default value of ``NULL``, and +for simple expressions, documented in the following sections. + + +The ``NULL`` default value +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +For string and object parameters, you can set them to ``None`` to indicate +that there's no default. However, that means the C variable will be +initialized to ``Py_None``. For convenience's sakes, there's a special +value called ``NULL`` for just this reason: from Python's perspective it +behaves like a default value of ``None``, but the C variable is initialized +with ``NULL``. + + +Symbolic default values +^^^^^^^^^^^^^^^^^^^^^^^ + +The default value you provide for a parameter can't be any arbitrary +expression. Currently the following are explicitly supported: + +* Numeric constants (integer and float) +* String constants +* ``True``, ``False``, and ``None`` +* Simple symbolic constants like :py:data:`sys.maxsize`, which must + start with the name of the module + +(In the future, this may need to get even more elaborate, +to allow full expressions like ``CONSTANT - 1``.) + + +Expressions as default values +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The default value for a parameter can be more than just a literal value. +It can be an entire expression, using math operators and looking up attributes +on objects. However, this support isn't exactly simple, because of some +non-obvious semantics. + +Consider the following example: + +.. code-block:: none + + foo: Py_ssize_t = sys.maxsize - 1 + +:py:data:`sys.maxsize` can have different values on different platforms. Therefore +Argument Clinic can't simply evaluate that expression locally and hard-code it +in C. So it stores the default in such a way that it will get evaluated at +runtime, when the user asks for the function's signature. + +What namespace is available when the expression is evaluated? It's evaluated +in the context of the module the builtin came from. So, if your module has an +attribute called :py:attr:`!max_widgets`, you may simply use it: + +.. code-block:: none + + foo: Py_ssize_t = max_widgets + +If the symbol isn't found in the current module, it fails over to looking in +:py:data:`sys.modules`. That's how it can find :py:data:`sys.maxsize` for example. +(Since you don't know in advance what modules the user will load into their interpreter, +it's best to restrict yourself to modules that are preloaded by Python itself.) + +Evaluating default values only at runtime means Argument Clinic can't compute +the correct equivalent C default value. So you need to tell it explicitly. +When you use an expression, you must also specify the equivalent expression +in C, using the *c_default* parameter to the converter: + +.. code-block:: none + + foo: Py_ssize_t(c_default="PY_SSIZE_T_MAX - 1") = sys.maxsize - 1 + +Another complication: Argument Clinic can't know in advance whether or not the +expression you supply is valid. It parses it to make sure it looks legal, but +it can't *actually* know. You must be very careful when using expressions to +specify values that are guaranteed to be valid at runtime! + +Finally, because expressions must be representable as static C values, there +are many restrictions on legal expressions. Here's a list of Python features +you're not permitted to use: + +* Function calls. +* Inline if statements (``3 if foo else 5``). +* Automatic sequence unpacking (``*[1, 2, 3]``). +* List/set/dict comprehensions and generator expressions. +* Tuple/list/set/dict literals. + + +.. _clinic-howto-return-converters: + +How to use return converters +---------------------------- + +By default, the impl function Argument Clinic generates for you returns +:c:type:`PyObject * <PyObject>`. +But your C function often computes some C type, +then converts it into the :c:type:`!PyObject *` +at the last moment. Argument Clinic handles converting your inputs from Python types +into native C types—why not have it convert your return value from a native C type +into a Python type too? + +That's what a "return converter" does. It changes your impl function to return +some C type, then adds code to the generated (non-impl) function to handle converting +that value into the appropriate :c:type:`!PyObject *`. + +The syntax for return converters is similar to that of parameter converters. +You specify the return converter like it was a return annotation on the +function itself, using ``->`` notation. + +For example: + +.. code-block:: c + + /*[clinic input] + add -> int + + a: int + b: int + / + + [clinic start generated code]*/ + +Return converters behave much the same as parameter converters; +they take arguments, the arguments are all keyword-only, and if you're not changing +any of the default arguments you can omit the parentheses. + +(If you use both ``"as"`` *and* a return converter for your function, +the ``"as"`` should come before the return converter.) + +There's one additional complication when using return converters: how do you +indicate an error has occurred? Normally, a function returns a valid (non-``NULL``) +pointer for success, and ``NULL`` for failure. But if you use an integer return converter, +all integers are valid. How can Argument Clinic detect an error? Its solution: each return +converter implicitly looks for a special value that indicates an error. If you return +that value, and an error has been set (c:func:`PyErr_Occurred` returns a true +value), then the generated code will propagate the error. Otherwise it will +encode the value you return like normal. + +Currently Argument Clinic supports only a few return converters: + +.. code-block:: none + + bool + double + float + int + long + Py_ssize_t + size_t + unsigned int + unsigned long + +None of these take parameters. +For all of these, return ``-1`` to indicate error. + +To see all the return converters Argument Clinic supports, along with +their parameters (if any), +just run ``Tools/clinic/clinic.py --converters`` for the full list. + + +How to clone existing functions +------------------------------- + +If you have a number of functions that look similar, you may be able to +use Clinic's "clone" feature. When you clone an existing function, +you reuse: + +* its parameters, including + + * their names, + + * their converters, with all parameters, + + * their default values, + + * their per-parameter docstrings, + + * their *kind* (whether they're positional only, + positional or keyword, or keyword only), and + +* its return converter. + +The only thing not copied from the original function is its docstring; +the syntax allows you to specify a new docstring. + +Here's the syntax for cloning a function:: + + /*[clinic input] + module.class.new_function [as c_basename] = module.class.existing_function + + Docstring for new_function goes here. + [clinic start generated code]*/ + +(The functions can be in different modules or classes. I wrote +``module.class`` in the sample just to illustrate that you must +use the full path to *both* functions.) + +Sorry, there's no syntax for partially cloning a function, or cloning a function +then modifying it. Cloning is an all-or nothing proposition. + +Also, the function you are cloning from must have been previously defined +in the current file. + + +How to call Python code +----------------------- + +The rest of the advanced topics require you to write Python code +which lives inside your C file and modifies Argument Clinic's +runtime state. This is simple: you simply define a Python block. + +A Python block uses different delimiter lines than an Argument +Clinic function block. It looks like this:: + + /*[python input] + # python code goes here + [python start generated code]*/ + +All the code inside the Python block is executed at the +time it's parsed. All text written to stdout inside the block +is redirected into the "output" after the block. + +As an example, here's a Python block that adds a static integer +variable to the C code:: + + /*[python input] + print('static int __ignored_unused_variable__ = 0;') + [python start generated code]*/ + static int __ignored_unused_variable__ = 0; + /*[python checksum:...]*/ + + +.. _clinic-howto-self-converter: + +How to use the "self converter" +------------------------------- + +Argument Clinic automatically adds a "self" parameter for you +using a default converter. It automatically sets the ``type`` +of this parameter to the "pointer to an instance" you specified +when you declared the type. However, you can override +Argument Clinic's converter and specify one yourself. +Just add your own *self* parameter as the first parameter in a +block, and ensure that its converter is an instance of +:class:`!self_converter` or a subclass thereof. + +What's the point? This lets you override the type of ``self``, +or give it a different default name. + +How do you specify the custom type you want to cast ``self`` to? +If you only have one or two functions with the same type for ``self``, +you can directly use Argument Clinic's existing ``self`` converter, +passing in the type you want to use as the *type* parameter:: + + /*[clinic input] + + _pickle.Pickler.dump + + self: self(type="PicklerObject *") + obj: object + / + + Write a pickled representation of the given object to the open file. + [clinic start generated code]*/ + +On the other hand, if you have a lot of functions that will use the same +type for ``self``, it's best to create your own converter, subclassing +:class:`!self_converter` but overwriting the :py:attr:`!type` member:: + + /*[python input] + class PicklerObject_converter(self_converter): + type = "PicklerObject *" + [python start generated code]*/ + + /*[clinic input] + + _pickle.Pickler.dump + + self: PicklerObject + obj: object + / + + Write a pickled representation of the given object to the open file. + [clinic start generated code]*/ + + +How to use the "defining class" converter +----------------------------------------- + +Argument Clinic facilitates gaining access to the defining class of a method. +This is useful for :ref:`heap type <heap-types>` methods that need to fetch +module level state. Use :c:func:`PyType_FromModuleAndSpec` to associate a new +heap type with a module. You can now use :c:func:`PyType_GetModuleState` on +the defining class to fetch the module state, for example from a module method. + +Example from :cpy-file:`Modules/zlibmodule.c`. +First, ``defining_class`` is added to the clinic input:: + + /*[clinic input] + zlib.Compress.compress + + cls: defining_class + data: Py_buffer + Binary data to be compressed. + / + + +After running the Argument Clinic tool, the following function signature is +generated:: + + /*[clinic start generated code]*/ + static PyObject * + zlib_Compress_compress_impl(compobject *self, PyTypeObject *cls, + Py_buffer *data) + /*[clinic end generated code: output=6731b3f0ff357ca6 input=04d00f65ab01d260]*/ + + +The following code can now use ``PyType_GetModuleState(cls)`` to fetch the +module state:: + + zlibstate *state = PyType_GetModuleState(cls); + + +Each method may only have one argument using this converter, and it must appear +after ``self``, or, if ``self`` is not used, as the first argument. The argument +will be of type ``PyTypeObject *``. The argument will not appear in the +:py:attr:`!__text_signature__`. + +The ``defining_class`` converter is not compatible with :py:meth:`!__init__` +and :py:meth:`!__new__` methods, which cannot use the :c:macro:`METH_METHOD` +convention. + +It is not possible to use ``defining_class`` with slot methods. In order to +fetch the module state from such methods, use :c:func:`PyType_GetModuleByDef` +to look up the module and then :c:func:`PyModule_GetState` to fetch the module +state. Example from the ``setattro`` slot method in +:cpy-file:`Modules/_threadmodule.c`:: + + static int + local_setattro(localobject *self, PyObject *name, PyObject *v) + { + PyObject *module = PyType_GetModuleByDef(Py_TYPE(self), &thread_module); + thread_module_state *state = get_thread_state(module); + ... + } + + +See also :pep:`573`. + + +.. _clinic-howto-custom-converter: + +How to write a custom converter +------------------------------- + +A converter is a Python class that inherits from :py:class:`~clinic.CConverter`. +The main purpose of a custom converter, is for parameters parsed with +the ``O&`` format unit --- parsing such a parameter means calling +a :c:func:`PyArg_ParseTuple` "converter function". + +Your converter class should be named :samp:`{ConverterName}_converter`. +By following this convention, your converter class will be automatically +registered with Argument Clinic, with its *converter name* being the name of +your converter class with the ``_converter`` suffix stripped off. + +Instead of subclassing :py:meth:`!CConverter.__init__`, +write a :py:meth:`!converter_init` method. +:py:meth:`!converter_init` always accepts a *self* parameter. +After *self*, all additional parameters **must** be keyword-only. +Any arguments passed to the converter in Argument Clinic +will be passed along to your :py:meth:`!converter_init` method. +See :py:class:`~clinic.CConverter` for a list of members you may wish to specify +in your subclass. + +Here's the simplest example of a custom converter, from :cpy-file:`Modules/zlibmodule.c`:: + + /*[python input] + + class ssize_t_converter(CConverter): + type = 'Py_ssize_t' + converter = 'ssize_t_converter' + + [python start generated code]*/ + /*[python end generated code: output=da39a3ee5e6b4b0d input=35521e4e733823c7]*/ + +This block adds a converter named ``ssize_t`` to Argument Clinic. +Parameters declared as ``ssize_t`` will be declared with type :c:type:`Py_ssize_t`, +and will be parsed by the ``'O&'`` format unit, +which will call the :c:func:`!ssize_t_converter` converter C function. +``ssize_t`` variables automatically support default values. + +More sophisticated custom converters can insert custom C code to +handle initialization and cleanup. +You can see more examples of custom converters in the CPython +source tree; grep the C files for the string ``CConverter``. + + +How to write a custom return converter +-------------------------------------- + +Writing a custom return converter is much like writing +a custom converter. Except it's somewhat simpler, because return +converters are themselves much simpler. + +Return converters must subclass :py:class:`!CReturnConverter`. +There are no examples yet of custom return converters, +because they are not widely used yet. If you wish to +write your own return converter, please read :cpy-file:`Tools/clinic/clinic.py`, +specifically the implementation of :py:class:`!CReturnConverter` and +all its subclasses. + + +How to convert ``METH_O`` and ``METH_NOARGS`` functions +------------------------------------------------------- + +To convert a function using :c:macro:`METH_O`, make sure the function's +single argument is using the ``object`` converter, and mark the +arguments as positional-only:: + + /*[clinic input] + meth_o_sample + + argument: object + / + [clinic start generated code]*/ + + +To convert a function using :c:macro:`METH_NOARGS`, just don't specify +any arguments. + +You can still use a self converter, a return converter, and specify +a *type* argument to the object converter for :c:macro:`METH_O`. + + +How to convert ``*args`` parameters (starargs / var-positional) +--------------------------------------------------------------- + +There are two converters suitable for ``*args``: *array* and *tuple*. + +Using the *array* converter will provide the implementation function with +a C array *args* of type of :c:type:`PyObject * <PyObject>` and the number +of items in the array as :c:type:`Py_ssize_t` *args_length*. +For example:: + + /*[clinic input] + var_positional_sample + + spam: int + *args: array + [clinic start generated code]*/ + +Using the *tuple* converter will provide the implementation function with +a standard :c:type:`PyTupleObject`. +For example:: + + /*[clinic input] + var_positional_sample + + spam: int + *args: tuple + [clinic start generated code]*/ + +.. versionadded:: 3.11 + + +How to convert ``tp_new`` and ``tp_init`` functions +--------------------------------------------------- + +You can convert :c:member:`~PyTypeObject.tp_new` and +:c:member:`~PyTypeObject.tp_init` functions. +Just name them ``__new__`` or ``__init__`` as appropriate. Notes: + +* The function name generated for ``__new__`` doesn't end in ``__new__`` + like it would by default. It's just the name of the class, converted + into a valid C identifier. + +* No :c:type:`PyMethodDef` ``#define`` is generated for these functions. + +* ``__init__`` functions return ``int``, not ``PyObject *``. + +* Use the docstring as the class docstring. + +* Although ``__new__`` and ``__init__`` functions must always + accept both the ``args`` and ``kwargs`` objects, when converting + you may specify any signature for these functions that you like. + (If your function doesn't support keywords, the parsing function + generated will throw an exception if it receives any.) + + +How to change and redirect Clinic's output +------------------------------------------ + +It can be inconvenient to have Clinic's output interspersed with +your conventional hand-edited C code. Luckily, Clinic is configurable: +you can buffer up its output for printing later (or earlier!), or write +its output to a separate file. You can also add a prefix or suffix to +every line of Clinic's generated output. + +While changing Clinic's output in this manner can be a boon to readability, +it may result in Clinic code using types before they are defined, or +your code attempting to use Clinic-generated code before it is defined. +These problems can be easily solved by rearranging the declarations in your file, +or moving where Clinic's generated code goes. (This is why the default behavior +of Clinic is to output everything into the current block; while many people +consider this hampers readability, it will never require rearranging your +code to fix definition-before-use problems.) + +Let's start with defining some terminology: + +*field* + A field, in this context, is a subsection of Clinic's output. + For example, the ``#define`` for the :c:type:`PyMethodDef` structure + is a field, called ``methoddef_define``. Clinic has seven + different fields it can output per function definition: + + .. code-block:: none + + docstring_prototype + docstring_definition + methoddef_define + impl_prototype + parser_prototype + parser_definition + impl_definition + + All the names are of the form ``"<a>_<b>"``, + where ``"<a>"`` is the semantic object represented (the parsing function, + the impl function, the docstring, or the methoddef structure) and ``"<b>"`` + represents what kind of statement the field is. Field names that end in + ``"_prototype"`` + represent forward declarations of that thing, without the actual body/data + of the thing; field names that end in ``"_definition"`` represent the actual + definition of the thing, with the body/data of the thing. (``"methoddef"`` + is special, it's the only one that ends with ``"_define"``, representing that + it's a preprocessor #define.) + +*destination* + A destination is a place Clinic can write output to. There are + five built-in destinations: + + ``block`` + The default destination: printed in the output section of + the current Clinic block. + + ``buffer`` + A text buffer where you can save text for later. Text sent + here is appended to the end of any existing text. It's an + error to have any text left in the buffer when Clinic finishes + processing a file. + + ``file`` + A separate "clinic file" that will be created automatically by Clinic. + The filename chosen for the file is ``{basename}.clinic{extension}``, + where ``basename`` and ``extension`` were assigned the output + from ``os.path.splitext()`` run on the current file. (Example: + the ``file`` destination for :file:`_pickle.c` would be written to + :file:`_pickle.clinic.c`.) + + **Important: When using a** ``file`` **destination, you** + *must check in* **the generated file!** + + ``two-pass`` + A buffer like ``buffer``. However, a two-pass buffer can only + be dumped once, and it prints out all text sent to it during + all processing, even from Clinic blocks *after* the dumping point. + + ``suppress`` + The text is suppressed—thrown away. + + +Clinic defines five new directives that let you reconfigure its output. + +The first new directive is ``dump``: + +.. code-block:: none + + dump <destination> + +This dumps the current contents of the named destination into the output of +the current block, and empties it. This only works with ``buffer`` and +``two-pass`` destinations. + +The second new directive is ``output``. The most basic form of ``output`` +is like this: + +.. code-block:: none + + output <field> <destination> + +This tells Clinic to output *field* to *destination*. ``output`` also +supports a special meta-destination, called ``everything``, which tells +Clinic to output *all* fields to that *destination*. + +``output`` has a number of other functions: + +.. code-block:: none + + output push + output pop + output preset <preset> + + +``output push`` and ``output pop`` allow you to push and pop +configurations on an internal configuration stack, so that you +can temporarily modify the output configuration, then easily restore +the previous configuration. Simply push before your change to save +the current configuration, then pop when you wish to restore the +previous configuration. + +``output preset`` sets Clinic's output to one of several built-in +preset configurations, as follows: + +``block`` + Clinic's original starting configuration. Writes everything + immediately after the input block. + + Suppress the ``parser_prototype`` + and ``docstring_prototype``, write everything else to ``block``. + +``file`` + Designed to write everything to the "clinic file" that it can. + You then ``#include`` this file near the top of your file. + You may need to rearrange your file to make this work, though + usually this just means creating forward declarations for various + ``typedef`` and ``PyTypeObject`` definitions. + + Suppress the ``parser_prototype`` + and ``docstring_prototype``, write the ``impl_definition`` to + ``block``, and write everything else to ``file``. + + The default filename is ``"{dirname}/clinic/{basename}.h"``. + +``buffer`` + Save up most of the output from Clinic, to be written into + your file near the end. For Python files implementing modules + or builtin types, it's recommended that you dump the buffer + just above the static structures for your module or + builtin type; these are normally very near the end. Using + ``buffer`` may require even more editing than ``file``, if + your file has static ``PyMethodDef`` arrays defined in the + middle of the file. + + Suppress the ``parser_prototype``, ``impl_prototype``, + and ``docstring_prototype``, write the ``impl_definition`` to + ``block``, and write everything else to ``file``. + +``two-pass`` + Similar to the ``buffer`` preset, but writes forward declarations to + the ``two-pass`` buffer, and definitions to the ``buffer``. + This is similar to the ``buffer`` preset, but may require + less editing than ``buffer``. Dump the ``two-pass`` buffer + near the top of your file, and dump the ``buffer`` near + the end just like you would when using the ``buffer`` preset. + + Suppresses the ``impl_prototype``, write the ``impl_definition`` + to ``block``, write ``docstring_prototype``, ``methoddef_define``, + and ``parser_prototype`` to ``two-pass``, write everything else + to ``buffer``. + +``partial-buffer`` + Similar to the ``buffer`` preset, but writes more things to ``block``, + only writing the really big chunks of generated code to ``buffer``. + This avoids the definition-before-use problem of ``buffer`` completely, + at the small cost of having slightly more stuff in the block's output. + Dump the ``buffer`` near the end, just like you would when using + the ``buffer`` preset. + + Suppresses the ``impl_prototype``, write the ``docstring_definition`` + and ``parser_definition`` to ``buffer``, write everything else to ``block``. + +The third new directive is ``destination``: + +.. code-block:: none + + destination <name> <command> [...] + +This performs an operation on the destination named ``name``. + +There are two defined subcommands: ``new`` and ``clear``. + +The ``new`` subcommand works like this: + +.. code-block:: none + + destination <name> new <type> + +This creates a new destination with name ``<name>`` and type ``<type>``. + +There are five destination types: + +``suppress`` + Throws the text away. + +``block`` + Writes the text to the current block. This is what Clinic + originally did. + +``buffer`` + A simple text buffer, like the "buffer" builtin destination above. + +``file`` + A text file. The file destination takes an extra argument, + a template to use for building the filename, like so:: + + destination <name> new <type> <file_template> + + The template can use three strings internally that will be replaced + by bits of the filename: + + ``{path}`` + The full path to the file, including directory and full filename. + ``{dirname}`` + The name of the directory the file is in. + ``{basename}`` + Just the name of the file, not including the directory. + ``{basename_root}`` + Basename with the extension clipped off + (everything up to but not including the last '.'). + ``{basename_extension}`` + The last '.' and everything after it. If the basename + does not contain a period, this will be the empty string. + + If there are no periods in the filename, ``{basename}`` and ``{filename}`` + are the same, and ``{extension}`` is empty. ``{basename}{extension}`` + is always exactly the same as ``{filename}``. + +``two-pass`` + A two-pass buffer, like the "two-pass" builtin destination above. + + +The ``clear`` subcommand works like this: + +.. code-block:: none + + destination <name> clear + +It removes all the accumulated text up to this point in the destination. +(I don't know what you'd need this for, but I thought maybe it'd be +useful while someone's experimenting.) + +The fourth new directive is ``set``: + +.. code-block:: none + + set line_prefix "string" + set line_suffix "string" + +``set`` lets you set two internal variables in Clinic. +``line_prefix`` is a string that will be prepended to every line of Clinic's output; +``line_suffix`` is a string that will be appended to every line of Clinic's output. + +Both of these support two format strings: + +``{block comment start}`` + Turns into the string ``/*``, the start-comment text sequence for C files. + +``{block comment end}`` + Turns into the string ``*/``, the end-comment text sequence for C files. + +The final new directive is one you shouldn't need to use directly, +called ``preserve``: + +.. code-block:: none + + preserve + +This tells Clinic that the current contents of the output should be kept, unmodified. +This is used internally by Clinic when dumping output into ``file`` files; wrapping +it in a Clinic block lets Clinic use its existing checksum functionality to ensure +the file was not modified by hand before it gets overwritten. + + +How to use the ``#ifdef`` trick +------------------------------- + +If you're converting a function that isn't available on all platforms, +there's a trick you can use to make life a little easier. The existing +code probably looks like this:: + + #ifdef HAVE_FUNCTIONNAME + static module_functionname(...) + { + ... + } + #endif /* HAVE_FUNCTIONNAME */ + +And then in the ``PyMethodDef`` structure at the bottom the existing code +will have: + +.. code-block:: none + + #ifdef HAVE_FUNCTIONNAME + {'functionname', ... }, + #endif /* HAVE_FUNCTIONNAME */ + +In this scenario, you should enclose the body of your impl function inside the ``#ifdef``, +like so:: + + #ifdef HAVE_FUNCTIONNAME + /*[clinic input] + module.functionname + ... + [clinic start generated code]*/ + static module_functionname(...) + { + ... + } + #endif /* HAVE_FUNCTIONNAME */ + +Then, remove those three lines from the :c:type:`PyMethodDef` structure, +replacing them with the macro Argument Clinic generated: + +.. code-block:: none + + MODULE_FUNCTIONNAME_METHODDEF + +(You can find the real name for this macro inside the generated code. +Or you can calculate it yourself: it's the name of your function as defined +on the first line of your block, but with periods changed to underscores, +uppercased, and ``"_METHODDEF"`` added to the end.) + +Perhaps you're wondering: what if ``HAVE_FUNCTIONNAME`` isn't defined? +The ``MODULE_FUNCTIONNAME_METHODDEF`` macro won't be defined either! + +Here's where Argument Clinic gets very clever. It actually detects that the +Argument Clinic block might be deactivated by the ``#ifdef``. When that +happens, it generates a little extra code that looks like this:: + + #ifndef MODULE_FUNCTIONNAME_METHODDEF + #define MODULE_FUNCTIONNAME_METHODDEF + #endif /* !defined(MODULE_FUNCTIONNAME_METHODDEF) */ + +That means the macro always works. If the function is defined, this turns +into the correct structure, including the trailing comma. If the function is +undefined, this turns into nothing. + +However, this causes one ticklish problem: where should Argument Clinic put this +extra code when using the "block" output preset? It can't go in the output block, +because that could be deactivated by the ``#ifdef``. (That's the whole point!) + +In this situation, Argument Clinic writes the extra code to the "buffer" destination. +This may mean that you get a complaint from Argument Clinic: + +.. code-block:: none + + Warning in file "Modules/posixmodule.c" on line 12357: + Destination buffer 'buffer' not empty at end of file, emptying. + +When this happens, just open your file, find the ``dump buffer`` block that +Argument Clinic added to your file (it'll be at the very bottom), then +move it above the :c:type:`PyMethodDef` structure where that macro is used. + + +How to use Argument Clinic in Python files +------------------------------------------ + +It's actually possible to use Argument Clinic to preprocess Python files. +There's no point to using Argument Clinic blocks, of course, as the output +wouldn't make any sense to the Python interpreter. But using Argument Clinic +to run Python blocks lets you use Python as a Python preprocessor! + +Since Python comments are different from C comments, Argument Clinic +blocks embedded in Python files look slightly different. They look like this: + +.. code-block:: python3 + + #/*[python input] + #print("def foo(): pass") + #[python start generated code]*/ + def foo(): pass + #/*[python checksum:...]*/ + + +.. _clinic-howto-limited-capi: + +How to use the Limited C API +---------------------------- + +If Argument Clinic :term:`input` is located within a C source file +that contains ``#define Py_LIMITED_API``, Argument Clinic will generate C code +that uses the :ref:`Limited API <limited-c-api>` to parse arguments. The +advantage of this is that the generated code will not use private functions. +However, this *can* result in Argument Clinic generating less efficient code +in some cases. The extent of the performance penalty will depend +on the parameters (types, number, etc.). + +.. versionadded:: 3.13 + + +.. _clinic-howto-override-signature: + +How to override the generated signature +--------------------------------------- + +You can use the ``@text_signature`` directive to override the default generated +signature in the docstring. +This can be useful for complex signatures that Argument Clinic cannot handle. +The ``@text_signature`` directive takes one argument: +the custom signature as a string. +The provided signature is copied verbatim to the generated docstring. + +Example from :cpy-file:`Objects/codeobject.c`:: + + /*[clinic input] + @text_signature "($self, /, **changes)" + code.replace + * + co_argcount: int(c_default="self->co_argcount") = unchanged + co_posonlyargcount: int(c_default="self->co_posonlyargcount") = unchanged + # etc ... + + Return a copy of the code object with new values for the specified fields. + [clinic start generated output]*/ + +The generated docstring ends up looking like this: + +.. code-block:: none + + replace($self, /, **changes) + -- + + Return a copy of the code object with new values for the specified fields. + + +.. _clinic-howto-critical-sections: + +How to use critical sections with Argument Clinic +------------------------------------------------- + +You can use the ``@critical_section`` directive to instruct Argument Clinic to +wrap the call to the "impl" function in a "Python critical section". +In builds of CPython without the Global Interpreter Lock ("GIL"), +critical sections are required in order to achieve +thread safety without causing deadlocks between threads. +When a critical section is entered into, a per-object lock associated +with the first argument of the decorated function is acquired. +The lock is released on exiting the critical section. + +Python critical sections are no-ops in builds of CPython with the GIL. +See :cpy-file:`Include/internal/pycore_critical_section.h` +and :pep:`PEP 703 <703#python-critical-sections>` +for more details about critical sections. + +Example from :cpy-file:`Modules/_io/bufferedio.c`:: + + /*[clinic input] + @critical_section + _io._Buffered.close + [clinic start generated code]*/ + +The generated glue code looks like this: + +.. code-block:: c + + static PyObject * + _io__Buffered_close(buffered *self, PyObject *Py_UNUSED(ignored)) + { + PyObject *return_value = NULL; + + Py_BEGIN_CRITICAL_SECTION(self); + return_value = _io__Buffered_close_impl(self); + Py_END_CRITICAL_SECTION(); + + return return_value; + } + +You can lock one or two additional objects +by supplying their C variable names as arguments +to the ``@critical_section`` directive. +This example from :cpy-file:`Modules/_weakref.c` takes +one additional argument (a C variable named ``object``):: + + /*[clinic input] + @critical_section object + _weakref.getweakrefcount -> Py_ssize_t + + object: object + / + Return the number of weak references to 'object'. + [clinic start generated code]*/ + +The generated glue code looks like this: + +.. code-block:: c + + static PyObject * + _weakref_getweakrefs(PyObject *module, PyObject *object) + { + PyObject *return_value = NULL; + + Py_BEGIN_CRITICAL_SECTION(object); + return_value = _weakref_getweakrefs_impl(module, object); + Py_END_CRITICAL_SECTION(); + + return return_value; + } + +.. versionadded:: 3.13 + + +.. _clinic-howto-pygetsetdef: + +How to declare ``PyGetSetDef`` ("getter/setter") functions +---------------------------------------------------------- + +"Getters" and "setters" are C functions defined in a :c:type:`PyGetSetDef` struct +that facilitate :py:class:`property`-like access for a class. +You can use the ``@getter`` and ``@setter`` directives to generate +"impl" functions using Argument Clinic. + +This example --- taken from :cpy-file:`Modules/_io/textio.c` --- +shows the use of ``@getter`` and ``@setter`` in combination with +the :ref:`@critical_section <clinic-howto-critical-sections>` directive +(which achieves thread safety without causing deadlocks between threads):: + + /*[clinic input] + @critical_section + @getter + _io.TextIOWrapper._CHUNK_SIZE + [clinic start generated code]*/ + + /*[clinic input] + @critical_section + @setter + _io.TextIOWrapper._CHUNK_SIZE + [clinic start generated code]*/ + +The generated glue code looks like this: + +.. code-block:: c + + static PyObject * + _io_TextIOWrapper__CHUNK_SIZE_get(textio *self, void *Py_UNUSED(context)) + { + PyObject *return_value = NULL; + + Py_BEGIN_CRITICAL_SECTION(self); + return_value = _io_TextIOWrapper__CHUNK_SIZE_get_impl(self); + Py_END_CRITICAL_SECTION(); + + return return_value; + } + + static int + _io_TextIOWrapper__CHUNK_SIZE_set(textio *self, PyObject *value, void *Py_UNUSED(context)) + { + int return_value; + Py_BEGIN_CRITICAL_SECTION(self); + return_value = _io_TextIOWrapper__CHUNK_SIZE_set_impl(self, value); + Py_END_CRITICAL_SECTION(); + return return_value; + } + +.. note:: + + Getters and setters must be declared as separate functions. + The *value* parameter for a "setter" is added implicitly by Argument Clinic. + It is possible to create a docstring for the property by adding it to + the ``@getter``. + +And then the implementation will work the same as a Python method which is +decorated by :py:class:`property`: + +.. code-block:: pycon + + >>> import sys, _io + >>> a = _io.TextIOWrapper(sys.stdout) + >>> a._CHUNK_SIZE + 8192 + >>> a._CHUNK_SIZE = 30 + >>> a._CHUNK_SIZE + 30 + +.. versionadded:: 3.13 + + +.. _clinic-howto-deprecate-positional: +.. _clinic-howto-deprecate-keyword: + +How to deprecate passing parameters positionally or by keyword +-------------------------------------------------------------- + +Argument Clinic provides syntax that makes it possible to generate code that +deprecates passing :term:`arguments <argument>` for positional-or-keyword +:term:`parameters <parameter>` positionally or by keyword. +For example, say we've got a module-level function :py:func:`!foo.myfunc` +that has five parameters: a positional-only parameter *a*, three +positional-or-keyword parameters *b*, *c* and *d*, and a keyword-only +parameter *e*:: + + /*[clinic input] + module foo + myfunc + a: int + / + b: int + c: int + d: int + * + e: int + [clinic start generated output]*/ + +We now want to make the *b* parameter positional-only and the *d* parameter +keyword-only; +however, we'll have to wait two releases before making these changes, +as mandated by Python's backwards-compatibility policy (see :pep:`387`). +For this example, imagine we're in the development phase for Python 3.12: +that means we'll be allowed to introduce deprecation warnings in Python 3.12 +whenever an argument for the *b* parameter is passed by keyword or an argument +for the *d* parameter is passed positionally, and we'll be allowed to make +them positional-only and keyword-only respectively in Python 3.14 at +the earliest. + +We can use Argument Clinic to emit the desired deprecation warnings +using the ``[from ...]`` syntax, by adding the line ``/ [from 3.14]`` right +below the *b* parameter and adding the line ``* [from 3.14]`` right above +the *d* parameter:: + + /*[clinic input] + module foo + myfunc + a: int + / + b: int + / [from 3.14] + c: int + * [from 3.14] + d: int + * + e: int + [clinic start generated output]*/ + +Next, regenerate Argument Clinic code (``make clinic``), +and add unit tests for the new behaviour. + +The generated code will now emit a :exc:`DeprecationWarning` +when an :term:`argument` for the :term:`parameter` *d* is passed positionally +(e.g ``myfunc(1, 2, 3, 4, e=5)``) or an argument for the parameter *b* is +passed by keyword (e.g ``myfunc(1, b=2, c=3, d=4, e=5)``). +C preprocessor directives are also generated for emitting +compiler warnings if the ``[from ...]`` lines have not been removed +from the Argument Clinic input when the deprecation period is over, +which means when the alpha phase of the specified Python version kicks in. + +Let's return to our example and skip ahead two years: +Python 3.14 development has now entered the alpha phase, +but we forgot all about updating the Argument Clinic code +for :py:func:`!myfunc`! +Luckily for us, compiler warnings are now generated: + +.. code-block:: none + + In file included from Modules/foomodule.c:139: + Modules/clinic/foomodule.c.h:139:8: warning: In 'foomodule.c', update the clinic input of 'mymod.myfunc'. [-W#warnings] + # warning "In 'foomodule.c', update the clinic input of 'mymod.myfunc'. [-W#warnings]" + ^ + +We now close the deprecation phase by making *a* positional-only and *c* +keyword-only; +replace the ``/ [from ...]`` line below *b* with the ``/`` from the line +below *a* and the ``* [from ...]`` line above *d* with the ``*`` from +the line above *e*:: + + /*[clinic input] + module foo + myfunc + a: int + b: int + / + c: int + * + d: int + e: int + [clinic start generated output]*/ + +Finally, run ``make clinic`` to regenerate the Argument Clinic code, +and update your unit tests to reflect the new behaviour. + +.. note:: + + If you forget to update your input block during the alpha and beta phases, + the compiler warning will turn into a compiler error when the + release candidate phase begins. diff --git a/development-tools/clinic/index.rst b/development-tools/clinic/index.rst new file mode 100644 index 0000000000..a6ddd5c721 --- /dev/null +++ b/development-tools/clinic/index.rst @@ -0,0 +1,268 @@ +.. highlight:: c + +.. _clinic: + +*************** +Argument Clinic +*************** + +:author: Larry Hastings + +**Source code:** :cpy-file:`Tools/clinic/clinic.py`. + +Argument Clinic is a preprocessor for CPython C files. +It was introduced in Python 3.4 with :pep:`436`, +in order to provide introspection signatures, +and to generate performant and tailor-made boilerplate code +for argument parsing in CPython builtins, module level functions, and class methods. +This document is divided in four major sections: + +* :ref:`clinic-background` talks about the basic concepts and goals of Argument Clinic. +* :ref:`clinic-reference` describes the command-line interface and Argument Clinic terminology. +* :ref:`clinic-tutorial` guides you through all the steps required to adapt an existing C function to Argument Clinic. +* :ref:`clinic-howtos` details how to handle specific tasks. + +.. toctree:: + :maxdepth: 2 + :hidden: + + tutorial + howto + +.. note:: + + Argument Clinic is considered internal-only + for CPython. Its use is not supported for files outside + CPython, and no guarantees are made regarding backwards + compatibility for future versions. In other words: if you + maintain an external C extension for CPython, you're welcome + to experiment with Argument Clinic in your own code. But the + version of Argument Clinic that ships with the next version + of CPython *could* be totally incompatible and break all your code. + + +.. _clinic-background: + +Background +========== + +Basic concepts +-------------- + +When Argument Clinic is run on a file, either via the :ref:`clinic-cli` +or via ``make clinic``, it will scan over the input files looking for +:term:`start lines <start line>`: + +.. code-block:: none + + /*[clinic input] + +When it finds one, it reads everything up to the :term:`end line`: + +.. code-block:: none + + [clinic start generated code]*/ + +Everything in between these two lines is Argument Clinic :term:`input`. +When Argument Clinic parses input, it generates :term:`output`. +The output is rewritten into the C file immediately after the input, +followed by a :term:`checksum line`. +All of these lines, including the :term:`start line` and :term:`checksum line`, +are collectively called an Argument Clinic :term:`block`: + +.. code-block:: none + + /*[clinic input] + ... clinic input goes here ... + [clinic start generated code]*/ + ... clinic output goes here ... + /*[clinic end generated code: ...]*/ + +If you run Argument Clinic on the same file a second time, Argument Clinic +will discard the old :term:`output` and write out the new output with a fresh +:term:`checksum line`. +If the :term:`input` hasn't changed, the output won't change either. + +.. note:: + + You should never modify the output of an Argument Clinic block, + as any change will be lost in future Argument Clinic runs; + Argument Clinic will detect an output checksum mismatch and regenerate the + correct output. + If you are not happy with the generated output, + you should instead change the input until it produces the output you want. + + +.. _clinic-reference: + +Reference +========= + + +.. _clinic-terminology: + +Terminology +----------- + +.. glossary:: + + start line + The line ``/*[clinic input]``. + This line marks the beginning of Argument Clinic input. + Note that the *start line* opens a C block comment. + + end line + The line ``[clinic start generated code]*/``. + The *end line* marks the *end* of Argument Clinic :term:`input`, + but at the same time marks the *start* of Argument Clinic :term:`output`, + thus the text *"clinic start start generated code"* + Note that the *end line* closes the C block comment opened + by the *start line*. + + checksum + A hash to distinguish unique :term:`inputs <input>` + and :term:`outputs <output>`. + + checksum line + A line that looks like ``/*[clinic end generated code: ...]*/``. + The three dots will be replaced by a :term:`checksum` generated from the + :term:`input`, and a :term:`checksum` generated from the :term:`output`. + The checksum line marks the end of Argument Clinic generated code, + and is used by Argument Clinic to determine if it needs to regenerate + output. + + input + The text between the :term:`start line` and the :term:`end line`. + Note that the start and end lines open and close a C block comment; + the *input* is thus a part of that same C block comment. + + output + The text between the :term:`end line` and the :term:`checksum line`. + + block + All text from the :term:`start line` to the :term:`checksum line` inclusively. + + +.. _clinic-cli: + +Command-line interface +---------------------- + +The Argument Clinic :abbr:`CLI (Command-Line Interface)` is typically used to +process a single source file, like this: + +.. code-block:: shell-session + + $ python3 ./Tools/clinic/clinic.py foo.c + +The CLI supports the following options: + +.. program:: ./Tools/clinic/clinic.py [-h] [-f] [-o OUTPUT] [-v] \ + [--converters] [--make] [--srcdir SRCDIR] [--limited] [FILE ...] + +.. option:: -h, --help + + Print CLI usage. + +.. option:: -f, --force + + Force output regeneration. + +.. option:: -o, --output OUTPUT + + Redirect file output to OUTPUT + +.. option:: -v, --verbose + + Enable verbose mode. + +.. option:: --converters + + Print a list of all supported converters and return converters. + +.. option:: --make + + Walk :option:`--srcdir` to run over all relevant files. + +.. option:: --srcdir SRCDIR + + The directory tree to walk in :option:`--make` mode. + +.. option:: --exclude EXCLUDE + + A file to exclude in :option:`--make` mode. + This option can be given multiple times. + +.. option:: --limited + + Use the :ref:`Limited API <limited-c-api>` to parse arguments in the generated C code. + See :ref:`clinic-howto-limited-capi`. + +.. option:: FILE ... + + The list of files to process. + + +.. _clinic-classes: + +Classes for extending Argument Clinic +------------------------------------- + +.. module:: clinic + +.. class:: CConverter + + The base class for all converters. + See :ref:`clinic-howto-custom-converter` for how to subclass this class. + + .. attribute:: type + + The C type to use for this variable. + :attr:`!type` should be a Python string specifying the type, + for example, ``'int'``. + If this is a pointer type, the type string should end with ``' *'``. + + .. attribute:: default + + The Python default value for this parameter, as a Python value. + Or the magic value ``unspecified`` if there is no default. + + .. attribute:: py_default + + :attr:`!default` as it should appear in Python code, + as a string. + Or ``None`` if there is no default. + + .. attribute:: c_default + + :attr:`!default` as it should appear in C code, + as a string. + Or ``None`` if there is no default. + + .. attribute:: c_ignored_default + + The default value used to initialize the C variable when + there is no default, but not specifying a default may + result in an "uninitialized variable" warning. This can + easily happen when using option groups—although + properly written code will never actually use this value, + the variable does get passed in to the impl, and the + C compiler will complain about the "use" of the + uninitialized value. This value should always be a + non-empty string. + + .. attribute:: converter + + The name of the C converter function, as a string. + + .. attribute:: impl_by_reference + + A boolean value. If true, + Argument Clinic will add a ``&`` in front of the name of + the variable when passing it into the impl function. + + .. attribute:: parse_by_reference + + A boolean value. If true, + Argument Clinic will add a ``&`` in front of the name of + the variable when passing it into :c:func:`PyArg_ParseTuple`. diff --git a/development-tools/clinic/tutorial.rst b/development-tools/clinic/tutorial.rst new file mode 100644 index 0000000000..6acfaee4bd --- /dev/null +++ b/development-tools/clinic/tutorial.rst @@ -0,0 +1,408 @@ +.. _clinic-tutorial: + +Tutorial +======== + +The best way to get a sense of how Argument Clinic works is to +convert a function to work with it. Here, then, are the bare +minimum steps you'd need to follow to convert a function to +work with Argument Clinic. Note that for code you plan to +check in to CPython, you really should take the conversion farther, +using some of the :ref:`advanced concepts <clinic-howtos>` +you'll see later on in the document, +like :ref:`clinic-howto-return-converters` +and :ref:`clinic-howto-self-converter`. +But we'll keep it simple for this walkthrough so you can learn. + +First, make sure you're working with a freshly updated checkout +of the CPython trunk. + +Next, find a Python builtin that calls either :c:func:`PyArg_ParseTuple` +or :c:func:`PyArg_ParseTupleAndKeywords`, and hasn't been converted +to work with Argument Clinic yet. +For this tutorial, we'll be using +:py:meth:`_pickle.Pickler.dump <pickle.Pickler.dump>`. + +If the call to the :c:func:`!PyArg_Parse*` function uses any of the +following format units...: + +.. code-block:: none + + O& + O! + es + es# + et + et# + +... or if it has multiple calls to :c:func:`PyArg_ParseTuple`, +you should choose a different function. +(See :ref:`clinic-howto-advanced-converters` for those scenarios.) + +Also, if the function has multiple calls to :c:func:`!PyArg_ParseTuple` +or :c:func:`PyArg_ParseTupleAndKeywords` where it supports different +types for the same argument, or if the function uses something besides +:c:func:`!PyArg_Parse*` functions to parse its arguments, it probably +isn't suitable for conversion to Argument Clinic. Argument Clinic +doesn't support generic functions or polymorphic parameters. + +Next, add the following boilerplate above the function, +creating our input block:: + + /*[clinic input] + [clinic start generated code]*/ + +Cut the docstring and paste it in between the ``[clinic]`` lines, +removing all the junk that makes it a properly quoted C string. +When you're done you should have just the text, based at the left +margin, with no line wider than 80 characters. +Argument Clinic will preserve indents inside the docstring. + +If the old docstring had a first line that looked like a function +signature, throw that line away; The docstring doesn't need it anymore --- +when you use :py:func:`help` on your builtin in the future, +the first line will be built automatically based on the function's signature. + +Example docstring summary line:: + + /*[clinic input] + Write a pickled representation of obj to the open file. + [clinic start generated code]*/ + +If your docstring doesn't have a "summary" line, Argument Clinic will +complain, so let's make sure it has one. The "summary" line should +be a paragraph consisting of a single 80-column line +at the beginning of the docstring. +(See :pep:`257` regarding docstring conventions.) + +Our example docstring consists solely of a summary line, so the sample +code doesn't have to change for this step. + +Now, above the docstring, enter the name of the function, followed +by a blank line. This should be the Python name of the function, +and should be the full dotted path to the function --- +it should start with the name of the module, +include any sub-modules, and if the function is a method on +a class it should include the class name too. + +In our example, :mod:`!_pickle` is the module, :py:class:`!Pickler` is the class, +and :py:meth:`!dump` is the method, so the name becomes +:py:meth:`!_pickle.Pickler.dump`:: + + /*[clinic input] + _pickle.Pickler.dump + + Write a pickled representation of obj to the open file. + [clinic start generated code]*/ + +If this is the first time that module or class has been used with Argument +Clinic in this C file, +you must declare the module and/or class. Proper Argument Clinic hygiene +prefers declaring these in a separate block somewhere near the +top of the C file, in the same way that include files and statics go at +the top. +In our sample code we'll just show the two blocks next to each other. + +The name of the class and module should be the same as the one +seen by Python. Check the name defined in the :c:type:`PyModuleDef` +or :c:type:`PyTypeObject` as appropriate. + +When you declare a class, you must also specify two aspects of its type +in C: the type declaration you'd use for a pointer to an instance of +this class, and a pointer to the :c:type:`!PyTypeObject` for this class:: + + /*[clinic input] + module _pickle + class _pickle.Pickler "PicklerObject *" "&Pickler_Type" + [clinic start generated code]*/ + + /*[clinic input] + _pickle.Pickler.dump + + Write a pickled representation of obj to the open file. + [clinic start generated code]*/ + +Declare each of the parameters to the function. Each parameter +should get its own line. All the parameter lines should be +indented from the function name and the docstring. +The general form of these parameter lines is as follows: + +.. code-block:: none + + name_of_parameter: converter + +If the parameter has a default value, add that after the +converter: + +.. code-block:: none + + name_of_parameter: converter = default_value + +Argument Clinic's support for "default values" is quite sophisticated; +see :ref:`clinic-howto-default-values` for more information. + +Next, add a blank line below the parameters. + +What's a "converter"? +It establishes both the type of the variable used in C, +and the method to convert the Python value into a C value at runtime. +For now you're going to use what's called a "legacy converter" --- +a convenience syntax intended to make porting old code into Argument +Clinic easier. + +For each parameter, copy the "format unit" for that +parameter from the :c:func:`PyArg_Parse` format argument and +specify *that* as its converter, as a quoted string. +The "format unit" is the formal name for the one-to-three +character substring of the *format* parameter that tells +the argument parsing function what the type of the variable +is and how to convert it. +For more on format units please see :ref:`arg-parsing`. + +For multicharacter format units like ``z#``, +use the entire two-or-three character string. + +Sample:: + + /*[clinic input] + module _pickle + class _pickle.Pickler "PicklerObject *" "&Pickler_Type" + [clinic start generated code]*/ + + /*[clinic input] + _pickle.Pickler.dump + + obj: 'O' + + Write a pickled representation of obj to the open file. + [clinic start generated code]*/ + +If your function has ``|`` in the format string, +meaning some parameters have default values, you can ignore it. +Argument Clinic infers which parameters are optional +based on whether or not they have default values. + +If your function has ``$`` in the format string, +meaning it takes keyword-only arguments, +specify ``*`` on a line by itself before the first keyword-only argument, +indented the same as the parameter lines. + +:py:meth:`!_pickle.Pickler.dump` has neither, so our sample is unchanged. + +Next, if the existing C function calls :c:func:`PyArg_ParseTuple` +(as opposed to :c:func:`PyArg_ParseTupleAndKeywords`), then all its +arguments are positional-only. + +To mark parameters as positional-only in Argument Clinic, +add a ``/`` on a line by itself after the last positional-only parameter, +indented the same as the parameter lines. + +Sample:: + + /*[clinic input] + module _pickle + class _pickle.Pickler "PicklerObject *" "&Pickler_Type" + [clinic start generated code]*/ + + /*[clinic input] + _pickle.Pickler.dump + + obj: 'O' + / + + Write a pickled representation of obj to the open file. + [clinic start generated code]*/ + +It can be helpful to write a per-parameter docstring for each parameter. +Since per-parameter docstrings are optional, +you can skip this step if you prefer. + +Nevertheless, here's how to add a per-parameter docstring. +The first line of the per-parameter docstring +must be indented further than the parameter definition. +The left margin of this first line establishes +the left margin for the whole per-parameter docstring; +all the text you write will be outdented by this amount. +You can write as much text as you like, across multiple lines if you wish. + +Sample:: + + /*[clinic input] + module _pickle + class _pickle.Pickler "PicklerObject *" "&Pickler_Type" + [clinic start generated code]*/ + + /*[clinic input] + _pickle.Pickler.dump + + obj: 'O' + The object to be pickled. + / + + Write a pickled representation of obj to the open file. + [clinic start generated code]*/ + +Save and close the file, then run ``Tools/clinic/clinic.py`` on it. +With luck everything worked---your block now has output, +and a :file:`.c.h` file has been generated! +Reload the file in your text editor to see the generated code:: + + /*[clinic input] + _pickle.Pickler.dump + + obj: 'O' + The object to be pickled. + / + + Write a pickled representation of obj to the open file. + [clinic start generated code]*/ + + static PyObject * + _pickle_Pickler_dump(PicklerObject *self, PyObject *obj) + /*[clinic end generated code: output=87ecad1261e02ac7 input=552eb1c0f52260d9]*/ + +Obviously, if Argument Clinic didn't produce any output, +it's because it found an error in your input. +Keep fixing your errors and retrying until Argument Clinic processes your file +without complaint. + +For readability, most of the glue code has been generated to a :file:`.c.h` +file. You'll need to include that in your original :file:`.c` file, +typically right after the clinic module block:: + + #include "clinic/_pickle.c.h" + +Double-check that the argument-parsing code Argument Clinic generated +looks basically the same as the existing code. + +First, ensure both places use the same argument-parsing function. +The existing code must call either +:c:func:`PyArg_ParseTuple` or :c:func:`PyArg_ParseTupleAndKeywords`; +ensure that the code generated by Argument Clinic calls the +*exact* same function. + +Second, the format string passed in to :c:func:`!PyArg_ParseTuple` or +:c:func:`!PyArg_ParseTupleAndKeywords` should be *exactly* the same +as the hand-written one in the existing function, +up to the colon or semi-colon. + +Argument Clinic always generates its format strings +with a ``:`` followed by the name of the function. +If the existing code's format string ends with ``;``, +to provide usage help, this change is harmless --- don't worry about it. + +Third, for parameters whose format units require two arguments, +like a length variable, an encoding string, or a pointer +to a conversion function, ensure that the second argument is +*exactly* the same between the two invocations. + +Fourth, inside the output portion of the block, +you'll find a preprocessor macro defining the appropriate static +:c:type:`PyMethodDef` structure for this builtin:: + + #define __PICKLE_PICKLER_DUMP_METHODDEF \ + {"dump", (PyCFunction)__pickle_Pickler_dump, METH_O, __pickle_Pickler_dump__doc__}, + +This static structure should be *exactly* the same as the existing static +:c:type:`!PyMethodDef` structure for this builtin. + +If any of these items differ in *any way*, +adjust your Argument Clinic function specification and rerun +``Tools/clinic/clinic.py`` until they *are* the same. + +Notice that the last line of its output is the declaration +of your "impl" function. This is where the builtin's implementation goes. +Delete the existing prototype of the function you're modifying, but leave +the opening curly brace. Now delete its argument parsing code and the +declarations of all the variables it dumps the arguments into. +Notice how the Python arguments are now arguments to this impl function; +if the implementation used different names for these variables, fix it. + +Let's reiterate, just because it's kind of weird. +Your code should now look like this:: + + static return_type + your_function_impl(...) + /*[clinic end generated code: input=..., output=...]*/ + { + ... + +Argument Clinic generated the checksum line and the function prototype just +above it. You should write the opening and closing curly braces for the +function, and the implementation inside. + +Sample:: + + /*[clinic input] + module _pickle + class _pickle.Pickler "PicklerObject *" "&Pickler_Type" + [clinic start generated code]*/ + /*[clinic end generated code: checksum=da39a3ee5e6b4b0d3255bfef95601890afd80709]*/ + + /*[clinic input] + _pickle.Pickler.dump + + obj: 'O' + The object to be pickled. + / + + Write a pickled representation of obj to the open file. + [clinic start generated code]*/ + + PyDoc_STRVAR(__pickle_Pickler_dump__doc__, + "Write a pickled representation of obj to the open file.\n" + "\n" + ... + static PyObject * + _pickle_Pickler_dump_impl(PicklerObject *self, PyObject *obj) + /*[clinic end generated code: checksum=3bd30745bf206a48f8b576a1da3d90f55a0a4187]*/ + { + /* Check whether the Pickler was initialized correctly (issue3664). + Developers often forget to call __init__() in their subclasses, which + would trigger a segfault without this check. */ + if (self->write == NULL) { + PyErr_Format(PicklingError, + "Pickler.__init__() was not called by %s.__init__()", + Py_TYPE(self)->tp_name); + return NULL; + } + + if (_Pickler_ClearBuffer(self) < 0) { + return NULL; + } + + ... + +Remember the macro with the :c:type:`PyMethodDef` structure for this function? +Find the existing :c:type:`!PyMethodDef` structure for this +function and replace it with a reference to the macro. If the builtin +is at module scope, this will probably be very near the end of the file; +if the builtin is a class method, this will probably be below but relatively +near to the implementation. + +Note that the body of the macro contains a trailing comma; when you +replace the existing static :c:type:`!PyMethodDef` structure with the macro, +*don't* add a comma to the end. + +Sample:: + + static struct PyMethodDef Pickler_methods[] = { + __PICKLE_PICKLER_DUMP_METHODDEF + __PICKLE_PICKLER_CLEAR_MEMO_METHODDEF + {NULL, NULL} /* sentinel */ + }; + +Argument Clinic may generate new instances of ``_Py_ID``. For example:: + + &_Py_ID(new_unique_py_id) + +If it does, you'll have to run ``make regen-global-objects`` +to regenerate the list of precompiled identifiers at this point. + +Finally, compile, then run the relevant portions of the regression-test suite. +This change should not introduce any new compile-time warnings or errors, +and there should be no externally visible change to Python's behavior, +except for one difference: :py:func:`inspect.signature` run on your function +should now provide a valid signature! + +Congratulations, you've ported your first function to work with Argument Clinic! diff --git a/development-tools/gdb.rst b/development-tools/gdb.rst new file mode 100644 index 0000000000..835b2dbc70 --- /dev/null +++ b/development-tools/gdb.rst @@ -0,0 +1,60 @@ +.. _gdb: + +=========== +GDB support +=========== + +.. highlight:: none + +Page moved +========== + +Information on debugging CPython using GDB is now in the main Python +documentation, since it is relevant for C extension modules as well. +Please read it first: :ref:`python:gdb` + + +CPython tips +============ + +This document includes a few additional tips that are useful specifically for +debugging CPython internals. + + +Breaking at labels +------------------ + +You will most often set breakpoints at the start of functions, but +this approach is less helpful when debugging the runtime virtual +machine, since the main interpreter loop function, +``_PyEval_EvalFrameDefault``, is well over 4,000 lines long as of Python 3.12. +Fortunately, among the `many ways to set breakpoints +<https://sourceware.org/gdb/current/onlinedocs/gdb.html/Location-Specifications.html>`__, +you can break at C labels, such as those generated for computed gotos. +If you are debugging an interpreter compiled with computed goto support +(generally true, certainly when using GCC), each instruction will be +prefaced with a label named ``TARGET_<instruction>``, for example, +``TARGET_LOAD_CONST``. You can then set a breakpoint with a command +like:: + + (gdb) break ceval.c:_PyEval_EvalFrameDefault:TARGET_LOAD_CONST + +Add commands, save to a file, then reload in future sessions without +worrying that the starting line number of individual instructions +change over time. + +Saving and loading breakpoints +------------------------------ + +With extended exposure to particular parts of the Python runtime, you +might find it helpful to define a routine set of breakpoints and +commands to execute when they are hit. +For convenience, save your breakpoints to a file and load them in future +sessions using the ``save breakpoints`` command:: + + (gdb) save breakpoints python.brk + +You can edit the file to your heart's content, then load it in a later +session:: + + (gdb) source python.brk diff --git a/development-tools/index.rst b/development-tools/index.rst new file mode 100644 index 0000000000..b564c933e8 --- /dev/null +++ b/development-tools/index.rst @@ -0,0 +1,13 @@ +.. _development-tools: + +================= +Development tools +================= + +.. toctree:: + :maxdepth: 5 + + clinic/index + gdb + clang + warnings diff --git a/development-tools/warnings.rst b/development-tools/warnings.rst new file mode 100644 index 0000000000..b30d811311 --- /dev/null +++ b/development-tools/warnings.rst @@ -0,0 +1,69 @@ +.. warnings: + +Tools for tracking compiler warnings +==================================== + +.. highlight:: bash + +The compiler warning tracking tooling is intended to alert developers about new +compiler warnings introduced by their contributions. The tooling consists of +a Python script which is ran by the following GitHub workflows: + +* Ubuntu/build and test (:cpy-file:`.github/workflows/reusable-ubuntu.yml`) +* macOS/build and test (:cpy-file:`.github/workflows/reusable-macos.yml`) + +You can check the documentation for the :cpy-file:`Tools/build/check_warnings.py` tool +by running:: + + python Tools/build/check_warnings.py --help + +The script can be run locally by providing the compiler output file +(where the output is saved) and the compiler output type +(either ``gcc`` or ``clang``) to see a list of unique warnings:: + + python Tools/build/check_warnings.py --compiler-output-file-path=compiler_output.txt --compiler-output-type=gcc + +.. _warning-check-failure: + +What to do if a warning check fails GitHub CI +--------------------------------------------- + +The :cpy-file:`Tools/build/check_warnings.py` tool will fail if the compiler generates +more or less warnings than expected for a given source file as defined in the +platform-specific warning ignore file. The warning ignore file is either +:cpy-file:`Tools/build/.warningignore_ubuntu` or +:cpy-file:`Tools/build/.warningignore_macos` depending on the platform. + +If a warning check fails with: + +* Unexpected warnings + + * Attempt to refactor the code to avoid the warning. + * If it is not possible to avoid the warning document in the PR why it is + reasonable to ignore and add the warning to the platform-specific + warning ignore file. If the file exists in the warning ignore file + increment the count by the number of newly introduced warnings. + +* Unexpected improvements (less warnings) + + * Document in the PR that the change reduces the number of compiler + warnings. Decrement the count in the platform-specific warning + ignore file or remove the file if the count is now zero. + +.. _updating-warning-ignore-file: + +Updating the warning ignore file +-------------------------------- + +The warning ignore files can be found in the :cpy-file:`Tools/build/` directory. +Both files and directories can be added to the ignore file. Files can have an explicit warning count or a wildcard count. +Directories must be followed by a wildcard count. Wildcards indicate that 0 or more warnings will be ignored. +The following is an example of the warning ignore file format:: + + Modules/_ctypes/_ctypes_test_generated.c.h * + Objects/longobject.c 46 + Objects/methodobject.c 1 + Objects/mimalloc/ * + +Using wildcards is reserved for code that is not maintained by CPython, or code that is for tests. +Keep lines in warning ignore files sorted lexicographically. diff --git a/docquality.rst b/docquality.rst deleted file mode 100644 index 2f26f7c55f..0000000000 --- a/docquality.rst +++ /dev/null @@ -1,139 +0,0 @@ -.. _docquality: - -Helping with Documentation -========================== - -Python is known for having well-written documentation. Maintaining the -documentation's accuracy and keeping a high level of quality takes a lot of -effort. Community members, like you, help with writing, editing, and updating -content, and these contributions are appreciated and welcomed. - -This high-level **Helping with Documentation** section provides: - -* an overview of Python's documentation -* how to help with documentation issues -* information on proofreading -* guidance on contributing to this Developer's Guide - -The next chapter, :ref:`Documenting Python <documenting>`, gives extensive, -detailed information on how to write documentation and submit changes. - - -Python Documentation --------------------- - -The :ref:`Documenting Python <documenting>` section covers the details of how -Python's documentation works. It includes information about the markup -language used, specific formats, and style recommendations. Looking at -pre-existing documentation source files can be very helpful when getting -started. :ref:`How to build the documentation <building-doc>` walks you through -the steps to create a draft build which lets you see how your changes will look -and validates that your new markup is correct. - -You can view the documentation built from :ref:`in-development <indevbranch>` -and :ref:`maintenance <maintbranch>` branches at https://docs.python.org/dev/. -The in-development and most recent 3.x (as well as 2.x) maintenance -branches are rebuilt once per day. - -If you would like to be more involved with documentation, consider subscribing -to the `docs@python.org <https://mail.python.org/mailman/listinfo/docs>`_ -mailing list. The `issue tracker`_ sends new documentation issues to this -mailing list, and, less frequently, the list receives some directly mailed bug -reports. The `docs-sig@python.org <https://mail.python.org/mailman/listinfo/doc-sig>`_ -mailing list discusses the documentation toolchain, projects, and standards. - - -Helping with documentation issues ---------------------------------- - -If you look at `documentation issues`_ on the `issue tracker`_, you -will find various documentation problems that may need work. Issues vary from -typos to unclear documentation and items lacking documentation. - -If you see a documentation issue that you would like to tackle, you can: - -* check to see if there is a paperclip or `octocat`_ icon at the end of the - issue's title column. If there is, then someone has already created a pull - request for the issue. -* leave a comment on the issue saying you are going to try and create a pull - request and roughly how long you think you will take to do so (this allows - others to take on the issue if you happen to forget or lose interest). -* submit a :doc:`pull request <pullrequest>` for the issue. - -By following the steps in the :ref:`Quick Guide to Pull Requests <pullrequest-quickguide>`, -you will learn the workflow for documentation pull requests. - -.. _issue tracker: https://bugs.python.org -.. _documentation issues: https://bugs.python.org/issue?%40search_text=&ignore=file%3Acontent&title=&%40columns=title&id=&%40columns=id&stage=&creation=&creator=&activity=&%40columns=activity&%40sort=activity&actor=&nosy=&type=&components=4&versions=&dependencies=&assignee=&keywords=6&priority=&status=1&%40columns=status&resolution=&nosy_count=&message_count=&%40group=&%40pagesize=100&%40startwith=0&%40sortdir=on&%40queryname=&%40old-queryname=&%40action=search -.. _octocat: https://github.com/logos - - -Proofreading ------------- - -While an issue filed on the `issue tracker`_ means there is a known issue -somewhere, that does not mean there are not other issues lurking about in the -documentation. Proofreading a part of the documentation, such as a "How to" or -OS specific document, can often uncover problems (e.g., documentation that -needs updating for Python 3). - -If you decide to proofread, read a section of the documentation from start -to finish, filing issues in the issue tracker for each major type of problem -you find. Simple typos don't require issues of their own, but, instead, submit -a pull request directly. It's best to avoid filing a single issue for an entire -section containing multiple problems; instead, file several issues so that it -is easier to break the work up for multiple people and more efficient review. - - -.. _helping-with-the-developers-guide: - -Helping with the Developer's Guide ----------------------------------- - -.. highlight:: console - -The Developer's Guide (what you're reading now) uses the same process as the -main Python documentation, except for some small differences. The source -lives in a `separate repository`_ and bug reports should be submitted to the -`devguide GitHub tracker`_. - -Our devguide workflow uses continuous integration and deployment so changes to -the devguide are normally published when the pull request is merged. Changes -to CPython documentation follows the workflow of a CPython release and is -published in the release. - - -Developer's Guide workflow --------------------------- - -To submit a :doc:`pull request <pullrequest>`, you can fork the -`devguide repo`_ to your GitHub account and clone it using:: - - $ git clone https://github.com/<your_username>/devguide - -For your PR to be accepted, you will also need to sign the -:ref:`contributor agreement <cla>`. - -To build the devguide, some additional dependencies are required (most -importantly, `Sphinx`_), and the standard way to install dependencies in -Python projects is to create a virtualenv, and then install dependencies from -a ``requirements.txt`` file. For your convenience, this is all *automated for -you*. To build the devguide on a Unix-like system use:: - - $ make html - -in the checkout directory. On Windows use: - -.. code-block:: doscon - - > .\make html - -You will find the generated files in ``_build/html``. Note that ``make check`` -runs automatically when you submit a :doc:`pull request <pullrequest>`. You may -wish to run ``make check`` and ``make linkcheck`` to make sure that it runs -without errors. - -.. _separate repository: -.. _devguide repo: https://github.com/python/devguide -.. _devguide GitHub tracker: https://github.com/python/devguide/issues -.. _Sphinx: http://www.sphinx-doc.org/ diff --git a/documentation/devguide.rst b/documentation/devguide.rst new file mode 100644 index 0000000000..74f734831b --- /dev/null +++ b/documentation/devguide.rst @@ -0,0 +1,70 @@ +.. _devguide: + +================================== +Helping with the Developer's Guide +================================== + +.. include:: /include/activate-tab.rst + +.. highlight:: console + +The Developer's Guide (what you're reading now) uses the same process as the +main Python documentation, except for some small differences. The source +lives in a `separate repository`_ and bug reports should be submitted to the +`devguide GitHub tracker`_. + +Changes to the Developer's Guide are published when pull requests are merged. + +Changes to the Python documentation are published regularly, +usually within 48 hours of the change being committed. +The documentation is also `published for each release <https://docs.python.org/release/>`__, +which may also be used by redistributors. + + +Developer's Guide workflow +========================== + +To submit a :ref:`pull request <pullrequest>`, you can fork the +`devguide repo`_ to your GitHub account and clone it using:: + + $ git clone https://github.com/<your_username>/devguide + +For your PR to be accepted, you will also need to sign the +:ref:`contributor agreement <cla>`. + +To build the devguide, some additional dependencies are required (most +importantly, `Sphinx`_), and the standard way to install dependencies in +Python projects is to create a virtualenv, and then install dependencies from +a ``requirements.txt`` file. For your convenience, this is all *automated for +you*. + +To build the devguide from the checkout directory: + +.. tab:: Unix/macOS + + .. code-block:: shell + + make html + +.. tab:: Windows + + .. code-block:: dosbatch + + .\make html + +You will find the generated files in ``_build/html``. + +.. tip:: * Replace ``html`` with ``htmlview`` to open the docs in a web browser + once the build completes. + * Replace ``html`` with ``htmllive`` to rebuild the docs, + start a local server, and automatically reload the page in your + browser when you make changes to reST files (Unix only). + +Note that ``make check`` runs automatically when you submit +a :ref:`pull request <pullrequest>`. You may wish to run ``make check`` +and ``make linkcheck`` to make sure that it runs without errors. + +.. _separate repository: +.. _devguide repo: https://github.com/python/devguide +.. _devguide GitHub tracker: https://github.com/python/devguide/issues +.. _Sphinx: https://www.sphinx-doc.org/ diff --git a/documentation/help-documenting.rst b/documentation/help-documenting.rst new file mode 100644 index 0000000000..23520375cb --- /dev/null +++ b/documentation/help-documenting.rst @@ -0,0 +1,102 @@ +.. _help-documenting: +.. _docquality: + +========================== +Helping with documentation +========================== + +Python is known for having well-written documentation. Maintaining the +documentation's accuracy and keeping a high level of quality takes a lot of +effort. Community members, like you, help with writing, editing, and updating +content, and these contributions are appreciated and welcomed. + +This high-level **Helping with Documentation** section provides: + +* an overview of Python's documentation +* how to help with documentation issues +* information on proofreading + +You will find extensive and detailed information on how to write documentation +and submit changes on the :ref:`Documenting Python <documenting>` page. + + +Python documentation +==================== + +The :ref:`Documenting Python <documenting>` section covers the details of how +Python's documentation works. It includes information about the markup +language used, specific formats, and style recommendations. Looking at +pre-existing documentation source files can be very helpful when getting +started. :ref:`How to build the documentation <building-doc>` walks you through +the steps to create a draft build which lets you see how your changes will look +and validates that your new markup is correct. + +You can view the documentation built from :ref:`in-development <indevbranch>` +and :ref:`maintenance <maintbranch>` branches at https://docs.python.org/dev/. +The in-development and recent maintenance branches are rebuilt once per day. + +If you would like to be more involved with documentation, consider subscribing +to the `Documentation category on the Python Discourse +<https://discuss.python.org/c/documentation/26>`__ and the +`docs@python.org <https://mail.python.org/mailman3/lists/docs.python.org/>`__ mailing list +where user issues are raised and documentation toolchain, projects, and standards +are discussed. + + +Helping with documentation issues +================================= + +If you look at `documentation issues`_ on the `issue tracker`_, you +will find various documentation problems that may need work. Issues vary from +typos to unclear documentation and items lacking documentation. + +If you see a documentation issue that you would like to tackle, you can: + +* check to see if there is pull request icon to the right of the issue's title, + or an open pull request listed under :guilabel:`Linked PRs` in the issue body. + If there is, then someone has already created a pull + request for the issue. +* leave a comment on the issue saying you are going to try and create a pull + request and roughly how long you think you will take to do so (this allows + others to take on the issue if you happen to forget or lose interest). +* submit a :ref:`pull request <pullrequest>` for the issue. + +By following the steps in the :ref:`Quick Guide to Pull Requests <pullrequest-quickguide>`, +you will learn the workflow for documentation pull requests. + +.. _documentation issues: https://github.com/python/cpython/issues?q=is%3Aissue+is%3Aopen+label%3Adocs + + +Translating +=========== + +The Python documentation is being actively translated into several languages. +If you are interested in helping with translation, see our pages on +:ref:`translating <translating>` to get started. + + +Proofreading +============ + +While an issue filed on the `issue tracker`_ means there is a known issue +somewhere, that does not mean there are not other issues lurking about in the +documentation. Proofreading a part of the documentation, such as a "How to" or +OS specific document, can often uncover problems (for example, documentation that +needs updating for Python 3). + +If you decide to proofread, read a section of the documentation from start +to finish, filing issues in the issue tracker for each major type of problem +you find. Simple typos don't require issues of their own, but, instead, submit +a pull request directly. It's best to avoid filing a single issue for an entire +section containing multiple problems; instead, file several issues so that it +is easier to break the work up for multiple people and more efficient review. + +For help with the finer points of English technical writing, mention the +`@python/proofreaders <https://github.com/orgs/python/teams/proofreaders>`__ +team in your issue or pull request in any `@python <https://github.com/python/>`__ +repo. If you'd like to join the team, +`open a core-workflow issue <https://github.com/python/core-workflow/issues/new/choose>`__ +similar to +`python/core-workflow#461 <https://github.com/python/core-workflow/issues/461>`__. + +.. _issue tracker: https://github.com/python/cpython/issues diff --git a/documentation/index.rst b/documentation/index.rst new file mode 100644 index 0000000000..eaa9e1a967 --- /dev/null +++ b/documentation/index.rst @@ -0,0 +1,13 @@ +============= +Documentation +============= + +.. toctree:: + :maxdepth: 5 + + start-documenting + help-documenting + style-guide + markup + translations/index + devguide diff --git a/documenting.rst b/documentation/markup.rst similarity index 54% rename from documenting.rst rename to documentation/markup.rst index e9bb8149e0..5ba8e4c7af 100644 --- a/documenting.rst +++ b/documentation/markup.rst @@ -1,68 +1,58 @@ -.. _documenting: +.. _markup: -================== -Documenting Python -================== +======================= +reStructuredText markup +======================= .. highlight:: rest -The Python language has a substantial body of documentation, much of it -contributed by various authors. The markup used for the Python documentation is -`reStructuredText`_, developed by the `docutils`_ project, amended by custom -directives and using a toolset named `Sphinx`_ to post-process the HTML output. - -This document describes the style guide for our documentation as well as the -custom reStructuredText markup introduced by Sphinx to support Python -documentation and how it should be used. - -The documentation in HTML, PDF or EPUB format is generated from text files -written using the :ref:`reStructuredText format <markup>` and contained in the -:ref:`CPython Git repository <setup>`. - -.. _reStructuredText: http://docutils.sourceforge.net/rst.html - -.. note:: - - If you're interested in contributing to Python's documentation, there's no - need to write reStructuredText if you're not so inclined; plain text - contributions are more than welcome as well. Send an e-mail to - docs@python.org or open an issue on the :ref:`tracker <reporting-bugs>`. - +This document describes the custom reStructuredText markup introduced by Sphinx +to support Python documentation and how it should be used. + + +Quick reference +=============== + +This table summarizes which markup should be used for some commonly used +elements: + +======================= =========================================== ==================== +Element Markup See also +======================= =========================================== ==================== +arguments/parameters ``*arg*`` :ref:`inline-markup` +variables/literals/code ````foo````, ````42````, ````len(s) - 1```` :ref:`inline-markup` +True/False/None ````True````, ````False````, ````None```` :ref:`inline-markup` +function definitions ``.. function:: print(*args)`` :ref:`directives` +function references ``:func:`print``` :ref:`roles` +attribute definitions ``.. attribute: `attr-name``` :ref:`information-units` +attribute references ``:attr:`attr-name``` :ref:`roles` +reference labels ``.. _label-name:`` :ref:`doc-ref-role` +internal references ``:ref:`label-name``` :ref:`doc-ref-role` +external links ```Link text <https://example.com>`__`` :ref:`hyperlinks` +roles w/ custom text ``:role:`custom text <target>``` :ref:`roles` +roles w/ only last part ``:role:`~hidden.hidden.visible``` :ref:`roles` +roles w/o link ``:role:`!target``` :ref:`roles` +issues ``:gh:`ID```, ``:issue:`ID``` :ref:`roles` +CPython source ``:source:`PATH``` :ref:`roles` +comments ``.. a comment`` :ref:`comments` +======================= =========================================== ==================== -Introduction -============ -Python's documentation has long been considered to be good for a free -programming language. There are a number of reasons for this, the most -important being the early commitment of Python's creator, Guido van Rossum, to -providing documentation on the language and its libraries, and the continuing -involvement of the user community in providing assistance for creating and -maintaining documentation. +.. _rst-primer: -The involvement of the community takes many forms, from authoring to bug reports -to just plain complaining when the documentation could be more complete or -easier to use. +reStructuredText primer +======================= -This document is aimed at authors and potential authors of documentation for -Python. More specifically, it is for people contributing to the standard -documentation and developing additional documents using the same tools as the -standard documents. This guide will be less useful for authors using the Python -documentation tools for topics other than Python, and less useful still for -authors not using the tools at all. +This section is a brief introduction to reStructuredText (reST) concepts and +syntax, intended to provide authors with enough information to author documents +productively. Since reST was designed to be a simple, unobtrusive markup +language, this will not take too long. -If your interest is in contributing to the Python documentation, but you don't -have the time or inclination to learn reStructuredText and the markup structures -documented here, there's a welcoming place for you among the Python contributors -as well. Any time you feel that you can clarify existing documentation or -provide documentation that's missing, the existing documentation team will -gladly work with you to integrate your text, dealing with the markup for you. -Please don't let the material in this document stand between the documentation -and your desire to help out! +.. seealso:: -.. _style-guide: + The authoritative `reStructuredText User + Documentation <https://docutils.sourceforge.io/rst.html>`__. -Style guide -=========== Use of whitespace ----------------- @@ -72,228 +62,14 @@ maximum line length is 80 characters for normal text, but tables, deeply indented code samples and long links may extend beyond that. Code example bodies should use normal Python 4-space indentation. -Make generous use of blank lines where applicable; they help group things -together. +Make use of multiple blank lines where applicable to clarify the structure of +the reST file. Extra blank lines help group sections together to make the +organization of the file clearer. -A sentence-ending period may be followed by one or two spaces; while reST +A sentence-ending period may be followed by one or two spaces. While reST ignores the second space, it is customarily put in by some users, for example to aid Emacs' auto-fill mode. -Footnotes ---------- - -Footnotes are generally discouraged, though they may be used when they are the -best way to present specific information. When a footnote reference is added at -the end of the sentence, it should follow the sentence-ending punctuation. The -reST markup should appear something like this:: - - This sentence has a footnote reference. [#]_ This is the next sentence. - -Footnotes should be gathered at the end of a file, or if the file is very long, -at the end of a section. The docutils will automatically create backlinks to -the footnote reference. - -Footnotes may appear in the middle of sentences where appropriate. - -Capitalization --------------- - -.. sidebar:: Sentence case - - Sentence case is a set of capitalization rules used in English - sentences: the first word is always capitalized and other words are - only capitalized if there is a specific rule requiring it. - -In the Python documentation, the use of sentence case in section titles is -preferable, but consistency within a unit is more important than -following this rule. If you add a section to a chapter where most -sections are in title case, you can either convert all titles to -sentence case or use the dominant style in the new section title. - -Sentences that start with a word for which specific rules require -starting it with a lower case letter should be avoided. - -.. note:: - - Sections that describe a library module often have titles in the - form of "modulename --- Short description of the module." In this - case, the description should be capitalized as a stand-alone - sentence. - -Many special names are used in the Python documentation, including the names of -operating systems, programming languages, standards bodies, and the like. Most -of these entities are not assigned any special markup, but the preferred -spellings are given here to aid authors in maintaining the consistency of -presentation in the Python documentation. - -Other terms and words deserve special mention as well; these conventions should -be used to ensure consistency throughout the documentation: - -CPU - For "central processing unit." Many style guides say this should be - spelled out on the first use (and if you must use it, do so!). For - the Python documentation, this abbreviation should be avoided since - there's no reasonable way to predict which occurrence will be the - first seen by the reader. It is better to use the word "processor" - instead. - -POSIX - The name assigned to a particular group of standards. This is always - uppercase. - -Python - The name of our favorite programming language is always capitalized. - -reST - For "reStructuredText," an easy to read, plaintext markup syntax - used to produce Python documentation. When spelled out, it is - always one word and both forms start with a lower case 'r'. - -Unicode - The name of a character coding system. This is always written - capitalized. - -Unix - The name of the operating system developed at AT&T Bell Labs in the early - 1970s. - -Affirmative Tone ----------------- - -The documentation focuses on affirmatively stating what the language does and -how to use it effectively. - -Except for certain security or segfault risks, the docs should avoid -wording along the lines of "feature x is dangerous" or "experts only". These -kinds of value judgments belong in external blogs and wikis, not in the core -documentation. - -Bad example (creating worry in the mind of a reader): - - Warning: failing to explicitly close a file could result in lost data or - excessive resource consumption. Never rely on reference counting to - automatically close a file. - -Good example (establishing confident knowledge in the effective use of the -language): - - A best practice for using files is use a try/finally pair to explicitly - close a file after it is used. Alternatively, using a with-statement can - achieve the same effect. This assures that files are flushed and file - descriptor resources are released in a timely manner. - -Economy of Expression ---------------------- - -More documentation is not necessarily better documentation. Err on the side -of being succinct. - -It is an unfortunate fact that making documentation longer can be an impediment -to understanding and can result in even more ways to misread or misinterpret the -text. Long descriptions full of corner cases and caveats can create the -impression that a function is more complex or harder to use than it actually is. - -Security Considerations (and Other Concerns) --------------------------------------------- - -Some modules provided with Python are inherently exposed to security issues -(e.g. shell injection vulnerabilities) due to the purpose of the module -(e.g. :mod:`ssl`). Littering the documentation of these modules with red -warning boxes for problems that are due to the task at hand, rather than -specifically to Python's support for that task, doesn't make for a good -reading experience. - -Instead, these security concerns should be gathered into a dedicated -"Security Considerations" section within the module's documentation, and -cross-referenced from the documentation of affected interfaces with a note -similar to ``"Please refer to the :ref:`security-considerations` section -for important information on how to avoid common mistakes."``. - -Similarly, if there is a common error that affects many interfaces in a -module (e.g. OS level pipe buffers filling up and stalling child processes), -these can be documented in a "Common Errors" section and cross-referenced -rather than repeated for every affected interface. - -Code Examples -------------- - -Short code examples can be a useful adjunct to understanding. Readers can often -grasp a simple example more quickly than they can digest a formal description in -prose. - -People learn faster with concrete, motivating examples that match the context of -a typical use case. For instance, the :meth:`str.rpartition` method is better -demonstrated with an example splitting the domain from a URL than it would be -with an example of removing the last word from a line of Monty Python dialog. - -The ellipsis for the :py:data:`sys.ps2` secondary interpreter prompt should only -be used sparingly, where it is necessary to clearly differentiate between input -lines and output lines. Besides contributing visual clutter, it makes it -difficult for readers to cut-and-paste examples so they can experiment with -variations. - -Code Equivalents ----------------- - -Giving pure Python code equivalents (or approximate equivalents) can be a useful -adjunct to a prose description. A documenter should carefully weigh whether the -code equivalent adds value. - -A good example is the code equivalent for :func:`all`. The short 4-line code -equivalent is easily digested; it re-emphasizes the early-out behavior; and it -clarifies the handling of the corner-case where the iterable is empty. In -addition, it serves as a model for people wanting to implement a commonly -requested alternative where :func:`all` would return the specific object -evaluating to False whenever the function terminates early. - -A more questionable example is the code for :func:`itertools.groupby`. Its code -equivalent borders on being too complex to be a quick aid to understanding. -Despite its complexity, the code equivalent was kept because it serves as a -model to alternative implementations and because the operation of the "grouper" -is more easily shown in code than in English prose. - -An example of when not to use a code equivalent is for the :func:`oct` function. -The exact steps in converting a number to octal doesn't add value for a user -trying to learn what the function does. - -Audience --------- - -The tone of the tutorial (and all the docs) needs to be respectful of the -reader's intelligence. Don't presume that the readers are stupid. Lay out the -relevant information, show motivating use cases, provide glossary links, and do -your best to connect-the-dots, but don't talk down to them or waste their time. - -The tutorial is meant for newcomers, many of whom will be using the tutorial to -evaluate the language as a whole. The experience needs to be positive and not -leave the reader with worries that something bad will happen if they make a -misstep. The tutorial serves as guide for intelligent and curious readers, -saving details for the how-to guides and other sources. - -Be careful accepting requests for documentation changes from the rare but vocal -category of reader who is looking for vindication for one of their programming -errors ("I made a mistake, therefore the docs must be wrong ..."). Typically, -the documentation wasn't consulted until after the error was made. It is -unfortunate, but typically no documentation edit would have saved the user from -making false assumptions about the language ("I was surprised by ..."). - - -.. _rst-primer: - -reStructuredText Primer -======================= - -This section is a brief introduction to reStructuredText (reST) concepts and -syntax, intended to provide authors with enough information to author documents -productively. Since reST was designed to be a simple, unobtrusive markup -language, this will not take too long. - -.. seealso:: - - The authoritative `reStructuredText User - Documentation <http://docutils.sourceforge.net/rst.html>`_. - - Paragraphs ---------- @@ -302,6 +78,7 @@ chunks of text separated by one or more blank lines. As in Python, indentation is significant in reST, so all lines of the same paragraph must be left-aligned to the same level of indentation. +.. _inline-markup: Inline markup ------------- @@ -310,7 +87,7 @@ The standard reST inline markup is quite simple: use * one asterisk: ``*text*`` for emphasis (italics), * two asterisks: ``**text**`` for strong emphasis (boldface), and -* backquotes: ````text```` for code samples. +* backquotes: ````text```` for code samples, variables, and literals. If asterisks or backquotes appear in running text and could be confused with inline markup delimiters, they have to be escaped with a backslash. @@ -324,13 +101,13 @@ Be aware of some restrictions of this markup: These restrictions may be lifted in future versions of the docutils. -reST also allows for custom "interpreted text roles"', which signify that the +reST also allows for custom "interpreted text roles", which signify that the enclosed text should be interpreted in a specific way. Sphinx uses this to provide semantic markup and cross-referencing of identifiers, as described in the appropriate section. The general syntax is ``:rolename:`content```. -Lists and Quotes +Lists and quotes ---------------- List markup is natural: just place an asterisk at the start of a paragraph and @@ -374,7 +151,7 @@ Paragraphs are quoted by just indenting them more than the surrounding paragraphs. -Source Code +Source code ----------- Literal code blocks are introduced by ending a paragraph with the special marker @@ -400,6 +177,7 @@ The handling of the ``::`` marker is smart: That way, the second sentence in the above example's first paragraph would be rendered as "The next paragraph is a code sample:". +.. _hyperlinks: Hyperlinks ---------- @@ -407,9 +185,12 @@ Hyperlinks External links ^^^^^^^^^^^^^^ -Use ```Link text <http://target>`_`` for inline web links. If the link text +Use ```Link text <https://example.com>`__`` for inline web links. If the link text should be the web address, you don't need special markup at all, the parser -finds links and mail addresses in ordinary text. +finds links and mail addresses in ordinary text. Prefer anonymous hyperlinks +(with a double underscore) over named hyperlinks (with a single underscore) +to avoid target name clashes. + Internal links ^^^^^^^^^^^^^^ @@ -440,7 +221,7 @@ Python documentation, here is a suggested convention: * ``"``, for paragraphs -Explicit Markup +Explicit markup --------------- "Explicit markup" is used in reST for most constructs that need special @@ -453,6 +234,7 @@ indentation. (There needs to be a blank line between explicit markup and normal paragraphs. This may all sound a bit complicated, but it is intuitive enough when you write it.) +.. _directives: Directives ---------- @@ -461,7 +243,8 @@ A directive is a generic block of explicit markup. Besides roles, it is one of the extension mechanisms of reST, and Sphinx makes heavy use of it. Basically, a directive consists of a name, arguments, options and content. (Keep -this terminology in mind, it is used in the next chapter describing custom +this terminology in mind, it is used in :ref:`the next section +<additional-markup-constructs>` describing custom directives.) Looking at this example, :: @@ -496,12 +279,15 @@ body at the bottom of the document after a "Footnotes" rubric heading, like so:: You can also explicitly number the footnotes for better context. +.. _comments: Comments -------- -Every explicit markup block which isn't a valid markup construct (like the -footnotes above) is regarded as a comment. +Every explicit markup block (starting with :literal:`.. \ `) which isn't a +:ref:`valid markup construct <directives>` is regarded as a comment:: + + .. This is a comment Source encoding @@ -525,7 +311,30 @@ There are some problems one commonly runs into while authoring reST documents: an escaped space to get around that. -Additional Markup Constructs +Typographic conventions +======================= + +Big *O* notation +---------------- + +Big *O* notation is used to describe the performance of algorithms. + +Use italics for the big *O* and variables. For example: + +======================== ==================== +reStructuredText Rendered +======================== ==================== +``*O*\ (1)`` *O*\ (1) +``*O*\ (log *n*)`` *O*\ (log *n*) +``*O*\ (*n*)`` *O*\ (*n*) +``*O*\ (*n* log *n*)`` *O*\ (*n* log *n*) +``*O*\ (*n*\ :sup:`2`)`` *O*\ (*n*\ :sup:`2`) +======================== ==================== + + +.. _additional-markup-constructs: + +Additional markup constructs ============================ Sphinx adds a lot of new directives and interpreted text roles to standard reST @@ -537,23 +346,7 @@ they are used in the Python documentation. This is just an overview of Sphinx' extended markup capabilities; full coverage can be found in `its own documentation - <http://sphinx-doc.org/>`_. - - -Meta-information markup ------------------------ - -.. describe:: sectionauthor - - Identifies the author of the current section. The argument should include - the author's name such that it can be used for presentation (though it isn't) - and email address. The domain name portion of the address should be lower - case. Example:: - - .. sectionauthor:: Guido van Rossum <guido@python.org> - - Currently, this markup isn't reflected in the output in any way, but it helps - keep track of contributions. + <https://www.sphinx-doc.org/>`__. Module-specific markup @@ -564,42 +357,24 @@ module being documented. Each module should be documented in its own file. Normally this markup appears after the title heading of that file; a typical file might start like this:: - :mod:`parrot` -- Dead parrot access - =================================== + :mod:`!parrot` -- Dead parrot access + ==================================== .. module:: parrot - :platform: Unix, Windows :synopsis: Analyze and reanimate dead parrots. - .. moduleauthor:: Eric Cleese <eric@python.invalid> - .. moduleauthor:: John Idle <john@python.invalid> - -As you can see, the module-specific markup consists of two directives, the -``module`` directive and the ``moduleauthor`` directive. .. describe:: module This directive marks the beginning of the description of a module, package, - or submodule. The name should be fully qualified (i.e. including the + or submodule. The name should be fully qualified (that is, including the package name for submodules). - The ``platform`` option, if present, is a comma-separated list of the - platforms on which the module is available (if it is available on all - platforms, the option should be omitted). The keys are short identifiers; - examples that are in use include "IRIX", "Mac", "Windows", and "Unix". It is - important to use a key which has already been used when applicable. - The ``synopsis`` option should consist of one sentence describing the module's purpose -- it is currently only used in the Global Module Index. The ``deprecated`` option can be given (with no value) to mark a module as deprecated; it will be designated as such in various locations then. -.. describe:: moduleauthor - - The ``moduleauthor`` directive, which can appear multiple times, names the - authors of the module code, just like ``sectionauthor`` names the author(s) - of a piece of documentation. It too does not result in any output currently. - .. note:: It is important to make the section title of a module-describing file @@ -607,6 +382,8 @@ As you can see, the module-specific markup consists of two directives, the in overview files. +.. _information-units: + Information units ----------------- @@ -635,7 +412,7 @@ The directives are: .. describe:: c:function - Describes a C function. The signature should be given as in C, e.g.:: + Describes a C function. The signature should be given as in C, for example:: .. c:function:: PyObject* PyType_GenericAlloc(PyTypeObject *type, Py_ssize_t nitems) @@ -736,8 +513,8 @@ The directives are: Set name of the decorated function to *name*. - There is no ``deco`` role to link to a decorator that is marked up with - this directive; rather, use the ``:func:`` role. + To link to a decorator that is marked up with this directive, + use the ``:deco:`` role. .. describe:: class @@ -759,6 +536,10 @@ The directives are: Description of the attribute. + Refer to an attribute using the ``:attr:`` role:: + + Use the :attr:`ham` attribute to spam the eggs. + If is also possible to document an attribute outside of a class directive, for example if the documentation for different attributes and methods is split in multiple sections. The class name should then be included @@ -809,12 +590,12 @@ The directives are: Describes a Python :term:`bytecode` instruction. -.. describe:: cmdoption +.. describe:: option Describes a Python command line option or switch. Option argument names should be enclosed in angle brackets. Example:: - .. cmdoption:: -m <module> + .. option:: -m <module> Run a module as a script. @@ -845,14 +626,13 @@ preceding paragraph and delimited by indentation. Representing an interactive session requires including the prompts and output along with the Python code. No special markup is required for interactive -sessions. After the last line of input or output presented, there should not be -an "unused" primary prompt; this is an example of what *not* to do: +sessions. After the last line of input or output is presented, there should +be no trailing prompt. An example of correct usage is: .. code-block:: python >>> 1 + 1 2 - >>> Syntax highlighting is handled in a smart way: @@ -872,7 +652,7 @@ Syntax highlighting is handled in a smart way: encountered. * The ``code-block`` directive can be used to specify the highlight language - of a single code block, e.g.:: + of a single code block, for example:: .. code-block:: c @@ -894,7 +674,7 @@ Syntax highlighting is handled in a smart way: Longer displays of verbatim text may be included by storing the example text in an external file containing only plain text. The file may be included using the -``literalinclude`` directive. [1]_ For example, to include the Python source +``literalinclude`` directive. For example, to include the Python source file :file:`example.py`, use:: .. literalinclude:: example.py @@ -902,18 +682,37 @@ file :file:`example.py`, use:: The file name is relative to the current file's path. Documentation-specific include files should be placed in the ``Doc/includes`` subdirectory. +.. note:: + + There is a standard ``include`` directive, but it raises errors if the + file is not found. ``literalinclude`` is preferred because it only emits a + warning instead of raising an error. + + .. _rest-inline-markup: +.. _roles: -Inline markup -------------- +Roles +----- + +As :ref:`previously mentioned <inline-markup>`, Sphinx uses +interpreted text roles of the form ``:rolename:`content``` +to insert semantic markup in documents. -As said before, Sphinx uses interpreted text roles to insert semantic markup in -documents. +In the CPython documentation, there are a couple common cases +where simpler markup should be used: -Names of local variables, such as function/method arguments, are an exception, -they should be marked simply with ``*var*``. +* ``*arg*`` (rendered as *arg*) for function and method arguments. +* ````True````/````False````/````None```` for ``True``/``False``/``None``. -For all other roles, you have to write ``:rolename:`content```. +In addition, the CPython documentation defines a few custom roles: + +* ``:cve:`YYYY-NNNNN```: link to a Common Vulnerabilities and Exposures entry. +* ``:cwe:`NNN```: link to a Common Weakness Enumeration entry. +* ``:gh:`ID```: link to a GitHub issue. +* ``:issue:`ID```: link to a bugs.python.com issue. +* ``:pypi:`NAME```: link to a project on PyPI. +* ``:source:`PATH```: link to a source file on GitHub. There are some additional facilities that make cross-referencing roles more versatile: @@ -929,9 +728,13 @@ versatile: ``:meth:`~Queue.Queue.get``` will refer to ``Queue.Queue.get`` but only display ``get`` as the link text. - In HTML output, the link's ``title`` attribute (that is e.g. shown as a + In HTML output, the link's ``title`` attribute (that might be shown as a tool-tip on mouse-hover) will always be the full target name. +* Combining ``~`` and ``!`` (for example, ``:meth:`~!Queue.Queue.get```) is not + supported. You can obtain the same result by using ``!`` and the last + component of the target (for example, ``:meth:`!get```). + The following roles refer to objects in modules and are possibly hyperlinked if a matching identifier is found: @@ -972,6 +775,10 @@ a matching identifier is found: The name of an exception. A dotted name may be used. +.. describe:: deco + + The name of a decorator. A dotted name may be used. + The name enclosed in this markup can include a module name and/or a class name. For example, ``:func:`filter``` could refer to a function named ``filter`` in the current module, or the built-in function of that name. In contrast, @@ -1115,7 +922,7 @@ in a different style: .. describe:: manpage A reference to a Unix manual page including the section, - e.g. ``:manpage:`ls(1)```. + for example, ``:manpage:`ls(1)```. .. describe:: menuselection @@ -1216,6 +1023,17 @@ Paragraph-level markup These directives create short paragraphs and can be used inside information units as well as normal text: +.. describe:: availability + + This directive documents the platforms on which a module or feature + is available. For example:: + + .. availability:: Unix, not WASI, not Android. + + :: + + .. availability:: Linux >= 3.0 with glibc >= 2.14. + .. describe:: note An especially important bit of information about an API that a user should be @@ -1245,13 +1063,42 @@ units as well as normal text: feature, or a part of it, to the library or C API. When this applies to an entire module, it should be placed at the top of the module section before any prose. + When adding a new API :ref:`with a directive <information-units>` + (``class``, ``attribute``, ``function``, ``method``, ``c:type``, etc), + a ``versionadded`` should be included at the end of its description block. - The first argument must be given and is the version in question. The second - argument is optional and can be used to describe the details of the feature. + The first argument must be given and is the version in question. + Instead of a specific version number, you can---and should---use + the word ``next``, indicating that the API will first appear in the + upcoming release. + The second argument is optional and can be used to describe the details of the feature. Example:: - .. versionadded:: 3.5 + .. function:: func() + + Return foo and bar. + + .. versionadded:: next + + When a release is made, the release manager will change the ``next`` to + the just-released version. For example, if ``func`` in the above example is + released in 3.14, the snippet will be changed to:: + + .. function:: func() + + Return foo and bar. + + .. versionadded:: 3.14 + + The tool to do this replacement is `update_version_next.py`_ + in the release-tools repository. + + .. _update_version_next.py: https://github.com/python/release-tools/blob/master/update_version_next.py + + When adding documentation for a function that existed in a past version, + but wasn't documented yet, use the version number where the function was + added instead of ``next``. .. describe:: versionchanged @@ -1261,8 +1108,12 @@ units as well as normal text: Example:: - .. versionchanged:: 3.1 - The *spam* parameter was added. + .. function:: func(spam=False) + + Return foo and bar, optionally with *spam* applied. + + .. versionchanged:: next + Added the *spam* parameter. Note that there should be no blank line between the directive head and the explanation; this is to make these blocks visually continuous in the markup. @@ -1273,10 +1124,12 @@ units as well as normal text: There is one required argument: the version from which the feature is deprecated. + Similarly to ``versionadded``, you should use the word ``next`` to indicate + the API will be first deprecated in the upcoming release. Example:: - .. deprecated:: 3.8 + .. deprecated:: next .. describe:: deprecated-removed @@ -1284,16 +1137,30 @@ units as well as normal text: removed. There are two required arguments: the version from which the feature is - deprecated, and the version in which the feature is removed. + deprecated (usually ``next``), and the version in which the feature + is removed, which must be a specific version number (*not* ``next``). + + Example:: + + .. deprecated-removed:: next 4.0 + +.. describe:: soft-deprecated + + Indicates the version from which the described feature is :term:`soft deprecated`. + + There is one required argument: the version from which the feature is soft + deprecated. + Use the word ``next`` to indicate the API will be first soft deprecated in + the upcoming release. Example:: - .. deprecated-removed:: 3.8 4.0 + .. soft-deprecated:: next .. describe:: impl-detail This directive is used to mark CPython-specific information. Use either with - a block content or a single sentence as an argument, i.e. either :: + a block content or a single sentence as an argument, that is, either :: .. impl-detail:: @@ -1345,6 +1212,9 @@ units as well as normal text: Table-of-contents markup ------------------------ +.. TODO: This is a copy of the Sphinx description of the toctree directive. + Why duplicate it here? + Since reST does not have facilities to interconnect several documents, or split documents into multiple output files, Sphinx uses a custom directive to add relations between the single files the documentation is made of, as well as @@ -1459,7 +1329,7 @@ the definition of the symbol. There is this directive: Blank lines are not allowed within ``productionlist`` directive arguments. The definition can contain token names which are marked as interpreted text - (e.g. ``unaryneg ::= "-" `integer```) -- this generates cross-references + (for example, ``unaryneg ::= "-" `integer```) -- this generates cross-references to the productions of these tokens. Note that no further reST parsing is done in the production, so that you @@ -1489,341 +1359,15 @@ default. They are set in the build configuration file :file:`conf.py`. .. describe:: |release| Replaced by the Python release the documentation refers to. This is the full - version string including alpha/beta/release candidate tags, e.g. ``2.5.2b3``. + version string including alpha/beta/release candidate tags, for example, ``2.5.2b3``. .. describe:: |version| Replaced by the Python version the documentation refers to. This consists - only of the major and minor version parts, e.g. ``2.5``, even for version + only of the major and minor version parts, for example, ``2.5``, even for version 2.5.1. .. describe:: |today| Replaced by either today's date, or the date set in the build configuration file. Normally has the format ``April 14, 2007``. - - -.. rubric:: Footnotes - -.. [1] There is a standard ``include`` directive, but it raises errors if the - file is not found. This one only emits a warning. - - -.. _building-doc: - -Building the documentation -========================== - -.. highlight:: bash - -The toolset used to build the docs is written in Python and is called Sphinx_. -Sphinx is maintained separately and is not included in this tree. Also needed -are blurb_, a tool to create :file:`Misc/NEWS` on demand; and -python-docs-theme_, the Sphinx theme for the Python documentation. - -To build the documentation, follow the instructions from one of the sections -below. You can view the documentation after building the HTML by pointing -a browser at the file :file:`Doc/build/html/index.html`. - -You are expected to have installed the latest stable version of -Sphinx_ and blurb_ on your system or in a virtualenv_ (which can be -created using ``make venv``), so that the Makefile can find the -``sphinx-build`` command. You can also specify the location of -``sphinx-build`` with the ``SPHINXBUILD`` :command:`make` variable. - - -.. _building-using-make: - -Using make / make.bat ---------------------- - -**On Unix**, run the following from the root of your :ref:`repository clone -<checkout>` to build the output as HTML:: - - cd Doc - make venv - make html - -or alternatively ``make -C Doc/ venv html``. - -You can also use ``make help`` to see a list of targets supported by -:command:`make`. Note that ``make check`` is automatically run when -you submit a :doc:`pull request <pullrequest>`, so you should make -sure that it runs without errors. - -**On Windows**, a :file:`make.bat` batchfile tries to emulate :command:`make` -as closely as possible, but the venv target is not implemented, so you will -probably want to make sure you are working in a virtual environment before -proceeding, otherwise all dependencies will be automatically installed on your -system. - -When ready, run the following from the root of your :ref:`repository clone -<checkout>` to build the output as HTML:: - - cd Doc - make html - -You can also use ``make help`` to see a list of targets supported by -:file:`make.bat`. - -See also :file:`Doc/README.rst` for more information. - -Using sphinx-build ------------------- - -Sometimes we directly want to execute the sphinx-build tool instead of through -`make` (although the latter is still the preferred way). In this case, you can -use the following command line from the `Doc` directory (make sure to install -Sphinx_, blurb_ and python-docs-theme_ packages from PyPI):: - - sphinx-build -b<builder> . build/<builder> - -where ``<builder>`` is one of html, text, latex, or htmlhelp (for explanations -see the make targets above). - -.. _translating: - -Translating -=========== - -Python documentation translations are governed by the :PEP:`545`, -they are built by `docsbuild-scripts -<https://github.com/python/docsbuild-scripts/>`__ and hosted on -docs.python.org. There are several documentation translations already -in production, other are work in progress: - -+--------------+--------------------+------------------------------------------+ -| Language | Contact | Links | -+==============+====================+==========================================+ -| Arabic (ar) | Abdur-Rahmaan | `github <https://github.com/ | -| | Janhangeer | Abdur-rahmaanJ/py-docs-ar>`__ | -+--------------+--------------------+------------------------------------------+ -| Bengali as | `Kushal Das | `github <https://github.com/python/ | -| spoken in | <http://bugs.python| python-docs-bn-in>`__ | -| India (bn_IN)| .org/user16382>`__ | | -+--------------+--------------------+------------------------------------------+ -| French (fr) | `Julien Palard | `github <https://github.com/python/ | -| | (mdk) <https://bug | python-docs-fr/>`__ | -| | s.python.org/user2 | `doc <https://docs.python.org/fr/>`__ | -| | 3063>`__ | | -+--------------+--------------------+------------------------------------------+ -| Hindi as | | `github <https://github.com/ | -| spoken in | | CuriousLearner/python-docs-hi-in>`__ | -| India | | | -| (hi_IN) | | | -+--------------+--------------------+------------------------------------------+ -| Hungarian | `Tamás Bajusz | `github <https://github.com/python/ | -| (hu) | (gbtami) <http://b | python-docs-hu/>`__ | -| | ugs.python.org/use | | -| | r25857>`__ | `list <https://mail.python.org/pipermail/| -| | | python-hu/>`__ | -| | | | -+--------------+--------------------+------------------------------------------+ -| Italian (it) | | `mail <https://mail.python.org/pipermail/| -| | | doc-sig/2019-April/004114.html>`__ | -| | | | -+--------------+--------------------+------------------------------------------+ -| Japanese | `Kinebuchi Tomohiko| `github <https://github.com/python/ | -| (ja) | (cocoatomo) | python-docs-ja/>`__ | -| | <https://bugs. | | -| | python.org/ | `doc <https://docs.python.org/ja/>`__ | -| | user19001>`__ | | -+--------------+--------------------+------------------------------------------+ -| Korean (ko) | | `github <https://github.com/python/ | -| | | python-docs-ko/>`__ | -| | | | -| | | `doc <https://docs.python.org/ko/>`__ | -| | | | -+--------------+--------------------+------------------------------------------+ -| Lithuanian | | `mail <https://mail.python.org/pipermail/| -| (lt) | | doc-sig/2019-July/004138.html>`__ | -+--------------+--------------------+------------------------------------------+ -| Polish (pl) | | `mail <https://mail.python.org/pipermail/| -| | | doc-sig/2019-April/004106.html>`__ | -| | | | -+--------------+--------------------+------------------------------------------+ -| Portuguese | Gustavo Toffo | | -| (pt) | | | -+--------------+--------------------+------------------------------------------+ -| Portuguese | Marco Rougeth | `github <https://github.com/python/ | -| as spoken | | python-docs-pt-br/>`__ | -| in Brasil | | | -| (pt-br) | | `wiki <http://python.org.br/traducao>`__ | -| | | | -| | | `telgram <https://t.me/pybr_i18n>`__ | -| | | | -| | | `article <http://rgth.co/blog/ | -| | | python-ptbr-cenario-atual>`__ | -| | | | -+--------------+--------------------+------------------------------------------+ -| Russian (ru) | | `mail <https://mail.python.org/pipermail/| -| | | doc-sig/2019-May/004131.html>`__ | -| | | | -+--------------+--------------------+------------------------------------------+ -| Simplified | `Shengjing | `transifex <https://www.transifex.com/ | -| Chinese | Zhu <https://bugs. | python-doc/python-newest/language/ | -| (zh-cn) | python.org/user248 | zh_CN/>`__ | -| | 11>`__ | | -| | | `github <https://github.com/python/ | -| | | python-docs-zh-cn/>`__ | -| | | | -| | | `doc <https://docs.python.org/zh-cn/>`__ | -| | | | -+--------------+--------------------+------------------------------------------+ -| Spanish | Raul Cumplido | `github <https://github.com/raulcd/ | -| (es) | | python-docs.es/>`__ | -| | | | -| | | `old repo <https://github.com/PyAr/ | -| | | tutorial/>`__ | -+--------------+--------------------+------------------------------------------+ -| Traditional | 廖偉涵 Adrian Liaw | `github <https://github.com/python/ | -| Chinese | | python-docs-zh-tw/>`__ | -| (zh-tw) | | | -| | | `transifex <https://www.transifex.com/ | -| | | python-tw-doc/python-36-tw>`__ | -| | | | -| | | `doc <https://docs.python.org/zh-tw/>`__ | -+--------------+--------------------+------------------------------------------+ -| Turkish (tr) | | `github <https://github.com/alaeddingurel| -| | | /python-docs-tr>`__ | -| | | | -+--------------+--------------------+------------------------------------------+ - - -Starting a new translation --------------------------- - -First subscribe to the `doc-sig -<https://mail.python.org/mailman/listinfo/doc-sig>`_ mailing list, -and introduce yourself and the translation you're starting. - -Then you can bootstrap your new translation by using our `cookiecutter -<https://github.com/JulienPalard/python-docs-cookiecutter>`__. - -The important steps looks like this: - -- Create the github repo (anywhere), with the right hierarchy (using the - cookiecutter). -- Gather people to help you translating, you can't do it alone. -- You can use any tool to translate, as long as you can synchronize with git. - Some are using Transifex, some are using only github, or you can choose another - way, it's up to you. -- Ensure we updated this page to reflect your work and progress, either via a - PR, or by asking on the doc-sig mailing list. -- When ``tutorial/``, ``library/stdtypes`` and ``library/functions`` - are complete, ask on doc-sig for your language to be added in the - language picker on docs.python.org. - - -PEP 545 summary: ----------------- - -Here are the essential points of :PEP:`545`: - -- Each translation is assigned an appropriate lowercased language tag, - with an optional region subtag, joined with a dash, like - ``pt-br`` or ``fr``. - -- Each translation is under CC0 and marked as so in the README (as in - the cookiecutter). - -- Translations files are hosted on - ``https://github.com/python/python-docs-{LANGUAGE_TAG}`` (not - mandatory to start a translation, but mandatory to land on - ``docs.python.org``). - -- Translations having completed ``tutorial/``, ``library/stdtypes`` - and ``library/functions`` are hosted on - ``https://docs.python.org/{LANGUAGE_TAG}/{VERSION_TAG}/``. - - -How to get help ---------------- - -Discussions about translations occur on the `doc-sig -<https://mail.python.org/mailman/listinfo/doc-sig>`_ mailing list, -and there's a freenode IRC channel, ``#python-doc``. - - -Translation FAQ ---------------- - -Which version of Python documentation should be translated? -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Consensus is to work on current stable, you can then propagate your -translation from a branch to another using `pomerge -<https://pypi.org/p/pomerge>`__. - - -Are there some tools to help in managing the repo? -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Here's what's we're using: - -- `pomerge <https://pypi.org/p/pomerge>`__ to propagate translation - from a files to others. -- `pospell <https://pypi.org/p/pospell>`__ to check for typo in po files. -- `powrap <https://pypi.org/p/powrap>`__ to rewrap the ``.po`` files - before committing, this helps keeping git diffs short. -- `potodo <https://pypi.org/p/potodo>`__ to list what needs to be translated. - - - -How a coordinator is elected? -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -There is no election, each country have to sort this out. Here are some suggestions. - -- Coordinator requests are to be public on doc-sig mailing list. -- If the given language have a native core dev, the core dev have its - word on the choice. -- Anyone who wants to become coordinator for its native language, and shows - motivation by translating and building a community, will be named - coordinator. -- In case of concurrency between two persons, no one will sort this out - for you. It is up to you two to organize a local election or whatever - needed to sort this out. -- In case a coordinator become inactive or unreachable for a long - period of time, someone else can ask for a takeover on doc-sig. - - -The entry for my translation is missing/not up to date on this page -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Ask on doc-sig, or better, make a PR on the `devguide -<https://github.com/python/devguide/>`__. - - -I have a translation, but not on git, what should I do? -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Just ask for help on the doc-sig mailing list and our python-fu, git-fu -and bash-fu combined will help you create an appropriate repository. If -you use a tool like transifex don’t worry. Keeping them in sync is not -that hard. - - -My git hierarchy does not match yours, can I keep it? -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -No, inside the ``github.com/python`` organization we’ll all have the -exact same hierarchy so bots will be able to build all of our -translations. So you may have to convert from one hierarchy to another. -Ask for help on the doc-sig mailing list if you’re not sure on how to do -it. - -What hierarchy should I use in my github repository? -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -As for every project, we have a *branch* per version. We store ``po`` -files in the root of the repository using the ``gettext_compact=0`` -style. - - - -.. _docutils: http://docutils.sourceforge.net/ -.. _python-docs-theme: https://pypi.org/project/python-docs-theme/ -.. _Sphinx: http://sphinx-doc.org/ -.. _virtualenv: https://virtualenv.pypa.io/ -.. _blurb: https://pypi.org/project/blurb/ diff --git a/documentation/start-documenting.rst b/documentation/start-documenting.rst new file mode 100644 index 0000000000..917cb30bfa --- /dev/null +++ b/documentation/start-documenting.rst @@ -0,0 +1,242 @@ +.. _start-documenting: +.. _documenting: + +=============== +Getting started +=============== + +.. include:: /include/activate-tab.rst + +.. highlight:: rest + +The Python language has a substantial body of documentation, much of it +contributed by various authors. The markup used for the Python documentation is +`reStructuredText`_, developed by the `docutils`_ project, amended by custom +directives and using a toolset named `Sphinx`_ to post-process the HTML output. + +The documentation in HTML, PDF or EPUB format is generated from text files +written using the :ref:`reStructuredText format <markup>` and contained in the +:ref:`CPython Git repository <setup>`. + +.. _reStructuredText: https://docutils.sourceforge.io/rst.html + +.. note:: + + If you're interested in contributing to Python's documentation, there's no + need to write reStructuredText if you're not so inclined; plain text + contributions are more than welcome as well. Send an e-mail to + docs@python.org or open an issue on the :ref:`tracker <reporting-bugs>`. + + +Introduction +============ + +Python's documentation has long been considered to be good for a free +programming language. There are a number of reasons for this, the most +important being the early commitment of Python's creator, Guido van Rossum, to +providing documentation on the language and its libraries, and the continuing +involvement of the user community in providing assistance for creating and +maintaining documentation. + +The involvement of the community takes many forms, from authoring to bug reports +to just plain complaining when the documentation could be more complete or +easier to use. + +This section is aimed at authors and potential authors of documentation for +Python. More specifically, it is for people contributing to the standard +documentation and developing additional documents using the same tools as the +standard documents. This guide will be less useful for authors using the Python +documentation tools for topics other than Python, and less useful still for +authors not using the tools at all. + +If your interest is in contributing to the Python documentation, but you don't +have the time or inclination to learn reStructuredText and the markup structures +documented here, there's a welcoming place for you among the Python contributors +as well. Any time you feel that you can clarify existing documentation or +provide documentation that's missing, the existing documentation team will +gladly work with you to integrate your text, dealing with the markup for you. +Please don't let the material in this section stand between the documentation +and your desire to help out! + + +.. _building-doc: + +Building the documentation +========================== + +.. highlight:: bash + +To build the documentation, follow the steps in one of the sections below. +You can view the documentation after building the HTML +by opening the file :file:`Doc/build/html/index.html` in a web browser. + +Initial requirements +-------------------- + +Ensure your current working directory is the top level ``Doc/`` directory +inside your :ref:`CPython repository clone <checkout>`. You can switch to +it with: + +.. code-block:: shell + + cd Doc + +Ensure your Python version is at least 3.11. You can verify it with: + +.. code-block:: shell + + python --version + +.. _doc-create-venv: + +Create a virtual environment +---------------------------- + +.. _doc-create-venv-unix: +.. _doc-create-venv-windows: + +You can create a new :mod:`venv` with the required dependencies using: + +.. tab:: Unix/macOS + + .. code-block:: shell + + make venv + + Building the docs with :program:`make` will automatically use this environment + without you having to activate it. + +.. tab:: Windows + + `Create a new virtual environment <venv-create_>`__ manually. + Always be sure to `activate this environment <venv-activate_>`__ + before building the documentation. + + +.. _building-using-make: +.. _using-make-make-bat: +.. _doc-build-make: + +Build using make / make.bat +--------------------------- + +.. tab:: Unix/macOS + + A Unix ``Makefile`` is provided, :cpy-file:`Doc/Makefile`. + +.. tab:: Windows + + A Windows ``make.bat`` is provided, :cpy-file:`Doc/make.bat`, which + attempts to emulate the Unix ``Makefile`` as closely as practical. + + .. important:: + + The Windows ``make.bat`` batch file lacks a ``make venv`` target. + Instead, it automatically installs any missing dependencies + into the currently activated environment (or the base Python, if none). + Make sure the environment you :ref:`created above <doc-create-venv-windows>` + is `activated <venv-activate_>`__ before running ``make.bat``. + +To build the docs as HTML, run: + +.. tab:: Unix/macOS + + .. code-block:: shell + + make html + +.. tab:: Windows + + .. code-block:: dosbatch + + .\make html + +.. tip:: * Replace ``html`` with ``htmlview`` to open the docs in a web browser + once the build completes. + * Replace ``html`` with ``htmllive`` to rebuild the docs, + start a local server, and automatically reload the page in your + browser when you make changes to reST files (Unix only). + * To build a documentation translation, see this + :ref:`guide <docs-build-translation>`. + +It is also possible to build only certain pages of the documentation in order +to save time during the build process. Following is an example for building two +pages: + +.. tab:: Unix/macOS + + .. code-block:: shell + + make html SOURCES="tutorial/classes.rst tutorial/inputoutput.rst" + +.. tab:: Windows + + See :ref:`using-sphinx-build`. When invoking ``sphinx-build``, pass the + desired pages as the final parameter, like so: + + .. code-block:: dosbatch + + python -m sphinx -b html . build/html tutorial/classes.rst tutorial/inputoutput.rst + +To check the docs for common errors with `Sphinx Lint`_ +(which is run on all :ref:`pull requests <pullrequest>`), use: + +.. tab:: Unix/macOS + + .. code-block:: shell + + make check + +.. tab:: Windows + + .. code-block:: dosbatch + + .\make check + +To list other supported :program:`make` targets, run: + +.. tab:: Unix/macOS + + .. code-block:: shell + + make help + +.. tab:: Windows + + .. code-block:: dosbatch + + .\make help + +See :cpy-file:`Doc/README.rst` for more information. + + +.. _using-sphinx-build: +.. _doc-build-sphinx: + +Build using Sphinx directly +--------------------------- + +Advanced users may want to invoke Sphinx directly, +to pass specialized options or to handle specific use cases. + +Make sure the environment you :ref:`created above <doc-create-venv-windows>` +is `activated <venv-activate_>`__. +Then, install the documentation requirements, :cpy-file:`Doc/requirements.txt`. +Using pip:: + + python -m pip install --upgrade -r requirements.txt + +Finally, directly invoke Sphinx with:: + + python -m sphinx -b html . build/html + +To use a different `Sphinx builder`_, +replace ``html`` above with the desired builder ``name``. + + +.. _docutils: https://docutils.sourceforge.io/ +.. _Sphinx: https://www.sphinx-doc.org/ +.. _Sphinx builder: https://www.sphinx-doc.org/en/master/usage/builders/index.html +.. _Sphinx Lint: https://github.com/sphinx-contrib/sphinx-lint +.. _venv-activate: https://packaging.python.org/en/latest/guides/installing-using-pip-and-virtual-environments/#activating-a-virtual-environment +.. _venv-create: https://packaging.python.org/en/latest/guides/installing-using-pip-and-virtual-environments/#creating-a-virtual-environment diff --git a/documentation/style-guide.rst b/documentation/style-guide.rst new file mode 100644 index 0000000000..28e4f21682 --- /dev/null +++ b/documentation/style-guide.rst @@ -0,0 +1,381 @@ +.. _style-guide: + +=========== +Style guide +=========== + +.. highlight:: rest + +This page describes the linguistic style guide for our documentation. +For markup details in reST files, see :ref:`markup`. + + +Footnotes +========= + +Footnotes are generally discouraged, though they may be used when they are the +best way to present specific information. When a footnote reference is added at +the end of the sentence, it should follow the sentence-ending punctuation. The +reST markup should appear something like this:: + + This sentence has a footnote reference. [#]_ This is the next sentence. + +Footnotes should be gathered at the end of a file, or if the file is very long, +at the end of a section. The docutils will automatically create backlinks to +the footnote reference. + +Footnotes may appear in the middle of sentences where appropriate. + + +Capitalization +============== + +.. sidebar:: Sentence case + + Sentence case is a set of capitalization rules used in English + sentences: the first word is always capitalized and other words are + only capitalized if there is a specific rule requiring it. + +In the Python documentation, the use of sentence case in section titles is +preferable, but consistency within a unit is more important than +following this rule. If you add a section to a chapter where most +sections are in title case, you can either convert all titles to +sentence case or use the dominant style in the new section title. + +Sentences that start with a word for which specific rules require +starting it with a lowercase letter should be avoided. + +.. note:: + + Sections that describe a library module often have titles in the + form of "modulename --- Short description of the module." In this + case, the description should be capitalized as a stand-alone + sentence. + +Many special names are used in the Python documentation, including the names of +operating systems, programming languages, standards bodies, and the like. Most +of these entities are not assigned any special markup, but the preferred +spellings are given in :ref:`specific words` to aid authors in maintaining the +consistency of presentation in the Python documentation. + +.. _specific words: + +Specific words +============== + +Some terms and words deserve special mention. These conventions should +be used to ensure consistency throughout the documentation: + +boolean + Lowercase in most instances. + Uppercase for *Boolean mathematics* and *Boolean logic*. + To refer to the Python or C data type, prefer using the exact, + abbreviated name with appropriate markup (for example, ``:type:`bool```). + +C API + Python's `API <https://docs.python.org/3/c-api/>`__ used by C programmers + to write extension modules. All caps and unhyphenated. + +CPU + Central processing unit. No need to spell out. + +free-threaded + The preferred term for the build mode that makes the global interpreter + lock (GIL) optional (per :pep:`703`). Avoid using "No-GIL" to avoid + double negatives (for example, "non-no-GIL"). + +POSIX + The name assigned to a particular group of standards. This is always + uppercase. + +Python + The name of our favorite programming language is always capitalized. + +reST + For "reStructuredText," an easy to read, plaintext markup syntax + used to produce Python documentation. When spelled out, it is + always one word and both forms start with a lowercase 'r'. + +time zone + When referring to a Python term like a module, class, or argument spell it + as one word with appropriate markup (for example, ``:mod:`timezone```). + When talking about the real-world concept spell it as two words with no + markup. + +Unicode + The name of a character coding system. This is always written + capitalized. + +Unix + The name of the operating system developed at AT&T Bell Labs in the early + 1970s. + + +Use simple language +=================== + +Avoid esoteric phrasing where possible. Our audience is world-wide and may not +be native English speakers. + +Don't use Latin abbreviations like "e.g." or "i.e." where English words will do, +such as "for example" or "that is." + + +Charged terminology to avoid +============================ + +Avoid terminology that may be considered insensitive or exclusionary. + +.. list-table:: + :header-rows: 1 + + * - Avoid + - Instead + * - whitelist + - allowlist + * - blacklist + - blocklist, denylist + * - master/slave + - main, parent/child, server/client, primary/secondary + + +.. index:: diataxis +.. _diataxis: + +Diátaxis +======== + +Python's documentation strives to follow the `Diátaxis <https://diataxis.fr/>`__ +framework. This means adapting the writing style according to the nature of +the documentation that is being written. The framework splits +documentation into four distinct types: tutorials, how-to guides, reference, and +explanation. + +* :ref:`python:tutorial-index` should + be explicit and avoid making assumptions about the + reader's knowledge. The goal of a tutorial is to get the user writing + Python code as quickly as possible with clear logical steps. Explanations + and abstract concepts should be avoided. Please consult the Diátaxis guide on + :ref:`diataxis:tutorials` for more detail. + +* `Python how-to guides <https://docs.python.org/3/howto/index.html>`__ are + designed to guide a user through a problem-field. + Both tutorials and how-to guides are instructional rather than explanatory + and should provide logical steps on how to complete a task. However, + how-to guides make more assumptions about the user's knowledge and + focus on the user finding the best way to solve their own + particular problem. + +* :ref:`python:reference-index` should + be factual and succinct. The purpose of reference documentation is + to describe rather than to explain. Accuracy and consistency are key as + this type of documentation should be seen as an authoritative source. + :ref:`Code-examples` can be a useful way of achieving these + objectives. + +* Python explanations provide + a deeper level of understanding and are naturally more discursive. They aim + to deepen the reader's understanding and answer 'why' questions. They should + provide context, make connections between topics, and discuss alternative + opinions. There is no section dedicated to explanations but these can be + found throughout Python's documentation, for example the + :ref:`python:unicode-howto`. + +Please consult the `Diátaxis <https://diataxis.fr/>`__ guide for more +detail. + + +Links +===== + +Links are a powerful tool for helping people navigate documentation and find +more information, but links can be over-used. Links should be used only if +they help the reader. + +Generally, a link should be provided for the first use of a term in a unit, +such as a section or paragraph. This is not a hard and fast rule. Sometimes +the second mention is more appropriate for a link. Some units are long enough +to have a few repeated links. Use judgement to decide when a link will help +the reader. + +We use the :pypi:`linklint Sphinx extension <linklint>` to suppress two kinds +of excessive links: references in a section to itself and duplicate references +in a paragraph. Previously, editors had to carefully use an exclamation mark +in a Sphinx reference (``:func:`!map```) to prevent such links. + +Do not use links in section headers. They distract from the title of the +section. The term will be mentioned in the paragraph text and can be linked +from there. + +Sphinx automatically adds links to references, and provides a way to +suppress the link. Using roles like ``:func:`map``` will link to the +documentation for ``map``. If automatic link suppression isn't enough, +you can suppress the link while keeping the +semantic presentation of the function name by adding an exclamation point +prefix: ``:func:`!map```. See :ref:`roles` for more details. + + +Affirmative tone +================ + +The documentation focuses on affirmatively stating what the language does and +how to use it effectively. + +Except for certain security or segfault risks, the docs should avoid +wording along the lines of "feature x is dangerous" or "experts only". These +kinds of value judgments belong in external blogs and wikis, not in the core +documentation. + +Bad example (creating worry in the mind of a reader): + + Warning: failing to explicitly close a file could result in lost data or + excessive resource consumption. Never rely on reference counting to + automatically close a file. + +Good example (establishing confident knowledge in the effective use of the +language): + + A best practice for using files is use a try/finally pair to explicitly + close a file after it is used. Alternatively, using a with-statement can + achieve the same effect. This assures that files are flushed and file + descriptor resources are released in a timely manner. + + +Author attribution +================== + +For new documentation, do not use a byline (naming the author of the document). +Explicit attribution tends to discourage other users from updating community +documentation. + +Existing bylines are for historical interest only. They do not imply ownership +or necessary approvals, and do not prevent edits or updates by others. + + +Pronunciation of dunder names +============================= + +"Dunder names" like ``__init__`` can be awkward in running prose: is it "an +init" or "a dunder init"? Our recommendation is to ignore the underscores and +use the article that is appropriate for the word in the name. A `quick poll`__ +backs this up: "an __init__." + +__ https://hachyderm.io/@nedbat/112129685322594689 + + +Economy of expression +===================== + +More documentation is not necessarily better documentation. Err on the side +of being succinct. + +It is an unfortunate fact that making documentation longer can be an impediment +to understanding and can result in even more ways to misread or misinterpret the +text. Long descriptions full of corner cases and caveats can create the +impression that a function is more complex or harder to use than it actually is. + + +Security considerations (and other concerns) +============================================ + +Some modules provided with Python are inherently exposed to security issues +(for example, shell injection vulnerabilities) due to the purpose of the module +(for example, :mod:`ssl`). Littering the documentation of these modules with red +warning boxes for problems that are due to the task at hand, rather than +specifically to Python's support for that task, doesn't make for a good +reading experience. + +Instead, these security concerns should be gathered into a dedicated +"Security Considerations" section within the module's documentation, and +cross-referenced from the documentation of affected interfaces with a note +similar to :samp:`"Please refer to the :ref:\`{security-considerations}\` +section for important information on how to avoid common mistakes."`. + +Similarly, if there is a common error that affects many interfaces in a +module (for example, OS level pipe buffers filling up and stalling child processes), +these can be documented in a "Common Errors" section and cross-referenced +rather than repeated for every affected interface. + + +.. _code-examples: + +Code examples +============= + +Short code examples can be a useful adjunct to understanding. Readers can often +grasp a simple example more quickly than they can digest a formal description in +prose. + +People learn faster with concrete, motivating examples that match the context of +a typical use case. For instance, the :meth:`str.rpartition` method is better +demonstrated with an example splitting the domain from a URL than it would be +with an example of removing the last word from a line of Monty Python dialog. + +The ellipsis for the :py:data:`sys.ps2` secondary interpreter prompt should only +be used sparingly, where it is necessary to clearly differentiate between input +lines and output lines. Besides contributing visual clutter, it makes it +difficult for readers to cut-and-paste examples so they can experiment with +variations. + + +Code equivalents +================ + +Giving pure Python code equivalents (or approximate equivalents) can be a useful +adjunct to a prose description. A documenter should carefully weigh whether the +code equivalent adds value. + +A good example is the code equivalent for :func:`all`. The short 4-line code +equivalent is easily digested; it re-emphasizes the early-out behavior; and it +clarifies the handling of the corner-case where the iterable is empty. In +addition, it serves as a model for people wanting to implement a commonly +requested alternative where :func:`all` would return the specific object +evaluating to False whenever the function terminates early. + +A more questionable example is the code for :func:`itertools.groupby`. Its code +equivalent borders on being too complex to be a quick aid to understanding. +Despite its complexity, the code equivalent was kept because it serves as a +model to alternative implementations and because the operation of the "grouper" +is more easily shown in code than in English prose. + +An example of when not to use a code equivalent is for the :func:`oct` function. +The exact steps in converting a number to octal doesn't add value for a user +trying to learn what the function does. + + +Audience +======== + +The tone of the tutorial (and all the docs) needs to be respectful of the +reader's intelligence. Don't presume that the readers are stupid. Lay out the +relevant information, show motivating use cases, provide glossary links, and do +your best to connect-the-dots, but don't talk down to them or waste their time. + +The tutorial is meant for newcomers, many of whom will be using the tutorial to +evaluate the language as a whole. The experience needs to be positive and not +leave the reader with worries that something bad will happen if they make a +misstep. The tutorial serves as guide for intelligent and curious readers, +saving details for the how-to guides and other sources. + +Be careful accepting requests for documentation changes from the rare but vocal +category of reader who is looking for vindication for one of their programming +errors ("I made a mistake, therefore the docs must be wrong ..."). Typically, +the documentation wasn't consulted until after the error was made. It is +unfortunate, but typically no documentation edit would have saved the user from +making false assumptions about the language ("I was surprised by ..."). + + +Function signatures +=================== + +These are the evolving guidelines for how to include function signatures in the +reference guide. As outlined in :ref:`diataxis`, reference material should +prioritize precision and completeness. + +- If a function accepts positional-only or keyword-only arguments, include the + slash and the star in the signature as appropriate:: + + .. function:: some_function(pos1, pos2, /, pos_or_kwd, *, kwd1, kwd2): + + Although the syntax is terse, it is precise about the allowable ways to call + the function and is taken from Python itself. diff --git a/documentation/translations/coordinating.rst b/documentation/translations/coordinating.rst new file mode 100644 index 0000000000..82cfce74fa --- /dev/null +++ b/documentation/translations/coordinating.rst @@ -0,0 +1,300 @@ +============ +Coordinating +============ + +Information about the Python documentation translation processes is +found on this page and in :PEP:`545`. Translations are overseen by the +`Editorial Board <EB_>`_. + +.. _translation-help: + +Communication/help channels +=========================== + +Discussions about translations occur on the Python Docs Discord +`#translations channel <https://discord.gg/h3qDwgyzga>`__ and the +`translations category <trans_disc_>`_ of the Python Discourse. + +For administrative issues, ping ``@python/editorial-board``. + + +Starting a new translation +========================== + +Coordination is not a one-off task, it is a long-term commitment. Before +you start your translation, carefully consider if you will be able to commit +to this. +Every coordinator should be familiar with translating: see :ref:`translating`. + +The following sections will guide you through setting up your translation. +If you have any questions or need help, ask in one of the +:ref:`help channels <translation-help>`. + + +Announcement +------------ + +Post an announcement introducing yourself and the translation you're +starting on `Discourse <trans_disc_>`_. Also join the other communication +channels, if possible. + + +Coordination team +----------------- + +Each translation team will decide on the number of coordinators. +While initially one person is fine, we recommend expanding to having two or +three coordinators. You can find more on choosing coordinators in the FAQ +section on this page. + + +Translation team +---------------- + +.. figure:: translator-workload.svg + :class: invert-in-dark-mode + :align: center + :alt: An exaggerated chart showing that individual translator workload + decreases with the number of translators. + + +Gather people to translate with you. You can't do it alone. +Update :ref:`this table <translation-coordinators>` via a PR on the devguide +to make your translation easier to find. In the entry you can also include links +to guides or other resources for translators. + + +.. _translation-repo: + +Repository +---------- + +To start your translation create a GitHub repository, under any +account, with the correct Git hierarchy and folder structure. This can be done +in several ways, and depends on what translation process you plan to use. + +Each translation is assigned an appropriate lowercase +`IETF language tag <https://datatracker.ietf.org/doc/html/rfc5646.html>`__. +The tag may have an optional subtag, joined with a dash. +For example, ``pt`` (Portuguese) or ``pt-br`` (Brazilian Portuguese). +The repository name is then: ``python-docs-TAG`` + +The name of each branch should be the Python version it holds translations +for, for example, ``3.14``. The files should be structured like the source files +in `CPython/Doc <https://github.com/python/cpython/tree/main/Doc>`__. +A correctly set up repository looks like this: +`python-docs-pl <https://github.com/python/python-docs-pl/>`__ + +Below, the recommended ways for starting your repository are described. You can +choose another way if you like; it’s up to you. + + +Cookiecutter/bootstrapper +~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can bootstrap your new translation by using the `cookiecutter +<https://github.com/python-docs-translations/python-docs-cookiecutter>`__ or +`bootstrapper <https://github.com/python-docs-translations/python-docs-bootstrapper>`__. +The repository can then be used with a pull-request based translation process. + + +Translation platform +~~~~~~~~~~~~~~~~~~~~ + +You can also start your translation using +`Transifex <https://explore.transifex.com/python-doc/python-newest/>`__. +This will allow you to translate via the web interface, and to use shared +automatically updated source files. + +This is best done with a workflow that periodically checks for translations. +An example with instructions can be found in the +`python-docs-tx-automations documentation <https://python-docs-transifex-automation.readthedocs.io/workflows.html>`__. +An in-depth guide for manually doing this can also be found +in the same documentation's +`commands page <https://python-docs-transifex-automation.readthedocs.io/commands.html>`__. + +To be added as coordinators on Transifex for your language, open an issue +in the `tracker <https://github.com/python-docs-translations/transifex-automations/issues>`__. + + +Glossary +-------- + +Each translation team should have a way to store translations of terms to ensure +consistency. This is often done with a glossary. More information about the use +of glossaries can be found in the :ref:`translation-style-guide`. + + +Moving the repo to the ``python`` org +------------------------------------- + +This will allow you to plug your translation into docsbuild-scripts_, and it +will be found at ``docs.python.org/LANG/``, but not in the switcher. + +.. TODO Give a general milestone when this will be done. + +Adding to the language switcher +------------------------------- + +.. TODO Specify branch: https://github.com/python/devguide/issues/1586 + +Once the following resources have been fully translated: + +- ``bugs.po``, with proper links to the language repository issue tracker +- all files in the ``tutorial/`` folder +- ``library/functions.po``, the page documenting builtins + +the translation can be added to the language switcher. This can be done with a +pull request to docsbuild-scripts_, like `this commit <https://github.com/python/docsbuild-scripts/commit/e4a8aff9772738a63d0945042777d18c3d926930>`__ +if your translation was previously built but not in the switcher, or like +`this commit <https://github.com/python/docsbuild-scripts/commit/a601ce67c6c2f3be7fde3376d3e5d3851f19950b>`__ +if this is it's initial addition. + + +PEP 545 summary +=============== + +Here are the essential points of :PEP:`545`: + +- Each translation is assigned an appropriate lowercase + `IETF language tag <https://datatracker.ietf.org/doc/html/rfc5646.html>`__. + The tag may have an optional region subtag, joined with a dash. + For example, ``pt`` (Portuguese) or ``pt-br`` (Brazilian Portuguese). + +- Each translation is under CC0 and is marked as such in the README. + +- Translation files are hosted in repositories under the Python org: + ``https://github.com/python/python-docs-{LANGUAGE_TAG}`` + +- Translations having completed ``bugs``, ``tutorial/`` + and ``library/functions`` are added to the language switcher. + + +Translating Sphinx +================== + +Some messages that appear in the docs must be translated in the +`Sphinx project <https://www.sphinx-doc.org/en/master/internals/contributing.html#translations>`__ +(`sphinx-doc on Transifex <https://app.transifex.com/sphinx-doc/>`__) or in +the :ref:`Python Docs Sphinx Theme <python-docs-theme-i18n>`. +Coordinators should direct some translators there, so that the documentation +is fully translated. + + +Coordination FAQ +================ + +Are there tools to help in managing the repo? +--------------------------------------------- + +Here's what we're using: + +- :pypi:`poutils` which includes: + + - :pypi:`pomerge` to propagate translations from one file to others. + - :pypi:`pospell` to check for typos in ``.po`` files. + - :pypi:`powrap` to rewrap the ``.po`` files + before committing. This helps keep Git diffs short. + - :pypi:`potodo` to list what needs to be translated. + +- :pypi:`sphinx-lint` to validate reST syntax in translation files. + +More related tools and projects can be found in the +`python-docs-translations`__ organisation on GitHub. + +__ https://github.com/python-docs-translations + + +How should I test my translation? +--------------------------------- + +Testing should ideally be set up in your repository, and will help catch errors +early and ensure translation quality. Testing generally consists of building, and +linting with :pypi:`sphinx-lint`. + +See `this documentation <https://python-docs-transifex-automation.readthedocs.io/workflows.html#test-build-workflow>`__ +for sample workflows with usage guides. + +The `dashboard <https://translations.python.org/build-details.html>`__ +also tests translations and uploads error logs. + + +How is a coordination team chosen? +---------------------------------- + +Each translation team will decide on the number of coordinators. +We recommend two or three coordinators, though you may begin with one. + +- Coordinator requests are to be public in the `translations category of the + Python Discourse <trans_disc_>`_. +- If the given language has a native core team member, they have input + on the coordinator request. +- Anyone who wants to become coordinator for their native language and shows + motivation by translating and building a community will be named + coordinator. +- We expect the local community to self-organize coordinators and contributors. + If you have questions, please ask on the mailing list or Discourse. +- If a coordinator becomes inactive or unreachable for a long + period of time, someone else can ask to be added as a primary coordinator in + the `translations category of the Python Discourse <trans_disc_>`_. + As a community resource, we aim to keep translations up to date with active + contributors, including coordinators. + + +I have a translation, but it's not in Git. What should I do? +------------------------------------------------------------ + +You can ask for help in one of the :ref:`translation-help`, and +the team will help you create an appropriate repository. You can still use tools +like Transifex, if you like. + + +My Git hierarchy does not match yours. Can I keep it? +----------------------------------------------------- + +No, inside the ``github.com/python`` organization all repositories must have the +exact same hierarchy so bots will be able to build all of our +translations. So, you may have to convert from one hierarchy to another. +Ask for help in one of the :ref:`translation-help` if you’re not sure on how to +do it. + + +What hierarchy should I use in my GitHub repository? +---------------------------------------------------- + +As for every project, we have a *branch* per version. We store ``.po`` +files in the root of the repository using the ``gettext_compact=0`` +style. + + +Which version of the Python documentation should be translated? +--------------------------------------------------------------- + +It's best to work on Python's current stable or beta version. You can then +propagate your translation from one branch to another using :pypi:`pomerge`. + + +The entry for my translation is missing or not up to date +--------------------------------------------------------- + +Make a PR on the `devguide <https://github.com/python/devguide/>`__ to update it. + + +How are translations built? +--------------------------- + +Translations are built by `docsbuild-scripts <https://github.com/python/docsbuild-scripts/>`__ +and hosted on docs.python.org. + + +Is there a Weblate instance we can translate on? +------------------------------------------------ + +There is currently no Weblate instance for Python translations. +See this `Discourse thread <https://discuss.python.org/t/docs-translation-platform/29940>`__ +for updates. + + +.. _EB: https://python.github.io/editorial-board/ +.. _trans_disc: https://discuss.python.org/c/documentation/translations/ +.. _docsbuild-scripts: https://github.com/python/docsbuild-scripts diff --git a/documentation/translations/index.rst b/documentation/translations/index.rst new file mode 100644 index 0000000000..a6d4dc4e72 --- /dev/null +++ b/documentation/translations/index.rst @@ -0,0 +1,9 @@ +============ +Translations +============ + +.. toctree:: + :maxdepth: 4 + + translating + coordinating diff --git a/documentation/translations/translating.rst b/documentation/translations/translating.rst new file mode 100644 index 0000000000..eb3eb164a9 --- /dev/null +++ b/documentation/translations/translating.rst @@ -0,0 +1,420 @@ +.. _translating: + +=========== +Translating +=========== + +.. highlight:: rest + +There are several documentation translations already +in production and can be found in the language switcher; others are works in +progress. To get started read your repository's contributing guide, which is +generally the ``README`` file, and this page. +If your language isn’t listed below, feel free to start the translation! +See :doc:`coordination <coordinating>` to get started. + +For more details about translations and their progress, see +`translations.python.org <https://translations.python.org>`__. + +.. _translation-coordinators: + +.. list-table:: + :header-rows: 1 + + * - Language + - Coordination team + - Links + * - Arabic (ar) + - Abdur-Rahmaan Janhangeer (:github-user:`Abdur-rahmaanJ`) + - :github:`GitHub <Abdur-rahmaanJ/python-docs-ar>` + * - `Bengali (bn-IN) <https://docs.python.org/bn-in/>`__ + - Kushal Das (:github-user:`kushaldas`) + - :github:`GitHub <python/python-docs-bn-in>` + * - `French (fr) <https://docs.python.org/fr/>`__ + - Julien Palard (:github-user:`JulienPalard`) + - `AFPy/python-docs-fr <https://git.afpy.org/AFPy/python-docs-fr/>`__, + :github:`mirror <python/python-docs-fr>` + * - `Greek (el) <https://docs.python.org/el/>`__ + - | Lysandros Nikolaou (:github-user:`lysnikolaou`), + | Fanis Petkos (:github-user:`thepetk`), + | Panagiotis Skias (:github-user:`skpanagiotis`) + - :github:`GitHub <python/python-docs-el>` + * - Hindi (hi-IN) + - Sanyam Khurana (:github-user:`CuriousLearner`) + - :github:`GitHub <CuriousLearner/python-docs-hi-in>` + * - Hungarian (hu) + - + - :github:`GitHub <python/python-docs-hu>` + * - `Indonesian (id) <https://docs.python.org/id/>`__ + - | Irvan Putra (:github-user:`irvan-putra`), + | Jeff Jacobson (:github-user:`jwjacobson`), + | Lutfi Zuchri (:github-user:`lutfizuchri`) + - :github:`GitHub <python/python-docs-id>` + * - `Italian (it) <https://docs.python.org/it/>`__ + - Alessandro Cucci (:github-user:`acuccie3`, `email <mailto:alessandro.cucci@gmail.com>`__) + - :github:`GitHub <python/python-docs-it>`, + `original announcement <https://mail.python.org/pipermail/doc-sig/2019-April/004114.html>`__ + * - `Japanese (ja) <https://docs.python.org/ja/>`__ + - | Kinebuchi Tomohiko (:github-user:`cocoatomo`), + | Atsuo Ishimoto (:github-user:`atsuoishimoto`) + - :github:`GitHub <python/python-docs-ja>` + * - `Korean (ko) <https://docs.python.org/ko/>`__ + - 오동권 (:github-user:`flowdas`) + - :github:`GitHub <python/python-docs-ko>` + * - Marathi (mr) + - Sanket Garade (:github-user:`sanketgarade`, `email <mailto:garade@pm.me>`__) + - :github:`GitHub <sanketgarade/python-doc-mr>` + * - Lithuanian (lt) + - Albertas Gimbutas (:github-user:`albertas`, `email <mailto:albertasgim@gmail.com>`__) + - `original announcement <https://mail.python.org/pipermail/doc-sig/2019-July/004138.html>`__ + * - Persian (fa) + - Alireza Shabani (:github-user:`revisto`) + - :github:`GitHub <revisto/python-docs-fa>` + * - `Polish (pl) <https://docs.python.org/pl/>`__ + - | Maciej Olko (:github-user:`m-aciek`), + | Stan Ulbrych (:github-user:`StanFromIreland`) + - :github:`GitHub <python/python-docs-pl>`, + `Transifex <tx_>`_, + `original announcement <https://mail.python.org/pipermail/doc-sig/2019-April/004106.html>`__ + * - `Brazilian Portuguese (pt-br) <https://docs.python.org/pt-br/>`__ + - | Rafael Fontenelle (:github-user:`rffontenelle`), + | Marco Rougeth (:github-user:`rougeth`) + - :github:`GitHub <python/python-docs-pt-br>`, + `guide <https://python.org.br/traducao/>`__, + `Telegram <https://t.me/pybr_i18n>`__, + `article <https://rgth.co/blog/python-ptbr-cenario-atual/>`__ + * - `Romanian (ro) <https://docs.python.org/ro/>`__ + - Octavian Mustafa (:github-user:`octaG-M`, `email <mailto:octawian@yahoo.com>`__) + - :github:`GitHub <python/python-docs-ro>` + * - Russian (ru) + - Daniil Kolesnikov (:github-user:`MLGRussianXP`, `email <mailto:mlgrussianxp@gmail.com>`__) + - :github:`GitHub <MLGRussianXP/python-docs-ru>`, + `original announcement <https://mail.python.org/pipermail/doc-sig/2019-May/004131.html>`__ + * - `Simplified Chinese (zh-cn) <https://docs.python.org/zh-cn/>`__ + - | Shengjing Zhu (:github-user:`zhsj`), + | Du, Meng (:github-user:`dumeng`) + - :github:`GitHub <python/python-docs-zh-cn>`, + `Transifex <tx_>`_ + * - `Spanish (es) <https://docs.python.org/es/>`__ + - Raúl Cumplido (:github-user:`raulcd`) + - :github:`GitHub <python/python-docs-es>` + * - Swedish (sv) + - Daniel Nylander (:github-user:`yeager`) + - :github:`GitHub <python/python-docs-sv>` + * - Tamil (ta) + - | Murugan Santhosh (:github-user:`terminaljoint`), + | Hari (:github-user:`nammahari`) + - :github:`GitHub <Terminal-Joint/python-docs-ta>`, + `Discord <https://discord.gg/9rpdtag3ej>`__ + * - `Traditional Chinese (zh-tw) <https://docs.python.org/zh-tw/>`__ + - | 王威翔 Matt Wang (:github-user:`mattwang44`), + | Josix Wang (:github-user:`josix`) + - :github:`GitHub <python/python-docs-zh-tw>` + * - `Turkish (tr) <https://docs.python.org/tr/>`__ + - Ege Akman (:github-user:`egeakman`) + - :github:`GitHub <python/python-docs-tr>`, + `RTD <https://python-docs-tr.readthedocs.io/>`__ + * - `Ukrainian (uk) <https://docs.python.org/uk/>`__ + - Dmytro Kazanzhy (:github-user:`kazanzhy`, `email <mailto:dkazanzhy@gmail.com>`__) + - :github:`GitHub <python/python-docs-uk>`, + `Transifex <tx_>`_ + * - Vietnamese (vi) + - Duc-Tam Nguyen (:github-user:`tamnd`) + - :github:`GitHub <tamnd/python-docs-vi>`, + `Transifex <tx_>`_ + + +How to get help +=============== + +If there is already a repository for your language team (there may be links to +Telegrams/Discords in the ``README``), join and introduce +yourself. Your fellow translators will be more than happy to help! +General discussions about translations occur on the Python Docs Discord +`#translations channel <https://discord.gg/h3qDwgyzga>`__ and the +`translations category <discourse_>`_ of the Python Discourse. + +.. _translation-style-guide: + +Style guide +=========== + +Before translating, you should familiarize yourself with the general +documentation :doc:`style guide <../style-guide>`. Some translation-specific +guidelines are explained below. + + +Translate the meaning +--------------------- + +Try to stay as close as possible to the original text. Focus on translating its +meaning in the best possible way. + + +Gender neutrality +----------------- + +Many languages use grammatical gender. When possible and natural, prefer +gender-neutral or inclusive forms. Aim to reflect the inclusive tone of +the English documentation. + + +Roles and links +--------------- + +The Python docs contain many roles (``:role:`target```) that link to other parts +of the documentation. +Do not translate reStructuredText roles targets, such as ``:func:`print``` or +``:ref:`some-section``` because it will break the link. +If alternate text (``:role:`text <target>```) is provided, it generally +should be translated. You can also introduce alternate text for translation if +the target is not a name or term. + +Links (```text <target>`_``) should be handled similarly. If possible, the target +should be updated to match the language. + +.. seealso:: + :doc:`../markup` + + +Translation quality +------------------- + +Translators should know both English and the language they are +translating to. Translators should aim for a similar level of quality as that +of the English documentation. + +Do not rely solely on machine translation. These tools can be useful to speed up +work, but often produce inaccurate or misleading results and should be reviewed +by a human. + + +Terminology +----------- + +The documentation is full of technical terms, some are common in general +programming and have translations, whereas others are specific to Python +and previous translations are not available. +Translation teams should keep the translations of these terms +consistent, which is done with glossaries. + +Some general guidelines for deciding on a translation: + +- Use existing community conventions over inventing new terms. +- You can use a hybrid English form if users are generally familiar + with the English word. +- For common terms, the English word may be best. +- Use other translations as a reference as to what they did for the word. +- Be careful to not translate names. +- Use your best judgment. +- When you translate a specific term, record it in your translations glossary to + help fellow translators and ensure consistency. + + +Dialects +-------- + +Some translations receive contributions from people of several different dialects, +understandably the language will differ. It is recommended however that +translators try to keep files and sections consistent. + + +Code examples +------------- + +Translate values in code examples, that is string literals, and comments. +Don't translate keywords or names, including variable, function, class, argument, +and attribute names. An example of a translated codeblock from the `tutorial <https://docs.python.org/3/tutorial/controlflow.html#keyword-arguments>`__ +is provided below: + +.. code-block:: python + + def cheeseshop(kind, *arguments, **keywords): + print("-- Czy jest może", kind, "?") + print("-- Przykro mi, nie mamy już sera", kind) + for arg in arguments: + print(arg) + print("-" * 40) + for kw in keywords: + print(kw, ":", keywords[kw]) + + +.. _transifex-use: + +Transifex +========= + +.. important:: + + There are many translations in the `python-doc organization on Transifex <tx_>`_, + some of which, however, are not used or do not have a coordination team. + Confirm that a coordination team exists before you begin translating. + +Several language projects use Transifex as their translation interface. +Translations on Transifex are carried out via a web interface, similar to Weblate. +You should translate the `python-newest <tx_>`_ project. +If you are new to Transifex, it is recommended that you take the time to read +through the following resources from the Transifex documentation: + +- `Getting started as a translator <https://help.transifex.com/en/articles/6248698-getting-started-as-a-translator>`__: + This covers signing up for an account and joining a translation team. +- `Translating with the Web Editor <https://help.transifex.com/en/articles/6318216-translating-with-the-web-editor>`__: + This covers getting to the editor, searching and filtering strings, and translating strings. +- `Other Tools in the Editor <https://help.transifex.com/en/articles/6318944-other-tools-in-the-editor>`__: + This covers the history, glossary, comments, keyboard shortcuts, and more. +- `Starting with the basics <https://help.transifex.com/en/collections/3441044-starting-with-the-basics>`__: + A group of documents with basic information. + +Within the organization, a project for translating the +:github:`Python Docs Sphinx Theme <python/python-docs-theme>` can also be +found. +For further information about Transifex see our `documentation <https://python-docs-transifex-automation.readthedocs.io/>`__. + + +Resources +========= + +Some useful resources: + +- :ref:`git-boot-camp`: + Several translations accept contributions by pull requests. Most have their + own guide for how to do this, but this can provide useful tips. +- `Translation issues & improvements <https://github.com/orgs/python/projects/58>`__ GitHub project: + This project contains issues and pull requests that aim to improve + the Python documentation for translations. +- `Python Pootle archive <https://github.com/python/pootle-python-org-backup>`__: + Pootle is no longer used for translation. Contains translations for old Python versions. + + +Translation FAQ +=============== + +.. _docs-build-translation: + +How do I build a docs translation? +---------------------------------- + +To build a documentation translation for a specific language, +you need to have Python installed and a +local copy of the :github:`CPython repository <python/cpython>` and +translation repository (see table above). The PO files must be placed +in a :samp:`locales/{LANG}/LC_MESSAGES/` (replacing :samp:`{LANG}` with the translation's +language code) folder inside the :file:`Doc/` directory of the CPython repository. + +You can then build with :ref:`make <doc-build-make>` by adding +a ``SPHINXOPTS="-D language=LANG"`` variable before the target +or by using :ref:`Sphinx directly <doc-build-sphinx>` and adding a +``-D language=LANG`` option. For example: + +.. code-block:: bash + + # Build the HTML format of the Polish translation using make + make SPHINXOPTS="-D language=pl" html + + # Build the HTML format of the Romanian translation using Sphinx directly + python -m sphinx -b html . build/html -D language=ro + + +Which version of the Python documentation should I work on? +----------------------------------------------------------- + +You should work on the latest branch available to you for translation (this should +be the latest non-alpha branch), the translations should then be propagated by +your languages coordination team. + + +.. _python-docs-theme-i18n: + +How do I translate the Python Docs Sphinx Theme? +------------------------------------------------ + +The Sphinx theme for the Python documentation supports localization. + +You can translate either on +`Transifex <https://explore.transifex.com/python-doc/python-docs-theme/>`__ +(see :ref:`translating on Transifex <transifex-use>` for more information) +or locally by following the steps outlined below. + +To translate locally, clone the :github:`Python Docs Sphinx Theme repository <python/python-docs-theme>` and run the following +commands to generate the PO files. Replace ``LANG`` with the same language code +that is used for the docs translation: + +.. code-block:: bash + + python babel_runner.py extract + python babel_runner.py init -l LANG + +The file can then be found at: + +.. code-block:: text + + python-docs-theme/locale/LANG/LC_MESSAGES/python-docs-theme.po + +After translating, submit your PO file via a pull request to the +:github:`repository <python/python-docs-theme>`. +See our :ref:`git-boot-camp` for more information about using Git. + +To update an existing translation after source changes, run: + +.. code-block:: bash + + python babel_runner.py update # To update source for all languages + python babel_runner.py update -l LANG # To update source just for LANG + + +The coordination team for my language is inactive, what do I do? +---------------------------------------------------------------- + +If you would like to coordinate, open a pull request in the +`devguide <https://github.com/python/devguide>`__ adding yourself to the table +at the top of this page, and ping ``@python/editorial-board``. + + +How do I merge translations back in after docs are moved? +--------------------------------------------------------- + +When docs are moved in the CPython repository, translated messages are not +moved automatically and will be lost. +They can be recovered by merging them into the new locations. +Note that this is not necessary for Transifex-based translations, as Transifex's +translation memory will automatically copy them over. + +The :pypi:`pomerge` tool merges translations between PO files by matching +messages, regardless of file paths. To use it, first install the package: + +.. code-block:: bash + + pip install pomerge + +Then, merge translations from a specific commit (replace :samp:`{COMMIT_HASH}` +with the commit hash from before the files were moved): + +.. TODO: Provide Windows instructions. + +.. tab:: Unix + + .. code-block:: bash + + # These commands are to be run in the root of the translation repo + + # Check out a commit before the move + git checkout COMMIT_HASH -- . + + # Copy translations to a temporary dir + cp -r . /tmp/old-po-files + + # Return to the current version + git checkout HEAD -- . + + # Merge translations from temporary dir back in + pomerge --from /tmp/old-po-files/**/*.po --to **/*.po --clear + + # Clean up temporary dir + rm -rf /tmp/old-po-files + +After running ``pomerge``, review the changes and commit the updated files. +You may also need to rewrap the lines (see :pypi:`powrap`). + + +.. _discourse: https://discuss.python.org/c/documentation/translations/ +.. _tx: https://explore.transifex.com/python-doc/python-newest/ diff --git a/documentation/translations/translator-workload.svg b/documentation/translations/translator-workload.svg new file mode 100644 index 0000000000..e3e1318613 --- /dev/null +++ b/documentation/translations/translator-workload.svg @@ -0,0 +1,191 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<svg + width="460.8pt" + height="345.6pt" + viewBox="0 0 460.8 345.6" + version="1.1" + id="svg18" + sodipodi:docname="translator-workload.svg" + inkscape:version="1.4.2 (ebf0e940d0, 2025-05-08)" + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" + xmlns="http://www.w3.org/2000/svg" + xmlns:svg="http://www.w3.org/2000/svg" + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" + xmlns:cc="http://creativecommons.org/ns#" + xmlns:dc="http://purl.org/dc/elements/1.1/"> + <sodipodi:namedview + id="namedview18" + pagecolor="#ffffff" + bordercolor="#000000" + borderopacity="0.25" + inkscape:showpageshadow="2" + inkscape:pageopacity="0.0" + inkscape:pagecheckerboard="0" + inkscape:deskcolor="#d1d1d1" + inkscape:document-units="pt" + inkscape:zoom="1.0864401" + inkscape:cx="282.57426" + inkscape:cy="148.19041" + inkscape:window-width="1712" + inkscape:window-height="894" + inkscape:window-x="0" + inkscape:window-y="0" + inkscape:window-maximized="1" + inkscape:current-layer="svg18" /> + <metadata + id="metadata1"> + <rdf:RDF> + <cc:Work> + <dc:type + rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> + <dc:date>2025-06-29T10:46:39.952440</dc:date> + <dc:format>image/svg+xml</dc:format> + <dc:creator> + <cc:Agent> + <dc:title>Matplotlib v3.10.3, https://matplotlib.org/</dc:title> + </cc:Agent> + </dc:creator> + </cc:Work> + </rdf:RDF> + </metadata> + <defs + id="defs1"> + <style + type="text/css" + id="style1">*{stroke-linejoin: round; stroke-linecap: butt}</style> + </defs> + <g + id="figure_1"> + <g + id="patch_1"> + <path + d="M 0 345.6 L 1 345.631436 L 2 345.668377 L 3 345.766123 L 4 345.798645 L 5 345.87227 L 6 345.910835 L 7 345.946248 L 8 346.003888 L 9 346.074274 L 10 346.126239 L 11 346.185328 L 12 346.273649 L 13 346.319794 L 14 346.362205 L 15 346.392697 L 16 346.418742 L 17 346.439942 L 18 346.494243 L 19 346.522181 L 20 346.551905 L 21 346.5773 L 22 346.5885 L 23 346.598624 L 24 346.59842 L 25 346.58891 L 26 346.577256 L 27 346.546227 L 28 346.535059 L 29 346.504942 L 30 346.445165 L 31 346.407973 L 32 346.368877 L 33 346.326437 L 34 346.293672 L 35 346.226246 L 36 346.18712 L 37 346.144445 L 38 346.073865 L 39 346.037474 L 40 345.979071 L 41 345.868118 L 42 345.79746 L 43 345.68452 L 44 345.638747 L 45 345.577464 L 46 345.528965 L 47 345.448142 L 48 345.329623 L 49 345.259412 L 50 345.17615 L 51 345.143008 L 52 345.091771 L 53 345.023372 L 54 344.957157 L 55 344.88024 L 56 344.852924 L 57 344.826447 L 58 344.803796 L 59 344.784265 L 60 344.757871 L 61 344.7081 L 62 344.673027 L 63 344.637161 L 64 344.621794 L 65 344.606025 L 66 344.602612 L 67 344.600195 L 68 344.600681 L 69 344.60261 L 70 344.615867 L 71 344.624258 L 72 344.645794 L 73 344.668827 L 74 344.68606 L 75 344.704523 L 76 344.724975 L 77 344.741575 L 78 344.804354 L 79 344.879619 L 80 344.912258 L 81 344.979822 L 82 345.033869 L 83 345.067573 L 84 345.157699 L 85 345.186234 L 86 345.21772 L 87 345.248731 L 88 345.303539 L 89 345.368126 L 90 345.406322 L 91 345.502256 L 92 345.551514 L 93 345.595583 L 94 345.635707 L 95 345.744074 L 96 345.785702 L 97 345.847844 L 98 345.917806 L 99 346.02231 L 100 346.059298 L 101 346.105175 L 102 346.17367 L 103 346.222416 L 104 346.300013 L 105 346.330554 L 106 346.400068 L 107 346.424041 L 108 346.452663 L 109 346.494456 L 110 346.516032 L 111 346.52998 L 112 346.556702 L 113 346.566012 L 114 346.578459 L 115 346.589514 L 116 346.595178 L 117 346.599942 L 118 346.594394 L 119 346.581106 L 120 346.573589 L 121 346.548804 L 122 346.525235 L 123 346.489055 L 124 346.463093 L 125 346.440771 L 126 346.372011 L 127 346.297476 L 128 346.203497 L 129 346.152445 L 130 346.098511 L 131 346.06326 L 132 345.957172 L 133 345.904908 L 134 345.868001 L 135 345.83697 L 136 345.775815 L 137 345.708395 L 138 345.659489 L 139 345.594297 L 140 345.556109 L 141 345.514113 L 142 345.472096 L 143 345.41258 L 144 345.29942 L 145 345.247169 L 146 345.207751 L 147 345.16065 L 148 345.10387 L 149 345.071207 L 150 345.035029 L 151 345.002939 L 152 344.968659 L 153 344.910281 L 154 344.865096 L 155 344.835472 L 156 344.785086 L 157 344.759889 L 158 344.738838 L 159 344.70387 L 160 344.67958 L 161 344.665513 L 162 344.646571 L 163 344.63091 L 164 344.618358 L 165 344.612522 L 166 344.60564 L 167 344.600466 L 168 344.602249 L 169 344.604974 L 170 344.616128 L 171 344.644363 L 172 344.688151 L 173 344.70884 L 174 344.749813 L 175 344.789888 L 176 344.808998 L 177 344.831507 L 178 344.898158 L 179 344.947868 L 180 345.021574 L 181 345.052888 L 182 345.12951 L 183 345.167808 L 184 345.241925 L 185 345.345983 L 186 345.415814 L 187 345.521048 L 188 345.576063 L 189 345.699538 L 190 345.770097 L 191 345.885936 L 192 345.936117 L 193 345.971721 L 194 346.063128 L 195 346.116636 L 196 346.204544 L 197 346.273729 L 198 346.320493 L 199 346.392537 L 200 346.442679 L 201 346.460069 L 202 346.487072 L 203 346.506499 L 204 346.525837 L 205 346.564086 L 206 346.580519 L 207 346.588888 L 208 346.593207 L 209 346.599762 L 210 346.597216 L 211 346.591757 L 212 346.575329 L 213 346.543394 L 214 346.505414 L 215 346.47061 L 216 346.407538 L 217 346.386111 L 218 346.335493 L 219 346.310536 L 220 346.254902 L 221 346.223673 L 222 346.173529 L 223 346.141036 L 224 346.060624 L 225 345.991698 L 226 345.876001 L 227 345.800522 L 228 345.684997 L 229 345.605513 L 230 345.497072 L 231 345.457704 L 232 345.354836 L 233 345.255038 L 234 345.209541 L 235 345.175219 L 236 345.123263 L 237 345.083616 L 238 345.048102 L 239 344.980457 L 240 344.941375 L 241 344.890894 L 242 344.841588 L 243 344.790518 L 244 344.746279 L 245 344.724259 L 246 344.708703 L 247 344.666256 L 248 344.651388 L 249 344.62866 L 250 344.608344 L 251 344.602547 L 252 344.600065 L 253 344.603122 L 254 344.614718 L 255 344.631638 L 256 344.663299 L 257 344.677382 L 258 344.730054 L 259 344.779143 L 260 344.833844 L 261 344.878192 L 262 344.948184 L 263 344.998567 L 264 345.052474 L 265 345.121913 L 266 345.179301 L 267 345.229466 L 268 345.306628 L 269 345.364818 L 270 345.425456 L 271 345.462657 L 272 345.527749 L 273 345.632879 L 274 345.693181 L 275 345.789503 L 276 345.821506 L 277 345.872523 L 278 345.989315 L 279 346.024762 L 280 346.080642 L 281 346.111018 L 282 346.199404 L 283 346.244168 L 284 346.325056 L 285 346.385202 L 286 346.448288 L 287 346.471236 L 288 346.487406 L 289 346.516335 L 290 346.546687 L 291 346.559261 L 292 346.58414 L 293 346.596224 L 294 346.599986 L 295 346.59555 L 296 346.583211 L 297 346.568798 L 298 346.552725 L 299 346.517204 L 300 346.49727 L 301 346.440681 L 302 346.373487 L 303 346.346117 L 304 346.311969 L 305 346.263289 L 306 346.215004 L 307 346.155927 L 308 346.060322 L 309 346.017182 L 310 345.967334 L 311 345.9088 L 312 345.861214 L 313 345.800086 L 314 345.744001 L 315 345.66983 L 316 345.552592 L 317 345.496868 L 318 345.388642 L 319 345.282492 L 320 345.17492 L 321 345.140412 L 322 345.037105 L 323 344.961381 L 324 344.921946 L 325 344.882562 L 326 344.86008 L 327 344.804267 L 328 344.778215 L 329 344.74798 L 330 344.697209 L 331 344.678558 L 332 344.656849 L 333 344.644203 L 334 344.62521 L 335 344.60782 L 336 344.600782 L 337 344.601806 L 338 344.60881 L 339 344.61818 L 340 344.641578 L 341 344.666661 L 342 344.67906 L 343 344.712153 L 344 344.72852 L 345 344.746925 L 346 344.796062 L 347 344.839875 L 348 344.88296 L 349 344.905901 L 350 344.946164 L 351 345.031024 L 352 345.073416 L 353 345.137802 L 354 345.182091 L 355 345.289937 L 356 345.366877 L 357 345.403319 L 358 345.458206 L 359 345.533307 L 360 345.591902 L 361 345.628477 L 362 345.740524 L 363 345.802209 L 364 345.852729 L 365 345.951514 L 366 345.989536 L 367 346.024984 L 368 346.116618 L 369 346.15989 L 370 346.213219 L 371 346.246084 L 372 346.308978 L 373 346.362832 L 374 346.419958 L 375 346.442048 L 376 346.485787 L 377 346.532881 L 378 346.549728 L 379 346.577802 L 380 346.588798 L 381 346.593367 L 382 346.599015 L 383 346.599066 L 384 346.595976 L 385 346.592463 L 386 346.586641 L 387 346.573789 L 388 346.550164 L 389 346.53528 L 390 346.511708 L 391 346.475389 L 392 346.443806 L 393 346.413913 L 394 346.335221 L 395 346.29867 L 396 346.272947 L 397 346.202274 L 398 346.111172 L 399 346.049215 L 400 346.015602 L 401 345.981102 L 402 345.883662 L 403 345.836072 L 404 345.804566 L 405 345.760881 L 406 345.690712 L 407 345.640845 L 408 345.606168 L 409 345.49652 L 410 345.463049 L 411 345.425707 L 412 345.345462 L 413 345.306968 L 414 345.265191 L 415 345.222766 L 416 345.113038 L 417 345.024753 L 418 344.950107 L 419 344.86165 L 420 344.787588 L 421 344.738423 L 422 344.682806 L 423 344.648106 L 424 344.636235 L 425 344.614012 L 426 344.602033 L 427 344.600281 L 428 344.605698 L 429 344.621896 L 430 344.638396 L 431 344.669579 L 432 344.682944 L 433 344.712587 L 434 344.77561 L 435 344.824931 L 436 344.87102 L 437 344.953247 L 438 344.99915 L 439 345.033475 L 440 345.087014 L 441 345.175901 L 442 345.207039 L 443 345.315088 L 444 345.42716 L 445 345.462598 L 446 345.547384 L 447 345.612991 L 448 345.715045 L 449 345.83126 L 450 345.871951 L 451 345.91304 L 452 345.949681 L 453 345.990677 L 454 346.066746 L 455 346.142812 L 456 346.1735 L 457 346.199991 L 458 346.256572 L 459 346.301088 L 460.8 346.331106 L 461.558162 344.6 L 461.600727 343.6 L 461.653592 342.6 L 461.684513 341.6 L 461.710788 340.6 L 461.725721 339.6 L 461.75601 338.6 L 461.777339 337.6 L 461.794228 336.6 L 461.798943 335.6 L 461.799553 334.6 L 461.797507 333.6 L 461.791646 332.6 L 461.772999 331.6 L 461.740942 330.6 L 461.694502 329.6 L 461.652556 328.6 L 461.585851 327.6 L 461.516785 326.6 L 461.46941 325.6 L 461.417891 324.6 L 461.378191 323.6 L 461.308771 322.6 L 461.24224 321.6 L 461.133331 320.6 L 461.068083 319.6 L 460.959875 318.6 L 460.898871 317.6 L 460.850186 316.6 L 460.773952 315.6 L 460.714421 314.6 L 460.639793 313.6 L 460.520966 312.6 L 460.423021 311.6 L 460.343973 310.6 L 460.298226 309.6 L 460.270954 308.6 L 460.227292 307.6 L 460.178708 306.6 L 460.146974 305.6 L 460.066744 304.6 L 460.000251 303.6 L 459.976226 302.6 L 459.915727 301.6 L 459.893495 300.6 L 459.874895 299.6 L 459.845569 298.6 L 459.829868 297.6 L 459.821569 296.6 L 459.811333 295.6 L 459.80099 294.6 L 459.801668 293.6 L 459.805448 292.6 L 459.821889 291.6 L 459.834023 290.6 L 459.844618 289.6 L 459.875995 288.6 L 459.901768 287.6 L 459.933177 286.6 L 459.955986 285.6 L 459.97358 284.6 L 460.023392 283.6 L 460.071052 282.6 L 460.142761 281.6 L 460.198524 280.6 L 460.224722 279.6 L 460.25549 278.6 L 460.345248 277.6 L 460.430042 276.6 L 460.495636 275.6 L 460.541461 274.6 L 460.584458 273.6 L 460.645971 272.6 L 460.745796 271.6 L 460.790226 270.6 L 460.840276 269.6 L 460.962117 268.6 L 461.02181 267.6 L 461.053376 266.6 L 461.085719 265.6 L 461.140279 264.6 L 461.182779 263.6 L 461.234251 262.6 L 461.322636 261.6 L 461.356833 260.6 L 461.400767 259.6 L 461.46448 258.6 L 461.539677 257.6 L 461.568491 256.6 L 461.610695 255.6 L 461.65328 254.6 L 461.670172 253.6 L 461.692653 252.6 L 461.73499 251.6 L 461.76495 250.6 L 461.783583 249.6 L 461.793375 248.6 L 461.797138 247.6 L 461.799976 246.6 L 461.798227 245.6 L 461.788871 244.6 L 461.778174 243.6 L 461.768304 242.6 L 461.749446 241.6 L 461.719107 240.6 L 461.680716 239.6 L 461.62123 238.6 L 461.577941 237.6 L 461.517203 236.6 L 461.433129 235.6 L 461.384836 234.6 L 461.341259 233.6 L 461.314378 232.6 L 461.282448 231.6 L 461.215256 230.6 L 461.134435 229.6 L 461.05889 228.6 L 461.01516 227.6 L 460.935265 226.6 L 460.873786 225.6 L 460.810161 224.6 L 460.702912 223.6 L 460.584202 222.6 L 460.542296 221.6 L 460.499342 220.6 L 460.437143 219.6 L 460.407006 218.6 L 460.374488 217.6 L 460.322553 216.6 L 460.217003 215.6 L 460.168557 214.6 L 460.122233 213.6 L 460.088417 212.6 L 460.04054 211.6 L 459.985662 210.6 L 459.961751 209.6 L 459.935714 208.6 L 459.879597 207.6 L 459.865723 206.6 L 459.839689 205.6 L 459.812943 204.6 L 459.805197 203.6 L 459.800044 202.6 L 459.806242 201.6 L 459.812549 200.6 L 459.82013 199.6 L 459.847636 198.6 L 459.891869 197.6 L 459.921407 196.6 L 459.963254 195.6 L 460.022428 194.6 L 460.045138 193.6 L 460.08177 192.6 L 460.138558 191.6 L 460.163728 190.6 L 460.246424 189.6 L 460.333356 188.6 L 460.38404 187.6 L 460.421434 186.6 L 460.505814 185.6 L 460.540325 184.6 L 460.632316 183.6 L 460.719341 182.6 L 460.842481 181.6 L 460.88035 180.6 L 460.927825 179.6 L 461.033351 178.6 L 461.130812 177.6 L 461.207449 176.6 L 461.239376 175.6 L 461.293616 174.6 L 461.332467 173.6 L 461.406172 172.6 L 461.438168 171.6 L 461.494707 170.6 L 461.530823 169.6 L 461.599425 168.6 L 461.630841 167.6 L 461.685508 166.6 L 461.704279 165.6 L 461.749908 164.6 L 461.772811 163.6 L 461.781352 162.6 L 461.788693 161.6 L 461.794988 160.6 L 461.798165 159.6 L 461.799751 158.6 L 461.798288 157.6 L 461.785334 156.6 L 461.770712 155.6 L 461.758856 154.6 L 461.740831 153.6 L 461.720453 152.6 L 461.697054 151.6 L 461.682145 150.6 L 461.627431 149.6 L 461.593834 148.6 L 461.531138 147.6 L 461.503763 146.6 L 461.459783 145.6 L 461.380836 144.6 L 461.323308 143.6 L 461.273329 142.6 L 461.201345 141.6 L 461.164813 140.6 L 461.0965 139.6 L 461.008294 138.6 L 460.886947 137.6 L 460.821266 136.6 L 460.787648 135.6 L 460.723371 134.6 L 460.6774 133.6 L 460.605243 132.6 L 460.565417 131.6 L 460.522787 130.6 L 460.416828 129.6 L 460.364043 128.6 L 460.284766 127.6 L 460.242362 126.6 L 460.210096 125.6 L 460.17523 124.6 L 460.132572 123.6 L 460.100999 122.6 L 460.03342 121.6 L 459.996535 120.6 L 459.968579 119.6 L 459.947731 118.6 L 459.922118 117.6 L 459.8845 116.6 L 459.869658 115.6 L 459.844928 114.6 L 459.826698 113.6 L 459.815291 112.6 L 459.809656 111.6 L 459.804902 110.6 L 459.800293 109.6 L 459.801966 108.6 L 459.807748 107.6 L 459.827744 106.6 L 459.839396 105.6 L 459.850385 104.6 L 459.863352 103.6 L 459.913766 102.6 L 459.934588 101.6 L 459.962535 100.6 L 460.01928 99.6 L 460.041924 98.6 L 460.093327 97.6 L 460.134463 96.6 L 460.217232 95.6 L 460.265692 94.6 L 460.317119 93.6 L 460.368279 92.6 L 460.435578 91.6 L 460.468732 90.6 L 460.53479 89.6 L 460.590975 88.6 L 460.652254 87.6 L 460.692237 86.6 L 460.78866 85.6 L 460.90042 84.6 L 460.939339 83.6 L 461.037188 82.6 L 461.071842 81.6 L 461.155524 80.6 L 461.20603 79.6 L 461.275073 78.6 L 461.376176 77.6 L 461.428622 76.6 L 461.51793 75.6 L 461.582938 74.6 L 461.624483 73.6 L 461.666823 72.6 L 461.688843 71.6 L 461.72633 70.6 L 461.743582 69.6 L 461.76699 68.6 L 461.775557 67.6 L 461.784646 66.6 L 461.791714 65.6 L 461.798741 64.6 L 461.799849 63.6 L 461.799863 62.6 L 461.797189 61.6 L 461.794163 60.6 L 461.788696 59.6 L 461.768701 58.6 L 461.75673 57.6 L 461.729611 56.6 L 461.702599 55.6 L 461.675433 54.6 L 461.620958 53.6 L 461.591342 52.6 L 461.549586 51.6 L 461.476477 50.6 L 461.433039 49.6 L 461.362348 48.6 L 461.323941 47.6 L 461.263602 46.6 L 461.232847 45.6 L 461.202349 44.6 L 461.143439 43.6 L 461.100262 42.6 L 461.05865 41.6 L 461.009535 40.6 L 460.944448 39.6 L 460.878053 38.6 L 460.75329 37.6 L 460.709475 36.6 L 460.655147 35.6 L 460.548443 34.6 L 460.505943 33.6 L 460.468449 32.6 L 460.378953 31.6 L 460.32173 30.6 L 460.252087 29.6 L 460.203068 28.6 L 460.147123 27.6 L 460.099998 26.6 L 460.06111 25.6 L 460.007418 24.6 L 459.961847 23.6 L 459.92491 22.6 L 459.902834 21.6 L 459.869951 20.6 L 459.840231 19.6 L 459.827681 18.6 L 459.815782 17.6 L 459.810664 16.6 L 459.802775 15.6 L 459.800144 14.6 L 459.800942 13.6 L 459.804183 12.6 L 459.819321 11.6 L 459.826258 10.6 L 459.842635 9.6 L 459.861048 8.6 L 459.89064 7.6 L 459.912722 6.6 L 459.970416 5.6 L 459.995607 4.6 L 460.06392 3.6 L 460.111046 2.6 L 460.148394 1.6 L 460.203603 0 L 459.8 0.506966 L 458.8 0.403856 L 457.8 0.349882 L 456.8 0.319162 L 455.8 0.263621 L 454.8 0.225886 L 453.8 0.157632 L 452.8 0.121803 L 451.8 0.052019 L 450.8 -0.007275 L 449.8 -0.045882 L 448.8 -0.079878 L 447.8 -0.122458 L 446.8 -0.169107 L 445.8 -0.223673 L 444.8 -0.309574 L 443.8 -0.35625 L 442.8 -0.413565 L 441.8 -0.443979 L 440.8 -0.52903 L 439.8 -0.562705 L 438.8 -0.650629 L 437.8 -0.705614 L 436.8 -0.744303 L 435.8 -0.814334 L 434.8 -0.84478 L 433.8 -0.902505 L 432.8 -0.919649 L 431.8 -0.944384 L 430.8 -0.959884 L 429.8 -0.983336 L 428.8 -0.99015 L 427.8 -0.994083 L 426.8 -0.997815 L 425.8 -0.999848 L 424.8 -0.991462 L 423.8 -0.975076 L 422.8 -0.948806 L 421.8 -0.935477 L 420.8 -0.905523 L 419.8 -0.871272 L 418.8 -0.850602 L 417.8 -0.80959 L 416.8 -0.736272 L 415.8 -0.713054 L 414.8 -0.672688 L 413.8 -0.645437 L 412.8 -0.564899 L 411.8 -0.511421 L 410.8 -0.43285 L 409.8 -0.384382 L 408.8 -0.270352 L 407.8 -0.169667 L 406.8 -0.085243 L 405.8 0.006297 L 404.8 0.10871 L 403.8 0.149518 L 402.8 0.192661 L 401.8 0.231962 L 400.8 0.265385 L 399.8 0.308493 L 398.8 0.414072 L 397.8 0.469773 L 396.8 0.5751 L 395.8 0.672097 L 394.8 0.695117 L 393.8 0.722104 L 392.8 0.752205 L 391.8 0.825447 L 390.8 0.862839 L 389.8 0.897798 L 388.8 0.916374 L 387.8 0.94688 L 386.8 0.959092 L 385.8 0.968868 L 384.8 0.978437 L 383.8 0.986646 L 382.8 0.997922 L 381.8 0.999784 L 380.8 0.993482 L 379.8 0.987469 L 378.8 0.982012 L 377.8 0.96182 L 376.8 0.951931 L 375.8 0.924178 L 374.8 0.905171 L 373.8 0.889772 L 372.8 0.860507 L 371.8 0.796703 L 370.8 0.74765 L 369.8 0.677461 L 368.8 0.648352 L 367.8 0.588782 L 366.8 0.541833 L 365.8 0.490711 L 364.8 0.436658 L 363.8 0.354971 L 362.8 0.276314 L 361.8 0.239654 L 360.8 0.118 L 359.8 0.039058 L 358.8 -0.025433 L 357.8 -0.071061 L 356.8 -0.18671 L 355.8 -0.234985 L 354.8 -0.270508 L 353.8 -0.314086 L 352.8 -0.349862 L 351.8 -0.420687 L 350.8 -0.457091 L 349.8 -0.554567 L 348.8 -0.623631 L 347.8 -0.689597 L 346.8 -0.754127 L 345.8 -0.777549 L 344.8 -0.804954 L 343.8 -0.853448 L 342.8 -0.883441 L 341.8 -0.915979 L 340.8 -0.930722 L 339.8 -0.944262 L 338.8 -0.967697 L 337.8 -0.980177 L 336.8 -0.987315 L 335.8 -0.992913 L 334.8 -0.998519 L 333.8 -1 L 332.8 -0.994007 L 331.8 -0.988042 L 330.8 -0.97653 L 329.8 -0.952723 L 328.8 -0.94259 L 327.8 -0.900632 L 326.8 -0.85856 L 325.8 -0.827344 L 324.8 -0.757486 L 323.8 -0.71323 L 322.8 -0.63076 L 321.8 -0.542573 L 320.8 -0.497653 L 319.8 -0.401923 L 318.8 -0.329819 L 317.8 -0.234829 L 316.8 -0.178455 L 315.8 -0.134258 L 314.8 -0.078442 L 313.8 -0.038504 L 312.8 0.036947 L 311.8 0.094942 L 310.8 0.132129 L 309.8 0.190656 L 308.8 0.293433 L 307.8 0.35016 L 306.8 0.421165 L 305.8 0.482934 L 304.8 0.520397 L 303.8 0.555683 L 302.8 0.599101 L 301.8 0.64096 L 300.8 0.668583 L 299.8 0.719698 L 298.8 0.753234 L 297.8 0.815297 L 296.8 0.834939 L 295.8 0.896712 L 294.8 0.919191 L 293.8 0.939414 L 292.8 0.960103 L 291.8 0.98653 L 290.8 0.997487 L 289.8 0.999269 L 288.8 0.996641 L 287.8 0.990091 L 286.8 0.968128 L 285.8 0.929128 L 284.8 0.908845 L 283.8 0.892196 L 282.8 0.830573 L 281.8 0.801989 L 280.8 0.778481 L 279.8 0.734033 L 278.8 0.70807 L 277.8 0.65771 L 276.8 0.581318 L 275.8 0.553797 L 274.8 0.521939 L 273.8 0.486315 L 272.8 0.398542 L 271.8 0.301531 L 270.8 0.221578 L 269.8 0.103903 L 268.8 0.031909 L 267.8 -0.072257 L 266.8 -0.183566 L 265.8 -0.278988 L 264.8 -0.373885 L 263.8 -0.440904 L 262.8 -0.501789 L 261.8 -0.54625 L 260.8 -0.581921 L 259.8 -0.661217 L 258.8 -0.691472 L 257.8 -0.765116 L 256.8 -0.797561 L 255.8 -0.842088 L 254.8 -0.863344 L 253.8 -0.891696 L 252.8 -0.920022 L 251.8 -0.954355 L 250.8 -0.967671 L 249.8 -0.984463 L 248.8 -0.995007 L 247.8 -0.998126 L 246.8 -0.999962 L 245.8 -0.994973 L 244.8 -0.989525 L 243.8 -0.97538 L 242.8 -0.940746 L 241.8 -0.921719 L 240.8 -0.879119 L 239.8 -0.861014 L 238.8 -0.816611 L 237.8 -0.794181 L 236.8 -0.753913 L 235.8 -0.721408 L 234.8 -0.658097 L 233.8 -0.569587 L 232.8 -0.483117 L 231.8 -0.403482 L 230.8 -0.349696 L 229.8 -0.289585 L 228.8 -0.218544 L 227.8 -0.098423 L 226.8 0.006039 L 225.8 0.116842 L 224.8 0.170115 L 223.8 0.243365 L 222.8 0.281948 L 221.8 0.357711 L 220.8 0.435272 L 219.8 0.521412 L 218.8 0.548855 L 217.8 0.644831 L 216.8 0.720941 L 215.8 0.771105 L 214.8 0.825458 L 213.8 0.853129 L 212.8 0.889151 L 211.8 0.920712 L 210.8 0.938819 L 209.8 0.955558 L 208.8 0.972565 L 207.8 0.989619 L 206.8 0.99403 L 205.8 0.998289 L 204.8 0.999886 L 203.8 0.998359 L 202.8 0.995935 L 201.8 0.992476 L 200.8 0.982211 L 199.8 0.962483 L 198.8 0.950784 L 197.8 0.90804 L 196.8 0.88236 L 195.8 0.838178 L 194.8 0.782063 L 193.8 0.725365 L 192.8 0.693505 L 191.8 0.656796 L 190.8 0.628663 L 189.8 0.572864 L 188.8 0.538147 L 187.8 0.46646 L 186.8 0.410402 L 185.8 0.328747 L 184.8 0.273173 L 183.8 0.188865 L 182.8 0.14624 L 181.8 0.055234 L 180.8 -0.005051 L 179.8 -0.110128 L 178.8 -0.174313 L 177.8 -0.253509 L 176.8 -0.319736 L 175.8 -0.374012 L 174.8 -0.407139 L 173.8 -0.463853 L 172.8 -0.50741 L 171.8 -0.604653 L 170.8 -0.678599 L 169.8 -0.740393 L 168.8 -0.768808 L 167.8 -0.794142 L 166.8 -0.860397 L 165.8 -0.903414 L 164.8 -0.931921 L 163.8 -0.943915 L 162.8 -0.957989 L 161.8 -0.968817 L 160.8 -0.984115 L 159.8 -0.993971 L 158.8 -0.999784 L 157.8 -0.998949 L 156.8 -0.996987 L 155.8 -0.993379 L 154.8 -0.976068 L 153.8 -0.966337 L 152.8 -0.932307 L 151.8 -0.907236 L 150.8 -0.868539 L 149.8 -0.802605 L 148.8 -0.761617 L 147.8 -0.686776 L 146.8 -0.654849 L 145.8 -0.630635 L 144.8 -0.604815 L 143.8 -0.545775 L 142.8 -0.491063 L 141.8 -0.384861 L 140.8 -0.304585 L 139.8 -0.187843 L 138.8 -0.08788 L 137.8 -0.035566 L 136.8 0.003007 L 135.8 0.039368 L 134.8 0.160354 L 133.8 0.191539 L 132.8 0.227915 L 131.8 0.290066 L 130.8 0.378077 L 129.8 0.42247 L 128.8 0.470988 L 127.8 0.569778 L 126.8 0.611246 L 125.8 0.653898 L 124.8 0.718748 L 123.8 0.785183 L 122.8 0.805272 L 121.8 0.829751 L 120.8 0.870359 L 119.8 0.894905 L 118.8 0.911852 L 117.8 0.942871 L 116.8 0.965923 L 115.8 0.985366 L 114.8 0.992773 L 113.8 0.996995 L 112.8 0.999656 L 111.8 0.999239 L 110.8 0.993894 L 109.8 0.984738 L 108.8 0.972213 L 107.8 0.945446 L 106.8 0.91655 L 105.8 0.86624 L 104.8 0.837897 L 103.8 0.782994 L 102.8 0.745187 L 101.8 0.692498 L 100.8 0.662794 L 99.8 0.631793 L 98.8 0.601321 L 97.8 0.559084 L 96.8 0.531062 L 95.8 0.433515 L 94.8 0.35707 L 93.8 0.301773 L 92.8 0.220903 L 91.8 0.143522 L 90.8 0.062112 L 89.8 0.005147 L 88.8 -0.117966 L 87.8 -0.149535 L 86.8 -0.216766 L 85.8 -0.295058 L 84.8 -0.387611 L 83.8 -0.421765 L 82.8 -0.452679 L 81.8 -0.503004 L 80.8 -0.547822 L 79.8 -0.588823 L 78.8 -0.618678 L 77.8 -0.663526 L 76.8 -0.74679 L 75.8 -0.76885 L 74.8 -0.812967 L 73.8 -0.833129 L 72.8 -0.893251 L 71.8 -0.93548 L 70.8 -0.958737 L 69.8 -0.976732 L 68.8 -0.983734 L 67.8 -0.995973 L 66.8 -0.999442 L 65.8 -0.998259 L 64.8 -0.994084 L 63.8 -0.980354 L 62.8 -0.972703 L 61.8 -0.958263 L 60.8 -0.927611 L 59.8 -0.902922 L 58.8 -0.882675 L 57.8 -0.864202 L 56.8 -0.845248 L 55.8 -0.810642 L 54.8 -0.743359 L 53.8 -0.695131 L 52.8 -0.665749 L 51.8 -0.633906 L 50.8 -0.555682 L 49.8 -0.45647 L 48.8 -0.412576 L 47.8 -0.301816 L 46.8 -0.248043 L 45.8 -0.189835 L 44.8 -0.153658 L 43.8 -0.098867 L 42.8 -0.015916 L 41.8 0.031754 L 40.8 0.120599 L 39.8 0.168247 L 38.8 0.248469 L 37.8 0.337896 L 36.8 0.382122 L 35.8 0.441179 L 34.8 0.539628 L 33.8 0.57467 L 32.8 0.620434 L 31.8 0.673635 L 30.8 0.709483 L 29.8 0.751738 L 28.8 0.793097 L 27.8 0.820445 L 26.8 0.88147 L 25.8 0.904483 L 24.8 0.919261 L 23.8 0.934284 L 22.8 0.947208 L 21.8 0.979534 L 20.8 0.996802 L 19.8 0.999844 L 18.8 0.997823 L 17.8 0.99401 L 16.8 0.978994 L 15.8 0.970072 L 14.8 0.95778 L 13.8 0.929404 L 12.8 0.901094 L 11.8 0.866107 L 10.8 0.813717 L 9.8 0.765101 L 8.8 0.721134 L 7.8 0.682742 L 6.8 0.590438 L 5.8 0.563187 L 4.8 0.517238 L 3.8 0.475854 L 2.8 0.436431 L 1.8 0.377515 L 0 0.273593 L 0.227262 1 L 0.140289 2 L 0.091558 3 L 0.053928 4 L 0.017733 5 L -0.06793 6 L -0.161753 7 L -0.273189 8 L -0.360274 9 L -0.40709 10 L -0.463838 11 L -0.531601 12 L -0.573508 13 L -0.625352 14 L -0.650645 15 L -0.724163 16 L -0.770317 17 L -0.791479 18 L -0.851149 19 L -0.887991 20 L -0.917061 21 L -0.941292 22 L -0.951546 23 L -0.981839 24 L -0.994579 25 L -0.999784 26 L -0.999825 27 L -0.998417 28 L -0.992654 29 L -0.986301 30 L -0.967662 31 L -0.943214 32 L -0.912437 33 L -0.895086 34 L -0.880479 35 L -0.851999 36 L -0.833049 37 L -0.804776 38 L -0.736949 39 L -0.694852 40 L -0.659088 41 L -0.608192 42 L -0.546144 43 L -0.469078 44 L -0.390646 45 L -0.314256 46 L -0.272519 47 L -0.174586 48 L -0.104796 49 L -0.033939 50 L 0.084549 51 L 0.122597 52 L 0.158643 53 L 0.20132 54 L 0.299241 55 L 0.371531 56 L 0.414118 57 L 0.451421 58 L 0.546295 59 L 0.588994 60 L 0.621715 61 L 0.647784 62 L 0.677809 63 L 0.707013 64 L 0.742447 65 L 0.763133 66 L 0.785911 67 L 0.848282 68 L 0.876933 69 L 0.89743 70 L 0.932584 71 L 0.952705 72 L 0.963835 73 L 0.983785 74 L 0.997162 75 L 0.998974 76 L 0.993744 77 L 0.987133 78 L 0.961107 79 L 0.93948 80 L 0.917584 81 L 0.899066 82 L 0.868853 83 L 0.826455 84 L 0.799415 85 L 0.778893 86 L 0.743514 87 L 0.655618 88 L 0.618638 89 L 0.545793 90 L 0.443104 91 L 0.409892 92 L 0.309442 93 L 0.277702 94 L 0.234758 95 L 0.200953 96 L 0.120665 97 L 0.086322 98 L 0.0144 99 L -0.061467 100 L -0.117562 101 L -0.207304 102 L -0.24726 103 L -0.314957 104 L -0.42911 105 L -0.460269 106 L -0.525752 107 L -0.557786 108 L -0.642979 109 L -0.673037 110 L -0.719408 111 L -0.749116 112 L -0.778759 113 L -0.843855 114 L -0.877651 115 L -0.902804 116 L -0.918897 117 L -0.955058 118 L -0.973964 119 L -0.984187 120 L -0.992492 121 L -0.999215 122 L -0.996501 123 L -0.988797 124 L -0.971166 125 L -0.940938 126 L -0.912341 127 L -0.885031 128 L -0.825603 129 L -0.77009 130 L -0.688452 131 L -0.647196 132 L -0.60259 133 L -0.511042 134 L -0.430427 135 L -0.384469 136 L -0.292923 137 L -0.225967 138 L -0.179248 139 L -0.136118 140 L -0.077875 141 L -0.030604 142 L 0.026452 143 L 0.080989 144 L 0.196427 145 L 0.315576 146 L 0.370627 147 L 0.40698 148 L 0.502034 149 L 0.546466 150 L 0.575573 151 L 0.667237 152 L 0.714029 153 L 0.749742 154 L 0.795559 155 L 0.859505 156 L 0.892455 157 L 0.917515 158 L 0.933607 159 L 0.970088 160 L 0.979122 161 L 0.985274 162 L 0.990848 163 L 0.99806 164 L 0.99889 165 L 0.994277 166 L 0.981883 167 L 0.973583 168 L 0.937803 169 L 0.919049 170 L 0.901448 171 L 0.87707 172 L 0.844234 173 L 0.771924 174 L 0.735339 175 L 0.713128 176 L 0.683072 177 L 0.643552 178 L 0.614091 179 L 0.569454 180 L 0.500184 181 L 0.392301 182 L 0.355195 183 L 0.247165 184 L 0.140245 185 L 0.103559 186 L 0.051805 187 L -0.035129 188 L -0.106027 189 L -0.227181 190 L -0.260107 191 L -0.313632 192 L -0.359984 193 L -0.401339 194 L -0.450067 195 L -0.490327 196 L -0.533979 197 L -0.560575 198 L -0.651745 199 L -0.691652 200 L -0.720319 201 L -0.762616 202 L -0.811738 203 L -0.865675 204 L -0.918013 205 L -0.952001 206 L -0.967156 207 L -0.980387 208 L -0.992416 209 L -0.998222 210 L -0.99846 211 L -0.995029 212 L -0.978361 213 L -0.950969 214 L -0.910428 215 L -0.890133 216 L -0.872536 217 L -0.847806 218 L -0.794595 219 L -0.753623 220 L -0.693228 221 L -0.609661 222 L -0.563669 223 L -0.532753 224 L -0.502298 225 L -0.455614 226 L -0.387673 227 L -0.355756 228 L -0.30615 229 L -0.205734 230 L -0.170513 231 L -0.129026 232 L -0.0754 233 L -0.035334 234 L 0.07453 235 L 0.195709 236 L 0.233871 237 L 0.303602 238 L 0.362359 239 L 0.415477 240 L 0.479944 241 L 0.522985 242 L 0.587131 243 L 0.631929 244 L 0.71055 245 L 0.733761 246 L 0.756219 247 L 0.826066 248 L 0.846169 249 L 0.872053 250 L 0.895656 251 L 0.909427 252 L 0.933238 253 L 0.968289 254 L 0.987905 255 L 0.997925 256 L 0.999511 257 L 0.997397 258 L 0.994191 259 L 0.987806 260 L 0.972822 261 L 0.963505 262 L 0.943913 263 L 0.912031 264 L 0.858743 265 L 0.824485 266 L 0.803278 267 L 0.770858 268 L 0.745139 269 L 0.704247 270 L 0.679944 271 L 0.652386 272 L 0.613312 273 L 0.574818 274 L 0.521172 275 L 0.478431 276 L 0.446006 277 L 0.408082 278 L 0.378531 279 L 0.304491 280 L 0.26975 281 L 0.198648 282 L 0.140692 283 L 0.106477 284 L 0.001931 285 L -0.031948 286 L -0.139586 287 L -0.197401 288 L -0.263521 289 L -0.338446 290 L -0.397233 291 L -0.504686 292 L -0.600611 293 L -0.660743 294 L -0.694963 295 L -0.772666 296 L -0.810252 297 L -0.853431 298 L -0.881952 299 L -0.917155 300 L -0.941985 301 L -0.967909 302 L -0.983386 303 L -0.988682 304 L -0.999195 305 L -0.999894 306 L -0.998307 307 L -0.983759 308 L -0.976299 309 L -0.949036 310 L -0.904736 311 L -0.887316 312 L -0.847912 313 L -0.811558 314 L -0.773772 315 L -0.719976 316 L -0.6736 317 L -0.625248 318 L -0.57127 319 L -0.507815 320 L -0.41649 321 L -0.374633 322 L -0.343546 323 L -0.27172 324 L -0.238363 325 L -0.204546 326 L -0.16887 327 L -0.085534 328 L -0.053624 329 L 0.040791 330 L 0.163353 331 L 0.248217 332 L 0.307634 333 L 0.341295 334 L 0.436499 335 L 0.466063 336 L 0.500969 337 L 0.532344 338 L 0.629809 339 L 0.655764 340 L 0.706154 341 L 0.736458 342 L 0.792812 343 L 0.811609 344 L 0.857562 345.6 z " + style="fill: #ffffff; stroke: #ffffff; stroke-width: 4; stroke-linejoin: miter" + id="path1" /> + <path + d="M 0 345.6 L 1 345.631436 L 2 345.668377 L 3 345.766123 L 4 345.798645 L 5 345.87227 L 6 345.910835 L 7 345.946248 L 8 346.003888 L 9 346.074274 L 10 346.126239 L 11 346.185328 L 12 346.273649 L 13 346.319794 L 14 346.362205 L 15 346.392697 L 16 346.418742 L 17 346.439942 L 18 346.494243 L 19 346.522181 L 20 346.551905 L 21 346.5773 L 22 346.5885 L 23 346.598624 L 24 346.59842 L 25 346.58891 L 26 346.577256 L 27 346.546227 L 28 346.535059 L 29 346.504942 L 30 346.445165 L 31 346.407973 L 32 346.368877 L 33 346.326437 L 34 346.293672 L 35 346.226246 L 36 346.18712 L 37 346.144445 L 38 346.073865 L 39 346.037474 L 40 345.979071 L 41 345.868118 L 42 345.79746 L 43 345.68452 L 44 345.638747 L 45 345.577464 L 46 345.528965 L 47 345.448142 L 48 345.329623 L 49 345.259412 L 50 345.17615 L 51 345.143008 L 52 345.091771 L 53 345.023372 L 54 344.957157 L 55 344.88024 L 56 344.852924 L 57 344.826447 L 58 344.803796 L 59 344.784265 L 60 344.757871 L 61 344.7081 L 62 344.673027 L 63 344.637161 L 64 344.621794 L 65 344.606025 L 66 344.602612 L 67 344.600195 L 68 344.600681 L 69 344.60261 L 70 344.615867 L 71 344.624258 L 72 344.645794 L 73 344.668827 L 74 344.68606 L 75 344.704523 L 76 344.724975 L 77 344.741575 L 78 344.804354 L 79 344.879619 L 80 344.912258 L 81 344.979822 L 82 345.033869 L 83 345.067573 L 84 345.157699 L 85 345.186234 L 86 345.21772 L 87 345.248731 L 88 345.303539 L 89 345.368126 L 90 345.406322 L 91 345.502256 L 92 345.551514 L 93 345.595583 L 94 345.635707 L 95 345.744074 L 96 345.785702 L 97 345.847844 L 98 345.917806 L 99 346.02231 L 100 346.059298 L 101 346.105175 L 102 346.17367 L 103 346.222416 L 104 346.300013 L 105 346.330554 L 106 346.400068 L 107 346.424041 L 108 346.452663 L 109 346.494456 L 110 346.516032 L 111 346.52998 L 112 346.556702 L 113 346.566012 L 114 346.578459 L 115 346.589514 L 116 346.595178 L 117 346.599942 L 118 346.594394 L 119 346.581106 L 120 346.573589 L 121 346.548804 L 122 346.525235 L 123 346.489055 L 124 346.463093 L 125 346.440771 L 126 346.372011 L 127 346.297476 L 128 346.203497 L 129 346.152445 L 130 346.098511 L 131 346.06326 L 132 345.957172 L 133 345.904908 L 134 345.868001 L 135 345.83697 L 136 345.775815 L 137 345.708395 L 138 345.659489 L 139 345.594297 L 140 345.556109 L 141 345.514113 L 142 345.472096 L 143 345.41258 L 144 345.29942 L 145 345.247169 L 146 345.207751 L 147 345.16065 L 148 345.10387 L 149 345.071207 L 150 345.035029 L 151 345.002939 L 152 344.968659 L 153 344.910281 L 154 344.865096 L 155 344.835472 L 156 344.785086 L 157 344.759889 L 158 344.738838 L 159 344.70387 L 160 344.67958 L 161 344.665513 L 162 344.646571 L 163 344.63091 L 164 344.618358 L 165 344.612522 L 166 344.60564 L 167 344.600466 L 168 344.602249 L 169 344.604974 L 170 344.616128 L 171 344.644363 L 172 344.688151 L 173 344.70884 L 174 344.749813 L 175 344.789888 L 176 344.808998 L 177 344.831507 L 178 344.898158 L 179 344.947868 L 180 345.021574 L 181 345.052888 L 182 345.12951 L 183 345.167808 L 184 345.241925 L 185 345.345983 L 186 345.415814 L 187 345.521048 L 188 345.576063 L 189 345.699538 L 190 345.770097 L 191 345.885936 L 192 345.936117 L 193 345.971721 L 194 346.063128 L 195 346.116636 L 196 346.204544 L 197 346.273729 L 198 346.320493 L 199 346.392537 L 200 346.442679 L 201 346.460069 L 202 346.487072 L 203 346.506499 L 204 346.525837 L 205 346.564086 L 206 346.580519 L 207 346.588888 L 208 346.593207 L 209 346.599762 L 210 346.597216 L 211 346.591757 L 212 346.575329 L 213 346.543394 L 214 346.505414 L 215 346.47061 L 216 346.407538 L 217 346.386111 L 218 346.335493 L 219 346.310536 L 220 346.254902 L 221 346.223673 L 222 346.173529 L 223 346.141036 L 224 346.060624 L 225 345.991698 L 226 345.876001 L 227 345.800522 L 228 345.684997 L 229 345.605513 L 230 345.497072 L 231 345.457704 L 232 345.354836 L 233 345.255038 L 234 345.209541 L 235 345.175219 L 236 345.123263 L 237 345.083616 L 238 345.048102 L 239 344.980457 L 240 344.941375 L 241 344.890894 L 242 344.841588 L 243 344.790518 L 244 344.746279 L 245 344.724259 L 246 344.708703 L 247 344.666256 L 248 344.651388 L 249 344.62866 L 250 344.608344 L 251 344.602547 L 252 344.600065 L 253 344.603122 L 254 344.614718 L 255 344.631638 L 256 344.663299 L 257 344.677382 L 258 344.730054 L 259 344.779143 L 260 344.833844 L 261 344.878192 L 262 344.948184 L 263 344.998567 L 264 345.052474 L 265 345.121913 L 266 345.179301 L 267 345.229466 L 268 345.306628 L 269 345.364818 L 270 345.425456 L 271 345.462657 L 272 345.527749 L 273 345.632879 L 274 345.693181 L 275 345.789503 L 276 345.821506 L 277 345.872523 L 278 345.989315 L 279 346.024762 L 280 346.080642 L 281 346.111018 L 282 346.199404 L 283 346.244168 L 284 346.325056 L 285 346.385202 L 286 346.448288 L 287 346.471236 L 288 346.487406 L 289 346.516335 L 290 346.546687 L 291 346.559261 L 292 346.58414 L 293 346.596224 L 294 346.599986 L 295 346.59555 L 296 346.583211 L 297 346.568798 L 298 346.552725 L 299 346.517204 L 300 346.49727 L 301 346.440681 L 302 346.373487 L 303 346.346117 L 304 346.311969 L 305 346.263289 L 306 346.215004 L 307 346.155927 L 308 346.060322 L 309 346.017182 L 310 345.967334 L 311 345.9088 L 312 345.861214 L 313 345.800086 L 314 345.744001 L 315 345.66983 L 316 345.552592 L 317 345.496868 L 318 345.388642 L 319 345.282492 L 320 345.17492 L 321 345.140412 L 322 345.037105 L 323 344.961381 L 324 344.921946 L 325 344.882562 L 326 344.86008 L 327 344.804267 L 328 344.778215 L 329 344.74798 L 330 344.697209 L 331 344.678558 L 332 344.656849 L 333 344.644203 L 334 344.62521 L 335 344.60782 L 336 344.600782 L 337 344.601806 L 338 344.60881 L 339 344.61818 L 340 344.641578 L 341 344.666661 L 342 344.67906 L 343 344.712153 L 344 344.72852 L 345 344.746925 L 346 344.796062 L 347 344.839875 L 348 344.88296 L 349 344.905901 L 350 344.946164 L 351 345.031024 L 352 345.073416 L 353 345.137802 L 354 345.182091 L 355 345.289937 L 356 345.366877 L 357 345.403319 L 358 345.458206 L 359 345.533307 L 360 345.591902 L 361 345.628477 L 362 345.740524 L 363 345.802209 L 364 345.852729 L 365 345.951514 L 366 345.989536 L 367 346.024984 L 368 346.116618 L 369 346.15989 L 370 346.213219 L 371 346.246084 L 372 346.308978 L 373 346.362832 L 374 346.419958 L 375 346.442048 L 376 346.485787 L 377 346.532881 L 378 346.549728 L 379 346.577802 L 380 346.588798 L 381 346.593367 L 382 346.599015 L 383 346.599066 L 384 346.595976 L 385 346.592463 L 386 346.586641 L 387 346.573789 L 388 346.550164 L 389 346.53528 L 390 346.511708 L 391 346.475389 L 392 346.443806 L 393 346.413913 L 394 346.335221 L 395 346.29867 L 396 346.272947 L 397 346.202274 L 398 346.111172 L 399 346.049215 L 400 346.015602 L 401 345.981102 L 402 345.883662 L 403 345.836072 L 404 345.804566 L 405 345.760881 L 406 345.690712 L 407 345.640845 L 408 345.606168 L 409 345.49652 L 410 345.463049 L 411 345.425707 L 412 345.345462 L 413 345.306968 L 414 345.265191 L 415 345.222766 L 416 345.113038 L 417 345.024753 L 418 344.950107 L 419 344.86165 L 420 344.787588 L 421 344.738423 L 422 344.682806 L 423 344.648106 L 424 344.636235 L 425 344.614012 L 426 344.602033 L 427 344.600281 L 428 344.605698 L 429 344.621896 L 430 344.638396 L 431 344.669579 L 432 344.682944 L 433 344.712587 L 434 344.77561 L 435 344.824931 L 436 344.87102 L 437 344.953247 L 438 344.99915 L 439 345.033475 L 440 345.087014 L 441 345.175901 L 442 345.207039 L 443 345.315088 L 444 345.42716 L 445 345.462598 L 446 345.547384 L 447 345.612991 L 448 345.715045 L 449 345.83126 L 450 345.871951 L 451 345.91304 L 452 345.949681 L 453 345.990677 L 454 346.066746 L 455 346.142812 L 456 346.1735 L 457 346.199991 L 458 346.256572 L 459 346.301088 L 460.8 346.331106 L 461.558162 344.6 L 461.600727 343.6 L 461.653592 342.6 L 461.684513 341.6 L 461.710788 340.6 L 461.725721 339.6 L 461.75601 338.6 L 461.777339 337.6 L 461.794228 336.6 L 461.798943 335.6 L 461.799553 334.6 L 461.797507 333.6 L 461.791646 332.6 L 461.772999 331.6 L 461.740942 330.6 L 461.694502 329.6 L 461.652556 328.6 L 461.585851 327.6 L 461.516785 326.6 L 461.46941 325.6 L 461.417891 324.6 L 461.378191 323.6 L 461.308771 322.6 L 461.24224 321.6 L 461.133331 320.6 L 461.068083 319.6 L 460.959875 318.6 L 460.898871 317.6 L 460.850186 316.6 L 460.773952 315.6 L 460.714421 314.6 L 460.639793 313.6 L 460.520966 312.6 L 460.423021 311.6 L 460.343973 310.6 L 460.298226 309.6 L 460.270954 308.6 L 460.227292 307.6 L 460.178708 306.6 L 460.146974 305.6 L 460.066744 304.6 L 460.000251 303.6 L 459.976226 302.6 L 459.915727 301.6 L 459.893495 300.6 L 459.874895 299.6 L 459.845569 298.6 L 459.829868 297.6 L 459.821569 296.6 L 459.811333 295.6 L 459.80099 294.6 L 459.801668 293.6 L 459.805448 292.6 L 459.821889 291.6 L 459.834023 290.6 L 459.844618 289.6 L 459.875995 288.6 L 459.901768 287.6 L 459.933177 286.6 L 459.955986 285.6 L 459.97358 284.6 L 460.023392 283.6 L 460.071052 282.6 L 460.142761 281.6 L 460.198524 280.6 L 460.224722 279.6 L 460.25549 278.6 L 460.345248 277.6 L 460.430042 276.6 L 460.495636 275.6 L 460.541461 274.6 L 460.584458 273.6 L 460.645971 272.6 L 460.745796 271.6 L 460.790226 270.6 L 460.840276 269.6 L 460.962117 268.6 L 461.02181 267.6 L 461.053376 266.6 L 461.085719 265.6 L 461.140279 264.6 L 461.182779 263.6 L 461.234251 262.6 L 461.322636 261.6 L 461.356833 260.6 L 461.400767 259.6 L 461.46448 258.6 L 461.539677 257.6 L 461.568491 256.6 L 461.610695 255.6 L 461.65328 254.6 L 461.670172 253.6 L 461.692653 252.6 L 461.73499 251.6 L 461.76495 250.6 L 461.783583 249.6 L 461.793375 248.6 L 461.797138 247.6 L 461.799976 246.6 L 461.798227 245.6 L 461.788871 244.6 L 461.778174 243.6 L 461.768304 242.6 L 461.749446 241.6 L 461.719107 240.6 L 461.680716 239.6 L 461.62123 238.6 L 461.577941 237.6 L 461.517203 236.6 L 461.433129 235.6 L 461.384836 234.6 L 461.341259 233.6 L 461.314378 232.6 L 461.282448 231.6 L 461.215256 230.6 L 461.134435 229.6 L 461.05889 228.6 L 461.01516 227.6 L 460.935265 226.6 L 460.873786 225.6 L 460.810161 224.6 L 460.702912 223.6 L 460.584202 222.6 L 460.542296 221.6 L 460.499342 220.6 L 460.437143 219.6 L 460.407006 218.6 L 460.374488 217.6 L 460.322553 216.6 L 460.217003 215.6 L 460.168557 214.6 L 460.122233 213.6 L 460.088417 212.6 L 460.04054 211.6 L 459.985662 210.6 L 459.961751 209.6 L 459.935714 208.6 L 459.879597 207.6 L 459.865723 206.6 L 459.839689 205.6 L 459.812943 204.6 L 459.805197 203.6 L 459.800044 202.6 L 459.806242 201.6 L 459.812549 200.6 L 459.82013 199.6 L 459.847636 198.6 L 459.891869 197.6 L 459.921407 196.6 L 459.963254 195.6 L 460.022428 194.6 L 460.045138 193.6 L 460.08177 192.6 L 460.138558 191.6 L 460.163728 190.6 L 460.246424 189.6 L 460.333356 188.6 L 460.38404 187.6 L 460.421434 186.6 L 460.505814 185.6 L 460.540325 184.6 L 460.632316 183.6 L 460.719341 182.6 L 460.842481 181.6 L 460.88035 180.6 L 460.927825 179.6 L 461.033351 178.6 L 461.130812 177.6 L 461.207449 176.6 L 461.239376 175.6 L 461.293616 174.6 L 461.332467 173.6 L 461.406172 172.6 L 461.438168 171.6 L 461.494707 170.6 L 461.530823 169.6 L 461.599425 168.6 L 461.630841 167.6 L 461.685508 166.6 L 461.704279 165.6 L 461.749908 164.6 L 461.772811 163.6 L 461.781352 162.6 L 461.788693 161.6 L 461.794988 160.6 L 461.798165 159.6 L 461.799751 158.6 L 461.798288 157.6 L 461.785334 156.6 L 461.770712 155.6 L 461.758856 154.6 L 461.740831 153.6 L 461.720453 152.6 L 461.697054 151.6 L 461.682145 150.6 L 461.627431 149.6 L 461.593834 148.6 L 461.531138 147.6 L 461.503763 146.6 L 461.459783 145.6 L 461.380836 144.6 L 461.323308 143.6 L 461.273329 142.6 L 461.201345 141.6 L 461.164813 140.6 L 461.0965 139.6 L 461.008294 138.6 L 460.886947 137.6 L 460.821266 136.6 L 460.787648 135.6 L 460.723371 134.6 L 460.6774 133.6 L 460.605243 132.6 L 460.565417 131.6 L 460.522787 130.6 L 460.416828 129.6 L 460.364043 128.6 L 460.284766 127.6 L 460.242362 126.6 L 460.210096 125.6 L 460.17523 124.6 L 460.132572 123.6 L 460.100999 122.6 L 460.03342 121.6 L 459.996535 120.6 L 459.968579 119.6 L 459.947731 118.6 L 459.922118 117.6 L 459.8845 116.6 L 459.869658 115.6 L 459.844928 114.6 L 459.826698 113.6 L 459.815291 112.6 L 459.809656 111.6 L 459.804902 110.6 L 459.800293 109.6 L 459.801966 108.6 L 459.807748 107.6 L 459.827744 106.6 L 459.839396 105.6 L 459.850385 104.6 L 459.863352 103.6 L 459.913766 102.6 L 459.934588 101.6 L 459.962535 100.6 L 460.01928 99.6 L 460.041924 98.6 L 460.093327 97.6 L 460.134463 96.6 L 460.217232 95.6 L 460.265692 94.6 L 460.317119 93.6 L 460.368279 92.6 L 460.435578 91.6 L 460.468732 90.6 L 460.53479 89.6 L 460.590975 88.6 L 460.652254 87.6 L 460.692237 86.6 L 460.78866 85.6 L 460.90042 84.6 L 460.939339 83.6 L 461.037188 82.6 L 461.071842 81.6 L 461.155524 80.6 L 461.20603 79.6 L 461.275073 78.6 L 461.376176 77.6 L 461.428622 76.6 L 461.51793 75.6 L 461.582938 74.6 L 461.624483 73.6 L 461.666823 72.6 L 461.688843 71.6 L 461.72633 70.6 L 461.743582 69.6 L 461.76699 68.6 L 461.775557 67.6 L 461.784646 66.6 L 461.791714 65.6 L 461.798741 64.6 L 461.799849 63.6 L 461.799863 62.6 L 461.797189 61.6 L 461.794163 60.6 L 461.788696 59.6 L 461.768701 58.6 L 461.75673 57.6 L 461.729611 56.6 L 461.702599 55.6 L 461.675433 54.6 L 461.620958 53.6 L 461.591342 52.6 L 461.549586 51.6 L 461.476477 50.6 L 461.433039 49.6 L 461.362348 48.6 L 461.323941 47.6 L 461.263602 46.6 L 461.232847 45.6 L 461.202349 44.6 L 461.143439 43.6 L 461.100262 42.6 L 461.05865 41.6 L 461.009535 40.6 L 460.944448 39.6 L 460.878053 38.6 L 460.75329 37.6 L 460.709475 36.6 L 460.655147 35.6 L 460.548443 34.6 L 460.505943 33.6 L 460.468449 32.6 L 460.378953 31.6 L 460.32173 30.6 L 460.252087 29.6 L 460.203068 28.6 L 460.147123 27.6 L 460.099998 26.6 L 460.06111 25.6 L 460.007418 24.6 L 459.961847 23.6 L 459.92491 22.6 L 459.902834 21.6 L 459.869951 20.6 L 459.840231 19.6 L 459.827681 18.6 L 459.815782 17.6 L 459.810664 16.6 L 459.802775 15.6 L 459.800144 14.6 L 459.800942 13.6 L 459.804183 12.6 L 459.819321 11.6 L 459.826258 10.6 L 459.842635 9.6 L 459.861048 8.6 L 459.89064 7.6 L 459.912722 6.6 L 459.970416 5.6 L 459.995607 4.6 L 460.06392 3.6 L 460.111046 2.6 L 460.148394 1.6 L 460.203603 0 L 459.8 0.506966 L 458.8 0.403856 L 457.8 0.349882 L 456.8 0.319162 L 455.8 0.263621 L 454.8 0.225886 L 453.8 0.157632 L 452.8 0.121803 L 451.8 0.052019 L 450.8 -0.007275 L 449.8 -0.045882 L 448.8 -0.079878 L 447.8 -0.122458 L 446.8 -0.169107 L 445.8 -0.223673 L 444.8 -0.309574 L 443.8 -0.35625 L 442.8 -0.413565 L 441.8 -0.443979 L 440.8 -0.52903 L 439.8 -0.562705 L 438.8 -0.650629 L 437.8 -0.705614 L 436.8 -0.744303 L 435.8 -0.814334 L 434.8 -0.84478 L 433.8 -0.902505 L 432.8 -0.919649 L 431.8 -0.944384 L 430.8 -0.959884 L 429.8 -0.983336 L 428.8 -0.99015 L 427.8 -0.994083 L 426.8 -0.997815 L 425.8 -0.999848 L 424.8 -0.991462 L 423.8 -0.975076 L 422.8 -0.948806 L 421.8 -0.935477 L 420.8 -0.905523 L 419.8 -0.871272 L 418.8 -0.850602 L 417.8 -0.80959 L 416.8 -0.736272 L 415.8 -0.713054 L 414.8 -0.672688 L 413.8 -0.645437 L 412.8 -0.564899 L 411.8 -0.511421 L 410.8 -0.43285 L 409.8 -0.384382 L 408.8 -0.270352 L 407.8 -0.169667 L 406.8 -0.085243 L 405.8 0.006297 L 404.8 0.10871 L 403.8 0.149518 L 402.8 0.192661 L 401.8 0.231962 L 400.8 0.265385 L 399.8 0.308493 L 398.8 0.414072 L 397.8 0.469773 L 396.8 0.5751 L 395.8 0.672097 L 394.8 0.695117 L 393.8 0.722104 L 392.8 0.752205 L 391.8 0.825447 L 390.8 0.862839 L 389.8 0.897798 L 388.8 0.916374 L 387.8 0.94688 L 386.8 0.959092 L 385.8 0.968868 L 384.8 0.978437 L 383.8 0.986646 L 382.8 0.997922 L 381.8 0.999784 L 380.8 0.993482 L 379.8 0.987469 L 378.8 0.982012 L 377.8 0.96182 L 376.8 0.951931 L 375.8 0.924178 L 374.8 0.905171 L 373.8 0.889772 L 372.8 0.860507 L 371.8 0.796703 L 370.8 0.74765 L 369.8 0.677461 L 368.8 0.648352 L 367.8 0.588782 L 366.8 0.541833 L 365.8 0.490711 L 364.8 0.436658 L 363.8 0.354971 L 362.8 0.276314 L 361.8 0.239654 L 360.8 0.118 L 359.8 0.039058 L 358.8 -0.025433 L 357.8 -0.071061 L 356.8 -0.18671 L 355.8 -0.234985 L 354.8 -0.270508 L 353.8 -0.314086 L 352.8 -0.349862 L 351.8 -0.420687 L 350.8 -0.457091 L 349.8 -0.554567 L 348.8 -0.623631 L 347.8 -0.689597 L 346.8 -0.754127 L 345.8 -0.777549 L 344.8 -0.804954 L 343.8 -0.853448 L 342.8 -0.883441 L 341.8 -0.915979 L 340.8 -0.930722 L 339.8 -0.944262 L 338.8 -0.967697 L 337.8 -0.980177 L 336.8 -0.987315 L 335.8 -0.992913 L 334.8 -0.998519 L 333.8 -1 L 332.8 -0.994007 L 331.8 -0.988042 L 330.8 -0.97653 L 329.8 -0.952723 L 328.8 -0.94259 L 327.8 -0.900632 L 326.8 -0.85856 L 325.8 -0.827344 L 324.8 -0.757486 L 323.8 -0.71323 L 322.8 -0.63076 L 321.8 -0.542573 L 320.8 -0.497653 L 319.8 -0.401923 L 318.8 -0.329819 L 317.8 -0.234829 L 316.8 -0.178455 L 315.8 -0.134258 L 314.8 -0.078442 L 313.8 -0.038504 L 312.8 0.036947 L 311.8 0.094942 L 310.8 0.132129 L 309.8 0.190656 L 308.8 0.293433 L 307.8 0.35016 L 306.8 0.421165 L 305.8 0.482934 L 304.8 0.520397 L 303.8 0.555683 L 302.8 0.599101 L 301.8 0.64096 L 300.8 0.668583 L 299.8 0.719698 L 298.8 0.753234 L 297.8 0.815297 L 296.8 0.834939 L 295.8 0.896712 L 294.8 0.919191 L 293.8 0.939414 L 292.8 0.960103 L 291.8 0.98653 L 290.8 0.997487 L 289.8 0.999269 L 288.8 0.996641 L 287.8 0.990091 L 286.8 0.968128 L 285.8 0.929128 L 284.8 0.908845 L 283.8 0.892196 L 282.8 0.830573 L 281.8 0.801989 L 280.8 0.778481 L 279.8 0.734033 L 278.8 0.70807 L 277.8 0.65771 L 276.8 0.581318 L 275.8 0.553797 L 274.8 0.521939 L 273.8 0.486315 L 272.8 0.398542 L 271.8 0.301531 L 270.8 0.221578 L 269.8 0.103903 L 268.8 0.031909 L 267.8 -0.072257 L 266.8 -0.183566 L 265.8 -0.278988 L 264.8 -0.373885 L 263.8 -0.440904 L 262.8 -0.501789 L 261.8 -0.54625 L 260.8 -0.581921 L 259.8 -0.661217 L 258.8 -0.691472 L 257.8 -0.765116 L 256.8 -0.797561 L 255.8 -0.842088 L 254.8 -0.863344 L 253.8 -0.891696 L 252.8 -0.920022 L 251.8 -0.954355 L 250.8 -0.967671 L 249.8 -0.984463 L 248.8 -0.995007 L 247.8 -0.998126 L 246.8 -0.999962 L 245.8 -0.994973 L 244.8 -0.989525 L 243.8 -0.97538 L 242.8 -0.940746 L 241.8 -0.921719 L 240.8 -0.879119 L 239.8 -0.861014 L 238.8 -0.816611 L 237.8 -0.794181 L 236.8 -0.753913 L 235.8 -0.721408 L 234.8 -0.658097 L 233.8 -0.569587 L 232.8 -0.483117 L 231.8 -0.403482 L 230.8 -0.349696 L 229.8 -0.289585 L 228.8 -0.218544 L 227.8 -0.098423 L 226.8 0.006039 L 225.8 0.116842 L 224.8 0.170115 L 223.8 0.243365 L 222.8 0.281948 L 221.8 0.357711 L 220.8 0.435272 L 219.8 0.521412 L 218.8 0.548855 L 217.8 0.644831 L 216.8 0.720941 L 215.8 0.771105 L 214.8 0.825458 L 213.8 0.853129 L 212.8 0.889151 L 211.8 0.920712 L 210.8 0.938819 L 209.8 0.955558 L 208.8 0.972565 L 207.8 0.989619 L 206.8 0.99403 L 205.8 0.998289 L 204.8 0.999886 L 203.8 0.998359 L 202.8 0.995935 L 201.8 0.992476 L 200.8 0.982211 L 199.8 0.962483 L 198.8 0.950784 L 197.8 0.90804 L 196.8 0.88236 L 195.8 0.838178 L 194.8 0.782063 L 193.8 0.725365 L 192.8 0.693505 L 191.8 0.656796 L 190.8 0.628663 L 189.8 0.572864 L 188.8 0.538147 L 187.8 0.46646 L 186.8 0.410402 L 185.8 0.328747 L 184.8 0.273173 L 183.8 0.188865 L 182.8 0.14624 L 181.8 0.055234 L 180.8 -0.005051 L 179.8 -0.110128 L 178.8 -0.174313 L 177.8 -0.253509 L 176.8 -0.319736 L 175.8 -0.374012 L 174.8 -0.407139 L 173.8 -0.463853 L 172.8 -0.50741 L 171.8 -0.604653 L 170.8 -0.678599 L 169.8 -0.740393 L 168.8 -0.768808 L 167.8 -0.794142 L 166.8 -0.860397 L 165.8 -0.903414 L 164.8 -0.931921 L 163.8 -0.943915 L 162.8 -0.957989 L 161.8 -0.968817 L 160.8 -0.984115 L 159.8 -0.993971 L 158.8 -0.999784 L 157.8 -0.998949 L 156.8 -0.996987 L 155.8 -0.993379 L 154.8 -0.976068 L 153.8 -0.966337 L 152.8 -0.932307 L 151.8 -0.907236 L 150.8 -0.868539 L 149.8 -0.802605 L 148.8 -0.761617 L 147.8 -0.686776 L 146.8 -0.654849 L 145.8 -0.630635 L 144.8 -0.604815 L 143.8 -0.545775 L 142.8 -0.491063 L 141.8 -0.384861 L 140.8 -0.304585 L 139.8 -0.187843 L 138.8 -0.08788 L 137.8 -0.035566 L 136.8 0.003007 L 135.8 0.039368 L 134.8 0.160354 L 133.8 0.191539 L 132.8 0.227915 L 131.8 0.290066 L 130.8 0.378077 L 129.8 0.42247 L 128.8 0.470988 L 127.8 0.569778 L 126.8 0.611246 L 125.8 0.653898 L 124.8 0.718748 L 123.8 0.785183 L 122.8 0.805272 L 121.8 0.829751 L 120.8 0.870359 L 119.8 0.894905 L 118.8 0.911852 L 117.8 0.942871 L 116.8 0.965923 L 115.8 0.985366 L 114.8 0.992773 L 113.8 0.996995 L 112.8 0.999656 L 111.8 0.999239 L 110.8 0.993894 L 109.8 0.984738 L 108.8 0.972213 L 107.8 0.945446 L 106.8 0.91655 L 105.8 0.86624 L 104.8 0.837897 L 103.8 0.782994 L 102.8 0.745187 L 101.8 0.692498 L 100.8 0.662794 L 99.8 0.631793 L 98.8 0.601321 L 97.8 0.559084 L 96.8 0.531062 L 95.8 0.433515 L 94.8 0.35707 L 93.8 0.301773 L 92.8 0.220903 L 91.8 0.143522 L 90.8 0.062112 L 89.8 0.005147 L 88.8 -0.117966 L 87.8 -0.149535 L 86.8 -0.216766 L 85.8 -0.295058 L 84.8 -0.387611 L 83.8 -0.421765 L 82.8 -0.452679 L 81.8 -0.503004 L 80.8 -0.547822 L 79.8 -0.588823 L 78.8 -0.618678 L 77.8 -0.663526 L 76.8 -0.74679 L 75.8 -0.76885 L 74.8 -0.812967 L 73.8 -0.833129 L 72.8 -0.893251 L 71.8 -0.93548 L 70.8 -0.958737 L 69.8 -0.976732 L 68.8 -0.983734 L 67.8 -0.995973 L 66.8 -0.999442 L 65.8 -0.998259 L 64.8 -0.994084 L 63.8 -0.980354 L 62.8 -0.972703 L 61.8 -0.958263 L 60.8 -0.927611 L 59.8 -0.902922 L 58.8 -0.882675 L 57.8 -0.864202 L 56.8 -0.845248 L 55.8 -0.810642 L 54.8 -0.743359 L 53.8 -0.695131 L 52.8 -0.665749 L 51.8 -0.633906 L 50.8 -0.555682 L 49.8 -0.45647 L 48.8 -0.412576 L 47.8 -0.301816 L 46.8 -0.248043 L 45.8 -0.189835 L 44.8 -0.153658 L 43.8 -0.098867 L 42.8 -0.015916 L 41.8 0.031754 L 40.8 0.120599 L 39.8 0.168247 L 38.8 0.248469 L 37.8 0.337896 L 36.8 0.382122 L 35.8 0.441179 L 34.8 0.539628 L 33.8 0.57467 L 32.8 0.620434 L 31.8 0.673635 L 30.8 0.709483 L 29.8 0.751738 L 28.8 0.793097 L 27.8 0.820445 L 26.8 0.88147 L 25.8 0.904483 L 24.8 0.919261 L 23.8 0.934284 L 22.8 0.947208 L 21.8 0.979534 L 20.8 0.996802 L 19.8 0.999844 L 18.8 0.997823 L 17.8 0.99401 L 16.8 0.978994 L 15.8 0.970072 L 14.8 0.95778 L 13.8 0.929404 L 12.8 0.901094 L 11.8 0.866107 L 10.8 0.813717 L 9.8 0.765101 L 8.8 0.721134 L 7.8 0.682742 L 6.8 0.590438 L 5.8 0.563187 L 4.8 0.517238 L 3.8 0.475854 L 2.8 0.436431 L 1.8 0.377515 L 0 0.273593 L 0.227262 1 L 0.140289 2 L 0.091558 3 L 0.053928 4 L 0.017733 5 L -0.06793 6 L -0.161753 7 L -0.273189 8 L -0.360274 9 L -0.40709 10 L -0.463838 11 L -0.531601 12 L -0.573508 13 L -0.625352 14 L -0.650645 15 L -0.724163 16 L -0.770317 17 L -0.791479 18 L -0.851149 19 L -0.887991 20 L -0.917061 21 L -0.941292 22 L -0.951546 23 L -0.981839 24 L -0.994579 25 L -0.999784 26 L -0.999825 27 L -0.998417 28 L -0.992654 29 L -0.986301 30 L -0.967662 31 L -0.943214 32 L -0.912437 33 L -0.895086 34 L -0.880479 35 L -0.851999 36 L -0.833049 37 L -0.804776 38 L -0.736949 39 L -0.694852 40 L -0.659088 41 L -0.608192 42 L -0.546144 43 L -0.469078 44 L -0.390646 45 L -0.314256 46 L -0.272519 47 L -0.174586 48 L -0.104796 49 L -0.033939 50 L 0.084549 51 L 0.122597 52 L 0.158643 53 L 0.20132 54 L 0.299241 55 L 0.371531 56 L 0.414118 57 L 0.451421 58 L 0.546295 59 L 0.588994 60 L 0.621715 61 L 0.647784 62 L 0.677809 63 L 0.707013 64 L 0.742447 65 L 0.763133 66 L 0.785911 67 L 0.848282 68 L 0.876933 69 L 0.89743 70 L 0.932584 71 L 0.952705 72 L 0.963835 73 L 0.983785 74 L 0.997162 75 L 0.998974 76 L 0.993744 77 L 0.987133 78 L 0.961107 79 L 0.93948 80 L 0.917584 81 L 0.899066 82 L 0.868853 83 L 0.826455 84 L 0.799415 85 L 0.778893 86 L 0.743514 87 L 0.655618 88 L 0.618638 89 L 0.545793 90 L 0.443104 91 L 0.409892 92 L 0.309442 93 L 0.277702 94 L 0.234758 95 L 0.200953 96 L 0.120665 97 L 0.086322 98 L 0.0144 99 L -0.061467 100 L -0.117562 101 L -0.207304 102 L -0.24726 103 L -0.314957 104 L -0.42911 105 L -0.460269 106 L -0.525752 107 L -0.557786 108 L -0.642979 109 L -0.673037 110 L -0.719408 111 L -0.749116 112 L -0.778759 113 L -0.843855 114 L -0.877651 115 L -0.902804 116 L -0.918897 117 L -0.955058 118 L -0.973964 119 L -0.984187 120 L -0.992492 121 L -0.999215 122 L -0.996501 123 L -0.988797 124 L -0.971166 125 L -0.940938 126 L -0.912341 127 L -0.885031 128 L -0.825603 129 L -0.77009 130 L -0.688452 131 L -0.647196 132 L -0.60259 133 L -0.511042 134 L -0.430427 135 L -0.384469 136 L -0.292923 137 L -0.225967 138 L -0.179248 139 L -0.136118 140 L -0.077875 141 L -0.030604 142 L 0.026452 143 L 0.080989 144 L 0.196427 145 L 0.315576 146 L 0.370627 147 L 0.40698 148 L 0.502034 149 L 0.546466 150 L 0.575573 151 L 0.667237 152 L 0.714029 153 L 0.749742 154 L 0.795559 155 L 0.859505 156 L 0.892455 157 L 0.917515 158 L 0.933607 159 L 0.970088 160 L 0.979122 161 L 0.985274 162 L 0.990848 163 L 0.99806 164 L 0.99889 165 L 0.994277 166 L 0.981883 167 L 0.973583 168 L 0.937803 169 L 0.919049 170 L 0.901448 171 L 0.87707 172 L 0.844234 173 L 0.771924 174 L 0.735339 175 L 0.713128 176 L 0.683072 177 L 0.643552 178 L 0.614091 179 L 0.569454 180 L 0.500184 181 L 0.392301 182 L 0.355195 183 L 0.247165 184 L 0.140245 185 L 0.103559 186 L 0.051805 187 L -0.035129 188 L -0.106027 189 L -0.227181 190 L -0.260107 191 L -0.313632 192 L -0.359984 193 L -0.401339 194 L -0.450067 195 L -0.490327 196 L -0.533979 197 L -0.560575 198 L -0.651745 199 L -0.691652 200 L -0.720319 201 L -0.762616 202 L -0.811738 203 L -0.865675 204 L -0.918013 205 L -0.952001 206 L -0.967156 207 L -0.980387 208 L -0.992416 209 L -0.998222 210 L -0.99846 211 L -0.995029 212 L -0.978361 213 L -0.950969 214 L -0.910428 215 L -0.890133 216 L -0.872536 217 L -0.847806 218 L -0.794595 219 L -0.753623 220 L -0.693228 221 L -0.609661 222 L -0.563669 223 L -0.532753 224 L -0.502298 225 L -0.455614 226 L -0.387673 227 L -0.355756 228 L -0.30615 229 L -0.205734 230 L -0.170513 231 L -0.129026 232 L -0.0754 233 L -0.035334 234 L 0.07453 235 L 0.195709 236 L 0.233871 237 L 0.303602 238 L 0.362359 239 L 0.415477 240 L 0.479944 241 L 0.522985 242 L 0.587131 243 L 0.631929 244 L 0.71055 245 L 0.733761 246 L 0.756219 247 L 0.826066 248 L 0.846169 249 L 0.872053 250 L 0.895656 251 L 0.909427 252 L 0.933238 253 L 0.968289 254 L 0.987905 255 L 0.997925 256 L 0.999511 257 L 0.997397 258 L 0.994191 259 L 0.987806 260 L 0.972822 261 L 0.963505 262 L 0.943913 263 L 0.912031 264 L 0.858743 265 L 0.824485 266 L 0.803278 267 L 0.770858 268 L 0.745139 269 L 0.704247 270 L 0.679944 271 L 0.652386 272 L 0.613312 273 L 0.574818 274 L 0.521172 275 L 0.478431 276 L 0.446006 277 L 0.408082 278 L 0.378531 279 L 0.304491 280 L 0.26975 281 L 0.198648 282 L 0.140692 283 L 0.106477 284 L 0.001931 285 L -0.031948 286 L -0.139586 287 L -0.197401 288 L -0.263521 289 L -0.338446 290 L -0.397233 291 L -0.504686 292 L -0.600611 293 L -0.660743 294 L -0.694963 295 L -0.772666 296 L -0.810252 297 L -0.853431 298 L -0.881952 299 L -0.917155 300 L -0.941985 301 L -0.967909 302 L -0.983386 303 L -0.988682 304 L -0.999195 305 L -0.999894 306 L -0.998307 307 L -0.983759 308 L -0.976299 309 L -0.949036 310 L -0.904736 311 L -0.887316 312 L -0.847912 313 L -0.811558 314 L -0.773772 315 L -0.719976 316 L -0.6736 317 L -0.625248 318 L -0.57127 319 L -0.507815 320 L -0.41649 321 L -0.374633 322 L -0.343546 323 L -0.27172 324 L -0.238363 325 L -0.204546 326 L -0.16887 327 L -0.085534 328 L -0.053624 329 L 0.040791 330 L 0.163353 331 L 0.248217 332 L 0.307634 333 L 0.341295 334 L 0.436499 335 L 0.466063 336 L 0.500969 337 L 0.532344 338 L 0.629809 339 L 0.655764 340 L 0.706154 341 L 0.736458 342 L 0.792812 343 L 0.811609 344 L 0.857562 345.6 z " + style="fill: #ffffff" + id="path2" /> + </g> + <g + id="axes_1"> + <g + id="patch_2"> + <path + d="M 57.6 307.584 L 58.6 307.615436 L 59.6 307.652377 L 60.6 307.750123 L 61.6 307.782645 L 62.6 307.85627 L 63.6 307.894835 L 64.6 307.930248 L 65.6 307.987888 L 66.6 308.058274 L 67.6 308.110239 L 68.6 308.169328 L 69.6 308.257649 L 70.6 308.303794 L 71.6 308.346205 L 72.6 308.376697 L 73.6 308.402742 L 74.6 308.423942 L 75.6 308.478243 L 76.6 308.506181 L 77.6 308.535905 L 78.6 308.5613 L 79.6 308.5725 L 80.6 308.582624 L 81.6 308.58242 L 82.6 308.57291 L 83.6 308.561256 L 84.6 308.530227 L 85.6 308.519059 L 86.6 308.488942 L 87.6 308.429165 L 88.6 308.391973 L 89.6 308.352877 L 90.6 308.310437 L 91.6 308.277672 L 92.6 308.210246 L 93.6 308.17112 L 94.6 308.128445 L 95.6 308.057865 L 96.6 308.021474 L 97.6 307.963071 L 98.6 307.852118 L 99.6 307.78146 L 100.6 307.66852 L 101.6 307.622747 L 102.6 307.561464 L 103.6 307.512965 L 104.6 307.432142 L 105.6 307.313623 L 106.6 307.243412 L 107.6 307.16015 L 108.6 307.127008 L 109.6 307.075771 L 110.6 307.007372 L 111.6 306.941157 L 112.6 306.86424 L 113.6 306.836924 L 114.6 306.810447 L 115.6 306.787796 L 116.6 306.768265 L 117.6 306.741871 L 118.6 306.6921 L 119.6 306.657027 L 120.6 306.621161 L 121.6 306.605794 L 122.6 306.590025 L 123.6 306.586612 L 124.6 306.584195 L 125.6 306.584681 L 126.6 306.58661 L 127.6 306.599867 L 128.6 306.608258 L 129.6 306.629794 L 130.6 306.652827 L 131.6 306.67006 L 132.6 306.688523 L 133.6 306.708975 L 134.6 306.725575 L 135.6 306.788354 L 136.6 306.863619 L 137.6 306.896258 L 138.6 306.963822 L 139.6 307.017869 L 140.6 307.051573 L 141.6 307.141699 L 142.6 307.170234 L 143.6 307.20172 L 144.6 307.232731 L 145.6 307.287539 L 146.6 307.352126 L 147.6 307.390322 L 148.6 307.486256 L 149.6 307.535514 L 150.6 307.579583 L 151.6 307.619707 L 152.6 307.728074 L 153.6 307.769702 L 154.6 307.831844 L 155.6 307.901806 L 156.6 308.00631 L 157.6 308.043298 L 158.6 308.089175 L 159.6 308.15767 L 160.6 308.206416 L 161.6 308.284013 L 162.6 308.314554 L 163.6 308.384068 L 164.6 308.408041 L 165.6 308.436663 L 166.6 308.478456 L 167.6 308.500032 L 168.6 308.51398 L 169.6 308.540702 L 170.6 308.550012 L 171.6 308.562459 L 172.6 308.573514 L 173.6 308.579178 L 174.6 308.583942 L 175.6 308.578394 L 176.6 308.565106 L 177.6 308.557589 L 178.6 308.532804 L 179.6 308.509235 L 180.6 308.473055 L 181.6 308.447093 L 182.6 308.424771 L 183.6 308.356011 L 184.6 308.281476 L 185.6 308.187497 L 186.6 308.136445 L 187.6 308.082511 L 188.6 308.04726 L 189.6 307.941172 L 190.6 307.888908 L 191.6 307.852001 L 192.6 307.82097 L 193.6 307.759815 L 194.6 307.692395 L 195.6 307.643489 L 196.6 307.578297 L 197.6 307.540109 L 198.6 307.498113 L 199.6 307.456096 L 200.6 307.39658 L 201.6 307.28342 L 202.6 307.231169 L 203.6 307.191751 L 204.6 307.14465 L 205.6 307.08787 L 206.6 307.055207 L 207.6 307.019029 L 208.6 306.986939 L 209.6 306.952659 L 210.6 306.894281 L 211.6 306.849096 L 212.6 306.819472 L 213.6 306.769086 L 214.6 306.743889 L 215.6 306.722838 L 216.6 306.68787 L 217.6 306.66358 L 218.6 306.649513 L 219.6 306.630571 L 220.6 306.61491 L 221.6 306.602358 L 222.6 306.596522 L 223.6 306.58964 L 224.6 306.584466 L 225.6 306.586249 L 226.6 306.588974 L 227.6 306.600128 L 228.6 306.628363 L 229.6 306.672151 L 230.6 306.69284 L 231.6 306.733813 L 232.6 306.773888 L 233.6 306.792998 L 234.6 306.815507 L 235.6 306.882158 L 236.6 306.931868 L 237.6 307.005574 L 238.6 307.036888 L 239.6 307.11351 L 240.6 307.151808 L 241.6 307.225925 L 242.6 307.329983 L 243.6 307.399814 L 244.6 307.505048 L 245.6 307.560063 L 246.6 307.683538 L 247.6 307.754097 L 248.6 307.869936 L 249.6 307.920117 L 250.6 307.955721 L 251.6 308.047128 L 252.6 308.100636 L 253.6 308.188544 L 254.6 308.257729 L 255.6 308.304493 L 256.6 308.376537 L 257.6 308.426679 L 258.6 308.444069 L 259.6 308.471072 L 260.6 308.490499 L 261.6 308.509837 L 262.6 308.548086 L 263.6 308.564519 L 264.6 308.572888 L 265.6 308.577207 L 266.6 308.583762 L 267.6 308.581216 L 268.6 308.575757 L 269.6 308.559329 L 270.6 308.527394 L 271.6 308.489414 L 272.6 308.45461 L 273.6 308.391538 L 274.6 308.370111 L 275.6 308.319493 L 276.6 308.294536 L 277.6 308.238902 L 278.6 308.207673 L 279.6 308.157529 L 280.6 308.125036 L 281.6 308.044624 L 282.6 307.975698 L 283.6 307.860001 L 284.6 307.784522 L 285.6 307.668997 L 286.6 307.589513 L 287.6 307.481072 L 288.6 307.441704 L 289.6 307.338836 L 290.6 307.239038 L 291.6 307.193541 L 292.6 307.159219 L 293.6 307.107263 L 294.6 307.067616 L 295.6 307.032102 L 296.6 306.964457 L 297.6 306.925375 L 298.6 306.874894 L 299.6 306.825588 L 300.6 306.774518 L 301.6 306.730279 L 302.6 306.708259 L 303.6 306.692703 L 304.6 306.650256 L 305.6 306.635388 L 306.6 306.61266 L 307.6 306.592344 L 308.6 306.586547 L 309.6 306.584065 L 310.6 306.587122 L 311.6 306.598718 L 312.6 306.615638 L 313.6 306.647299 L 314.6 306.661382 L 315.6 306.714054 L 316.6 306.763143 L 317.6 306.817844 L 318.6 306.862192 L 319.6 306.932184 L 320.6 306.982567 L 321.6 307.036474 L 322.6 307.105913 L 323.6 307.163301 L 324.6 307.213466 L 325.6 307.290628 L 326.6 307.348818 L 327.6 307.409456 L 328.6 307.446657 L 329.6 307.511749 L 330.6 307.616879 L 331.6 307.677181 L 332.6 307.773503 L 333.6 307.805506 L 334.6 307.856523 L 335.6 307.973315 L 336.6 308.008762 L 337.6 308.064642 L 338.6 308.095018 L 339.6 308.183404 L 340.6 308.228168 L 341.6 308.309056 L 342.6 308.369202 L 343.6 308.432288 L 344.6 308.455236 L 345.6 308.471406 L 346.6 308.500335 L 347.6 308.530687 L 348.6 308.543261 L 349.6 308.56814 L 350.6 308.580224 L 351.6 308.583986 L 352.6 308.57955 L 353.6 308.567211 L 354.6 308.552798 L 355.6 308.536725 L 356.6 308.501204 L 357.6 308.48127 L 358.6 308.424681 L 359.6 308.357487 L 360.6 308.330117 L 361.6 308.295969 L 362.6 308.247289 L 363.6 308.199004 L 364.6 308.139927 L 365.6 308.044322 L 366.6 308.001182 L 367.6 307.951334 L 368.6 307.8928 L 369.6 307.845214 L 370.6 307.784086 L 371.6 307.728001 L 372.6 307.65383 L 373.6 307.536592 L 374.6 307.480868 L 375.6 307.372642 L 376.6 307.266492 L 377.6 307.15892 L 378.6 307.124412 L 379.6 307.021105 L 380.6 306.945381 L 381.6 306.905946 L 382.6 306.866562 L 383.6 306.84408 L 384.6 306.788267 L 385.6 306.762215 L 386.6 306.73198 L 387.6 306.681209 L 388.6 306.662558 L 389.6 306.640849 L 390.6 306.628203 L 391.6 306.60921 L 392.6 306.59182 L 393.6 306.584782 L 394.6 306.585806 L 395.6 306.59281 L 396.6 306.60218 L 397.6 306.625578 L 398.6 306.650661 L 399.6 306.66306 L 400.6 306.696153 L 401.6 306.71252 L 402.6 306.730925 L 403.6 306.780062 L 404.6 306.823875 L 405.6 306.86696 L 406.6 306.889901 L 407.6 306.930164 L 408.6 307.015024 L 409.6 307.057416 L 410.6 307.121802 L 411.6 307.166091 L 412.6 307.273937 L 413.6 307.350877 L 414.72 307.387319 L 414.578206 306.584 L 414.653307 305.584 L 414.711902 304.584 L 414.748477 303.584 L 414.860524 302.584 L 414.922209 301.584 L 414.972729 300.584 L 415.071514 299.584 L 415.109536 298.584 L 415.144984 297.584 L 415.236618 296.584 L 415.27989 295.584 L 415.333219 294.584 L 415.366084 293.584 L 415.428978 292.584 L 415.482832 291.584 L 415.539958 290.584 L 415.562048 289.584 L 415.605787 288.584 L 415.652881 287.584 L 415.669728 286.584 L 415.697802 285.584 L 415.708798 284.584 L 415.713367 283.584 L 415.719015 282.584 L 415.719066 281.584 L 415.715976 280.584 L 415.712463 279.584 L 415.706641 278.584 L 415.693789 277.584 L 415.670164 276.584 L 415.65528 275.584 L 415.631708 274.584 L 415.595389 273.584 L 415.563806 272.584 L 415.533913 271.584 L 415.455221 270.584 L 415.41867 269.584 L 415.392947 268.584 L 415.322274 267.584 L 415.231172 266.584 L 415.169215 265.584 L 415.135602 264.584 L 415.101102 263.584 L 415.003662 262.584 L 414.956072 261.584 L 414.924566 260.584 L 414.880881 259.584 L 414.810712 258.584 L 414.760845 257.584 L 414.726168 256.584 L 414.61652 255.584 L 414.583049 254.584 L 414.545707 253.584 L 414.465462 252.584 L 414.426968 251.584 L 414.385191 250.584 L 414.342766 249.584 L 414.233038 248.584 L 414.144753 247.584 L 414.070107 246.584 L 413.98165 245.584 L 413.907588 244.584 L 413.858423 243.584 L 413.802806 242.584 L 413.768106 241.584 L 413.756235 240.584 L 413.734012 239.584 L 413.722033 238.584 L 413.720281 237.584 L 413.725698 236.584 L 413.741896 235.584 L 413.758396 234.584 L 413.789579 233.584 L 413.802944 232.584 L 413.832587 231.584 L 413.89561 230.584 L 413.944931 229.584 L 413.99102 228.584 L 414.073247 227.584 L 414.11915 226.584 L 414.153475 225.584 L 414.207014 224.584 L 414.295901 223.584 L 414.327039 222.584 L 414.435088 221.584 L 414.54716 220.584 L 414.582598 219.584 L 414.667384 218.584 L 414.732991 217.584 L 414.835045 216.584 L 414.95126 215.584 L 414.991951 214.584 L 415.03304 213.584 L 415.069681 212.584 L 415.110677 211.584 L 415.186746 210.584 L 415.262812 209.584 L 415.2935 208.584 L 415.319991 207.584 L 415.376572 206.584 L 415.421088 205.584 L 415.451106 204.584 L 415.478162 203.584 L 415.520727 202.584 L 415.573592 201.584 L 415.604513 200.584 L 415.630788 199.584 L 415.645721 198.584 L 415.67601 197.584 L 415.697339 196.584 L 415.714228 195.584 L 415.718943 194.584 L 415.719553 193.584 L 415.717507 192.584 L 415.711646 191.584 L 415.692999 190.584 L 415.660942 189.584 L 415.614502 188.584 L 415.572556 187.584 L 415.505851 186.584 L 415.436785 185.584 L 415.38941 184.584 L 415.337891 183.584 L 415.298191 182.584 L 415.228771 181.584 L 415.16224 180.584 L 415.053331 179.584 L 414.988083 178.584 L 414.879875 177.584 L 414.818871 176.584 L 414.770186 175.584 L 414.693952 174.584 L 414.634421 173.584 L 414.559793 172.584 L 414.440966 171.584 L 414.343021 170.584 L 414.263973 169.584 L 414.218226 168.584 L 414.190954 167.584 L 414.147292 166.584 L 414.098708 165.584 L 414.066974 164.584 L 413.986744 163.584 L 413.920251 162.584 L 413.896226 161.584 L 413.835727 160.584 L 413.813495 159.584 L 413.794895 158.584 L 413.765569 157.584 L 413.749868 156.584 L 413.741569 155.584 L 413.731333 154.584 L 413.72099 153.584 L 413.721668 152.584 L 413.725448 151.584 L 413.741889 150.584 L 413.754023 149.584 L 413.764618 148.584 L 413.795995 147.584 L 413.821768 146.584 L 413.853177 145.584 L 413.875986 144.584 L 413.89358 143.584 L 413.943392 142.584 L 413.991052 141.584 L 414.062761 140.584 L 414.118524 139.584 L 414.144722 138.584 L 414.17549 137.584 L 414.265248 136.584 L 414.350042 135.584 L 414.415636 134.584 L 414.461461 133.584 L 414.504458 132.584 L 414.565971 131.584 L 414.665796 130.584 L 414.710226 129.584 L 414.760276 128.584 L 414.882117 127.584 L 414.94181 126.584 L 414.973376 125.584 L 415.005719 124.584 L 415.060279 123.584 L 415.102779 122.584 L 415.154251 121.584 L 415.242636 120.584 L 415.276833 119.584 L 415.320767 118.584 L 415.38448 117.584 L 415.459677 116.584 L 415.488491 115.584 L 415.530695 114.584 L 415.57328 113.584 L 415.590172 112.584 L 415.612653 111.584 L 415.65499 110.584 L 415.68495 109.584 L 415.703583 108.584 L 415.713375 107.584 L 415.717138 106.584 L 415.719976 105.584 L 415.718227 104.584 L 415.708871 103.584 L 415.698174 102.584 L 415.688304 101.584 L 415.669446 100.584 L 415.639107 99.584 L 415.600716 98.584 L 415.54123 97.584 L 415.497941 96.584 L 415.437203 95.584 L 415.353129 94.584 L 415.304836 93.584 L 415.261259 92.584 L 415.234378 91.584 L 415.202448 90.584 L 415.135256 89.584 L 415.054435 88.584 L 414.97889 87.584 L 414.93516 86.584 L 414.855265 85.584 L 414.793786 84.584 L 414.730161 83.584 L 414.622912 82.584 L 414.504202 81.584 L 414.462296 80.584 L 414.419342 79.584 L 414.357143 78.584 L 414.327006 77.584 L 414.294488 76.584 L 414.242553 75.584 L 414.137003 74.584 L 414.088557 73.584 L 414.042233 72.584 L 414.008417 71.584 L 413.96054 70.584 L 413.905662 69.584 L 413.881751 68.584 L 413.855714 67.584 L 413.799597 66.584 L 413.785723 65.584 L 413.759689 64.584 L 413.732943 63.584 L 413.725197 62.584 L 413.720044 61.584 L 413.726242 60.584 L 413.732549 59.584 L 413.74013 58.584 L 413.767636 57.584 L 413.811869 56.584 L 413.841407 55.584 L 413.883254 54.584 L 413.942428 53.584 L 413.965138 52.584 L 414.00177 51.584 L 414.058558 50.584 L 414.083728 49.584 L 414.166424 48.584 L 414.253356 47.584 L 414.30404 46.584 L 414.341434 45.584 L 414.425814 44.584 L 414.460325 43.584 L 414.552316 42.584 L 414.639341 41.472 L 413.72 41.429519 L 412.72 41.39165 L 411.72 41.344175 L 410.72 41.238649 L 409.72 41.141188 L 408.72 41.064551 L 407.72 41.032624 L 406.72 40.978384 L 405.72 40.939533 L 404.72 40.865828 L 403.72 40.833832 L 402.72 40.777293 L 401.72 40.741177 L 400.72 40.672575 L 399.72 40.641159 L 398.72 40.586492 L 397.72 40.567721 L 396.72 40.522092 L 395.72 40.499189 L 394.72 40.490648 L 393.72 40.483307 L 392.72 40.477012 L 391.72 40.473835 L 390.72 40.472249 L 389.72 40.473712 L 388.72 40.486666 L 387.72 40.501288 L 386.72 40.513144 L 385.72 40.531169 L 384.72 40.551547 L 383.72 40.574946 L 382.72 40.589855 L 381.72 40.644569 L 380.72 40.678166 L 379.72 40.740862 L 378.72 40.768237 L 377.72 40.812217 L 376.72 40.891164 L 375.72 40.948692 L 374.72 40.998671 L 373.72 41.070655 L 372.72 41.107187 L 371.72 41.1755 L 370.72 41.263706 L 369.72 41.385053 L 368.72 41.450734 L 367.72 41.484352 L 366.72 41.548629 L 365.72 41.5946 L 364.72 41.666757 L 363.72 41.706583 L 362.72 41.749213 L 361.72 41.855172 L 360.72 41.907957 L 359.72 41.987234 L 358.72 42.029638 L 357.72 42.061904 L 356.72 42.09677 L 355.72 42.139428 L 354.72 42.171001 L 353.72 42.23858 L 352.72 42.275465 L 351.72 42.303421 L 350.72 42.324269 L 349.72 42.349882 L 348.72 42.3875 L 347.72 42.402342 L 346.72 42.427072 L 345.72 42.445302 L 344.72 42.456709 L 343.72 42.462344 L 342.72 42.467098 L 341.72 42.471707 L 340.72 42.470034 L 339.72 42.464252 L 338.72 42.444256 L 337.72 42.432604 L 336.72 42.421615 L 335.72 42.408648 L 334.72 42.358234 L 333.72 42.337412 L 332.72 42.309465 L 331.72 42.25272 L 330.72 42.230076 L 329.72 42.178673 L 328.72 42.137537 L 327.72 42.054768 L 326.72 42.006308 L 325.72 41.954881 L 324.72 41.903721 L 323.72 41.836422 L 322.72 41.803268 L 321.72 41.73721 L 320.72 41.681025 L 319.72 41.619746 L 318.72 41.579763 L 317.72 41.48334 L 316.72 41.37158 L 315.72 41.332661 L 314.72 41.234812 L 313.72 41.200158 L 312.72 41.116476 L 311.72 41.06597 L 310.72 40.996927 L 309.72 40.895824 L 308.72 40.843378 L 307.72 40.75407 L 306.72 40.689062 L 305.72 40.647517 L 304.72 40.605177 L 303.72 40.583157 L 302.72 40.54567 L 301.72 40.528418 L 300.72 40.50501 L 299.72 40.496443 L 298.72 40.487354 L 297.72 40.480286 L 296.72 40.473259 L 295.72 40.472151 L 294.72 40.472137 L 293.72 40.474811 L 292.72 40.477837 L 291.72 40.483304 L 290.72 40.503299 L 289.72 40.51527 L 288.72 40.542389 L 287.72 40.569401 L 286.72 40.596567 L 285.72 40.651042 L 284.72 40.680658 L 283.72 40.722414 L 282.72 40.795523 L 281.72 40.838961 L 280.72 40.909652 L 279.72 40.948059 L 278.72 41.008398 L 277.72 41.039153 L 276.72 41.069651 L 275.72 41.128561 L 274.72 41.171738 L 273.72 41.21335 L 272.72 41.262465 L 271.72 41.327552 L 270.72 41.393947 L 269.72 41.51871 L 268.72 41.562525 L 267.72 41.616853 L 266.72 41.723557 L 265.72 41.766057 L 264.72 41.803551 L 263.72 41.893047 L 262.72 41.95027 L 261.72 42.019913 L 260.72 42.068932 L 259.72 42.124877 L 258.72 42.172002 L 257.72 42.21089 L 256.72 42.264582 L 255.72 42.310153 L 254.72 42.34709 L 253.72 42.369166 L 252.72 42.402049 L 251.72 42.431769 L 250.72 42.444319 L 249.72 42.456218 L 248.72 42.461336 L 247.72 42.469225 L 246.72 42.471856 L 245.72 42.471058 L 244.72 42.467817 L 243.72 42.452679 L 242.72 42.445742 L 241.72 42.429365 L 240.72 42.410952 L 239.72 42.38136 L 238.72 42.359278 L 237.72 42.301584 L 236.72 42.276393 L 235.72 42.20808 L 234.72 42.160954 L 233.72 42.123606 L 232.72 42.068397 L 231.72 41.978966 L 230.72 41.875856 L 229.72 41.821882 L 228.72 41.791162 L 227.72 41.735621 L 226.72 41.697886 L 225.72 41.629632 L 224.72 41.593803 L 223.72 41.524019 L 222.72 41.464725 L 221.72 41.426118 L 220.72 41.392122 L 219.72 41.349542 L 218.72 41.302893 L 217.72 41.248327 L 216.72 41.162426 L 215.72 41.11575 L 214.72 41.058435 L 213.72 41.028021 L 212.72 40.94297 L 211.72 40.909295 L 210.72 40.821371 L 209.72 40.766386 L 208.72 40.727697 L 207.72 40.657666 L 206.72 40.62722 L 205.72 40.569495 L 204.72 40.552351 L 203.72 40.527616 L 202.72 40.512116 L 201.72 40.488664 L 200.72 40.48185 L 199.72 40.477917 L 198.72 40.474185 L 197.72 40.472152 L 196.72 40.480538 L 195.72 40.496924 L 194.72 40.523194 L 193.72 40.536523 L 192.72 40.566477 L 191.72 40.600728 L 190.72 40.621398 L 189.72 40.66241 L 188.72 40.735728 L 187.72 40.758946 L 186.72 40.799312 L 185.72 40.826563 L 184.72 40.907101 L 183.72 40.960579 L 182.72 41.03915 L 181.72 41.087618 L 180.72 41.201648 L 179.72 41.302333 L 178.72 41.386757 L 177.72 41.478297 L 176.72 41.58071 L 175.72 41.621518 L 174.72 41.664661 L 173.72 41.703962 L 172.72 41.737385 L 171.72 41.780493 L 170.72 41.886072 L 169.72 41.941773 L 168.72 42.0471 L 167.72 42.144097 L 166.72 42.167117 L 165.72 42.194104 L 164.72 42.224205 L 163.72 42.297447 L 162.72 42.334839 L 161.72 42.369798 L 160.72 42.388374 L 159.72 42.41888 L 158.72 42.431092 L 157.72 42.440868 L 156.72 42.450437 L 155.72 42.458646 L 154.72 42.469922 L 153.72 42.471784 L 152.72 42.465482 L 151.72 42.459469 L 150.72 42.454012 L 149.72 42.43382 L 148.72 42.423931 L 147.72 42.396178 L 146.72 42.377171 L 145.72 42.361772 L 144.72 42.332507 L 143.72 42.268703 L 142.72 42.21965 L 141.72 42.149461 L 140.72 42.120352 L 139.72 42.060782 L 138.72 42.013833 L 137.72 41.962711 L 136.72 41.908658 L 135.72 41.826971 L 134.72 41.748314 L 133.72 41.711654 L 132.72 41.59 L 131.72 41.511058 L 130.72 41.446567 L 129.72 41.400939 L 128.72 41.28529 L 127.72 41.237015 L 126.72 41.201492 L 125.72 41.157914 L 124.72 41.122138 L 123.72 41.051313 L 122.72 41.014909 L 121.72 40.917433 L 120.72 40.848369 L 119.72 40.782403 L 118.72 40.717873 L 117.72 40.694451 L 116.72 40.667046 L 115.72 40.618552 L 114.72 40.588559 L 113.72 40.556021 L 112.72 40.541278 L 111.72 40.527738 L 110.72 40.504303 L 109.72 40.491823 L 108.72 40.484685 L 107.72 40.479087 L 106.72 40.473481 L 105.72 40.472 L 104.72 40.477993 L 103.72 40.483958 L 102.72 40.49547 L 101.72 40.519277 L 100.72 40.52941 L 99.72 40.571368 L 98.72 40.61344 L 97.72 40.644656 L 96.72 40.714514 L 95.72 40.75877 L 94.72 40.84124 L 93.72 40.929427 L 92.72 40.974347 L 91.72 41.070077 L 90.72 41.142181 L 89.72 41.237171 L 88.72 41.293545 L 87.72 41.337742 L 86.72 41.393558 L 85.72 41.433496 L 84.72 41.508947 L 83.72 41.566942 L 82.72 41.604129 L 81.72 41.662656 L 80.72 41.765433 L 79.72 41.82216 L 78.72 41.893165 L 77.72 41.954934 L 76.72 41.992397 L 75.72 42.027683 L 74.72 42.071101 L 73.72 42.11296 L 72.72 42.140583 L 71.72 42.191698 L 70.72 42.225234 L 69.72 42.287297 L 68.72 42.306939 L 67.72 42.368712 L 66.72 42.391191 L 65.72 42.411414 L 64.72 42.432103 L 63.72 42.45853 L 62.72 42.469487 L 61.72 42.471269 L 60.72 42.468641 L 59.72 42.462091 L 58.72 42.440128 L 57.6 42.401128 L 58.508845 42.472 L 58.492196 43.472 L 58.430573 44.472 L 58.401989 45.472 L 58.378481 46.472 L 58.334033 47.472 L 58.30807 48.472 L 58.25771 49.472 L 58.181318 50.472 L 58.153797 51.472 L 58.121939 52.472 L 58.086315 53.472 L 57.998542 54.472 L 57.901531 55.472 L 57.821578 56.472 L 57.703903 57.472 L 57.631909 58.472 L 57.527743 59.472 L 57.416434 60.472 L 57.321012 61.472 L 57.226115 62.472 L 57.159096 63.472 L 57.098211 64.472 L 57.05375 65.472 L 57.018079 66.472 L 56.938783 67.472 L 56.908528 68.472 L 56.834884 69.472 L 56.802439 70.472 L 56.757912 71.472 L 56.736656 72.472 L 56.708304 73.472 L 56.679978 74.472 L 56.645645 75.472 L 56.632329 76.472 L 56.615537 77.472 L 56.604993 78.472 L 56.601874 79.472 L 56.600038 80.472 L 56.605027 81.472 L 56.610475 82.472 L 56.62462 83.472 L 56.659254 84.472 L 56.678281 85.472 L 56.720881 86.472 L 56.738986 87.472 L 56.783389 88.472 L 56.805819 89.472 L 56.846087 90.472 L 56.878592 91.472 L 56.941903 92.472 L 57.030413 93.472 L 57.116883 94.472 L 57.196518 95.472 L 57.250304 96.472 L 57.310415 97.472 L 57.381456 98.472 L 57.501577 99.472 L 57.606039 100.472 L 57.716842 101.472 L 57.770115 102.472 L 57.843365 103.472 L 57.881948 104.472 L 57.957711 105.472 L 58.035272 106.472 L 58.121412 107.472 L 58.148855 108.472 L 58.244831 109.472 L 58.320941 110.472 L 58.371105 111.472 L 58.425458 112.472 L 58.453129 113.472 L 58.489151 114.472 L 58.520712 115.472 L 58.538819 116.472 L 58.555558 117.472 L 58.572565 118.472 L 58.589619 119.472 L 58.59403 120.472 L 58.598289 121.472 L 58.599886 122.472 L 58.598359 123.472 L 58.595935 124.472 L 58.592476 125.472 L 58.582211 126.472 L 58.562483 127.472 L 58.550784 128.472 L 58.50804 129.472 L 58.48236 130.472 L 58.438178 131.472 L 58.382063 132.472 L 58.325365 133.472 L 58.293505 134.472 L 58.256796 135.472 L 58.228663 136.472 L 58.172864 137.472 L 58.138147 138.472 L 58.06646 139.472 L 58.010402 140.472 L 57.928747 141.472 L 57.873173 142.472 L 57.788865 143.472 L 57.74624 144.472 L 57.655234 145.472 L 57.594949 146.472 L 57.489872 147.472 L 57.425687 148.472 L 57.346491 149.472 L 57.280264 150.472 L 57.225988 151.472 L 57.192861 152.472 L 57.136147 153.472 L 57.09259 154.472 L 56.995347 155.472 L 56.921401 156.472 L 56.859607 157.472 L 56.831192 158.472 L 56.805858 159.472 L 56.739603 160.472 L 56.696586 161.472 L 56.668079 162.472 L 56.656085 163.472 L 56.642011 164.472 L 56.631183 165.472 L 56.615885 166.472 L 56.606029 167.472 L 56.600216 168.472 L 56.601051 169.472 L 56.603013 170.472 L 56.606621 171.472 L 56.623932 172.472 L 56.633663 173.472 L 56.667693 174.472 L 56.692764 175.472 L 56.731461 176.472 L 56.797395 177.472 L 56.838383 178.472 L 56.913224 179.472 L 56.945151 180.472 L 56.969365 181.472 L 56.995185 182.472 L 57.054225 183.472 L 57.108937 184.472 L 57.215139 185.472 L 57.295415 186.472 L 57.412157 187.472 L 57.51212 188.472 L 57.564434 189.472 L 57.603007 190.472 L 57.639368 191.472 L 57.760354 192.472 L 57.791539 193.472 L 57.827915 194.472 L 57.890066 195.472 L 57.978077 196.472 L 58.02247 197.472 L 58.070988 198.472 L 58.169778 199.472 L 58.211246 200.472 L 58.253898 201.472 L 58.318748 202.472 L 58.385183 203.472 L 58.405272 204.472 L 58.429751 205.472 L 58.470359 206.472 L 58.494905 207.472 L 58.511852 208.472 L 58.542871 209.472 L 58.565923 210.472 L 58.585366 211.472 L 58.592773 212.472 L 58.596995 213.472 L 58.599656 214.472 L 58.599239 215.472 L 58.593894 216.472 L 58.584738 217.472 L 58.572213 218.472 L 58.545446 219.472 L 58.51655 220.472 L 58.46624 221.472 L 58.437897 222.472 L 58.382994 223.472 L 58.345187 224.472 L 58.292498 225.472 L 58.262794 226.472 L 58.231793 227.472 L 58.201321 228.472 L 58.159084 229.472 L 58.131062 230.472 L 58.033515 231.472 L 57.95707 232.472 L 57.901773 233.472 L 57.820903 234.472 L 57.743522 235.472 L 57.662112 236.472 L 57.605147 237.472 L 57.482034 238.472 L 57.450465 239.472 L 57.383234 240.472 L 57.304942 241.472 L 57.212389 242.472 L 57.178235 243.472 L 57.147321 244.472 L 57.096996 245.472 L 57.052178 246.472 L 57.011177 247.472 L 56.981322 248.472 L 56.936474 249.472 L 56.85321 250.472 L 56.83115 251.472 L 56.787033 252.472 L 56.766871 253.472 L 56.706749 254.472 L 56.66452 255.472 L 56.641263 256.472 L 56.623268 257.472 L 56.616266 258.472 L 56.604027 259.472 L 56.600558 260.472 L 56.601741 261.472 L 56.605916 262.472 L 56.619646 263.472 L 56.627297 264.472 L 56.641737 265.472 L 56.672389 266.472 L 56.697078 267.472 L 56.717325 268.472 L 56.735798 269.472 L 56.754752 270.472 L 56.789358 271.472 L 56.856641 272.472 L 56.904869 273.472 L 56.934251 274.472 L 56.966094 275.472 L 57.044318 276.472 L 57.14353 277.472 L 57.187424 278.472 L 57.298184 279.472 L 57.351957 280.472 L 57.410165 281.472 L 57.446342 282.472 L 57.501133 283.472 L 57.584084 284.472 L 57.631754 285.472 L 57.720599 286.472 L 57.768247 287.472 L 57.848469 288.472 L 57.937896 289.472 L 57.982122 290.472 L 58.041179 291.472 L 58.139628 292.472 L 58.17467 293.472 L 58.220434 294.472 L 58.273635 295.472 L 58.309483 296.472 L 58.351738 297.472 L 58.393097 298.472 L 58.420445 299.472 L 58.48147 300.472 L 58.504483 301.472 L 58.519261 302.472 L 58.534284 303.472 L 58.547208 304.472 L 58.579534 305.472 L 58.596802 306.472 L 58.599844 307.584 z " + style="fill: #ffffff; stroke: #ffffff; stroke-width: 4; stroke-linejoin: miter" + id="path3" /> + <path + d="M 57.6 307.584 L 58.6 307.615436 L 59.6 307.652377 L 60.6 307.750123 L 61.6 307.782645 L 62.6 307.85627 L 63.6 307.894835 L 64.6 307.930248 L 65.6 307.987888 L 66.6 308.058274 L 67.6 308.110239 L 68.6 308.169328 L 69.6 308.257649 L 70.6 308.303794 L 71.6 308.346205 L 72.6 308.376697 L 73.6 308.402742 L 74.6 308.423942 L 75.6 308.478243 L 76.6 308.506181 L 77.6 308.535905 L 78.6 308.5613 L 79.6 308.5725 L 80.6 308.582624 L 81.6 308.58242 L 82.6 308.57291 L 83.6 308.561256 L 84.6 308.530227 L 85.6 308.519059 L 86.6 308.488942 L 87.6 308.429165 L 88.6 308.391973 L 89.6 308.352877 L 90.6 308.310437 L 91.6 308.277672 L 92.6 308.210246 L 93.6 308.17112 L 94.6 308.128445 L 95.6 308.057865 L 96.6 308.021474 L 97.6 307.963071 L 98.6 307.852118 L 99.6 307.78146 L 100.6 307.66852 L 101.6 307.622747 L 102.6 307.561464 L 103.6 307.512965 L 104.6 307.432142 L 105.6 307.313623 L 106.6 307.243412 L 107.6 307.16015 L 108.6 307.127008 L 109.6 307.075771 L 110.6 307.007372 L 111.6 306.941157 L 112.6 306.86424 L 113.6 306.836924 L 114.6 306.810447 L 115.6 306.787796 L 116.6 306.768265 L 117.6 306.741871 L 118.6 306.6921 L 119.6 306.657027 L 120.6 306.621161 L 121.6 306.605794 L 122.6 306.590025 L 123.6 306.586612 L 124.6 306.584195 L 125.6 306.584681 L 126.6 306.58661 L 127.6 306.599867 L 128.6 306.608258 L 129.6 306.629794 L 130.6 306.652827 L 131.6 306.67006 L 132.6 306.688523 L 133.6 306.708975 L 134.6 306.725575 L 135.6 306.788354 L 136.6 306.863619 L 137.6 306.896258 L 138.6 306.963822 L 139.6 307.017869 L 140.6 307.051573 L 141.6 307.141699 L 142.6 307.170234 L 143.6 307.20172 L 144.6 307.232731 L 145.6 307.287539 L 146.6 307.352126 L 147.6 307.390322 L 148.6 307.486256 L 149.6 307.535514 L 150.6 307.579583 L 151.6 307.619707 L 152.6 307.728074 L 153.6 307.769702 L 154.6 307.831844 L 155.6 307.901806 L 156.6 308.00631 L 157.6 308.043298 L 158.6 308.089175 L 159.6 308.15767 L 160.6 308.206416 L 161.6 308.284013 L 162.6 308.314554 L 163.6 308.384068 L 164.6 308.408041 L 165.6 308.436663 L 166.6 308.478456 L 167.6 308.500032 L 168.6 308.51398 L 169.6 308.540702 L 170.6 308.550012 L 171.6 308.562459 L 172.6 308.573514 L 173.6 308.579178 L 174.6 308.583942 L 175.6 308.578394 L 176.6 308.565106 L 177.6 308.557589 L 178.6 308.532804 L 179.6 308.509235 L 180.6 308.473055 L 181.6 308.447093 L 182.6 308.424771 L 183.6 308.356011 L 184.6 308.281476 L 185.6 308.187497 L 186.6 308.136445 L 187.6 308.082511 L 188.6 308.04726 L 189.6 307.941172 L 190.6 307.888908 L 191.6 307.852001 L 192.6 307.82097 L 193.6 307.759815 L 194.6 307.692395 L 195.6 307.643489 L 196.6 307.578297 L 197.6 307.540109 L 198.6 307.498113 L 199.6 307.456096 L 200.6 307.39658 L 201.6 307.28342 L 202.6 307.231169 L 203.6 307.191751 L 204.6 307.14465 L 205.6 307.08787 L 206.6 307.055207 L 207.6 307.019029 L 208.6 306.986939 L 209.6 306.952659 L 210.6 306.894281 L 211.6 306.849096 L 212.6 306.819472 L 213.6 306.769086 L 214.6 306.743889 L 215.6 306.722838 L 216.6 306.68787 L 217.6 306.66358 L 218.6 306.649513 L 219.6 306.630571 L 220.6 306.61491 L 221.6 306.602358 L 222.6 306.596522 L 223.6 306.58964 L 224.6 306.584466 L 225.6 306.586249 L 226.6 306.588974 L 227.6 306.600128 L 228.6 306.628363 L 229.6 306.672151 L 230.6 306.69284 L 231.6 306.733813 L 232.6 306.773888 L 233.6 306.792998 L 234.6 306.815507 L 235.6 306.882158 L 236.6 306.931868 L 237.6 307.005574 L 238.6 307.036888 L 239.6 307.11351 L 240.6 307.151808 L 241.6 307.225925 L 242.6 307.329983 L 243.6 307.399814 L 244.6 307.505048 L 245.6 307.560063 L 246.6 307.683538 L 247.6 307.754097 L 248.6 307.869936 L 249.6 307.920117 L 250.6 307.955721 L 251.6 308.047128 L 252.6 308.100636 L 253.6 308.188544 L 254.6 308.257729 L 255.6 308.304493 L 256.6 308.376537 L 257.6 308.426679 L 258.6 308.444069 L 259.6 308.471072 L 260.6 308.490499 L 261.6 308.509837 L 262.6 308.548086 L 263.6 308.564519 L 264.6 308.572888 L 265.6 308.577207 L 266.6 308.583762 L 267.6 308.581216 L 268.6 308.575757 L 269.6 308.559329 L 270.6 308.527394 L 271.6 308.489414 L 272.6 308.45461 L 273.6 308.391538 L 274.6 308.370111 L 275.6 308.319493 L 276.6 308.294536 L 277.6 308.238902 L 278.6 308.207673 L 279.6 308.157529 L 280.6 308.125036 L 281.6 308.044624 L 282.6 307.975698 L 283.6 307.860001 L 284.6 307.784522 L 285.6 307.668997 L 286.6 307.589513 L 287.6 307.481072 L 288.6 307.441704 L 289.6 307.338836 L 290.6 307.239038 L 291.6 307.193541 L 292.6 307.159219 L 293.6 307.107263 L 294.6 307.067616 L 295.6 307.032102 L 296.6 306.964457 L 297.6 306.925375 L 298.6 306.874894 L 299.6 306.825588 L 300.6 306.774518 L 301.6 306.730279 L 302.6 306.708259 L 303.6 306.692703 L 304.6 306.650256 L 305.6 306.635388 L 306.6 306.61266 L 307.6 306.592344 L 308.6 306.586547 L 309.6 306.584065 L 310.6 306.587122 L 311.6 306.598718 L 312.6 306.615638 L 313.6 306.647299 L 314.6 306.661382 L 315.6 306.714054 L 316.6 306.763143 L 317.6 306.817844 L 318.6 306.862192 L 319.6 306.932184 L 320.6 306.982567 L 321.6 307.036474 L 322.6 307.105913 L 323.6 307.163301 L 324.6 307.213466 L 325.6 307.290628 L 326.6 307.348818 L 327.6 307.409456 L 328.6 307.446657 L 329.6 307.511749 L 330.6 307.616879 L 331.6 307.677181 L 332.6 307.773503 L 333.6 307.805506 L 334.6 307.856523 L 335.6 307.973315 L 336.6 308.008762 L 337.6 308.064642 L 338.6 308.095018 L 339.6 308.183404 L 340.6 308.228168 L 341.6 308.309056 L 342.6 308.369202 L 343.6 308.432288 L 344.6 308.455236 L 345.6 308.471406 L 346.6 308.500335 L 347.6 308.530687 L 348.6 308.543261 L 349.6 308.56814 L 350.6 308.580224 L 351.6 308.583986 L 352.6 308.57955 L 353.6 308.567211 L 354.6 308.552798 L 355.6 308.536725 L 356.6 308.501204 L 357.6 308.48127 L 358.6 308.424681 L 359.6 308.357487 L 360.6 308.330117 L 361.6 308.295969 L 362.6 308.247289 L 363.6 308.199004 L 364.6 308.139927 L 365.6 308.044322 L 366.6 308.001182 L 367.6 307.951334 L 368.6 307.8928 L 369.6 307.845214 L 370.6 307.784086 L 371.6 307.728001 L 372.6 307.65383 L 373.6 307.536592 L 374.6 307.480868 L 375.6 307.372642 L 376.6 307.266492 L 377.6 307.15892 L 378.6 307.124412 L 379.6 307.021105 L 380.6 306.945381 L 381.6 306.905946 L 382.6 306.866562 L 383.6 306.84408 L 384.6 306.788267 L 385.6 306.762215 L 386.6 306.73198 L 387.6 306.681209 L 388.6 306.662558 L 389.6 306.640849 L 390.6 306.628203 L 391.6 306.60921 L 392.6 306.59182 L 393.6 306.584782 L 394.6 306.585806 L 395.6 306.59281 L 396.6 306.60218 L 397.6 306.625578 L 398.6 306.650661 L 399.6 306.66306 L 400.6 306.696153 L 401.6 306.71252 L 402.6 306.730925 L 403.6 306.780062 L 404.6 306.823875 L 405.6 306.86696 L 406.6 306.889901 L 407.6 306.930164 L 408.6 307.015024 L 409.6 307.057416 L 410.6 307.121802 L 411.6 307.166091 L 412.6 307.273937 L 413.6 307.350877 L 414.72 307.387319 L 414.578206 306.584 L 414.653307 305.584 L 414.711902 304.584 L 414.748477 303.584 L 414.860524 302.584 L 414.922209 301.584 L 414.972729 300.584 L 415.071514 299.584 L 415.109536 298.584 L 415.144984 297.584 L 415.236618 296.584 L 415.27989 295.584 L 415.333219 294.584 L 415.366084 293.584 L 415.428978 292.584 L 415.482832 291.584 L 415.539958 290.584 L 415.562048 289.584 L 415.605787 288.584 L 415.652881 287.584 L 415.669728 286.584 L 415.697802 285.584 L 415.708798 284.584 L 415.713367 283.584 L 415.719015 282.584 L 415.719066 281.584 L 415.715976 280.584 L 415.712463 279.584 L 415.706641 278.584 L 415.693789 277.584 L 415.670164 276.584 L 415.65528 275.584 L 415.631708 274.584 L 415.595389 273.584 L 415.563806 272.584 L 415.533913 271.584 L 415.455221 270.584 L 415.41867 269.584 L 415.392947 268.584 L 415.322274 267.584 L 415.231172 266.584 L 415.169215 265.584 L 415.135602 264.584 L 415.101102 263.584 L 415.003662 262.584 L 414.956072 261.584 L 414.924566 260.584 L 414.880881 259.584 L 414.810712 258.584 L 414.760845 257.584 L 414.726168 256.584 L 414.61652 255.584 L 414.583049 254.584 L 414.545707 253.584 L 414.465462 252.584 L 414.426968 251.584 L 414.385191 250.584 L 414.342766 249.584 L 414.233038 248.584 L 414.144753 247.584 L 414.070107 246.584 L 413.98165 245.584 L 413.907588 244.584 L 413.858423 243.584 L 413.802806 242.584 L 413.768106 241.584 L 413.756235 240.584 L 413.734012 239.584 L 413.722033 238.584 L 413.720281 237.584 L 413.725698 236.584 L 413.741896 235.584 L 413.758396 234.584 L 413.789579 233.584 L 413.802944 232.584 L 413.832587 231.584 L 413.89561 230.584 L 413.944931 229.584 L 413.99102 228.584 L 414.073247 227.584 L 414.11915 226.584 L 414.153475 225.584 L 414.207014 224.584 L 414.295901 223.584 L 414.327039 222.584 L 414.435088 221.584 L 414.54716 220.584 L 414.582598 219.584 L 414.667384 218.584 L 414.732991 217.584 L 414.835045 216.584 L 414.95126 215.584 L 414.991951 214.584 L 415.03304 213.584 L 415.069681 212.584 L 415.110677 211.584 L 415.186746 210.584 L 415.262812 209.584 L 415.2935 208.584 L 415.319991 207.584 L 415.376572 206.584 L 415.421088 205.584 L 415.451106 204.584 L 415.478162 203.584 L 415.520727 202.584 L 415.573592 201.584 L 415.604513 200.584 L 415.630788 199.584 L 415.645721 198.584 L 415.67601 197.584 L 415.697339 196.584 L 415.714228 195.584 L 415.718943 194.584 L 415.719553 193.584 L 415.717507 192.584 L 415.711646 191.584 L 415.692999 190.584 L 415.660942 189.584 L 415.614502 188.584 L 415.572556 187.584 L 415.505851 186.584 L 415.436785 185.584 L 415.38941 184.584 L 415.337891 183.584 L 415.298191 182.584 L 415.228771 181.584 L 415.16224 180.584 L 415.053331 179.584 L 414.988083 178.584 L 414.879875 177.584 L 414.818871 176.584 L 414.770186 175.584 L 414.693952 174.584 L 414.634421 173.584 L 414.559793 172.584 L 414.440966 171.584 L 414.343021 170.584 L 414.263973 169.584 L 414.218226 168.584 L 414.190954 167.584 L 414.147292 166.584 L 414.098708 165.584 L 414.066974 164.584 L 413.986744 163.584 L 413.920251 162.584 L 413.896226 161.584 L 413.835727 160.584 L 413.813495 159.584 L 413.794895 158.584 L 413.765569 157.584 L 413.749868 156.584 L 413.741569 155.584 L 413.731333 154.584 L 413.72099 153.584 L 413.721668 152.584 L 413.725448 151.584 L 413.741889 150.584 L 413.754023 149.584 L 413.764618 148.584 L 413.795995 147.584 L 413.821768 146.584 L 413.853177 145.584 L 413.875986 144.584 L 413.89358 143.584 L 413.943392 142.584 L 413.991052 141.584 L 414.062761 140.584 L 414.118524 139.584 L 414.144722 138.584 L 414.17549 137.584 L 414.265248 136.584 L 414.350042 135.584 L 414.415636 134.584 L 414.461461 133.584 L 414.504458 132.584 L 414.565971 131.584 L 414.665796 130.584 L 414.710226 129.584 L 414.760276 128.584 L 414.882117 127.584 L 414.94181 126.584 L 414.973376 125.584 L 415.005719 124.584 L 415.060279 123.584 L 415.102779 122.584 L 415.154251 121.584 L 415.242636 120.584 L 415.276833 119.584 L 415.320767 118.584 L 415.38448 117.584 L 415.459677 116.584 L 415.488491 115.584 L 415.530695 114.584 L 415.57328 113.584 L 415.590172 112.584 L 415.612653 111.584 L 415.65499 110.584 L 415.68495 109.584 L 415.703583 108.584 L 415.713375 107.584 L 415.717138 106.584 L 415.719976 105.584 L 415.718227 104.584 L 415.708871 103.584 L 415.698174 102.584 L 415.688304 101.584 L 415.669446 100.584 L 415.639107 99.584 L 415.600716 98.584 L 415.54123 97.584 L 415.497941 96.584 L 415.437203 95.584 L 415.353129 94.584 L 415.304836 93.584 L 415.261259 92.584 L 415.234378 91.584 L 415.202448 90.584 L 415.135256 89.584 L 415.054435 88.584 L 414.97889 87.584 L 414.93516 86.584 L 414.855265 85.584 L 414.793786 84.584 L 414.730161 83.584 L 414.622912 82.584 L 414.504202 81.584 L 414.462296 80.584 L 414.419342 79.584 L 414.357143 78.584 L 414.327006 77.584 L 414.294488 76.584 L 414.242553 75.584 L 414.137003 74.584 L 414.088557 73.584 L 414.042233 72.584 L 414.008417 71.584 L 413.96054 70.584 L 413.905662 69.584 L 413.881751 68.584 L 413.855714 67.584 L 413.799597 66.584 L 413.785723 65.584 L 413.759689 64.584 L 413.732943 63.584 L 413.725197 62.584 L 413.720044 61.584 L 413.726242 60.584 L 413.732549 59.584 L 413.74013 58.584 L 413.767636 57.584 L 413.811869 56.584 L 413.841407 55.584 L 413.883254 54.584 L 413.942428 53.584 L 413.965138 52.584 L 414.00177 51.584 L 414.058558 50.584 L 414.083728 49.584 L 414.166424 48.584 L 414.253356 47.584 L 414.30404 46.584 L 414.341434 45.584 L 414.425814 44.584 L 414.460325 43.584 L 414.552316 42.584 L 414.639341 41.472 L 413.72 41.429519 L 412.72 41.39165 L 411.72 41.344175 L 410.72 41.238649 L 409.72 41.141188 L 408.72 41.064551 L 407.72 41.032624 L 406.72 40.978384 L 405.72 40.939533 L 404.72 40.865828 L 403.72 40.833832 L 402.72 40.777293 L 401.72 40.741177 L 400.72 40.672575 L 399.72 40.641159 L 398.72 40.586492 L 397.72 40.567721 L 396.72 40.522092 L 395.72 40.499189 L 394.72 40.490648 L 393.72 40.483307 L 392.72 40.477012 L 391.72 40.473835 L 390.72 40.472249 L 389.72 40.473712 L 388.72 40.486666 L 387.72 40.501288 L 386.72 40.513144 L 385.72 40.531169 L 384.72 40.551547 L 383.72 40.574946 L 382.72 40.589855 L 381.72 40.644569 L 380.72 40.678166 L 379.72 40.740862 L 378.72 40.768237 L 377.72 40.812217 L 376.72 40.891164 L 375.72 40.948692 L 374.72 40.998671 L 373.72 41.070655 L 372.72 41.107187 L 371.72 41.1755 L 370.72 41.263706 L 369.72 41.385053 L 368.72 41.450734 L 367.72 41.484352 L 366.72 41.548629 L 365.72 41.5946 L 364.72 41.666757 L 363.72 41.706583 L 362.72 41.749213 L 361.72 41.855172 L 360.72 41.907957 L 359.72 41.987234 L 358.72 42.029638 L 357.72 42.061904 L 356.72 42.09677 L 355.72 42.139428 L 354.72 42.171001 L 353.72 42.23858 L 352.72 42.275465 L 351.72 42.303421 L 350.72 42.324269 L 349.72 42.349882 L 348.72 42.3875 L 347.72 42.402342 L 346.72 42.427072 L 345.72 42.445302 L 344.72 42.456709 L 343.72 42.462344 L 342.72 42.467098 L 341.72 42.471707 L 340.72 42.470034 L 339.72 42.464252 L 338.72 42.444256 L 337.72 42.432604 L 336.72 42.421615 L 335.72 42.408648 L 334.72 42.358234 L 333.72 42.337412 L 332.72 42.309465 L 331.72 42.25272 L 330.72 42.230076 L 329.72 42.178673 L 328.72 42.137537 L 327.72 42.054768 L 326.72 42.006308 L 325.72 41.954881 L 324.72 41.903721 L 323.72 41.836422 L 322.72 41.803268 L 321.72 41.73721 L 320.72 41.681025 L 319.72 41.619746 L 318.72 41.579763 L 317.72 41.48334 L 316.72 41.37158 L 315.72 41.332661 L 314.72 41.234812 L 313.72 41.200158 L 312.72 41.116476 L 311.72 41.06597 L 310.72 40.996927 L 309.72 40.895824 L 308.72 40.843378 L 307.72 40.75407 L 306.72 40.689062 L 305.72 40.647517 L 304.72 40.605177 L 303.72 40.583157 L 302.72 40.54567 L 301.72 40.528418 L 300.72 40.50501 L 299.72 40.496443 L 298.72 40.487354 L 297.72 40.480286 L 296.72 40.473259 L 295.72 40.472151 L 294.72 40.472137 L 293.72 40.474811 L 292.72 40.477837 L 291.72 40.483304 L 290.72 40.503299 L 289.72 40.51527 L 288.72 40.542389 L 287.72 40.569401 L 286.72 40.596567 L 285.72 40.651042 L 284.72 40.680658 L 283.72 40.722414 L 282.72 40.795523 L 281.72 40.838961 L 280.72 40.909652 L 279.72 40.948059 L 278.72 41.008398 L 277.72 41.039153 L 276.72 41.069651 L 275.72 41.128561 L 274.72 41.171738 L 273.72 41.21335 L 272.72 41.262465 L 271.72 41.327552 L 270.72 41.393947 L 269.72 41.51871 L 268.72 41.562525 L 267.72 41.616853 L 266.72 41.723557 L 265.72 41.766057 L 264.72 41.803551 L 263.72 41.893047 L 262.72 41.95027 L 261.72 42.019913 L 260.72 42.068932 L 259.72 42.124877 L 258.72 42.172002 L 257.72 42.21089 L 256.72 42.264582 L 255.72 42.310153 L 254.72 42.34709 L 253.72 42.369166 L 252.72 42.402049 L 251.72 42.431769 L 250.72 42.444319 L 249.72 42.456218 L 248.72 42.461336 L 247.72 42.469225 L 246.72 42.471856 L 245.72 42.471058 L 244.72 42.467817 L 243.72 42.452679 L 242.72 42.445742 L 241.72 42.429365 L 240.72 42.410952 L 239.72 42.38136 L 238.72 42.359278 L 237.72 42.301584 L 236.72 42.276393 L 235.72 42.20808 L 234.72 42.160954 L 233.72 42.123606 L 232.72 42.068397 L 231.72 41.978966 L 230.72 41.875856 L 229.72 41.821882 L 228.72 41.791162 L 227.72 41.735621 L 226.72 41.697886 L 225.72 41.629632 L 224.72 41.593803 L 223.72 41.524019 L 222.72 41.464725 L 221.72 41.426118 L 220.72 41.392122 L 219.72 41.349542 L 218.72 41.302893 L 217.72 41.248327 L 216.72 41.162426 L 215.72 41.11575 L 214.72 41.058435 L 213.72 41.028021 L 212.72 40.94297 L 211.72 40.909295 L 210.72 40.821371 L 209.72 40.766386 L 208.72 40.727697 L 207.72 40.657666 L 206.72 40.62722 L 205.72 40.569495 L 204.72 40.552351 L 203.72 40.527616 L 202.72 40.512116 L 201.72 40.488664 L 200.72 40.48185 L 199.72 40.477917 L 198.72 40.474185 L 197.72 40.472152 L 196.72 40.480538 L 195.72 40.496924 L 194.72 40.523194 L 193.72 40.536523 L 192.72 40.566477 L 191.72 40.600728 L 190.72 40.621398 L 189.72 40.66241 L 188.72 40.735728 L 187.72 40.758946 L 186.72 40.799312 L 185.72 40.826563 L 184.72 40.907101 L 183.72 40.960579 L 182.72 41.03915 L 181.72 41.087618 L 180.72 41.201648 L 179.72 41.302333 L 178.72 41.386757 L 177.72 41.478297 L 176.72 41.58071 L 175.72 41.621518 L 174.72 41.664661 L 173.72 41.703962 L 172.72 41.737385 L 171.72 41.780493 L 170.72 41.886072 L 169.72 41.941773 L 168.72 42.0471 L 167.72 42.144097 L 166.72 42.167117 L 165.72 42.194104 L 164.72 42.224205 L 163.72 42.297447 L 162.72 42.334839 L 161.72 42.369798 L 160.72 42.388374 L 159.72 42.41888 L 158.72 42.431092 L 157.72 42.440868 L 156.72 42.450437 L 155.72 42.458646 L 154.72 42.469922 L 153.72 42.471784 L 152.72 42.465482 L 151.72 42.459469 L 150.72 42.454012 L 149.72 42.43382 L 148.72 42.423931 L 147.72 42.396178 L 146.72 42.377171 L 145.72 42.361772 L 144.72 42.332507 L 143.72 42.268703 L 142.72 42.21965 L 141.72 42.149461 L 140.72 42.120352 L 139.72 42.060782 L 138.72 42.013833 L 137.72 41.962711 L 136.72 41.908658 L 135.72 41.826971 L 134.72 41.748314 L 133.72 41.711654 L 132.72 41.59 L 131.72 41.511058 L 130.72 41.446567 L 129.72 41.400939 L 128.72 41.28529 L 127.72 41.237015 L 126.72 41.201492 L 125.72 41.157914 L 124.72 41.122138 L 123.72 41.051313 L 122.72 41.014909 L 121.72 40.917433 L 120.72 40.848369 L 119.72 40.782403 L 118.72 40.717873 L 117.72 40.694451 L 116.72 40.667046 L 115.72 40.618552 L 114.72 40.588559 L 113.72 40.556021 L 112.72 40.541278 L 111.72 40.527738 L 110.72 40.504303 L 109.72 40.491823 L 108.72 40.484685 L 107.72 40.479087 L 106.72 40.473481 L 105.72 40.472 L 104.72 40.477993 L 103.72 40.483958 L 102.72 40.49547 L 101.72 40.519277 L 100.72 40.52941 L 99.72 40.571368 L 98.72 40.61344 L 97.72 40.644656 L 96.72 40.714514 L 95.72 40.75877 L 94.72 40.84124 L 93.72 40.929427 L 92.72 40.974347 L 91.72 41.070077 L 90.72 41.142181 L 89.72 41.237171 L 88.72 41.293545 L 87.72 41.337742 L 86.72 41.393558 L 85.72 41.433496 L 84.72 41.508947 L 83.72 41.566942 L 82.72 41.604129 L 81.72 41.662656 L 80.72 41.765433 L 79.72 41.82216 L 78.72 41.893165 L 77.72 41.954934 L 76.72 41.992397 L 75.72 42.027683 L 74.72 42.071101 L 73.72 42.11296 L 72.72 42.140583 L 71.72 42.191698 L 70.72 42.225234 L 69.72 42.287297 L 68.72 42.306939 L 67.72 42.368712 L 66.72 42.391191 L 65.72 42.411414 L 64.72 42.432103 L 63.72 42.45853 L 62.72 42.469487 L 61.72 42.471269 L 60.72 42.468641 L 59.72 42.462091 L 58.72 42.440128 L 57.6 42.401128 L 58.508845 42.472 L 58.492196 43.472 L 58.430573 44.472 L 58.401989 45.472 L 58.378481 46.472 L 58.334033 47.472 L 58.30807 48.472 L 58.25771 49.472 L 58.181318 50.472 L 58.153797 51.472 L 58.121939 52.472 L 58.086315 53.472 L 57.998542 54.472 L 57.901531 55.472 L 57.821578 56.472 L 57.703903 57.472 L 57.631909 58.472 L 57.527743 59.472 L 57.416434 60.472 L 57.321012 61.472 L 57.226115 62.472 L 57.159096 63.472 L 57.098211 64.472 L 57.05375 65.472 L 57.018079 66.472 L 56.938783 67.472 L 56.908528 68.472 L 56.834884 69.472 L 56.802439 70.472 L 56.757912 71.472 L 56.736656 72.472 L 56.708304 73.472 L 56.679978 74.472 L 56.645645 75.472 L 56.632329 76.472 L 56.615537 77.472 L 56.604993 78.472 L 56.601874 79.472 L 56.600038 80.472 L 56.605027 81.472 L 56.610475 82.472 L 56.62462 83.472 L 56.659254 84.472 L 56.678281 85.472 L 56.720881 86.472 L 56.738986 87.472 L 56.783389 88.472 L 56.805819 89.472 L 56.846087 90.472 L 56.878592 91.472 L 56.941903 92.472 L 57.030413 93.472 L 57.116883 94.472 L 57.196518 95.472 L 57.250304 96.472 L 57.310415 97.472 L 57.381456 98.472 L 57.501577 99.472 L 57.606039 100.472 L 57.716842 101.472 L 57.770115 102.472 L 57.843365 103.472 L 57.881948 104.472 L 57.957711 105.472 L 58.035272 106.472 L 58.121412 107.472 L 58.148855 108.472 L 58.244831 109.472 L 58.320941 110.472 L 58.371105 111.472 L 58.425458 112.472 L 58.453129 113.472 L 58.489151 114.472 L 58.520712 115.472 L 58.538819 116.472 L 58.555558 117.472 L 58.572565 118.472 L 58.589619 119.472 L 58.59403 120.472 L 58.598289 121.472 L 58.599886 122.472 L 58.598359 123.472 L 58.595935 124.472 L 58.592476 125.472 L 58.582211 126.472 L 58.562483 127.472 L 58.550784 128.472 L 58.50804 129.472 L 58.48236 130.472 L 58.438178 131.472 L 58.382063 132.472 L 58.325365 133.472 L 58.293505 134.472 L 58.256796 135.472 L 58.228663 136.472 L 58.172864 137.472 L 58.138147 138.472 L 58.06646 139.472 L 58.010402 140.472 L 57.928747 141.472 L 57.873173 142.472 L 57.788865 143.472 L 57.74624 144.472 L 57.655234 145.472 L 57.594949 146.472 L 57.489872 147.472 L 57.425687 148.472 L 57.346491 149.472 L 57.280264 150.472 L 57.225988 151.472 L 57.192861 152.472 L 57.136147 153.472 L 57.09259 154.472 L 56.995347 155.472 L 56.921401 156.472 L 56.859607 157.472 L 56.831192 158.472 L 56.805858 159.472 L 56.739603 160.472 L 56.696586 161.472 L 56.668079 162.472 L 56.656085 163.472 L 56.642011 164.472 L 56.631183 165.472 L 56.615885 166.472 L 56.606029 167.472 L 56.600216 168.472 L 56.601051 169.472 L 56.603013 170.472 L 56.606621 171.472 L 56.623932 172.472 L 56.633663 173.472 L 56.667693 174.472 L 56.692764 175.472 L 56.731461 176.472 L 56.797395 177.472 L 56.838383 178.472 L 56.913224 179.472 L 56.945151 180.472 L 56.969365 181.472 L 56.995185 182.472 L 57.054225 183.472 L 57.108937 184.472 L 57.215139 185.472 L 57.295415 186.472 L 57.412157 187.472 L 57.51212 188.472 L 57.564434 189.472 L 57.603007 190.472 L 57.639368 191.472 L 57.760354 192.472 L 57.791539 193.472 L 57.827915 194.472 L 57.890066 195.472 L 57.978077 196.472 L 58.02247 197.472 L 58.070988 198.472 L 58.169778 199.472 L 58.211246 200.472 L 58.253898 201.472 L 58.318748 202.472 L 58.385183 203.472 L 58.405272 204.472 L 58.429751 205.472 L 58.470359 206.472 L 58.494905 207.472 L 58.511852 208.472 L 58.542871 209.472 L 58.565923 210.472 L 58.585366 211.472 L 58.592773 212.472 L 58.596995 213.472 L 58.599656 214.472 L 58.599239 215.472 L 58.593894 216.472 L 58.584738 217.472 L 58.572213 218.472 L 58.545446 219.472 L 58.51655 220.472 L 58.46624 221.472 L 58.437897 222.472 L 58.382994 223.472 L 58.345187 224.472 L 58.292498 225.472 L 58.262794 226.472 L 58.231793 227.472 L 58.201321 228.472 L 58.159084 229.472 L 58.131062 230.472 L 58.033515 231.472 L 57.95707 232.472 L 57.901773 233.472 L 57.820903 234.472 L 57.743522 235.472 L 57.662112 236.472 L 57.605147 237.472 L 57.482034 238.472 L 57.450465 239.472 L 57.383234 240.472 L 57.304942 241.472 L 57.212389 242.472 L 57.178235 243.472 L 57.147321 244.472 L 57.096996 245.472 L 57.052178 246.472 L 57.011177 247.472 L 56.981322 248.472 L 56.936474 249.472 L 56.85321 250.472 L 56.83115 251.472 L 56.787033 252.472 L 56.766871 253.472 L 56.706749 254.472 L 56.66452 255.472 L 56.641263 256.472 L 56.623268 257.472 L 56.616266 258.472 L 56.604027 259.472 L 56.600558 260.472 L 56.601741 261.472 L 56.605916 262.472 L 56.619646 263.472 L 56.627297 264.472 L 56.641737 265.472 L 56.672389 266.472 L 56.697078 267.472 L 56.717325 268.472 L 56.735798 269.472 L 56.754752 270.472 L 56.789358 271.472 L 56.856641 272.472 L 56.904869 273.472 L 56.934251 274.472 L 56.966094 275.472 L 57.044318 276.472 L 57.14353 277.472 L 57.187424 278.472 L 57.298184 279.472 L 57.351957 280.472 L 57.410165 281.472 L 57.446342 282.472 L 57.501133 283.472 L 57.584084 284.472 L 57.631754 285.472 L 57.720599 286.472 L 57.768247 287.472 L 57.848469 288.472 L 57.937896 289.472 L 57.982122 290.472 L 58.041179 291.472 L 58.139628 292.472 L 58.17467 293.472 L 58.220434 294.472 L 58.273635 295.472 L 58.309483 296.472 L 58.351738 297.472 L 58.393097 298.472 L 58.420445 299.472 L 58.48147 300.472 L 58.504483 301.472 L 58.519261 302.472 L 58.534284 303.472 L 58.547208 304.472 L 58.579534 305.472 L 58.596802 306.472 L 58.599844 307.584 z " + style="fill: #ffffff" + id="path4" /> + </g> + <g + id="matplotlib.axis_1"> + <g + id="text_1"> + <path + d="M 171.004219 322.974312 C 172.165781 322.974312 172.165781 320.854625 172.165781 320.143687 C 172.165781 319.15275 171.995156 318.168375 171.995156 317.162125 C 171.995156 316.013688 172.124219 314.86525 172.124219 313.703688 C 172.124219 313.581187 172.124219 313.095562 172.084844 312.631813 C 172.043281 312.200875 171.940469 311.708687 171.686719 311.708687 C 171.181406 311.708687 170.647656 311.885875 170.566719 312.487437 C 170.457344 313.34275 170.483594 314.279 170.483594 315.132125 L 170.498906 317.05275 C 170.512031 318.017437 170.737344 319.014937 170.737344 319.99275 C 170.737344 320.005875 170.737344 320.124 170.724219 320.218062 C 170.724219 320.314312 170.724219 320.410563 170.682656 320.410563 C 170.586406 320.410563 170.437656 320.060563 170.299844 319.71275 C 170.164219 319.349625 170.032969 318.966813 170.006719 318.885875 C 169.540781 317.599625 166.957344 312.568375 165.487344 312.568375 C 164.564219 312.568375 164.564219 314.559 164.564219 315.105875 C 164.564219 317.286812 164.673594 319.480875 164.673594 321.661812 C 164.673594 322.167125 165.139531 322.987437 165.725781 322.987437 C 166.382031 322.987437 166.436719 321.819313 166.436719 321.353375 C 166.436719 320.349312 166.287969 319.343062 166.287969 318.339 C 166.287969 317.389625 166.075781 316.444625 166.075781 315.482125 C 166.075781 315.466813 166.047344 315.208687 166.102031 315.208687 C 166.465156 315.208687 168.427344 319.391188 168.707344 320.034312 C 169.028906 320.8065 170.000156 322.974312 171.004219 322.974312 z M 174.988477 316.096812 C 174.367227 316.424937 174.209727 317.450875 174.058789 318.297438 C 173.691289 320.375563 173.697852 323.05525 176.261602 322.794938 C 177.230664 322.700875 178.256602 322.186812 178.845039 321.456187 C 179.144727 321.0865 179.433477 320.506813 179.520977 320.054 C 179.733164 318.966813 179.426914 317.881813 179.234414 317.05275 C 179.166602 316.766188 179.118477 316.4665 178.871289 316.383375 C 178.652539 316.309 178.236914 316.444625 178.147227 316.61525 C 178.005039 316.888688 178.324414 317.5865 178.407539 317.96275 C 178.510352 318.448375 178.571602 319.104625 178.536602 319.6165 C 178.455664 320.74525 177.410039 321.661812 176.261602 321.764625 C 175.988164 321.790875 175.625039 321.810563 175.406289 321.709938 C 175.132852 321.578688 174.997227 321.108375 174.942539 320.751812 C 174.675664 318.934 175.338477 317.846812 175.480664 316.357125 C 175.371289 316.21275 175.152539 316.17775 174.988477 316.096812 z M 186.200781 322.399 C 186.467656 321.749312 186.555156 320.764937 186.686406 319.83525 C 186.808906 318.947125 186.924844 317.969313 187.342656 317.444313 C 187.513281 317.232125 187.944219 316.904 188.278906 316.93025 C 188.838906 316.971812 189.234844 317.763688 189.221719 318.413375 C 189.215156 318.721812 189.051094 319.207438 188.906719 319.609938 C 188.703281 320.191813 188.462656 320.896187 188.510781 321.626812 C 188.539219 322.003062 188.729531 322.61775 189.051094 322.794938 C 189.385781 322.980875 189.864844 322.685563 189.932656 322.37275 C 189.993906 322.09275 189.652656 321.893687 189.617656 321.572125 C 189.597969 321.408062 189.639531 321.14775 189.672344 320.977125 C 189.823281 320.191813 190.295781 319.268687 190.357031 318.4965 C 190.411719 317.853375 190.157969 317.177437 189.851719 316.733375 C 189.420781 316.1165 188.639844 315.598062 187.710156 315.878062 C 187.130469 316.05525 186.767344 316.418375 186.342969 316.958687 C 186.310156 316.68525 186.097969 316.376812 185.914219 316.158062 C 185.120156 315.61775 183.794531 316.035563 183.241094 316.704937 C 183.061719 316.917125 183.007031 317.170875 182.810156 317.299937 C 182.823281 316.998063 182.816719 316.05525 182.530156 315.904313 C 182.331094 315.803688 182.022656 315.994 181.757969 316.022438 C 181.523906 316.389937 181.668281 316.875563 181.703281 317.389625 C 181.784219 318.52275 181.893594 319.979625 181.812656 321.06025 C 181.777656 321.482438 181.539219 321.919938 181.585156 322.256813 C 181.613594 322.466813 181.845469 322.630875 181.928594 322.768687 C 182.398906 322.93275 182.672344 322.685563 182.871406 322.256813 C 182.952344 320.5265 183.308906 318.831187 184.032969 317.499 C 184.341406 317.28025 184.586406 317.013375 185.148594 317.046187 C 185.640781 318.255875 184.975781 320.375563 185.148594 321.858687 C 185.181406 322.18025 185.380469 322.37275 185.516094 322.514937 C 185.782969 322.5215 185.995156 322.453688 186.200781 322.399 z M 192.483555 317.334938 C 192.49668 316.534312 192.55793 315.173687 192.483555 314.224312 C 192.455117 313.889625 192.40043 313.137125 192.100742 313.075875 C 191.92793 313.040875 191.763867 313.178688 191.615117 313.178688 C 191.28043 314.018687 191.62168 315.420875 191.512305 316.77275 C 191.435742 317.689312 191.36793 318.654 191.409492 319.55525 C 191.457617 320.568062 191.483867 322.105875 192.249492 321.90025 C 192.448555 321.845562 192.61918 321.810563 192.686992 321.62025 C 193.645117 322.193375 195.272617 322.18025 196.106055 321.491188 C 196.33793 321.298687 196.447305 321.053688 196.666055 320.880875 C 196.974492 320.191813 197.46668 319.200875 197.27418 318.249312 C 197.18668 317.80525 196.95918 317.422438 196.788555 317.05275 C 196.270117 316.499312 195.791055 316.048687 194.826367 316.035563 C 193.719492 316.022438 192.966992 316.704937 192.483555 317.334938 z M 194.34293 321.06025 C 193.699805 321.066813 193.17918 320.799937 192.763555 320.471812 C 192.74168 318.796187 193.207617 317.464 194.417305 317.081187 C 194.732305 316.978375 195.327305 317.100875 195.546055 317.232125 C 196.701055 317.9365 196.318242 320.178688 195.285742 320.826188 C 195.12168 320.929 194.58793 321.06025 194.34293 321.06025 z M 199.577617 319.522438 C 200.24918 319.631813 201.041055 319.535563 201.957617 319.459 C 202.955117 319.378062 203.816992 319.522438 204.21293 318.947125 C 204.547617 317.921187 204.261055 316.698375 203.49543 316.1165 C 202.941992 315.694313 201.935742 315.412125 201.170117 315.604625 C 200.658242 315.733687 199.831367 316.274 199.393867 316.814312 C 198.608555 317.779 197.998242 319.67775 198.615117 320.964 C 198.96293 321.517437 199.27793 321.983375 199.844492 322.289625 C 200.822305 322.823375 201.951055 322.563063 202.858867 322.263375 C 203.289805 322.119 203.77543 321.954937 204.061992 321.723063 C 204.241367 321.578688 204.425117 321.292125 204.363867 321.0865 C 204.315742 320.909312 203.904492 320.539625 203.646367 320.546187 C 203.421055 320.55275 203.24168 320.8415 203.009805 320.964 C 202.395117 321.298687 201.27293 321.668375 200.481055 321.333687 C 199.83793 321.06025 199.551367 320.355875 199.577617 319.522438 z M 202.55918 316.93025 C 202.86543 317.094313 203.235117 317.599625 203.160742 318.229625 C 201.99918 318.24275 200.96668 318.345562 199.818242 318.43525 C 200.172617 317.553688 201.294805 316.260875 202.55918 316.93025 z M 210.160742 316.827437 C 210.138867 316.978375 210.228555 317.019938 210.270117 317.107438 C 210.93293 317.56025 211.460117 317.068062 211.27418 316.376812 C 211.096992 316.103375 210.83668 315.913063 210.49543 315.794938 C 209.27918 315.385875 207.069805 315.768687 206.529492 316.575875 C 206.406992 316.383375 205.86668 316.350563 205.669805 316.49275 C 205.545117 316.582438 205.512305 316.882125 205.49918 317.135875 C 205.457617 317.827125 205.553867 318.702125 205.49918 319.364937 C 205.396367 320.607438 205.396367 321.797438 205.52543 322.549937 C 205.64793 322.679 205.792305 322.781813 205.943242 322.884625 C 206.14668 322.8365 206.133555 322.843062 206.36543 322.858375 C 206.483555 322.762125 206.564492 322.630875 206.673867 322.5215 C 206.577617 321.86525 206.667305 321.250563 206.728555 320.513375 C 206.824805 319.349625 206.818242 318.107125 207.31043 317.299937 C 207.850742 316.724625 209.128242 316.656813 210.160742 316.827437 z M 219.08793 315.2415 C 218.444805 315.269937 217.768867 315.733687 217.412305 316.096812 C 217.27668 316.232438 217.15418 316.479625 216.990117 316.691813 C 216.537305 317.286812 216.108555 318.271187 215.99918 319.124312 C 215.813242 320.546187 216.333867 321.954937 217.125742 322.475563 C 217.27668 322.569625 217.639805 322.749 217.865117 322.781813 C 218.569492 322.884625 219.457617 322.536812 219.96293 322.21525 C 220.58418 321.819313 221.220742 321.128062 221.49418 320.484938 C 221.999492 319.303688 221.780742 317.730875 221.268867 316.801188 C 221.098242 316.49275 220.844492 316.260875 220.58418 316.007125 C 220.14668 315.584938 219.70918 315.21525 219.08793 315.2415 z M 217.585117 317.737437 C 217.781992 317.374312 218.521367 316.37025 219.08793 316.350563 C 219.094492 316.350563 219.116367 316.309 219.142617 316.322125 C 220.02418 316.704937 220.673867 317.676188 220.673867 319.043375 C 220.673867 319.809 220.256055 320.498063 219.792305 320.944313 C 219.381055 321.34025 218.547617 321.784312 218.007305 321.6465 C 217.65293 321.559 217.412305 321.195875 217.296367 320.915875 C 216.928867 320.02775 217.132305 318.551188 217.585117 317.737437 z M 226.116367 312.8965 C 226.538555 313.082437 226.99793 313.334 227.483555 313.581187 C 227.912305 313.799937 228.522617 314.237437 228.883555 314.163063 C 229.178867 314.099625 229.533242 313.404 229.436992 313.191812 C 229.288242 312.87025 228.365117 312.644937 227.975742 312.439312 C 227.345742 312.111187 226.888555 311.796187 226.409492 311.59275 C 225.96543 311.55775 225.534492 311.647438 225.206367 311.885875 C 224.43418 312.828688 224.33793 314.237437 224.228555 315.727125 C 223.292305 315.646187 222.636055 315.823375 222.92918 316.834 C 223.169805 317.107438 223.83918 316.936812 224.228555 317.0615 C 224.167305 318.345562 224.427617 319.343062 224.427617 320.539625 C 224.427617 321.388375 224.228555 322.289625 224.65293 322.788375 C 224.913242 322.788375 225.18668 322.803688 225.40543 322.755562 C 225.521367 322.5915 225.637305 322.392437 225.663555 322.202125 C 225.910742 320.629313 225.425117 318.693375 225.569492 317.129313 C 226.18418 317.013375 227.091992 317.081187 227.448555 316.669938 C 227.74168 316.33525 227.544805 315.891188 227.256055 315.694313 C 226.86668 315.420875 226.696055 315.61775 226.348242 315.727125 C 226.094492 315.81025 225.84293 315.794938 225.534492 315.858375 C 225.541055 315.324625 225.602305 314.784312 225.691992 314.263688 C 225.779492 313.758375 225.74668 313.178688 226.116367 312.8965 z M 237.258125 314.928688 C 237.496562 313.915875 237.721875 312.706187 237.518438 311.728375 C 237.299688 311.584 236.971563 311.551187 236.83375 311.632125 C 236.129375 312.049937 236.245312 314.073375 235.952187 314.928688 C 235.254375 315.029313 234.504062 314.764625 233.99 315.029313 C 233.941875 315.30275 233.784375 315.788375 233.99 316.007125 C 234.407812 316.241188 235.077187 316.219313 235.720312 316.232438 C 235.691875 316.7115 235.5825 317.422438 235.55625 317.9365 C 235.473125 319.548687 235.466562 321.600563 236.376562 322.405562 C 237.010937 322.974312 238.249062 322.81025 239.0825 322.536812 C 239.3625 322.447125 239.690625 322.399 239.835 322.2765 C 240.121562 322.029313 239.93125 321.469313 239.73875 321.202437 C 239.089062 320.977125 238.010625 321.825875 237.354375 321.49775 C 236.95625 321.298687 236.901562 320.382125 236.862188 319.828688 C 236.779062 318.673687 236.916875 317.232125 237.02625 316.232438 C 237.84 316.1865 238.638437 316.3965 239.506875 316.267437 C 239.786875 316.042125 239.684062 315.427437 239.506875 315.125563 C 238.850625 314.968062 237.98875 315.009625 237.258125 314.928688 z M 245.728125 316.827437 C 245.70625 316.978375 245.795937 317.019938 245.8375 317.107438 C 246.500313 317.56025 247.0275 317.068062 246.841562 316.376812 C 246.664375 316.103375 246.404062 315.913063 246.062813 315.794938 C 244.846563 315.385875 242.637187 315.768687 242.096875 316.575875 C 241.974375 316.383375 241.434062 316.350563 241.237188 316.49275 C 241.1125 316.582438 241.079687 316.882125 241.066562 317.135875 C 241.025 317.827125 241.12125 318.702125 241.066562 319.364937 C 240.96375 320.607438 240.96375 321.797438 241.092812 322.549937 C 241.215312 322.679 241.359688 322.781813 241.510625 322.884625 C 241.714062 322.8365 241.700937 322.843062 241.932812 322.858375 C 242.050937 322.762125 242.131875 322.630875 242.24125 322.5215 C 242.145 321.86525 242.234688 321.250563 242.295937 320.513375 C 242.392187 319.349625 242.385625 318.107125 242.877813 317.299937 C 243.418125 316.724625 244.695625 316.656813 245.728125 316.827437 z M 253.574687 317.162125 C 253.526562 317.0615 253.349375 317.100875 253.246562 317.05275 C 252.844063 316.514625 252.214062 316.068375 251.284375 316.096812 C 249.015938 316.158062 247.80625 318.68025 247.812813 320.880875 C 247.812813 321.257125 247.887187 321.755875 248.1125 322.077437 C 248.394687 322.475563 248.816875 322.685563 249.234688 322.816813 C 251.155312 322.823375 251.98875 321.749312 252.8375 320.690562 C 253.104375 321.62025 253.506875 323.029 254.532812 322.762125 C 254.887187 322.482125 254.812813 321.764625 254.36875 321.694625 C 254.005625 321.018687 253.754062 320.069313 253.684062 319.104625 C 253.644687 318.448375 253.8 317.750563 253.574687 317.162125 z M 250.328438 317.435563 C 250.984688 317.019938 252.065313 317.074625 252.564062 317.573375 C 252.49625 317.9365 252.605625 318.428688 252.564062 318.748063 C 252.474375 319.452437 251.86625 320.327437 251.284375 320.90275 C 250.83375 321.353375 249.761875 322.09275 249.015938 321.530562 C 248.626562 320.089 249.260937 318.12025 250.328438 317.435563 z M 261.306953 322.727125 C 261.628516 322.659312 262.031016 322.727125 262.181953 322.536812 C 262.304453 322.379313 262.216953 322.070875 262.216953 321.819313 C 262.223516 319.951188 262.722266 317.544938 261.586953 316.007125 C 261.223828 315.514937 260.451641 314.989937 259.679453 315.009625 C 258.434766 315.038063 257.868203 315.919625 257.308203 316.724625 C 257.295078 316.438063 257.253516 316.171187 257.150703 315.974312 C 256.912266 315.849625 256.459453 315.974312 256.240703 316.068375 C 256.056953 317.264937 256.146641 319.343062 256.091953 320.848063 C 256.076641 321.21775 255.851328 322.447125 256.179453 322.727125 C 256.404766 322.919625 257.076328 322.858375 257.211953 322.694313 C 257.349766 322.5215 257.286328 322.228375 257.308203 321.941813 C 257.395703 320.635875 257.382578 319.609938 257.868203 318.413375 C 258.170078 317.676188 258.926953 315.803688 260.116953 316.350563 C 261.114453 316.80775 261.191016 318.702125 261.088203 320.163375 C 261.020391 321.128062 260.760078 322.18025 261.306953 322.727125 z M 265.278086 322.768687 C 265.525273 322.679 265.750586 322.816813 265.975898 322.816813 C 266.577461 322.816813 267.179023 322.49525 267.581523 322.186812 C 267.931523 321.919938 268.334023 321.545875 268.484961 321.163063 C 268.697148 320.616188 268.655586 319.780562 268.504648 319.288375 C 268.408398 318.975563 268.012461 318.503062 267.658086 318.43525 C 267.472148 318.40025 267.095898 318.406813 266.850898 318.483375 C 266.358711 318.638688 265.100898 319.500563 265.100898 318.43525 C 265.100898 317.811812 265.647773 317.21025 266.126836 317.129313 C 266.509648 317.068062 266.986523 317.258375 267.179023 317.380875 C 267.336523 317.483687 267.356211 317.695875 267.555273 317.709 C 267.719336 317.724312 268.108711 317.396187 268.128398 317.203688 C 268.134961 317.107438 268.073711 316.943375 268.034336 316.882125 C 267.760898 316.459938 266.899023 316.171187 266.378398 316.103375 C 265.792148 316.022438 265.017773 316.575875 264.753086 316.93025 C 264.595586 317.142437 264.383398 317.396187 264.300273 317.634625 C 264.013711 318.483375 264.116523 319.249 264.676523 319.760875 C 265.531836 320.259625 266.522773 319.664625 267.301523 319.384625 C 267.651523 319.638375 267.745586 320.382125 267.555273 320.8415 C 267.507148 320.950875 267.314648 321.154313 267.227148 321.237437 C 267.069648 321.381813 266.741523 321.6465 266.454961 321.74275 C 266.111523 321.852125 265.409336 321.86525 265.175273 321.537125 C 264.971836 321.250563 264.991523 320.764937 264.724648 320.690562 C 264.534336 320.635875 264.306836 320.880875 264.074961 320.964 C 263.952461 321.784312 264.444648 322.193375 264.827461 322.5915 C 264.998086 322.624312 265.149023 322.685563 265.278086 322.768687 z M 271.759922 321.674937 C 271.116797 320.089 271.423047 317.991188 271.506172 316.164625 C 271.567422 314.845562 271.779609 313.506813 271.814609 312.27525 C 271.731484 312.124312 271.676797 311.947125 271.608984 311.789625 C 271.403359 311.702125 271.197734 311.605875 270.917734 311.584 C 270.618047 311.625563 270.001172 311.831187 269.994609 312.194313 C 269.988047 312.43275 270.138984 312.74775 270.351172 312.787125 C 270.548047 312.828688 270.624609 312.658062 270.788672 312.706187 C 270.747109 313.266188 270.650859 313.880875 270.611484 314.524 C 270.569922 315.132125 270.576484 315.77525 270.508672 316.3965 C 270.309609 318.1815 270.219922 319.6515 270.583047 321.163063 C 270.727422 321.755875 270.821484 322.366188 271.197734 322.646187 C 271.615547 322.952437 272.381172 322.685563 272.477422 322.234938 C 272.551797 321.874 272.101172 321.517437 271.759922 321.674937 z M 279.127422 317.162125 C 279.079297 317.0615 278.902109 317.100875 278.799297 317.05275 C 278.396797 316.514625 277.766797 316.068375 276.837109 316.096812 C 274.568672 316.158062 273.358984 318.68025 273.365547 320.880875 C 273.365547 321.257125 273.439922 321.755875 273.665234 322.077437 C 273.947422 322.475563 274.369609 322.685563 274.787422 322.816813 C 276.708047 322.823375 277.541484 321.749312 278.390234 320.690562 C 278.657109 321.62025 279.059609 323.029 280.085547 322.762125 C 280.439922 322.482125 280.365547 321.764625 279.921484 321.694625 C 279.558359 321.018687 279.306797 320.069313 279.236797 319.104625 C 279.197422 318.448375 279.352734 317.750563 279.127422 317.162125 z M 275.881172 317.435563 C 276.537422 317.019938 277.618047 317.074625 278.116797 317.573375 C 278.048984 317.9365 278.158359 318.428688 278.116797 318.748063 C 278.027109 319.452437 277.418984 320.327437 276.837109 320.90275 C 276.386484 321.353375 275.314609 322.09275 274.568672 321.530562 C 274.179297 320.089 274.813672 318.12025 275.881172 317.435563 z M 284.508125 314.928688 C 284.746562 313.915875 284.971875 312.706187 284.768438 311.728375 C 284.549688 311.584 284.221563 311.551187 284.08375 311.632125 C 283.379375 312.049937 283.495313 314.073375 283.202187 314.928688 C 282.504375 315.029313 281.754062 314.764625 281.24 315.029313 C 281.191875 315.30275 281.034375 315.788375 281.24 316.007125 C 281.657812 316.241188 282.327187 316.219313 282.970312 316.232438 C 282.941875 316.7115 282.8325 317.422438 282.80625 317.9365 C 282.723125 319.548687 282.716563 321.600563 283.626562 322.405562 C 284.260938 322.974312 285.499062 322.81025 286.3325 322.536812 C 286.6125 322.447125 286.940625 322.399 287.085 322.2765 C 287.371562 322.029313 287.18125 321.469313 286.98875 321.202437 C 286.339063 320.977125 285.260625 321.825875 284.604375 321.49775 C 284.20625 321.298687 284.151563 320.382125 284.112188 319.828688 C 284.029063 318.673687 284.166875 317.232125 284.27625 316.232438 C 285.09 316.1865 285.888438 316.3965 286.756875 316.267437 C 287.036875 316.042125 286.934062 315.427437 286.756875 315.125563 C 286.100625 314.968062 285.23875 315.009625 284.508125 314.928688 z M 291.405312 315.2415 C 290.762187 315.269937 290.08625 315.733687 289.729688 316.096812 C 289.594063 316.232438 289.471563 316.479625 289.3075 316.691813 C 288.854688 317.286812 288.425937 318.271187 288.316562 319.124312 C 288.130625 320.546187 288.65125 321.954937 289.443125 322.475563 C 289.594063 322.569625 289.957187 322.749 290.1825 322.781813 C 290.886875 322.884625 291.775 322.536812 292.280312 322.21525 C 292.901562 321.819313 293.538125 321.128062 293.811562 320.484938 C 294.316875 319.303688 294.098125 317.730875 293.58625 316.801188 C 293.415625 316.49275 293.161875 316.260875 292.901562 316.007125 C 292.464062 315.584938 292.026563 315.21525 291.405312 315.2415 z M 289.9025 317.737437 C 290.099375 317.374312 290.83875 316.37025 291.405312 316.350563 C 291.411875 316.350563 291.43375 316.309 291.46 316.322125 C 292.341563 316.704937 292.99125 317.676188 292.99125 319.043375 C 292.99125 319.809 292.573437 320.498063 292.109688 320.944313 C 291.698438 321.34025 290.865 321.784312 290.324687 321.6465 C 289.970312 321.559 289.729688 321.195875 289.61375 320.915875 C 289.24625 320.02775 289.449687 318.551188 289.9025 317.737437 z M 299.978125 316.827437 C 299.95625 316.978375 300.045937 317.019938 300.0875 317.107438 C 300.750312 317.56025 301.2775 317.068062 301.091563 316.376812 C 300.914375 316.103375 300.654063 315.913063 300.312812 315.794938 C 299.096563 315.385875 296.887187 315.768687 296.346875 316.575875 C 296.224375 316.383375 295.684062 316.350563 295.487188 316.49275 C 295.3625 316.582438 295.329687 316.882125 295.316563 317.135875 C 295.275 317.827125 295.37125 318.702125 295.316563 319.364937 C 295.21375 320.607438 295.21375 321.797438 295.342812 322.549937 C 295.465312 322.679 295.609687 322.781813 295.760625 322.884625 C 295.964062 322.8365 295.950938 322.843062 296.182812 322.858375 C 296.300938 322.762125 296.381875 322.630875 296.49125 322.5215 C 296.395 321.86525 296.484687 321.250563 296.545937 320.513375 C 296.642187 319.349625 296.635625 318.107125 297.127813 317.299937 C 297.668125 316.724625 298.945625 316.656813 299.978125 316.827437 z M 303.77125 322.768687 C 304.018438 322.679 304.24375 322.816813 304.469063 322.816813 C 305.070625 322.816813 305.672188 322.49525 306.074687 322.186812 C 306.424688 321.919938 306.827187 321.545875 306.978125 321.163063 C 307.190313 320.616188 307.14875 319.780562 306.997813 319.288375 C 306.901562 318.975563 306.505625 318.503062 306.15125 318.43525 C 305.965312 318.40025 305.589062 318.406813 305.344063 318.483375 C 304.851875 318.638688 303.594063 319.500563 303.594063 318.43525 C 303.594063 317.811812 304.140938 317.21025 304.62 317.129313 C 305.002813 317.068062 305.479687 317.258375 305.672188 317.380875 C 305.829687 317.483687 305.849375 317.695875 306.048437 317.709 C 306.2125 317.724312 306.601875 317.396187 306.621562 317.203688 C 306.628125 317.107438 306.566875 316.943375 306.5275 316.882125 C 306.254063 316.459938 305.392187 316.171187 304.871562 316.103375 C 304.285313 316.022438 303.510937 316.575875 303.24625 316.93025 C 303.08875 317.142437 302.876562 317.396187 302.793437 317.634625 C 302.506875 318.483375 302.609688 319.249 303.169688 319.760875 C 304.025 320.259625 305.015938 319.664625 305.794688 319.384625 C 306.144688 319.638375 306.23875 320.382125 306.048437 320.8415 C 306.000313 320.950875 305.807812 321.154313 305.720312 321.237437 C 305.562813 321.381813 305.234688 321.6465 304.948125 321.74275 C 304.604687 321.852125 303.9025 321.86525 303.668437 321.537125 C 303.465 321.250563 303.484688 320.764937 303.217812 320.690562 C 303.0275 320.635875 302.8 320.880875 302.568125 320.964 C 302.445625 321.784312 302.937813 322.193375 303.320625 322.5915 C 303.49125 322.624312 303.642187 322.685563 303.77125 322.768687 z " + style="stroke: #ffffff; stroke-width: 4" + id="path5" /> + <path + d="M 171.004219 322.974312 C 172.165781 322.974312 172.165781 320.854625 172.165781 320.143687 C 172.165781 319.15275 171.995156 318.168375 171.995156 317.162125 C 171.995156 316.013688 172.124219 314.86525 172.124219 313.703688 C 172.124219 313.581187 172.124219 313.095562 172.084844 312.631813 C 172.043281 312.200875 171.940469 311.708687 171.686719 311.708687 C 171.181406 311.708687 170.647656 311.885875 170.566719 312.487437 C 170.457344 313.34275 170.483594 314.279 170.483594 315.132125 L 170.498906 317.05275 C 170.512031 318.017437 170.737344 319.014937 170.737344 319.99275 C 170.737344 320.005875 170.737344 320.124 170.724219 320.218062 C 170.724219 320.314312 170.724219 320.410563 170.682656 320.410563 C 170.586406 320.410563 170.437656 320.060563 170.299844 319.71275 C 170.164219 319.349625 170.032969 318.966813 170.006719 318.885875 C 169.540781 317.599625 166.957344 312.568375 165.487344 312.568375 C 164.564219 312.568375 164.564219 314.559 164.564219 315.105875 C 164.564219 317.286812 164.673594 319.480875 164.673594 321.661812 C 164.673594 322.167125 165.139531 322.987437 165.725781 322.987437 C 166.382031 322.987437 166.436719 321.819313 166.436719 321.353375 C 166.436719 320.349312 166.287969 319.343062 166.287969 318.339 C 166.287969 317.389625 166.075781 316.444625 166.075781 315.482125 C 166.075781 315.466813 166.047344 315.208687 166.102031 315.208687 C 166.465156 315.208687 168.427344 319.391188 168.707344 320.034312 C 169.028906 320.8065 170.000156 322.974312 171.004219 322.974312 z M 174.988477 316.096812 C 174.367227 316.424937 174.209727 317.450875 174.058789 318.297438 C 173.691289 320.375563 173.697852 323.05525 176.261602 322.794938 C 177.230664 322.700875 178.256602 322.186812 178.845039 321.456187 C 179.144727 321.0865 179.433477 320.506813 179.520977 320.054 C 179.733164 318.966813 179.426914 317.881813 179.234414 317.05275 C 179.166602 316.766188 179.118477 316.4665 178.871289 316.383375 C 178.652539 316.309 178.236914 316.444625 178.147227 316.61525 C 178.005039 316.888688 178.324414 317.5865 178.407539 317.96275 C 178.510352 318.448375 178.571602 319.104625 178.536602 319.6165 C 178.455664 320.74525 177.410039 321.661812 176.261602 321.764625 C 175.988164 321.790875 175.625039 321.810563 175.406289 321.709938 C 175.132852 321.578688 174.997227 321.108375 174.942539 320.751812 C 174.675664 318.934 175.338477 317.846812 175.480664 316.357125 C 175.371289 316.21275 175.152539 316.17775 174.988477 316.096812 z M 186.200781 322.399 C 186.467656 321.749312 186.555156 320.764937 186.686406 319.83525 C 186.808906 318.947125 186.924844 317.969313 187.342656 317.444313 C 187.513281 317.232125 187.944219 316.904 188.278906 316.93025 C 188.838906 316.971812 189.234844 317.763688 189.221719 318.413375 C 189.215156 318.721812 189.051094 319.207438 188.906719 319.609938 C 188.703281 320.191813 188.462656 320.896187 188.510781 321.626812 C 188.539219 322.003062 188.729531 322.61775 189.051094 322.794938 C 189.385781 322.980875 189.864844 322.685563 189.932656 322.37275 C 189.993906 322.09275 189.652656 321.893687 189.617656 321.572125 C 189.597969 321.408062 189.639531 321.14775 189.672344 320.977125 C 189.823281 320.191813 190.295781 319.268687 190.357031 318.4965 C 190.411719 317.853375 190.157969 317.177437 189.851719 316.733375 C 189.420781 316.1165 188.639844 315.598062 187.710156 315.878062 C 187.130469 316.05525 186.767344 316.418375 186.342969 316.958687 C 186.310156 316.68525 186.097969 316.376812 185.914219 316.158062 C 185.120156 315.61775 183.794531 316.035563 183.241094 316.704937 C 183.061719 316.917125 183.007031 317.170875 182.810156 317.299937 C 182.823281 316.998063 182.816719 316.05525 182.530156 315.904313 C 182.331094 315.803688 182.022656 315.994 181.757969 316.022438 C 181.523906 316.389937 181.668281 316.875563 181.703281 317.389625 C 181.784219 318.52275 181.893594 319.979625 181.812656 321.06025 C 181.777656 321.482438 181.539219 321.919938 181.585156 322.256813 C 181.613594 322.466813 181.845469 322.630875 181.928594 322.768687 C 182.398906 322.93275 182.672344 322.685563 182.871406 322.256813 C 182.952344 320.5265 183.308906 318.831187 184.032969 317.499 C 184.341406 317.28025 184.586406 317.013375 185.148594 317.046187 C 185.640781 318.255875 184.975781 320.375563 185.148594 321.858687 C 185.181406 322.18025 185.380469 322.37275 185.516094 322.514937 C 185.782969 322.5215 185.995156 322.453688 186.200781 322.399 z M 192.483555 317.334938 C 192.49668 316.534312 192.55793 315.173687 192.483555 314.224312 C 192.455117 313.889625 192.40043 313.137125 192.100742 313.075875 C 191.92793 313.040875 191.763867 313.178688 191.615117 313.178688 C 191.28043 314.018687 191.62168 315.420875 191.512305 316.77275 C 191.435742 317.689312 191.36793 318.654 191.409492 319.55525 C 191.457617 320.568062 191.483867 322.105875 192.249492 321.90025 C 192.448555 321.845562 192.61918 321.810563 192.686992 321.62025 C 193.645117 322.193375 195.272617 322.18025 196.106055 321.491188 C 196.33793 321.298687 196.447305 321.053688 196.666055 320.880875 C 196.974492 320.191813 197.46668 319.200875 197.27418 318.249312 C 197.18668 317.80525 196.95918 317.422438 196.788555 317.05275 C 196.270117 316.499312 195.791055 316.048687 194.826367 316.035563 C 193.719492 316.022438 192.966992 316.704937 192.483555 317.334938 z M 194.34293 321.06025 C 193.699805 321.066813 193.17918 320.799937 192.763555 320.471812 C 192.74168 318.796187 193.207617 317.464 194.417305 317.081187 C 194.732305 316.978375 195.327305 317.100875 195.546055 317.232125 C 196.701055 317.9365 196.318242 320.178688 195.285742 320.826188 C 195.12168 320.929 194.58793 321.06025 194.34293 321.06025 z M 199.577617 319.522438 C 200.24918 319.631813 201.041055 319.535563 201.957617 319.459 C 202.955117 319.378062 203.816992 319.522438 204.21293 318.947125 C 204.547617 317.921187 204.261055 316.698375 203.49543 316.1165 C 202.941992 315.694313 201.935742 315.412125 201.170117 315.604625 C 200.658242 315.733687 199.831367 316.274 199.393867 316.814312 C 198.608555 317.779 197.998242 319.67775 198.615117 320.964 C 198.96293 321.517437 199.27793 321.983375 199.844492 322.289625 C 200.822305 322.823375 201.951055 322.563063 202.858867 322.263375 C 203.289805 322.119 203.77543 321.954937 204.061992 321.723063 C 204.241367 321.578688 204.425117 321.292125 204.363867 321.0865 C 204.315742 320.909312 203.904492 320.539625 203.646367 320.546187 C 203.421055 320.55275 203.24168 320.8415 203.009805 320.964 C 202.395117 321.298687 201.27293 321.668375 200.481055 321.333687 C 199.83793 321.06025 199.551367 320.355875 199.577617 319.522438 z M 202.55918 316.93025 C 202.86543 317.094313 203.235117 317.599625 203.160742 318.229625 C 201.99918 318.24275 200.96668 318.345562 199.818242 318.43525 C 200.172617 317.553688 201.294805 316.260875 202.55918 316.93025 z M 210.160742 316.827437 C 210.138867 316.978375 210.228555 317.019938 210.270117 317.107438 C 210.93293 317.56025 211.460117 317.068062 211.27418 316.376812 C 211.096992 316.103375 210.83668 315.913063 210.49543 315.794938 C 209.27918 315.385875 207.069805 315.768687 206.529492 316.575875 C 206.406992 316.383375 205.86668 316.350563 205.669805 316.49275 C 205.545117 316.582438 205.512305 316.882125 205.49918 317.135875 C 205.457617 317.827125 205.553867 318.702125 205.49918 319.364937 C 205.396367 320.607438 205.396367 321.797438 205.52543 322.549937 C 205.64793 322.679 205.792305 322.781813 205.943242 322.884625 C 206.14668 322.8365 206.133555 322.843062 206.36543 322.858375 C 206.483555 322.762125 206.564492 322.630875 206.673867 322.5215 C 206.577617 321.86525 206.667305 321.250563 206.728555 320.513375 C 206.824805 319.349625 206.818242 318.107125 207.31043 317.299937 C 207.850742 316.724625 209.128242 316.656813 210.160742 316.827437 z M 219.08793 315.2415 C 218.444805 315.269937 217.768867 315.733687 217.412305 316.096812 C 217.27668 316.232438 217.15418 316.479625 216.990117 316.691813 C 216.537305 317.286812 216.108555 318.271187 215.99918 319.124312 C 215.813242 320.546187 216.333867 321.954937 217.125742 322.475563 C 217.27668 322.569625 217.639805 322.749 217.865117 322.781813 C 218.569492 322.884625 219.457617 322.536812 219.96293 322.21525 C 220.58418 321.819313 221.220742 321.128062 221.49418 320.484938 C 221.999492 319.303688 221.780742 317.730875 221.268867 316.801188 C 221.098242 316.49275 220.844492 316.260875 220.58418 316.007125 C 220.14668 315.584938 219.70918 315.21525 219.08793 315.2415 z M 217.585117 317.737437 C 217.781992 317.374312 218.521367 316.37025 219.08793 316.350563 C 219.094492 316.350563 219.116367 316.309 219.142617 316.322125 C 220.02418 316.704937 220.673867 317.676188 220.673867 319.043375 C 220.673867 319.809 220.256055 320.498063 219.792305 320.944313 C 219.381055 321.34025 218.547617 321.784312 218.007305 321.6465 C 217.65293 321.559 217.412305 321.195875 217.296367 320.915875 C 216.928867 320.02775 217.132305 318.551188 217.585117 317.737437 z M 226.116367 312.8965 C 226.538555 313.082437 226.99793 313.334 227.483555 313.581187 C 227.912305 313.799937 228.522617 314.237437 228.883555 314.163063 C 229.178867 314.099625 229.533242 313.404 229.436992 313.191812 C 229.288242 312.87025 228.365117 312.644937 227.975742 312.439312 C 227.345742 312.111187 226.888555 311.796187 226.409492 311.59275 C 225.96543 311.55775 225.534492 311.647438 225.206367 311.885875 C 224.43418 312.828688 224.33793 314.237437 224.228555 315.727125 C 223.292305 315.646187 222.636055 315.823375 222.92918 316.834 C 223.169805 317.107438 223.83918 316.936812 224.228555 317.0615 C 224.167305 318.345562 224.427617 319.343062 224.427617 320.539625 C 224.427617 321.388375 224.228555 322.289625 224.65293 322.788375 C 224.913242 322.788375 225.18668 322.803688 225.40543 322.755562 C 225.521367 322.5915 225.637305 322.392437 225.663555 322.202125 C 225.910742 320.629313 225.425117 318.693375 225.569492 317.129313 C 226.18418 317.013375 227.091992 317.081187 227.448555 316.669938 C 227.74168 316.33525 227.544805 315.891188 227.256055 315.694313 C 226.86668 315.420875 226.696055 315.61775 226.348242 315.727125 C 226.094492 315.81025 225.84293 315.794938 225.534492 315.858375 C 225.541055 315.324625 225.602305 314.784312 225.691992 314.263688 C 225.779492 313.758375 225.74668 313.178688 226.116367 312.8965 z M 237.258125 314.928688 C 237.496562 313.915875 237.721875 312.706187 237.518438 311.728375 C 237.299688 311.584 236.971563 311.551187 236.83375 311.632125 C 236.129375 312.049937 236.245312 314.073375 235.952187 314.928688 C 235.254375 315.029313 234.504062 314.764625 233.99 315.029313 C 233.941875 315.30275 233.784375 315.788375 233.99 316.007125 C 234.407812 316.241188 235.077187 316.219313 235.720312 316.232438 C 235.691875 316.7115 235.5825 317.422438 235.55625 317.9365 C 235.473125 319.548687 235.466562 321.600563 236.376562 322.405562 C 237.010937 322.974312 238.249062 322.81025 239.0825 322.536812 C 239.3625 322.447125 239.690625 322.399 239.835 322.2765 C 240.121562 322.029313 239.93125 321.469313 239.73875 321.202437 C 239.089062 320.977125 238.010625 321.825875 237.354375 321.49775 C 236.95625 321.298687 236.901562 320.382125 236.862188 319.828688 C 236.779062 318.673687 236.916875 317.232125 237.02625 316.232438 C 237.84 316.1865 238.638437 316.3965 239.506875 316.267437 C 239.786875 316.042125 239.684062 315.427437 239.506875 315.125563 C 238.850625 314.968062 237.98875 315.009625 237.258125 314.928688 z M 245.728125 316.827437 C 245.70625 316.978375 245.795937 317.019938 245.8375 317.107438 C 246.500313 317.56025 247.0275 317.068062 246.841562 316.376812 C 246.664375 316.103375 246.404062 315.913063 246.062813 315.794938 C 244.846563 315.385875 242.637187 315.768687 242.096875 316.575875 C 241.974375 316.383375 241.434062 316.350563 241.237188 316.49275 C 241.1125 316.582438 241.079687 316.882125 241.066562 317.135875 C 241.025 317.827125 241.12125 318.702125 241.066562 319.364937 C 240.96375 320.607438 240.96375 321.797438 241.092812 322.549937 C 241.215312 322.679 241.359688 322.781813 241.510625 322.884625 C 241.714062 322.8365 241.700937 322.843062 241.932812 322.858375 C 242.050937 322.762125 242.131875 322.630875 242.24125 322.5215 C 242.145 321.86525 242.234688 321.250563 242.295937 320.513375 C 242.392187 319.349625 242.385625 318.107125 242.877813 317.299937 C 243.418125 316.724625 244.695625 316.656813 245.728125 316.827437 z M 253.574687 317.162125 C 253.526562 317.0615 253.349375 317.100875 253.246562 317.05275 C 252.844063 316.514625 252.214062 316.068375 251.284375 316.096812 C 249.015938 316.158062 247.80625 318.68025 247.812813 320.880875 C 247.812813 321.257125 247.887187 321.755875 248.1125 322.077437 C 248.394687 322.475563 248.816875 322.685563 249.234688 322.816813 C 251.155312 322.823375 251.98875 321.749312 252.8375 320.690562 C 253.104375 321.62025 253.506875 323.029 254.532812 322.762125 C 254.887187 322.482125 254.812813 321.764625 254.36875 321.694625 C 254.005625 321.018687 253.754062 320.069313 253.684062 319.104625 C 253.644687 318.448375 253.8 317.750563 253.574687 317.162125 z M 250.328438 317.435563 C 250.984688 317.019938 252.065313 317.074625 252.564062 317.573375 C 252.49625 317.9365 252.605625 318.428688 252.564062 318.748063 C 252.474375 319.452437 251.86625 320.327437 251.284375 320.90275 C 250.83375 321.353375 249.761875 322.09275 249.015938 321.530562 C 248.626562 320.089 249.260937 318.12025 250.328438 317.435563 z M 261.306953 322.727125 C 261.628516 322.659312 262.031016 322.727125 262.181953 322.536812 C 262.304453 322.379313 262.216953 322.070875 262.216953 321.819313 C 262.223516 319.951188 262.722266 317.544938 261.586953 316.007125 C 261.223828 315.514937 260.451641 314.989937 259.679453 315.009625 C 258.434766 315.038063 257.868203 315.919625 257.308203 316.724625 C 257.295078 316.438063 257.253516 316.171187 257.150703 315.974312 C 256.912266 315.849625 256.459453 315.974312 256.240703 316.068375 C 256.056953 317.264937 256.146641 319.343062 256.091953 320.848063 C 256.076641 321.21775 255.851328 322.447125 256.179453 322.727125 C 256.404766 322.919625 257.076328 322.858375 257.211953 322.694313 C 257.349766 322.5215 257.286328 322.228375 257.308203 321.941813 C 257.395703 320.635875 257.382578 319.609938 257.868203 318.413375 C 258.170078 317.676188 258.926953 315.803688 260.116953 316.350563 C 261.114453 316.80775 261.191016 318.702125 261.088203 320.163375 C 261.020391 321.128062 260.760078 322.18025 261.306953 322.727125 z M 265.278086 322.768687 C 265.525273 322.679 265.750586 322.816813 265.975898 322.816813 C 266.577461 322.816813 267.179023 322.49525 267.581523 322.186812 C 267.931523 321.919938 268.334023 321.545875 268.484961 321.163063 C 268.697148 320.616188 268.655586 319.780562 268.504648 319.288375 C 268.408398 318.975563 268.012461 318.503062 267.658086 318.43525 C 267.472148 318.40025 267.095898 318.406813 266.850898 318.483375 C 266.358711 318.638688 265.100898 319.500563 265.100898 318.43525 C 265.100898 317.811812 265.647773 317.21025 266.126836 317.129313 C 266.509648 317.068062 266.986523 317.258375 267.179023 317.380875 C 267.336523 317.483687 267.356211 317.695875 267.555273 317.709 C 267.719336 317.724312 268.108711 317.396187 268.128398 317.203688 C 268.134961 317.107438 268.073711 316.943375 268.034336 316.882125 C 267.760898 316.459938 266.899023 316.171187 266.378398 316.103375 C 265.792148 316.022438 265.017773 316.575875 264.753086 316.93025 C 264.595586 317.142437 264.383398 317.396187 264.300273 317.634625 C 264.013711 318.483375 264.116523 319.249 264.676523 319.760875 C 265.531836 320.259625 266.522773 319.664625 267.301523 319.384625 C 267.651523 319.638375 267.745586 320.382125 267.555273 320.8415 C 267.507148 320.950875 267.314648 321.154313 267.227148 321.237437 C 267.069648 321.381813 266.741523 321.6465 266.454961 321.74275 C 266.111523 321.852125 265.409336 321.86525 265.175273 321.537125 C 264.971836 321.250563 264.991523 320.764937 264.724648 320.690562 C 264.534336 320.635875 264.306836 320.880875 264.074961 320.964 C 263.952461 321.784312 264.444648 322.193375 264.827461 322.5915 C 264.998086 322.624312 265.149023 322.685563 265.278086 322.768687 z M 271.759922 321.674937 C 271.116797 320.089 271.423047 317.991188 271.506172 316.164625 C 271.567422 314.845562 271.779609 313.506813 271.814609 312.27525 C 271.731484 312.124312 271.676797 311.947125 271.608984 311.789625 C 271.403359 311.702125 271.197734 311.605875 270.917734 311.584 C 270.618047 311.625563 270.001172 311.831187 269.994609 312.194313 C 269.988047 312.43275 270.138984 312.74775 270.351172 312.787125 C 270.548047 312.828688 270.624609 312.658062 270.788672 312.706187 C 270.747109 313.266188 270.650859 313.880875 270.611484 314.524 C 270.569922 315.132125 270.576484 315.77525 270.508672 316.3965 C 270.309609 318.1815 270.219922 319.6515 270.583047 321.163063 C 270.727422 321.755875 270.821484 322.366188 271.197734 322.646187 C 271.615547 322.952437 272.381172 322.685563 272.477422 322.234938 C 272.551797 321.874 272.101172 321.517437 271.759922 321.674937 z M 279.127422 317.162125 C 279.079297 317.0615 278.902109 317.100875 278.799297 317.05275 C 278.396797 316.514625 277.766797 316.068375 276.837109 316.096812 C 274.568672 316.158062 273.358984 318.68025 273.365547 320.880875 C 273.365547 321.257125 273.439922 321.755875 273.665234 322.077437 C 273.947422 322.475563 274.369609 322.685563 274.787422 322.816813 C 276.708047 322.823375 277.541484 321.749312 278.390234 320.690562 C 278.657109 321.62025 279.059609 323.029 280.085547 322.762125 C 280.439922 322.482125 280.365547 321.764625 279.921484 321.694625 C 279.558359 321.018687 279.306797 320.069313 279.236797 319.104625 C 279.197422 318.448375 279.352734 317.750563 279.127422 317.162125 z M 275.881172 317.435563 C 276.537422 317.019938 277.618047 317.074625 278.116797 317.573375 C 278.048984 317.9365 278.158359 318.428688 278.116797 318.748063 C 278.027109 319.452437 277.418984 320.327437 276.837109 320.90275 C 276.386484 321.353375 275.314609 322.09275 274.568672 321.530562 C 274.179297 320.089 274.813672 318.12025 275.881172 317.435563 z M 284.508125 314.928688 C 284.746562 313.915875 284.971875 312.706187 284.768438 311.728375 C 284.549688 311.584 284.221563 311.551187 284.08375 311.632125 C 283.379375 312.049937 283.495313 314.073375 283.202187 314.928688 C 282.504375 315.029313 281.754062 314.764625 281.24 315.029313 C 281.191875 315.30275 281.034375 315.788375 281.24 316.007125 C 281.657812 316.241188 282.327187 316.219313 282.970312 316.232438 C 282.941875 316.7115 282.8325 317.422438 282.80625 317.9365 C 282.723125 319.548687 282.716563 321.600563 283.626562 322.405562 C 284.260938 322.974312 285.499062 322.81025 286.3325 322.536812 C 286.6125 322.447125 286.940625 322.399 287.085 322.2765 C 287.371562 322.029313 287.18125 321.469313 286.98875 321.202437 C 286.339063 320.977125 285.260625 321.825875 284.604375 321.49775 C 284.20625 321.298687 284.151563 320.382125 284.112188 319.828688 C 284.029063 318.673687 284.166875 317.232125 284.27625 316.232438 C 285.09 316.1865 285.888438 316.3965 286.756875 316.267437 C 287.036875 316.042125 286.934062 315.427437 286.756875 315.125563 C 286.100625 314.968062 285.23875 315.009625 284.508125 314.928688 z M 291.405312 315.2415 C 290.762187 315.269937 290.08625 315.733687 289.729688 316.096812 C 289.594063 316.232438 289.471563 316.479625 289.3075 316.691813 C 288.854688 317.286812 288.425937 318.271187 288.316562 319.124312 C 288.130625 320.546187 288.65125 321.954937 289.443125 322.475563 C 289.594063 322.569625 289.957187 322.749 290.1825 322.781813 C 290.886875 322.884625 291.775 322.536812 292.280312 322.21525 C 292.901562 321.819313 293.538125 321.128062 293.811562 320.484938 C 294.316875 319.303688 294.098125 317.730875 293.58625 316.801188 C 293.415625 316.49275 293.161875 316.260875 292.901562 316.007125 C 292.464062 315.584938 292.026563 315.21525 291.405312 315.2415 z M 289.9025 317.737437 C 290.099375 317.374312 290.83875 316.37025 291.405312 316.350563 C 291.411875 316.350563 291.43375 316.309 291.46 316.322125 C 292.341563 316.704937 292.99125 317.676188 292.99125 319.043375 C 292.99125 319.809 292.573437 320.498063 292.109688 320.944313 C 291.698438 321.34025 290.865 321.784312 290.324687 321.6465 C 289.970312 321.559 289.729688 321.195875 289.61375 320.915875 C 289.24625 320.02775 289.449687 318.551188 289.9025 317.737437 z M 299.978125 316.827437 C 299.95625 316.978375 300.045937 317.019938 300.0875 317.107438 C 300.750312 317.56025 301.2775 317.068062 301.091563 316.376812 C 300.914375 316.103375 300.654063 315.913063 300.312812 315.794938 C 299.096563 315.385875 296.887187 315.768687 296.346875 316.575875 C 296.224375 316.383375 295.684062 316.350563 295.487188 316.49275 C 295.3625 316.582438 295.329687 316.882125 295.316563 317.135875 C 295.275 317.827125 295.37125 318.702125 295.316563 319.364937 C 295.21375 320.607438 295.21375 321.797438 295.342812 322.549937 C 295.465312 322.679 295.609687 322.781813 295.760625 322.884625 C 295.964062 322.8365 295.950938 322.843062 296.182812 322.858375 C 296.300938 322.762125 296.381875 322.630875 296.49125 322.5215 C 296.395 321.86525 296.484687 321.250563 296.545937 320.513375 C 296.642187 319.349625 296.635625 318.107125 297.127813 317.299937 C 297.668125 316.724625 298.945625 316.656813 299.978125 316.827437 z M 303.77125 322.768687 C 304.018438 322.679 304.24375 322.816813 304.469063 322.816813 C 305.070625 322.816813 305.672188 322.49525 306.074687 322.186812 C 306.424688 321.919938 306.827187 321.545875 306.978125 321.163063 C 307.190313 320.616188 307.14875 319.780562 306.997813 319.288375 C 306.901562 318.975563 306.505625 318.503062 306.15125 318.43525 C 305.965312 318.40025 305.589062 318.406813 305.344063 318.483375 C 304.851875 318.638688 303.594063 319.500563 303.594063 318.43525 C 303.594063 317.811812 304.140938 317.21025 304.62 317.129313 C 305.002813 317.068062 305.479687 317.258375 305.672188 317.380875 C 305.829687 317.483687 305.849375 317.695875 306.048437 317.709 C 306.2125 317.724312 306.601875 317.396187 306.621562 317.203688 C 306.628125 317.107438 306.566875 316.943375 306.5275 316.882125 C 306.254063 316.459938 305.392187 316.171187 304.871562 316.103375 C 304.285313 316.022438 303.510937 316.575875 303.24625 316.93025 C 303.08875 317.142437 302.876562 317.396187 302.793437 317.634625 C 302.506875 318.483375 302.609688 319.249 303.169688 319.760875 C 304.025 320.259625 305.015938 319.664625 305.794688 319.384625 C 306.144688 319.638375 306.23875 320.382125 306.048437 320.8415 C 306.000313 320.950875 305.807812 321.154313 305.720312 321.237437 C 305.562813 321.381813 305.234688 321.6465 304.948125 321.74275 C 304.604687 321.852125 303.9025 321.86525 303.668437 321.537125 C 303.465 321.250563 303.484688 320.764937 303.217812 320.690562 C 303.0275 320.635875 302.8 320.880875 302.568125 320.964 C 302.445625 321.784312 302.937813 322.193375 303.320625 322.5915 C 303.49125 322.624312 303.642187 322.685563 303.77125 322.768687 z " + id="path6" /> + </g> + </g> + <g + id="matplotlib.axis_2"> + <g + id="text_2"> + <path + d="M 40.645625 230.911906 C 40.523125 230.323469 40.262812 229.811594 39.621875 229.811594 C 39.114375 229.811594 38.937188 230.638469 38.937188 230.986281 C 38.937188 231.082531 38.950312 231.172219 38.965625 231.253156 C 39.020312 231.561594 39.053125 232.108469 39.081562 232.749406 C 39.107812 233.405656 39.120937 234.164719 39.149375 234.890969 C 39.204062 236.358781 39.313437 237.774094 39.635 238.082531 C 39.805625 238.253156 40.09875 238.513469 40.37875 238.513469 C 40.88625 238.513469 40.899375 237.535656 40.899375 237.214094 C 40.899375 236.531594 40.770312 235.853469 40.770312 235.184094 C 40.770312 235.155656 40.770312 235.087844 40.783437 235.074719 C 40.879687 234.965344 43.277187 234.917219 43.627187 234.917219 C 45.000937 234.917219 46.368125 235.013469 47.755 235.013469 L 48.44625 235.013469 C 48.72625 235.000344 49.034687 234.971906 49.314687 234.917219 C 49.887813 234.820969 50.38875 234.582531 50.38875 234.035656 C 50.38875 233.460344 49.588125 233.405656 49.183437 233.392531 L 48.739375 233.392531 C 47.496875 233.392531 46.245625 233.591594 44.987812 233.591594 L 44.78875 233.591594 C 44.399375 233.591594 44.016562 233.530344 43.627187 233.530344 C 43.386562 233.530344 42.771875 233.530344 42.183437 233.515031 C 41.581875 233.501906 41.015313 233.475656 40.857812 233.392531 C 40.79 233.366281 40.755 233.228469 40.72875 233.044719 C 40.715625 232.874094 40.72875 232.688156 40.72875 232.620344 C 40.72875 232.408156 40.741875 232.147844 40.72875 231.841594 C 40.72875 231.546281 40.700312 231.218156 40.645625 230.911906 z M 44.200313 224.423781 C 44.35125 224.445656 44.392812 224.355969 44.480312 224.314406 C 44.933125 223.651594 44.440937 223.124406 43.749688 223.310344 C 43.47625 223.487531 43.285938 223.747844 43.167812 224.089094 C 42.75875 225.305344 43.141562 227.514719 43.94875 228.055031 C 43.75625 228.177531 43.723438 228.717844 43.865625 228.914719 C 43.955312 229.039406 44.255 229.072219 44.50875 229.085344 C 45.2 229.126906 46.075 229.030656 46.737812 229.085344 C 47.980312 229.188156 49.170313 229.188156 49.922812 229.059094 C 50.051875 228.936594 50.154688 228.792219 50.2575 228.641281 C 50.209375 228.437844 50.215938 228.450969 50.23125 228.219094 C 50.135 228.100969 50.00375 228.020031 49.894375 227.910656 C 49.238125 228.006906 48.623438 227.917219 47.88625 227.855969 C 46.7225 227.759719 45.48 227.766281 44.672812 227.274094 C 44.0975 226.733781 44.029688 225.456281 44.200313 224.423781 z M 44.535 216.577219 C 44.434375 216.625344 44.47375 216.802531 44.425625 216.905344 C 43.8875 217.307844 43.44125 217.937844 43.469687 218.867531 C 43.530938 221.135969 46.053125 222.345656 48.25375 222.339094 C 48.63 222.339094 49.12875 222.264719 49.450313 222.039406 C 49.848438 221.757219 50.058438 221.335031 50.189687 220.917219 C 50.19625 218.996594 49.122188 218.163156 48.063437 217.314406 C 48.993125 217.047531 50.401875 216.645031 50.135 215.619094 C 49.855 215.264719 49.1375 215.339094 49.0675 215.783156 C 48.391562 216.146281 47.442188 216.397844 46.4775 216.467844 C 45.82125 216.507219 45.123438 216.351906 44.535 216.577219 z M 44.808437 219.823469 C 44.392812 219.167219 44.4475 218.086594 44.94625 217.587844 C 45.309375 217.655656 45.801563 217.546281 46.120937 217.587844 C 46.825313 217.677531 47.700313 218.285656 48.275625 218.867531 C 48.72625 219.318156 49.465625 220.390031 48.903438 221.135969 C 47.461875 221.525344 45.493125 220.890969 44.808437 219.823469 z M 50.1 208.844953 C 50.032187 208.523391 50.1 208.120891 49.909688 207.969953 C 49.752187 207.847453 49.44375 207.934953 49.192188 207.934953 C 47.324063 207.928391 44.917812 207.429641 43.38 208.564953 C 42.887813 208.928078 42.362813 209.700266 42.3825 210.472453 C 42.410938 211.717141 43.2925 212.283703 44.0975 212.843703 C 43.810938 212.856828 43.544063 212.898391 43.347188 213.001203 C 43.2225 213.239641 43.347188 213.692453 43.44125 213.911203 C 44.637813 214.094953 46.715938 214.005266 48.220937 214.059953 C 48.590625 214.075266 49.82 214.300578 50.1 213.972453 C 50.2925 213.747141 50.23125 213.075578 50.067188 212.939953 C 49.894375 212.802141 49.60125 212.865578 49.314687 212.843703 C 48.00875 212.756203 46.982813 212.769328 45.78625 212.283703 C 45.049062 211.981828 43.176563 211.224953 43.723438 210.034953 C 44.180625 209.037453 46.075 208.960891 47.53625 209.063703 C 48.500937 209.131516 49.553125 209.391828 50.1 208.844953 z M 50.141562 204.87382 C 50.051875 204.626633 50.189687 204.40132 50.189687 204.176008 C 50.189687 203.574445 49.868125 202.972883 49.559688 202.570383 C 49.292813 202.220383 48.91875 201.817883 48.535938 201.666945 C 47.989063 201.454758 47.153438 201.49632 46.66125 201.647258 C 46.348438 201.743508 45.875937 202.139445 45.808125 202.49382 C 45.773125 202.679758 45.779688 203.056008 45.85625 203.301008 C 46.011562 203.793195 46.873438 205.051008 45.808125 205.051008 C 45.184688 205.051008 44.583125 204.504133 44.502187 204.02507 C 44.440938 203.642258 44.63125 203.165383 44.75375 202.972883 C 44.856563 202.815383 45.06875 202.795695 45.081875 202.596633 C 45.097188 202.43257 44.769063 202.043195 44.576563 202.023508 C 44.480313 202.016945 44.31625 202.078195 44.255 202.11757 C 43.832813 202.391008 43.544063 203.252883 43.47625 203.773508 C 43.395313 204.359758 43.94875 205.134133 44.303125 205.39882 C 44.515313 205.55632 44.769063 205.768508 45.0075 205.851633 C 45.85625 206.138195 46.621875 206.035383 47.13375 205.475383 C 47.6325 204.62007 47.0375 203.629133 46.7575 202.850383 C 47.01125 202.500383 47.755 202.40632 48.214375 202.596633 C 48.32375 202.644758 48.527188 202.837258 48.610312 202.924758 C 48.754688 203.082258 49.019375 203.410383 49.115625 203.696945 C 49.225 204.040383 49.238125 204.74257 48.91 204.976633 C 48.623438 205.18007 48.137813 205.160383 48.063437 205.427258 C 48.00875 205.61757 48.25375 205.84507 48.336875 206.076945 C 49.157187 206.199445 49.56625 205.707258 49.964375 205.324445 C 49.997188 205.15382 50.058438 205.002883 50.141562 204.87382 z M 49.047812 198.391984 C 47.461875 199.035109 45.364063 198.728859 43.5375 198.645734 C 42.218438 198.584484 40.879688 198.372297 39.648125 198.337297 C 39.497188 198.420422 39.32 198.475109 39.1625 198.542922 C 39.075 198.748547 38.97875 198.954172 38.956875 199.234172 C 38.998438 199.533859 39.204062 200.150734 39.567188 200.157297 C 39.805625 200.163859 40.120625 200.012922 40.16 199.800734 C 40.201563 199.603859 40.030938 199.527297 40.079062 199.363234 C 40.639063 199.404797 41.25375 199.501047 41.896875 199.540422 C 42.505 199.581984 43.148125 199.575422 43.769375 199.643234 C 45.554375 199.842297 47.024375 199.931984 48.535938 199.568859 C 49.12875 199.424484 49.739063 199.330422 50.019063 198.954172 C 50.325313 198.536359 50.058438 197.770734 49.607813 197.674484 C 49.246875 197.600109 48.890313 198.050734 49.047812 198.391984 z M 44.535 191.024484 C 44.434375 191.072609 44.47375 191.249797 44.425625 191.352609 C 43.8875 191.755109 43.44125 192.385109 43.469687 193.314797 C 43.530938 195.583234 46.053125 196.792922 48.25375 196.786359 C 48.63 196.786359 49.12875 196.711984 49.450313 196.486672 C 49.848438 196.204484 50.058438 195.782297 50.189688 195.364484 C 50.19625 193.443859 49.122188 192.610422 48.063437 191.761672 C 48.993125 191.494797 50.401875 191.092297 50.135 190.066359 C 49.855 189.711984 49.1375 189.786359 49.0675 190.230422 C 48.391562 190.593547 47.442188 190.845109 46.4775 190.915109 C 45.82125 190.954484 45.123438 190.799172 44.535 191.024484 z M 44.808438 194.270734 C 44.392813 193.614484 44.4475 192.533859 44.94625 192.035109 C 45.309375 192.102922 45.801563 191.993547 46.120938 192.035109 C 46.825313 192.124797 47.700313 192.732922 48.275625 193.314797 C 48.72625 193.765422 49.465625 194.837297 48.903438 195.583234 C 47.461875 195.972609 45.493125 195.338234 44.808438 194.270734 z M 42.301563 185.643781 C 41.28875 185.405344 40.079062 185.180031 39.10125 185.383469 C 38.956875 185.602219 38.924063 185.930344 39.005 186.068156 C 39.422812 186.772531 41.44625 186.656594 42.301563 186.949719 C 42.402188 187.647531 42.1375 188.397844 42.402188 188.911906 C 42.675625 188.960031 43.16125 189.117531 43.38 188.911906 C 43.614063 188.494094 43.592188 187.824719 43.605313 187.181594 C 44.084375 187.210031 44.795313 187.319406 45.309375 187.345656 C 46.921563 187.428781 48.973438 187.435344 49.778438 186.525344 C 50.347188 185.890969 50.183125 184.652844 49.909688 183.819406 C 49.82 183.539406 49.771875 183.211281 49.649375 183.066906 C 49.402188 182.780344 48.842188 182.970656 48.575313 183.163156 C 48.35 183.812844 49.19875 184.891281 48.870625 185.547531 C 48.671563 185.945656 47.755 186.000344 47.201563 186.039719 C 46.046563 186.122844 44.605 185.985031 43.605313 185.875656 C 43.559375 185.061906 43.769375 184.263469 43.640313 183.395031 C 43.415 183.115031 42.800313 183.217844 42.498438 183.395031 C 42.340938 184.051281 42.3825 184.913156 42.301563 185.643781 z M 42.614375 178.746594 C 42.642813 179.389719 43.106563 180.065656 43.469687 180.422219 C 43.605313 180.557844 43.8525 180.680344 44.064688 180.844406 C 44.659688 181.297219 45.644063 181.725969 46.497188 181.835344 C 47.919063 182.021281 49.327813 181.500656 49.848438 180.708781 C 49.9425 180.557844 50.121875 180.194719 50.154688 179.969406 C 50.2575 179.265031 49.909688 178.376906 49.588125 177.871594 C 49.192188 177.250344 48.500938 176.613781 47.857813 176.340344 C 46.676563 175.835031 45.10375 176.053781 44.174063 176.565656 C 43.865625 176.736281 43.63375 176.990031 43.38 177.250344 C 42.957813 177.687844 42.588125 178.125344 42.614375 178.746594 z M 45.110312 180.249406 C 44.747188 180.052531 43.743125 179.313156 43.723438 178.746594 C 43.723438 178.740031 43.681875 178.718156 43.695 178.691906 C 44.077813 177.810344 45.049063 177.160656 46.41625 177.160656 C 47.181875 177.160656 47.870938 177.578469 48.317188 178.042219 C 48.713125 178.453469 49.157188 179.286906 49.019375 179.827219 C 48.931875 180.181594 48.56875 180.422219 48.28875 180.538156 C 47.400625 180.905656 45.924063 180.702219 45.110312 180.249406 z M 44.200313 170.173781 C 44.35125 170.195656 44.392813 170.105969 44.480313 170.064406 C 44.933125 169.401594 44.440938 168.874406 43.749688 169.060344 C 43.47625 169.237531 43.285938 169.497844 43.167813 169.839094 C 42.75875 171.055344 43.141563 173.264719 43.94875 173.805031 C 43.75625 173.927531 43.723438 174.467844 43.865625 174.664719 C 43.955313 174.789406 44.255 174.822219 44.50875 174.835344 C 45.2 174.876906 46.075 174.780656 46.737813 174.835344 C 47.980313 174.938156 49.170313 174.938156 49.922813 174.809094 C 50.051875 174.686594 50.154688 174.542219 50.2575 174.391281 C 50.209375 174.187844 50.215938 174.200969 50.23125 173.969094 C 50.135 173.850969 50.00375 173.770031 49.894375 173.660656 C 49.238125 173.756906 48.623438 173.667219 47.88625 173.605969 C 46.7225 173.509719 45.48 173.516281 44.672813 173.024094 C 44.0975 172.483781 44.029688 171.206281 44.200313 170.173781 z M 43.469688 164.125344 C 43.66 164.466594 44.241875 164.479719 44.7625 164.460031 C 45.342188 164.431594 46.10125 164.322219 46.901875 164.225969 C 47.989063 164.090344 49.32125 163.865031 49.874688 163.296281 C 50.544063 162.176281 48.999688 161.635969 48.378438 161.156906 C 49.19875 160.850656 50.093438 160.439406 50.183125 159.680344 C 50.237813 159.216594 49.949063 158.765969 49.642813 158.492531 C 49.4175 158.286906 49.054375 158.100969 48.713125 157.904094 C 48.391563 157.711594 48.015313 157.486281 47.680625 157.383469 C 47.030938 157.186594 46.230313 157.125344 45.50625 157.077219 C 44.843438 157.035656 44.042813 157.116594 43.859063 157.486281 C 43.723438 157.759719 44.077813 158.258469 44.325 158.286906 C 44.480313 158.300031 44.589688 158.142531 44.78875 158.109719 C 45.097188 158.055031 45.34875 158.087844 45.6375 158.109719 C 47.050625 158.219094 48.500938 158.601906 49.150625 159.551281 C 48.780938 160.214094 47.365625 160.111281 47.085625 160.844094 C 46.928125 161.259719 47.243125 161.664406 47.523125 161.874406 C 47.9475 162.195969 48.562188 162.395031 48.91875 162.758156 C 48.021875 163.099406 46.915 163.132219 45.82125 163.296281 C 45.06875 163.405656 44.338125 163.536906 43.59875 163.585031 C 43.504688 163.714094 43.51125 163.945969 43.469688 164.125344 z M 42.614375 152.852062 C 42.642813 153.495187 43.106563 154.171125 43.469688 154.527687 C 43.605313 154.663312 43.8525 154.785812 44.064688 154.949875 C 44.659688 155.402687 45.644063 155.831437 46.497188 155.940812 C 47.919063 156.12675 49.327813 155.606125 49.848438 154.81425 C 49.9425 154.663312 50.121875 154.300187 50.154688 154.074875 C 50.2575 153.3705 49.909688 152.482375 49.588125 151.977062 C 49.192188 151.355812 48.500938 150.71925 47.857813 150.445812 C 46.676563 149.9405 45.10375 150.15925 44.174063 150.671125 C 43.865625 150.84175 43.63375 151.0955 43.38 151.355812 C 42.957813 151.793312 42.588125 152.230812 42.614375 152.852062 z M 45.110313 154.354875 C 44.747188 154.158 43.743125 153.418625 43.723438 152.852062 C 43.723438 152.8455 43.681875 152.823625 43.695 152.797375 C 44.077813 151.915812 45.049063 151.266125 46.41625 151.266125 C 47.181875 151.266125 47.870938 151.683937 48.317188 152.147687 C 48.713125 152.558937 49.157188 153.392375 49.019375 153.932687 C 48.931875 154.287062 48.56875 154.527687 48.28875 154.643625 C 47.400625 155.011125 45.924063 154.807687 45.110313 154.354875 z M 44.200313 144.27925 C 44.35125 144.301125 44.392813 144.211437 44.480313 144.169875 C 44.933125 143.507062 44.440938 142.979875 43.749688 143.165812 C 43.47625 143.343 43.285938 143.603312 43.167813 143.944562 C 42.75875 145.160812 43.141563 147.370187 43.94875 147.9105 C 43.75625 148.033 43.723438 148.573312 43.865625 148.770187 C 43.955313 148.894875 44.255 148.927687 44.50875 148.940812 C 45.2 148.982375 46.075 148.886125 46.737813 148.940812 C 47.980313 149.043625 49.170313 149.043625 49.922813 148.914562 C 50.051875 148.792062 50.154688 148.647687 50.2575 148.49675 C 50.209375 148.293312 50.215938 148.306437 50.23125 148.074562 C 50.135 147.956437 50.00375 147.8755 49.894375 147.766125 C 49.238125 147.862375 48.623438 147.772687 47.88625 147.711437 C 46.7225 147.615187 45.48 147.62175 44.672813 147.129562 C 44.0975 146.58925 44.029688 145.31175 44.200313 144.27925 z M 39.449063 141.1555 C 39.368125 141.313 39.361563 141.730812 39.449063 141.886125 C 40.60625 142.290812 42.47875 142.037062 44.042813 141.96925 C 45.3225 141.914562 46.387813 141.975812 47.577813 141.96925 C 47.9475 141.96925 48.439688 141.956125 48.864063 141.96925 C 49.0675 141.975812 49.456875 141.9955 49.594688 141.940812 C 49.874688 141.824875 50.0125 141.203625 49.75875 140.991437 C 49.28625 140.5955 48.214375 141.011125 47.516563 140.820812 C 47.461875 140.615187 47.394063 140.431437 47.208125 140.348312 C 47.864375 139.337687 48.658438 137.723312 49.874688 137.292375 C 50.03875 137.237687 50.215938 137.237687 50.347188 137.150187 C 50.865625 136.800187 50.421563 136.1855 50.03875 136.028 C 49.6975 136.262062 49.060938 136.362687 48.69125 136.644875 C 48.610313 136.706125 48.575313 136.800187 48.44625 136.896437 C 48.317188 136.992687 48.13125 137.115187 48.021875 137.237687 C 47.420313 137.9355 46.873438 138.762375 46.394375 139.534562 C 45.315938 138.613625 44.38625 137.546125 43.312188 136.616437 C 43.16125 136.658 42.997188 136.623 42.778438 136.706125 C 42.739063 136.883312 42.520313 137.150187 42.559688 137.347062 C 42.588125 137.484875 42.848438 137.6555 42.9775 137.799875 C 43.421563 138.27675 43.894063 138.736125 44.296563 139.138625 C 44.959375 139.801437 45.644063 140.273937 46.114375 140.8755 C 45.081875 140.8755 44.10625 140.862375 43.23125 140.93675 C 41.986563 141.039562 40.372188 140.868937 39.449063 141.1555 z M 49.047813 133.300187 C 47.461875 133.943312 45.364063 133.637062 43.5375 133.553937 C 42.218438 133.492687 40.879688 133.2805 39.648125 133.2455 C 39.497188 133.328625 39.32 133.383312 39.1625 133.451125 C 39.075 133.65675 38.97875 133.862375 38.956875 134.142375 C 38.998438 134.442062 39.204063 135.058937 39.567188 135.0655 C 39.805625 135.072062 40.120625 134.921125 40.16 134.708937 C 40.201563 134.512062 40.030938 134.4355 40.079063 134.271437 C 40.639063 134.313 41.25375 134.40925 41.896875 134.448625 C 42.505 134.490187 43.148125 134.483625 43.769375 134.551437 C 45.554375 134.7505 47.024375 134.840187 48.535938 134.477062 C 49.12875 134.332687 49.739063 134.238625 50.019063 133.862375 C 50.325313 133.444562 50.058438 132.678937 49.607813 132.582687 C 49.246875 132.508312 48.890313 132.958937 49.047813 133.300187 z M 42.614375 128.352062 C 42.642813 128.995187 43.106563 129.671125 43.469688 130.027687 C 43.605313 130.163312 43.8525 130.285812 44.064688 130.449875 C 44.659688 130.902687 45.644063 131.331437 46.497188 131.440812 C 47.919063 131.62675 49.327813 131.106125 49.848438 130.31425 C 49.9425 130.163312 50.121875 129.800187 50.154688 129.574875 C 50.2575 128.8705 49.909688 127.982375 49.588125 127.477062 C 49.192188 126.855812 48.500938 126.21925 47.857813 125.945812 C 46.676563 125.4405 45.10375 125.65925 44.174063 126.171125 C 43.865625 126.34175 43.63375 126.5955 43.38 126.855812 C 42.957813 127.293312 42.588125 127.730812 42.614375 128.352062 z M 45.110313 129.854875 C 44.747188 129.658 43.743125 128.918625 43.723438 128.352062 C 43.723438 128.3455 43.681875 128.323625 43.695 128.297375 C 44.077813 127.415812 45.049063 126.766125 46.41625 126.766125 C 47.181875 126.766125 47.870938 127.183937 48.317188 127.647687 C 48.713125 128.058937 49.157188 128.892375 49.019375 129.432687 C 48.931875 129.787062 48.56875 130.027687 48.28875 130.143625 C 47.400625 130.511125 45.924063 130.307687 45.110313 129.854875 z M 44.535 118.932687 C 44.434375 118.980812 44.47375 119.158 44.425625 119.260812 C 43.8875 119.663312 43.44125 120.293312 43.469688 121.223 C 43.530938 123.491437 46.053125 124.701125 48.25375 124.694562 C 48.63 124.694562 49.12875 124.620187 49.450313 124.394875 C 49.848438 124.112687 50.058438 123.6905 50.189688 123.272687 C 50.19625 121.352062 49.122188 120.518625 48.063438 119.669875 C 48.993125 119.403 50.401875 119.0005 50.135 117.974562 C 49.855 117.620187 49.1375 117.694562 49.0675 118.138625 C 48.391563 118.50175 47.442188 118.753312 46.4775 118.823312 C 45.82125 118.862687 45.123438 118.707375 44.535 118.932687 z M 44.808438 122.178937 C 44.392813 121.522687 44.4475 120.442062 44.94625 119.943312 C 45.309375 120.011125 45.801563 119.90175 46.120938 119.943312 C 46.825313 120.033 47.700313 120.641125 48.275625 121.223 C 48.72625 121.673625 49.465625 122.7455 48.903438 123.491437 C 47.461875 123.880812 45.493125 123.246437 44.808438 122.178937 z M 39.667813 111.467297 C 39.635 111.611672 39.593438 111.946359 39.689688 112.049172 C 40.687188 112.361984 42.327813 112.033859 43.415 112.259172 C 42.710625 113.387922 43.121875 114.871047 43.942188 115.533859 C 45.027188 116.415422 46.53875 116.977609 48.083125 116.642922 C 48.658438 116.415422 49.122188 116.183547 49.430625 115.746047 C 50.277188 114.542922 48.986563 112.978859 48.5075 112.158547 C 48.7 112.116984 48.903438 112.165109 49.012813 112.020734 C 49.095938 111.911359 49.1025 111.480422 49.060938 111.338234 C 49.04125 111.261672 48.98 111.139172 48.931875 111.097609 C 47.892813 110.852609 46.785938 111.174172 45.62875 111.255109 C 45.014063 111.296672 44.296563 111.283547 43.653438 111.228859 C 42.935938 111.165422 42.047813 111.174172 41.301875 111.228859 C 40.722188 111.274797 40.16 111.316359 39.667813 111.467297 z M 45.950313 112.287609 C 46.41625 112.259172 46.895313 112.335734 47.345938 112.259172 C 47.72875 112.915422 48.378438 113.580422 48.616875 114.372297 C 48.671563 114.556047 48.732813 114.803234 48.69125 114.980422 C 48.575313 115.520734 47.639063 115.800734 46.95 115.774484 C 46.020313 115.739484 44.611563 115.028547 44.206875 114.291359 C 44.023125 113.954484 44.058125 113.455734 44.152188 113.024797 C 44.370938 112.574172 45.34875 112.322609 45.950313 112.287609 z " + style="stroke: #ffffff; stroke-width: 4" + id="path7" /> + <path + d="M 40.645625 230.911906 C 40.523125 230.323469 40.262812 229.811594 39.621875 229.811594 C 39.114375 229.811594 38.937188 230.638469 38.937188 230.986281 C 38.937188 231.082531 38.950312 231.172219 38.965625 231.253156 C 39.020312 231.561594 39.053125 232.108469 39.081562 232.749406 C 39.107812 233.405656 39.120937 234.164719 39.149375 234.890969 C 39.204062 236.358781 39.313437 237.774094 39.635 238.082531 C 39.805625 238.253156 40.09875 238.513469 40.37875 238.513469 C 40.88625 238.513469 40.899375 237.535656 40.899375 237.214094 C 40.899375 236.531594 40.770312 235.853469 40.770312 235.184094 C 40.770312 235.155656 40.770312 235.087844 40.783437 235.074719 C 40.879687 234.965344 43.277187 234.917219 43.627187 234.917219 C 45.000937 234.917219 46.368125 235.013469 47.755 235.013469 L 48.44625 235.013469 C 48.72625 235.000344 49.034687 234.971906 49.314687 234.917219 C 49.887813 234.820969 50.38875 234.582531 50.38875 234.035656 C 50.38875 233.460344 49.588125 233.405656 49.183437 233.392531 L 48.739375 233.392531 C 47.496875 233.392531 46.245625 233.591594 44.987812 233.591594 L 44.78875 233.591594 C 44.399375 233.591594 44.016562 233.530344 43.627187 233.530344 C 43.386562 233.530344 42.771875 233.530344 42.183437 233.515031 C 41.581875 233.501906 41.015313 233.475656 40.857812 233.392531 C 40.79 233.366281 40.755 233.228469 40.72875 233.044719 C 40.715625 232.874094 40.72875 232.688156 40.72875 232.620344 C 40.72875 232.408156 40.741875 232.147844 40.72875 231.841594 C 40.72875 231.546281 40.700312 231.218156 40.645625 230.911906 z M 44.200313 224.423781 C 44.35125 224.445656 44.392812 224.355969 44.480312 224.314406 C 44.933125 223.651594 44.440937 223.124406 43.749688 223.310344 C 43.47625 223.487531 43.285938 223.747844 43.167812 224.089094 C 42.75875 225.305344 43.141562 227.514719 43.94875 228.055031 C 43.75625 228.177531 43.723438 228.717844 43.865625 228.914719 C 43.955312 229.039406 44.255 229.072219 44.50875 229.085344 C 45.2 229.126906 46.075 229.030656 46.737812 229.085344 C 47.980312 229.188156 49.170313 229.188156 49.922812 229.059094 C 50.051875 228.936594 50.154688 228.792219 50.2575 228.641281 C 50.209375 228.437844 50.215938 228.450969 50.23125 228.219094 C 50.135 228.100969 50.00375 228.020031 49.894375 227.910656 C 49.238125 228.006906 48.623438 227.917219 47.88625 227.855969 C 46.7225 227.759719 45.48 227.766281 44.672812 227.274094 C 44.0975 226.733781 44.029688 225.456281 44.200313 224.423781 z M 44.535 216.577219 C 44.434375 216.625344 44.47375 216.802531 44.425625 216.905344 C 43.8875 217.307844 43.44125 217.937844 43.469687 218.867531 C 43.530938 221.135969 46.053125 222.345656 48.25375 222.339094 C 48.63 222.339094 49.12875 222.264719 49.450313 222.039406 C 49.848438 221.757219 50.058438 221.335031 50.189687 220.917219 C 50.19625 218.996594 49.122188 218.163156 48.063437 217.314406 C 48.993125 217.047531 50.401875 216.645031 50.135 215.619094 C 49.855 215.264719 49.1375 215.339094 49.0675 215.783156 C 48.391562 216.146281 47.442188 216.397844 46.4775 216.467844 C 45.82125 216.507219 45.123438 216.351906 44.535 216.577219 z M 44.808437 219.823469 C 44.392812 219.167219 44.4475 218.086594 44.94625 217.587844 C 45.309375 217.655656 45.801563 217.546281 46.120937 217.587844 C 46.825313 217.677531 47.700313 218.285656 48.275625 218.867531 C 48.72625 219.318156 49.465625 220.390031 48.903438 221.135969 C 47.461875 221.525344 45.493125 220.890969 44.808437 219.823469 z M 50.1 208.844953 C 50.032187 208.523391 50.1 208.120891 49.909688 207.969953 C 49.752187 207.847453 49.44375 207.934953 49.192188 207.934953 C 47.324063 207.928391 44.917812 207.429641 43.38 208.564953 C 42.887813 208.928078 42.362813 209.700266 42.3825 210.472453 C 42.410938 211.717141 43.2925 212.283703 44.0975 212.843703 C 43.810938 212.856828 43.544063 212.898391 43.347188 213.001203 C 43.2225 213.239641 43.347188 213.692453 43.44125 213.911203 C 44.637813 214.094953 46.715938 214.005266 48.220937 214.059953 C 48.590625 214.075266 49.82 214.300578 50.1 213.972453 C 50.2925 213.747141 50.23125 213.075578 50.067188 212.939953 C 49.894375 212.802141 49.60125 212.865578 49.314687 212.843703 C 48.00875 212.756203 46.982813 212.769328 45.78625 212.283703 C 45.049062 211.981828 43.176563 211.224953 43.723438 210.034953 C 44.180625 209.037453 46.075 208.960891 47.53625 209.063703 C 48.500937 209.131516 49.553125 209.391828 50.1 208.844953 z M 50.141562 204.87382 C 50.051875 204.626633 50.189687 204.40132 50.189687 204.176008 C 50.189687 203.574445 49.868125 202.972883 49.559688 202.570383 C 49.292813 202.220383 48.91875 201.817883 48.535938 201.666945 C 47.989063 201.454758 47.153438 201.49632 46.66125 201.647258 C 46.348438 201.743508 45.875937 202.139445 45.808125 202.49382 C 45.773125 202.679758 45.779688 203.056008 45.85625 203.301008 C 46.011562 203.793195 46.873438 205.051008 45.808125 205.051008 C 45.184688 205.051008 44.583125 204.504133 44.502187 204.02507 C 44.440938 203.642258 44.63125 203.165383 44.75375 202.972883 C 44.856563 202.815383 45.06875 202.795695 45.081875 202.596633 C 45.097188 202.43257 44.769063 202.043195 44.576563 202.023508 C 44.480313 202.016945 44.31625 202.078195 44.255 202.11757 C 43.832813 202.391008 43.544063 203.252883 43.47625 203.773508 C 43.395313 204.359758 43.94875 205.134133 44.303125 205.39882 C 44.515313 205.55632 44.769063 205.768508 45.0075 205.851633 C 45.85625 206.138195 46.621875 206.035383 47.13375 205.475383 C 47.6325 204.62007 47.0375 203.629133 46.7575 202.850383 C 47.01125 202.500383 47.755 202.40632 48.214375 202.596633 C 48.32375 202.644758 48.527188 202.837258 48.610312 202.924758 C 48.754688 203.082258 49.019375 203.410383 49.115625 203.696945 C 49.225 204.040383 49.238125 204.74257 48.91 204.976633 C 48.623438 205.18007 48.137813 205.160383 48.063437 205.427258 C 48.00875 205.61757 48.25375 205.84507 48.336875 206.076945 C 49.157187 206.199445 49.56625 205.707258 49.964375 205.324445 C 49.997188 205.15382 50.058438 205.002883 50.141562 204.87382 z M 49.047812 198.391984 C 47.461875 199.035109 45.364063 198.728859 43.5375 198.645734 C 42.218438 198.584484 40.879688 198.372297 39.648125 198.337297 C 39.497188 198.420422 39.32 198.475109 39.1625 198.542922 C 39.075 198.748547 38.97875 198.954172 38.956875 199.234172 C 38.998438 199.533859 39.204062 200.150734 39.567188 200.157297 C 39.805625 200.163859 40.120625 200.012922 40.16 199.800734 C 40.201563 199.603859 40.030938 199.527297 40.079062 199.363234 C 40.639063 199.404797 41.25375 199.501047 41.896875 199.540422 C 42.505 199.581984 43.148125 199.575422 43.769375 199.643234 C 45.554375 199.842297 47.024375 199.931984 48.535938 199.568859 C 49.12875 199.424484 49.739063 199.330422 50.019063 198.954172 C 50.325313 198.536359 50.058438 197.770734 49.607813 197.674484 C 49.246875 197.600109 48.890313 198.050734 49.047812 198.391984 z M 44.535 191.024484 C 44.434375 191.072609 44.47375 191.249797 44.425625 191.352609 C 43.8875 191.755109 43.44125 192.385109 43.469687 193.314797 C 43.530938 195.583234 46.053125 196.792922 48.25375 196.786359 C 48.63 196.786359 49.12875 196.711984 49.450313 196.486672 C 49.848438 196.204484 50.058438 195.782297 50.189688 195.364484 C 50.19625 193.443859 49.122188 192.610422 48.063437 191.761672 C 48.993125 191.494797 50.401875 191.092297 50.135 190.066359 C 49.855 189.711984 49.1375 189.786359 49.0675 190.230422 C 48.391562 190.593547 47.442188 190.845109 46.4775 190.915109 C 45.82125 190.954484 45.123438 190.799172 44.535 191.024484 z M 44.808438 194.270734 C 44.392813 193.614484 44.4475 192.533859 44.94625 192.035109 C 45.309375 192.102922 45.801563 191.993547 46.120938 192.035109 C 46.825313 192.124797 47.700313 192.732922 48.275625 193.314797 C 48.72625 193.765422 49.465625 194.837297 48.903438 195.583234 C 47.461875 195.972609 45.493125 195.338234 44.808438 194.270734 z M 42.301563 185.643781 C 41.28875 185.405344 40.079062 185.180031 39.10125 185.383469 C 38.956875 185.602219 38.924063 185.930344 39.005 186.068156 C 39.422812 186.772531 41.44625 186.656594 42.301563 186.949719 C 42.402188 187.647531 42.1375 188.397844 42.402188 188.911906 C 42.675625 188.960031 43.16125 189.117531 43.38 188.911906 C 43.614063 188.494094 43.592188 187.824719 43.605313 187.181594 C 44.084375 187.210031 44.795313 187.319406 45.309375 187.345656 C 46.921563 187.428781 48.973438 187.435344 49.778438 186.525344 C 50.347188 185.890969 50.183125 184.652844 49.909688 183.819406 C 49.82 183.539406 49.771875 183.211281 49.649375 183.066906 C 49.402188 182.780344 48.842188 182.970656 48.575313 183.163156 C 48.35 183.812844 49.19875 184.891281 48.870625 185.547531 C 48.671563 185.945656 47.755 186.000344 47.201563 186.039719 C 46.046563 186.122844 44.605 185.985031 43.605313 185.875656 C 43.559375 185.061906 43.769375 184.263469 43.640313 183.395031 C 43.415 183.115031 42.800313 183.217844 42.498438 183.395031 C 42.340938 184.051281 42.3825 184.913156 42.301563 185.643781 z M 42.614375 178.746594 C 42.642813 179.389719 43.106563 180.065656 43.469687 180.422219 C 43.605313 180.557844 43.8525 180.680344 44.064688 180.844406 C 44.659688 181.297219 45.644063 181.725969 46.497188 181.835344 C 47.919063 182.021281 49.327813 181.500656 49.848438 180.708781 C 49.9425 180.557844 50.121875 180.194719 50.154688 179.969406 C 50.2575 179.265031 49.909688 178.376906 49.588125 177.871594 C 49.192188 177.250344 48.500938 176.613781 47.857813 176.340344 C 46.676563 175.835031 45.10375 176.053781 44.174063 176.565656 C 43.865625 176.736281 43.63375 176.990031 43.38 177.250344 C 42.957813 177.687844 42.588125 178.125344 42.614375 178.746594 z M 45.110312 180.249406 C 44.747188 180.052531 43.743125 179.313156 43.723438 178.746594 C 43.723438 178.740031 43.681875 178.718156 43.695 178.691906 C 44.077813 177.810344 45.049063 177.160656 46.41625 177.160656 C 47.181875 177.160656 47.870938 177.578469 48.317188 178.042219 C 48.713125 178.453469 49.157188 179.286906 49.019375 179.827219 C 48.931875 180.181594 48.56875 180.422219 48.28875 180.538156 C 47.400625 180.905656 45.924063 180.702219 45.110312 180.249406 z M 44.200313 170.173781 C 44.35125 170.195656 44.392813 170.105969 44.480313 170.064406 C 44.933125 169.401594 44.440938 168.874406 43.749688 169.060344 C 43.47625 169.237531 43.285938 169.497844 43.167813 169.839094 C 42.75875 171.055344 43.141563 173.264719 43.94875 173.805031 C 43.75625 173.927531 43.723438 174.467844 43.865625 174.664719 C 43.955313 174.789406 44.255 174.822219 44.50875 174.835344 C 45.2 174.876906 46.075 174.780656 46.737813 174.835344 C 47.980313 174.938156 49.170313 174.938156 49.922813 174.809094 C 50.051875 174.686594 50.154688 174.542219 50.2575 174.391281 C 50.209375 174.187844 50.215938 174.200969 50.23125 173.969094 C 50.135 173.850969 50.00375 173.770031 49.894375 173.660656 C 49.238125 173.756906 48.623438 173.667219 47.88625 173.605969 C 46.7225 173.509719 45.48 173.516281 44.672813 173.024094 C 44.0975 172.483781 44.029688 171.206281 44.200313 170.173781 z M 43.469688 164.125344 C 43.66 164.466594 44.241875 164.479719 44.7625 164.460031 C 45.342188 164.431594 46.10125 164.322219 46.901875 164.225969 C 47.989063 164.090344 49.32125 163.865031 49.874688 163.296281 C 50.544063 162.176281 48.999688 161.635969 48.378438 161.156906 C 49.19875 160.850656 50.093438 160.439406 50.183125 159.680344 C 50.237813 159.216594 49.949063 158.765969 49.642813 158.492531 C 49.4175 158.286906 49.054375 158.100969 48.713125 157.904094 C 48.391563 157.711594 48.015313 157.486281 47.680625 157.383469 C 47.030938 157.186594 46.230313 157.125344 45.50625 157.077219 C 44.843438 157.035656 44.042813 157.116594 43.859063 157.486281 C 43.723438 157.759719 44.077813 158.258469 44.325 158.286906 C 44.480313 158.300031 44.589688 158.142531 44.78875 158.109719 C 45.097188 158.055031 45.34875 158.087844 45.6375 158.109719 C 47.050625 158.219094 48.500938 158.601906 49.150625 159.551281 C 48.780938 160.214094 47.365625 160.111281 47.085625 160.844094 C 46.928125 161.259719 47.243125 161.664406 47.523125 161.874406 C 47.9475 162.195969 48.562188 162.395031 48.91875 162.758156 C 48.021875 163.099406 46.915 163.132219 45.82125 163.296281 C 45.06875 163.405656 44.338125 163.536906 43.59875 163.585031 C 43.504688 163.714094 43.51125 163.945969 43.469688 164.125344 z M 42.614375 152.852062 C 42.642813 153.495187 43.106563 154.171125 43.469688 154.527687 C 43.605313 154.663312 43.8525 154.785812 44.064688 154.949875 C 44.659688 155.402687 45.644063 155.831437 46.497188 155.940812 C 47.919063 156.12675 49.327813 155.606125 49.848438 154.81425 C 49.9425 154.663312 50.121875 154.300187 50.154688 154.074875 C 50.2575 153.3705 49.909688 152.482375 49.588125 151.977062 C 49.192188 151.355812 48.500938 150.71925 47.857813 150.445812 C 46.676563 149.9405 45.10375 150.15925 44.174063 150.671125 C 43.865625 150.84175 43.63375 151.0955 43.38 151.355812 C 42.957813 151.793312 42.588125 152.230812 42.614375 152.852062 z M 45.110313 154.354875 C 44.747188 154.158 43.743125 153.418625 43.723438 152.852062 C 43.723438 152.8455 43.681875 152.823625 43.695 152.797375 C 44.077813 151.915812 45.049063 151.266125 46.41625 151.266125 C 47.181875 151.266125 47.870938 151.683937 48.317188 152.147687 C 48.713125 152.558937 49.157188 153.392375 49.019375 153.932687 C 48.931875 154.287062 48.56875 154.527687 48.28875 154.643625 C 47.400625 155.011125 45.924063 154.807687 45.110313 154.354875 z M 44.200313 144.27925 C 44.35125 144.301125 44.392813 144.211437 44.480313 144.169875 C 44.933125 143.507062 44.440938 142.979875 43.749688 143.165812 C 43.47625 143.343 43.285938 143.603312 43.167813 143.944562 C 42.75875 145.160812 43.141563 147.370187 43.94875 147.9105 C 43.75625 148.033 43.723438 148.573312 43.865625 148.770187 C 43.955313 148.894875 44.255 148.927687 44.50875 148.940812 C 45.2 148.982375 46.075 148.886125 46.737813 148.940812 C 47.980313 149.043625 49.170313 149.043625 49.922813 148.914562 C 50.051875 148.792062 50.154688 148.647687 50.2575 148.49675 C 50.209375 148.293312 50.215938 148.306437 50.23125 148.074562 C 50.135 147.956437 50.00375 147.8755 49.894375 147.766125 C 49.238125 147.862375 48.623438 147.772687 47.88625 147.711437 C 46.7225 147.615187 45.48 147.62175 44.672813 147.129562 C 44.0975 146.58925 44.029688 145.31175 44.200313 144.27925 z M 39.449063 141.1555 C 39.368125 141.313 39.361563 141.730812 39.449063 141.886125 C 40.60625 142.290812 42.47875 142.037062 44.042813 141.96925 C 45.3225 141.914562 46.387813 141.975812 47.577813 141.96925 C 47.9475 141.96925 48.439688 141.956125 48.864063 141.96925 C 49.0675 141.975812 49.456875 141.9955 49.594688 141.940812 C 49.874688 141.824875 50.0125 141.203625 49.75875 140.991437 C 49.28625 140.5955 48.214375 141.011125 47.516563 140.820812 C 47.461875 140.615187 47.394063 140.431437 47.208125 140.348312 C 47.864375 139.337687 48.658438 137.723312 49.874688 137.292375 C 50.03875 137.237687 50.215938 137.237687 50.347188 137.150187 C 50.865625 136.800187 50.421563 136.1855 50.03875 136.028 C 49.6975 136.262062 49.060938 136.362687 48.69125 136.644875 C 48.610313 136.706125 48.575313 136.800187 48.44625 136.896437 C 48.317188 136.992687 48.13125 137.115187 48.021875 137.237687 C 47.420313 137.9355 46.873438 138.762375 46.394375 139.534562 C 45.315938 138.613625 44.38625 137.546125 43.312188 136.616437 C 43.16125 136.658 42.997188 136.623 42.778438 136.706125 C 42.739063 136.883312 42.520313 137.150187 42.559688 137.347062 C 42.588125 137.484875 42.848438 137.6555 42.9775 137.799875 C 43.421563 138.27675 43.894063 138.736125 44.296563 139.138625 C 44.959375 139.801437 45.644063 140.273937 46.114375 140.8755 C 45.081875 140.8755 44.10625 140.862375 43.23125 140.93675 C 41.986563 141.039562 40.372188 140.868937 39.449063 141.1555 z M 49.047813 133.300187 C 47.461875 133.943312 45.364063 133.637062 43.5375 133.553937 C 42.218438 133.492687 40.879688 133.2805 39.648125 133.2455 C 39.497188 133.328625 39.32 133.383312 39.1625 133.451125 C 39.075 133.65675 38.97875 133.862375 38.956875 134.142375 C 38.998438 134.442062 39.204063 135.058937 39.567188 135.0655 C 39.805625 135.072062 40.120625 134.921125 40.16 134.708937 C 40.201563 134.512062 40.030938 134.4355 40.079063 134.271437 C 40.639063 134.313 41.25375 134.40925 41.896875 134.448625 C 42.505 134.490187 43.148125 134.483625 43.769375 134.551437 C 45.554375 134.7505 47.024375 134.840187 48.535938 134.477062 C 49.12875 134.332687 49.739063 134.238625 50.019063 133.862375 C 50.325313 133.444562 50.058438 132.678937 49.607813 132.582687 C 49.246875 132.508312 48.890313 132.958937 49.047813 133.300187 z M 42.614375 128.352062 C 42.642813 128.995187 43.106563 129.671125 43.469688 130.027687 C 43.605313 130.163312 43.8525 130.285812 44.064688 130.449875 C 44.659688 130.902687 45.644063 131.331437 46.497188 131.440812 C 47.919063 131.62675 49.327813 131.106125 49.848438 130.31425 C 49.9425 130.163312 50.121875 129.800187 50.154688 129.574875 C 50.2575 128.8705 49.909688 127.982375 49.588125 127.477062 C 49.192188 126.855812 48.500938 126.21925 47.857813 125.945812 C 46.676563 125.4405 45.10375 125.65925 44.174063 126.171125 C 43.865625 126.34175 43.63375 126.5955 43.38 126.855812 C 42.957813 127.293312 42.588125 127.730812 42.614375 128.352062 z M 45.110313 129.854875 C 44.747188 129.658 43.743125 128.918625 43.723438 128.352062 C 43.723438 128.3455 43.681875 128.323625 43.695 128.297375 C 44.077813 127.415812 45.049063 126.766125 46.41625 126.766125 C 47.181875 126.766125 47.870938 127.183937 48.317188 127.647687 C 48.713125 128.058937 49.157188 128.892375 49.019375 129.432687 C 48.931875 129.787062 48.56875 130.027687 48.28875 130.143625 C 47.400625 130.511125 45.924063 130.307687 45.110313 129.854875 z M 44.535 118.932687 C 44.434375 118.980812 44.47375 119.158 44.425625 119.260812 C 43.8875 119.663312 43.44125 120.293312 43.469688 121.223 C 43.530938 123.491437 46.053125 124.701125 48.25375 124.694562 C 48.63 124.694562 49.12875 124.620187 49.450313 124.394875 C 49.848438 124.112687 50.058438 123.6905 50.189688 123.272687 C 50.19625 121.352062 49.122188 120.518625 48.063438 119.669875 C 48.993125 119.403 50.401875 119.0005 50.135 117.974562 C 49.855 117.620187 49.1375 117.694562 49.0675 118.138625 C 48.391563 118.50175 47.442188 118.753312 46.4775 118.823312 C 45.82125 118.862687 45.123438 118.707375 44.535 118.932687 z M 44.808438 122.178937 C 44.392813 121.522687 44.4475 120.442062 44.94625 119.943312 C 45.309375 120.011125 45.801563 119.90175 46.120938 119.943312 C 46.825313 120.033 47.700313 120.641125 48.275625 121.223 C 48.72625 121.673625 49.465625 122.7455 48.903438 123.491437 C 47.461875 123.880812 45.493125 123.246437 44.808438 122.178937 z M 39.667813 111.467297 C 39.635 111.611672 39.593438 111.946359 39.689688 112.049172 C 40.687188 112.361984 42.327813 112.033859 43.415 112.259172 C 42.710625 113.387922 43.121875 114.871047 43.942188 115.533859 C 45.027188 116.415422 46.53875 116.977609 48.083125 116.642922 C 48.658438 116.415422 49.122188 116.183547 49.430625 115.746047 C 50.277188 114.542922 48.986563 112.978859 48.5075 112.158547 C 48.7 112.116984 48.903438 112.165109 49.012813 112.020734 C 49.095938 111.911359 49.1025 111.480422 49.060938 111.338234 C 49.04125 111.261672 48.98 111.139172 48.931875 111.097609 C 47.892813 110.852609 46.785938 111.174172 45.62875 111.255109 C 45.014063 111.296672 44.296563 111.283547 43.653438 111.228859 C 42.935938 111.165422 42.047813 111.174172 41.301875 111.228859 C 40.722188 111.274797 40.16 111.316359 39.667813 111.467297 z M 45.950313 112.287609 C 46.41625 112.259172 46.895313 112.335734 47.345938 112.259172 C 47.72875 112.915422 48.378438 113.580422 48.616875 114.372297 C 48.671563 114.556047 48.732813 114.803234 48.69125 114.980422 C 48.575313 115.520734 47.639063 115.800734 46.95 115.774484 C 46.020313 115.739484 44.611563 115.028547 44.206875 114.291359 C 44.023125 113.954484 44.058125 113.455734 44.152188 113.024797 C 44.370938 112.574172 45.34875 112.322609 45.950313 112.287609 z " + id="path8" /> + </g> + </g> + <g + id="line2d_1"> + <path + d="M 65.62632 -1 L 65.623625 0.00049 L 65.615428 1.001139 L 65.54645 2.003534 L 65.542671 3.004056 L 65.497805 4.005758 L 65.487983 5.006453 L 65.481313 6.007058 L 65.452425 7.008301 L 65.410796 8.00991 L 65.387582 9.010991 L 65.357245 10.012275 L 65.297688 11.0144 L 65.280291 12.015313 L 65.266626 13.016118 L 65.264874 14.016582 L 65.267569 15.016917 L 65.275105 16.017113 L 65.249555 17.018261 L 65.250357 18.018651 L 65.249374 19.019092 L 65.252718 20.019409 L 65.27025 21.019318 L 65.288859 22.019196 L 65.317792 23.018777 L 65.356026 24.018091 L 65.396403 25.017344 L 65.456148 26.016039 L 65.496039 27.015306 L 65.554873 28.014028 L 65.643353 29.011898 L 65.709257 30.010417 L 65.777066 31.008881 L 65.875969 32.972894 L 65.946725 33.977527 L 66.051898 34.974264 L 66.12879 35.972071 L 66.209229 36.969744 L 66.317554 37.966362 L 66.391713 38.964272 L 66.487869 39.96135 L 66.636537 40.956442 L 66.74494 41.953057 L 66.895594 42.948074 L 66.979128 43.94563 L 67.078163 44.942599 L 67.164422 45.940052 L 67.282982 46.936282 L 67.43921 47.931089 L 67.547166 48.927721 L 67.668163 49.923859 L 67.739076 50.921892 L 67.828071 51.919241 L 67.934216 52.915942 L 68.038178 53.912725 L 68.152835 54.909103 L 68.217926 55.907356 L 68.282179 56.905641 L 68.342608 57.90407 L 68.39992 58.902618 L 68.46409 59.900906 L 68.55162 60.89831 L 68.624463 61.89627 L 68.698097 62.8942 L 68.751248 63.892905 L 68.804801 64.891594 L 68.846006 65.890751 L 68.886216 66.889945 L 68.923525 67.889249 L 68.983723 69.531925 L 69.019376 70.519785 L 69.060395 71.518979 L 69.088283 72.518822 L 69.114678 73.518739 L 69.146864 74.518369 L 69.177823 75.518061 L 69.206794 76.51785 L 69.239613 77.517449 L 69.22631 78.51933 L 69.200535 79.521827 L 69.217335 80.522218 L 69.199252 81.524335 L 69.19467 82.525784 L 69.210406 83.526228 L 69.169788 84.529459 L 69.190687 85.529648 L 69.208638 86.529982 L 69.227064 87.530293 L 69.221722 88.53178 L 69.206612 89.53375 L 69.217862 90.534416 L 69.171443 91.537934 L 69.171644 92.539146 L 69.177027 93.540102 L 69.186351 94.540864 L 69.127516 95.544996 L 69.135337 96.545831 L 69.124445 97.583556 L 69.117327 98.589227 L 69.075553 99.593805 L 69.101163 100.594161 L 69.117901 101.595073 L 69.112067 102.597399 L 69.125942 103.59849 L 69.111022 104.601385 L 69.143067 105.601338 L 69.136214 106.603728 L 69.174813 107.60327 L 69.208773 108.603103 L 69.229588 109.60376 L 69.27058 110.603152 L 69.319185 111.602067 L 69.35504 112.601782 L 69.408274 113.600407 L 69.458378 114.599229 L 69.50987 115.597963 L 69.566742 116.596361 L 69.624513 117.594702 L 69.692576 118.592399 L 69.777738 119.739256 L 69.863397 120.750051 L 69.965266 121.745157 L 70.065923 122.740358 L 70.179154 123.734585 L 70.282197 124.729601 L 70.38161 125.724897 L 70.527323 126.716611 L 70.678794 127.707878 L 70.849652 128.697646 L 70.97771 129.690726 L 71.108641 130.683583 L 71.220945 131.677882 L 71.403875 132.666715 L 71.533142 133.659702 L 71.647097 134.653873 L 71.755194 135.648497 L 71.966574 137.587295 L 72.127215 138.57948 L 72.269181 139.570559 L 72.427362 140.560119 L 72.558656 141.552198 L 72.693742 142.543921 L 72.828849 143.535643 L 72.981379 144.525732 L 73.187319 145.510818 L 73.332615 146.501585 L 73.465133 147.493549 L 73.605303 148.484796 L 73.755107 149.475141 L 73.880901 150.467735 L 74.089312 152.304535 L 74.231025 153.284892 L 74.375932 154.274931 L 74.544788 155.262299 L 74.700533 156.25113 L 74.840813 157.241685 L 75.001726 158.229938 L 75.137607 159.220984 L 75.269367 160.212489 L 75.414957 161.202452 L 75.549936 162.193598 L 75.674755 163.185877 L 75.859298 164.669696 L 76.002447 165.64111 L 76.144706 166.631019 L 76.280306 167.6218 L 76.416944 168.612445 L 76.551887 169.603312 L 76.679933 170.595082 L 76.807044 171.586974 L 76.925798 172.57996 L 77.027615 173.575164 L 77.200817 175.235419 L 77.327888 176.208648 L 77.437526 177.203464 L 77.548052 178.198145 L 77.679306 179.189678 L 77.8072 180.181721 L 77.89145 181.180392 L 77.992452 182.17652 L 78.069727 183.17625 L 78.222532 184.390967 L 78.316895 185.377432 L 78.450942 186.369146 L 78.549703 187.367014 L 78.618967 188.370025 L 78.72195 189.367156 L 78.790057 190.370369 L 78.907635 191.364955 L 78.968504 192.43285 L 79.094342 193.429735 L 79.175342 194.433158 L 79.320745 195.423802 L 79.480446 196.41161 L 79.585411 197.410278 L 79.727551 198.401569 L 79.858518 199.513305 L 80.01267 200.518739 L 80.185639 201.504776 L 80.333941 202.496339 L 80.503614 203.483114 L 80.705247 204.462729 L 80.970823 205.771754 L 81.208463 206.77257 L 81.439524 207.745701 L 81.652274 208.723556 L 81.886148 209.695962 L 82.12783 210.666353 L 82.373435 211.635733 L 82.616873 212.605672 L 82.948245 213.880046 L 83.253759 214.875087 L 83.558752 215.827583 L 83.878588 216.775594 L 84.204211 217.721856 L 84.526794 218.669037 L 84.876436 219.608041 L 85.238755 220.732965 L 85.627302 221.692365 L 85.981124 222.62801 L 86.363902 223.553525 L 86.723644 224.487099 L 87.10124 225.414426 L 87.557991 226.62142 L 88.013427 227.542336 L 88.449672 228.444799 L 88.929327 229.329851 L 89.371655 230.229875 L 90.06719 231.653606 L 90.55581 232.534187 L 91.069233 233.399147 L 91.519804 234.292755 L 92.028156 235.160027 L 92.53738 236.036614 L 93.027897 236.890589 L 93.515562 237.764294 L 94.018909 238.629939 L 94.760166 239.985381 L 95.278107 240.812752 L 95.835637 241.645661 L 96.368411 242.49282 L 96.992857 243.476372 L 97.556404 244.262897 L 98.138955 245.077295 L 99.174507 246.611243 L 99.750898 247.370904 L 100.348324 248.172979 L 100.967562 248.959328 L 101.995082 250.359155 L 102.610655 251.072353 L 103.259851 251.833246 L 103.897811 252.603337 L 104.769185 253.663765 L 105.406249 254.356161 L 106.075839 255.098982 L 106.741516 255.845414 L 107.453787 256.664083 L 108.125554 257.332034 L 108.807346 258.065474 L 110.106217 259.391396 L 110.792544 260.059592 L 111.517811 260.749487 L 112.732987 261.89968 L 113.463779 262.529989 L 114.220378 263.186086 L 114.967448 263.854448 L 116.025569 264.749217 L 116.801037 265.344128 L 117.580448 265.975376 L 118.37063 266.591005 L 119.3289 267.32553 L 120.153183 267.876943 L 120.970352 268.457005 L 121.766514 269.071152 L 122.643268 269.682309 L 123.4778 270.250033 L 124.339185 270.758992 L 125.191427 271.284622 L 126.659752 272.223185 L 127.560452 272.701216 L 128.435278 273.188866 L 129.32126 273.653579 L 130.739614 274.441745 L 131.665634 274.88977 L 132.552177 275.359434 L 133.446921 275.810045 L 134.340502 276.263358 L 135.504623 276.789422 L 136.468415 277.17404 L 137.392849 277.556477 L 138.316778 277.940244 L 139.247024 278.307394 L 140.346608 278.752094 L 141.327375 279.094856 L 142.274197 279.416637 L 143.223627 279.730645 L 144.175573 280.037162 L 145.927841 280.610129 L 146.926783 280.8878 L 147.896196 281.135793 L 148.861212 281.39874 L 149.836567 281.626521 L 150.814914 281.844128 L 152.257896 282.239851 L 153.258992 282.46307 L 154.239491 282.665534 L 155.219891 282.868382 L 156.202985 283.060778 L 157.195196 283.217804 L 158.596452 283.534445 L 159.594804 283.70952 L 160.583051 283.873212 L 161.56888 284.047583 L 162.557699 284.208747 L 163.545404 284.374828 L 164.537103 284.52327 L 165.635746 284.651764 L 166.626275 284.79097 L 167.62826 284.878941 L 168.629842 284.968949 L 169.631701 285.05756 L 170.619374 285.217848 L 171.620404 285.310643 L 173.366427 285.578994 L 174.342678 285.706215 L 175.334943 285.836446 L 176.324352 285.983334 L 177.319395 286.097372 L 178.309407 286.240743 L 179.300126 286.37999 L 180.294316 286.498997 L 181.283077 286.649662 L 182.40399 286.819892 L 183.373434 286.949984 L 184.365484 287.077256 L 185.357299 287.206115 L 186.347603 287.345213 L 187.336728 287.492289 L 188.324981 287.64528 L 189.312888 287.800611 L 190.298746 287.969819 L 192.075455 288.257497 L 193.046842 288.392725 L 194.034774 288.551108 L 195.024806 288.692897 L 196.014583 288.836709 L 197.000501 289.011008 L 197.987087 289.180026 L 198.973765 289.348322 L 199.962971 289.496633 L 200.950003 289.662129 L 201.931436 289.871869 L 203.084759 290.060556 L 204.062382 290.230494 L 205.051892 290.38159 L 206.034598 290.595879 L 207.020613 290.779439 L 208.010964 290.922733 L 208.99934 291.084367 L 209.985552 291.266098 L 210.973531 291.431419 L 211.963867 291.574846 L 212.946124 291.793311 L 213.933772 291.961704 L 215.456043 292.176435 L 216.44705 292.366026 L 217.439466 292.494696 L 218.432116 292.620802 L 219.419664 292.802862 L 220.411603 292.936761 L 221.40263 293.080674 L 222.395514 293.204208 L 223.385672 293.357647 L 224.37665 293.502084 L 225.367331 293.649779 L 226.361194 293.762582 L 227.353091 293.896946 L 229.247785 294.116996 L 230.256922 294.211404 L 231.251845 294.315884 L 232.248075 294.403337 L 233.244796 294.484382 L 234.241434 294.566502 L 235.2385 294.643042 L 236.235807 294.71645 L 237.233146 294.789436 L 238.230662 294.86012 L 239.228716 294.923795 L 240.227593 294.976728 L 241.225802 295.038376 L 242.224675 295.091362 L 243.224524 295.131639 L 245.194758 295.251106 L 246.205224 295.285947 L 247.208209 295.271342 L 248.2085 295.298792 L 249.208099 295.337047 L 250.210571 295.330445 L 251.21435 295.303456 L 252.216265 295.305552 L 253.216369 295.335934 L 254.216529 295.36543 L 255.220712 295.332116 L 256.221709 295.34855 L 257.221678 295.381034 L 258.222425 295.401365 L 259.224865 295.395266 L 260.226008 295.409427 L 261.226179 295.438747 L 262.231143 295.393249 L 263.272267 295.426401 L 264.271346 295.442036 L 265.274194 295.414917 L 266.274829 295.42949 L 267.275637 295.440784 L 268.27648 295.451431 L 269.280891 295.39487 L 270.284165 295.359721 L 271.286716 295.338193 L 272.289999 295.302872 L 273.292519 295.281928 L 274.293719 295.285843 L 275.295262 295.283317 L 276.295695 295.301679 L 277.294918 295.342837 L 278.29469 295.373657 L 279.293919 295.414708 L 280.292606 295.465972 L 281.290912 295.524393 L 282.288647 295.593581 L 284.088582 295.705657 L 285.077144 295.779884 L 286.075615 295.83675 L 287.073378 295.909877 L 288.069688 296.016355 L 289.066595 296.109143 L 290.063642 296.198701 L 291.059117 296.324365 L 292.056173 296.413738 L 293.053732 296.491544 L 294.050455 296.588546 L 295.04564 296.720862 L 296.043338 296.795485 L 297.037689 296.946945 L 298.031865 297.102424 L 299.029376 297.181342 L 300.02474 297.309562 L 301.020938 297.41862 L 302.01555 297.564091 L 303.009546 297.72371 L 304.006828 297.807876 L 305.004093 297.89244 L 306.001551 297.97256 L 306.99882 298.057031 L 308.253736 298.18783 L 309.25425 298.299319 L 310.252542 298.365306 L 311.250983 298.427099 L 312.248361 298.518964 L 313.246164 298.598771 L 314.24448 298.66409 L 315.242901 298.726448 L 316.240773 298.804306 L 317.238282 298.892457 L 318.236566 298.958678 L 319.235014 299.020255 L 320.233863 299.070498 L 321.232169 299.136087 L 322.230792 299.192722 L 323.229572 299.244919 L 324.228781 299.284951 L 325.228136 299.320879 L 326.227584 299.354153 L 327.227167 299.383615 L 328.227202 299.400298 L 329.22771 299.403581 L 330.228727 299.392489 L 331.229584 299.385888 L 332.231316 299.354544 L 333.233132 299.32084 L 334.234181 299.308813 L 335.235377 299.292646 L 336.644884 299.302734 L 337.650476 299.261826 L 338.651961 299.223678 L 339.654647 299.143167 L 340.656095 299.106301 L 341.658761 299.026492 L 342.660089 298.993868 L 343.661067 298.973558 L 344.662827 298.925711 L 345.664113 298.894559 L 346.665827 298.848316 L 347.668794 298.757893 L 348.671169 298.688343 L 349.673009 298.637681 L 350.673904 298.620309 L 351.674275 298.621403 L 352.675111 298.606114 L 353.676086 298.585905 L 354.676584 298.582539 L 355.678457 298.530697 L 356.67994 298.492586 L 357.680219 298.496927 L 358.681533 298.464808 L 359.681761 298.470941 L 360.681886 298.480703 L 361.682316 298.479744 L 362.682359 298.492406 L 363.682192 298.512465 L 364.68208 298.530589 L 365.681972 298.548605 L 366.68155 298.577639 L 367.681041 298.609773 L 368.680173 298.654563 L 369.931243 298.70219 L 370.925472 298.735551 L 371.924491 298.789824 L 372.923638 298.838493 L 373.922657 298.892797 L 374.921872 298.938504 L 375.921207 298.978997 L 376.919803 299.0517 L 377.918449 299.122251 L 378.916545 299.216844 L 379.915005 299.295496 L 380.914143 299.34459 L 381.913176 299.398255 L 382.910858 299.510892 L 383.908653 299.618568 L 384.906889 299.707048 L 385.905577 299.775764 L 386.90433 299.841654 L 387.902659 299.926054 L 388.90011 300.048757 L 389.89883 300.116079 L 390.897421 300.189018 L 391.894368 300.333731 L 392.892739 300.416312 L 393.891754 300.470773 L 394.890751 300.526012 L 395.889239 300.603461 L 396.888003 300.668853 L 397.886562 300.743215 L 398.884275 300.854481 L 399.883229 300.911572 L 400.881961 300.978398 L 401.880239 301.064998 L 403.125459 301.168742 L 403.1424 300.429259 " + clip-path="url(#p53efc7421d)" + style="fill: none; stroke: #ffffff; stroke-width: 4; stroke-linecap: square" + id="path9" /> + <path + d="M 65.62632 -1 L 65.623625 0.00049 L 65.615428 1.001139 L 65.54645 2.003534 L 65.542671 3.004056 L 65.497805 4.005758 L 65.487983 5.006453 L 65.481313 6.007058 L 65.452425 7.008301 L 65.410796 8.00991 L 65.387582 9.010991 L 65.357245 10.012275 L 65.297688 11.0144 L 65.280291 12.015313 L 65.266626 13.016118 L 65.264874 14.016582 L 65.267569 15.016917 L 65.275105 16.017113 L 65.249555 17.018261 L 65.250357 18.018651 L 65.249374 19.019092 L 65.252718 20.019409 L 65.27025 21.019318 L 65.288859 22.019196 L 65.317792 23.018777 L 65.356026 24.018091 L 65.396403 25.017344 L 65.456148 26.016039 L 65.496039 27.015306 L 65.554873 28.014028 L 65.643353 29.011898 L 65.709257 30.010417 L 65.777066 31.008881 L 65.875969 32.972894 L 65.946725 33.977527 L 66.051898 34.974264 L 66.12879 35.972071 L 66.209229 36.969744 L 66.317554 37.966362 L 66.391713 38.964272 L 66.487869 39.96135 L 66.636537 40.956442 L 66.74494 41.953057 L 66.895594 42.948074 L 66.979128 43.94563 L 67.078163 44.942599 L 67.164422 45.940052 L 67.282982 46.936282 L 67.43921 47.931089 L 67.547166 48.927721 L 67.668163 49.923859 L 67.739076 50.921892 L 67.828071 51.919241 L 67.934216 52.915942 L 68.038178 53.912725 L 68.152835 54.909103 L 68.217926 55.907356 L 68.282179 56.905641 L 68.342608 57.90407 L 68.39992 58.902618 L 68.46409 59.900906 L 68.55162 60.89831 L 68.624463 61.89627 L 68.698097 62.8942 L 68.751248 63.892905 L 68.804801 64.891594 L 68.846006 65.890751 L 68.886216 66.889945 L 68.923525 67.889249 L 68.983723 69.531925 L 69.019376 70.519785 L 69.060395 71.518979 L 69.088283 72.518822 L 69.114678 73.518739 L 69.146864 74.518369 L 69.177823 75.518061 L 69.206794 76.51785 L 69.239613 77.517449 L 69.22631 78.51933 L 69.200535 79.521827 L 69.217335 80.522218 L 69.199252 81.524335 L 69.19467 82.525784 L 69.210406 83.526228 L 69.169788 84.529459 L 69.190687 85.529648 L 69.208638 86.529982 L 69.227064 87.530293 L 69.221722 88.53178 L 69.206612 89.53375 L 69.217862 90.534416 L 69.171443 91.537934 L 69.171644 92.539146 L 69.177027 93.540102 L 69.186351 94.540864 L 69.127516 95.544996 L 69.135337 96.545831 L 69.124445 97.583556 L 69.117327 98.589227 L 69.075553 99.593805 L 69.101163 100.594161 L 69.117901 101.595073 L 69.112067 102.597399 L 69.125942 103.59849 L 69.111022 104.601385 L 69.143067 105.601338 L 69.136214 106.603728 L 69.174813 107.60327 L 69.208773 108.603103 L 69.229588 109.60376 L 69.27058 110.603152 L 69.319185 111.602067 L 69.35504 112.601782 L 69.408274 113.600407 L 69.458378 114.599229 L 69.50987 115.597963 L 69.566742 116.596361 L 69.624513 117.594702 L 69.692576 118.592399 L 69.777738 119.739256 L 69.863397 120.750051 L 69.965266 121.745157 L 70.065923 122.740358 L 70.179154 123.734585 L 70.282197 124.729601 L 70.38161 125.724897 L 70.527323 126.716611 L 70.678794 127.707878 L 70.849652 128.697646 L 70.97771 129.690726 L 71.108641 130.683583 L 71.220945 131.677882 L 71.403875 132.666715 L 71.533142 133.659702 L 71.647097 134.653873 L 71.755194 135.648497 L 71.966574 137.587295 L 72.127215 138.57948 L 72.269181 139.570559 L 72.427362 140.560119 L 72.558656 141.552198 L 72.693742 142.543921 L 72.828849 143.535643 L 72.981379 144.525732 L 73.187319 145.510818 L 73.332615 146.501585 L 73.465133 147.493549 L 73.605303 148.484796 L 73.755107 149.475141 L 73.880901 150.467735 L 74.089312 152.304535 L 74.231025 153.284892 L 74.375932 154.274931 L 74.544788 155.262299 L 74.700533 156.25113 L 74.840813 157.241685 L 75.001726 158.229938 L 75.137607 159.220984 L 75.269367 160.212489 L 75.414957 161.202452 L 75.549936 162.193598 L 75.674755 163.185877 L 75.859298 164.669696 L 76.002447 165.64111 L 76.144706 166.631019 L 76.280306 167.6218 L 76.416944 168.612445 L 76.551887 169.603312 L 76.679933 170.595082 L 76.807044 171.586974 L 76.925798 172.57996 L 77.027615 173.575164 L 77.200817 175.235419 L 77.327888 176.208648 L 77.437526 177.203464 L 77.548052 178.198145 L 77.679306 179.189678 L 77.8072 180.181721 L 77.89145 181.180392 L 77.992452 182.17652 L 78.069727 183.17625 L 78.222532 184.390967 L 78.316895 185.377432 L 78.450942 186.369146 L 78.549703 187.367014 L 78.618967 188.370025 L 78.72195 189.367156 L 78.790057 190.370369 L 78.907635 191.364955 L 78.968504 192.43285 L 79.094342 193.429735 L 79.175342 194.433158 L 79.320745 195.423802 L 79.480446 196.41161 L 79.585411 197.410278 L 79.727551 198.401569 L 79.858518 199.513305 L 80.01267 200.518739 L 80.185639 201.504776 L 80.333941 202.496339 L 80.503614 203.483114 L 80.705247 204.462729 L 80.970823 205.771754 L 81.208463 206.77257 L 81.439524 207.745701 L 81.652274 208.723556 L 81.886148 209.695962 L 82.12783 210.666353 L 82.373435 211.635733 L 82.616873 212.605672 L 82.948245 213.880046 L 83.253759 214.875087 L 83.558752 215.827583 L 83.878588 216.775594 L 84.204211 217.721856 L 84.526794 218.669037 L 84.876436 219.608041 L 85.238755 220.732965 L 85.627302 221.692365 L 85.981124 222.62801 L 86.363902 223.553525 L 86.723644 224.487099 L 87.10124 225.414426 L 87.557991 226.62142 L 88.013427 227.542336 L 88.449672 228.444799 L 88.929327 229.329851 L 89.371655 230.229875 L 90.06719 231.653606 L 90.55581 232.534187 L 91.069233 233.399147 L 91.519804 234.292755 L 92.028156 235.160027 L 92.53738 236.036614 L 93.027897 236.890589 L 93.515562 237.764294 L 94.018909 238.629939 L 94.760166 239.985381 L 95.278107 240.812752 L 95.835637 241.645661 L 96.368411 242.49282 L 96.992857 243.476372 L 97.556404 244.262897 L 98.138955 245.077295 L 99.174507 246.611243 L 99.750898 247.370904 L 100.348324 248.172979 L 100.967562 248.959328 L 101.995082 250.359155 L 102.610655 251.072353 L 103.259851 251.833246 L 103.897811 252.603337 L 104.769185 253.663765 L 105.406249 254.356161 L 106.075839 255.098982 L 106.741516 255.845414 L 107.453787 256.664083 L 108.125554 257.332034 L 108.807346 258.065474 L 110.106217 259.391396 L 110.792544 260.059592 L 111.517811 260.749487 L 112.732987 261.89968 L 113.463779 262.529989 L 114.220378 263.186086 L 114.967448 263.854448 L 116.025569 264.749217 L 116.801037 265.344128 L 117.580448 265.975376 L 118.37063 266.591005 L 119.3289 267.32553 L 120.153183 267.876943 L 120.970352 268.457005 L 121.766514 269.071152 L 122.643268 269.682309 L 123.4778 270.250033 L 124.339185 270.758992 L 125.191427 271.284622 L 126.659752 272.223185 L 127.560452 272.701216 L 128.435278 273.188866 L 129.32126 273.653579 L 130.739614 274.441745 L 131.665634 274.88977 L 132.552177 275.359434 L 133.446921 275.810045 L 134.340502 276.263358 L 135.504623 276.789422 L 136.468415 277.17404 L 137.392849 277.556477 L 138.316778 277.940244 L 139.247024 278.307394 L 140.346608 278.752094 L 141.327375 279.094856 L 142.274197 279.416637 L 143.223627 279.730645 L 144.175573 280.037162 L 145.927841 280.610129 L 146.926783 280.8878 L 147.896196 281.135793 L 148.861212 281.39874 L 149.836567 281.626521 L 150.814914 281.844128 L 152.257896 282.239851 L 153.258992 282.46307 L 154.239491 282.665534 L 155.219891 282.868382 L 156.202985 283.060778 L 157.195196 283.217804 L 158.596452 283.534445 L 159.594804 283.70952 L 160.583051 283.873212 L 161.56888 284.047583 L 162.557699 284.208747 L 163.545404 284.374828 L 164.537103 284.52327 L 165.635746 284.651764 L 166.626275 284.79097 L 167.62826 284.878941 L 168.629842 284.968949 L 169.631701 285.05756 L 170.619374 285.217848 L 171.620404 285.310643 L 173.366427 285.578994 L 174.342678 285.706215 L 175.334943 285.836446 L 176.324352 285.983334 L 177.319395 286.097372 L 178.309407 286.240743 L 179.300126 286.37999 L 180.294316 286.498997 L 181.283077 286.649662 L 182.40399 286.819892 L 183.373434 286.949984 L 184.365484 287.077256 L 185.357299 287.206115 L 186.347603 287.345213 L 187.336728 287.492289 L 188.324981 287.64528 L 189.312888 287.800611 L 190.298746 287.969819 L 192.075455 288.257497 L 193.046842 288.392725 L 194.034774 288.551108 L 195.024806 288.692897 L 196.014583 288.836709 L 197.000501 289.011008 L 197.987087 289.180026 L 198.973765 289.348322 L 199.962971 289.496633 L 200.950003 289.662129 L 201.931436 289.871869 L 203.084759 290.060556 L 204.062382 290.230494 L 205.051892 290.38159 L 206.034598 290.595879 L 207.020613 290.779439 L 208.010964 290.922733 L 208.99934 291.084367 L 209.985552 291.266098 L 210.973531 291.431419 L 211.963867 291.574846 L 212.946124 291.793311 L 213.933772 291.961704 L 215.456043 292.176435 L 216.44705 292.366026 L 217.439466 292.494696 L 218.432116 292.620802 L 219.419664 292.802862 L 220.411603 292.936761 L 221.40263 293.080674 L 222.395514 293.204208 L 223.385672 293.357647 L 224.37665 293.502084 L 225.367331 293.649779 L 226.361194 293.762582 L 227.353091 293.896946 L 229.247785 294.116996 L 230.256922 294.211404 L 231.251845 294.315884 L 232.248075 294.403337 L 233.244796 294.484382 L 234.241434 294.566502 L 235.2385 294.643042 L 236.235807 294.71645 L 237.233146 294.789436 L 238.230662 294.86012 L 239.228716 294.923795 L 240.227593 294.976728 L 241.225802 295.038376 L 242.224675 295.091362 L 243.224524 295.131639 L 245.194758 295.251106 L 246.205224 295.285947 L 247.208209 295.271342 L 248.2085 295.298792 L 249.208099 295.337047 L 250.210571 295.330445 L 251.21435 295.303456 L 252.216265 295.305552 L 253.216369 295.335934 L 254.216529 295.36543 L 255.220712 295.332116 L 256.221709 295.34855 L 257.221678 295.381034 L 258.222425 295.401365 L 259.224865 295.395266 L 260.226008 295.409427 L 261.226179 295.438747 L 262.231143 295.393249 L 263.272267 295.426401 L 264.271346 295.442036 L 265.274194 295.414917 L 266.274829 295.42949 L 267.275637 295.440784 L 268.27648 295.451431 L 269.280891 295.39487 L 270.284165 295.359721 L 271.286716 295.338193 L 272.289999 295.302872 L 273.292519 295.281928 L 274.293719 295.285843 L 275.295262 295.283317 L 276.295695 295.301679 L 277.294918 295.342837 L 278.29469 295.373657 L 279.293919 295.414708 L 280.292606 295.465972 L 281.290912 295.524393 L 282.288647 295.593581 L 284.088582 295.705657 L 285.077144 295.779884 L 286.075615 295.83675 L 287.073378 295.909877 L 288.069688 296.016355 L 289.066595 296.109143 L 290.063642 296.198701 L 291.059117 296.324365 L 292.056173 296.413738 L 293.053732 296.491544 L 294.050455 296.588546 L 295.04564 296.720862 L 296.043338 296.795485 L 297.037689 296.946945 L 298.031865 297.102424 L 299.029376 297.181342 L 300.02474 297.309562 L 301.020938 297.41862 L 302.01555 297.564091 L 303.009546 297.72371 L 304.006828 297.807876 L 305.004093 297.89244 L 306.001551 297.97256 L 306.99882 298.057031 L 308.253736 298.18783 L 309.25425 298.299319 L 310.252542 298.365306 L 311.250983 298.427099 L 312.248361 298.518964 L 313.246164 298.598771 L 314.24448 298.66409 L 315.242901 298.726448 L 316.240773 298.804306 L 317.238282 298.892457 L 318.236566 298.958678 L 319.235014 299.020255 L 320.233863 299.070498 L 321.232169 299.136087 L 322.230792 299.192722 L 323.229572 299.244919 L 324.228781 299.284951 L 325.228136 299.320879 L 326.227584 299.354153 L 327.227167 299.383615 L 328.227202 299.400298 L 329.22771 299.403581 L 330.228727 299.392489 L 331.229584 299.385888 L 332.231316 299.354544 L 333.233132 299.32084 L 334.234181 299.308813 L 335.235377 299.292646 L 336.644884 299.302734 L 337.650476 299.261826 L 338.651961 299.223678 L 339.654647 299.143167 L 340.656095 299.106301 L 341.658761 299.026492 L 342.660089 298.993868 L 343.661067 298.973558 L 344.662827 298.925711 L 345.664113 298.894559 L 346.665827 298.848316 L 347.668794 298.757893 L 348.671169 298.688343 L 349.673009 298.637681 L 350.673904 298.620309 L 351.674275 298.621403 L 352.675111 298.606114 L 353.676086 298.585905 L 354.676584 298.582539 L 355.678457 298.530697 L 356.67994 298.492586 L 357.680219 298.496927 L 358.681533 298.464808 L 359.681761 298.470941 L 360.681886 298.480703 L 361.682316 298.479744 L 362.682359 298.492406 L 363.682192 298.512465 L 364.68208 298.530589 L 365.681972 298.548605 L 366.68155 298.577639 L 367.681041 298.609773 L 368.680173 298.654563 L 369.931243 298.70219 L 370.925472 298.735551 L 371.924491 298.789824 L 372.923638 298.838493 L 373.922657 298.892797 L 374.921872 298.938504 L 375.921207 298.978997 L 376.919803 299.0517 L 377.918449 299.122251 L 378.916545 299.216844 L 379.915005 299.295496 L 380.914143 299.34459 L 381.913176 299.398255 L 382.910858 299.510892 L 383.908653 299.618568 L 384.906889 299.707048 L 385.905577 299.775764 L 386.90433 299.841654 L 387.902659 299.926054 L 388.90011 300.048757 L 389.89883 300.116079 L 390.897421 300.189018 L 391.894368 300.333731 L 392.892739 300.416312 L 393.891754 300.470773 L 394.890751 300.526012 L 395.889239 300.603461 L 396.888003 300.668853 L 397.886562 300.743215 L 398.884275 300.854481 L 399.883229 300.911572 L 400.881961 300.978398 L 401.880239 301.064998 L 403.125459 301.168742 L 403.1424 300.429259 " + clip-path="url(#p53efc7421d)" + style="fill: none; stroke: #0000ff; stroke-width: 2; stroke-linecap: square" + id="path10" /> + </g> + <g + id="patch_3"> + <path + d="M 59.602588 307.584 L 60.602588 307.615436 L 61.602588 307.652377 L 62.602588 307.750123 L 63.602588 307.782645 L 64.602588 307.85627 L 65.602588 307.894835 L 66.602588 307.930248 L 67.602588 307.987888 L 68.602588 308.058274 L 69.602588 308.110239 L 70.602588 308.169328 L 71.602588 308.257649 L 72.602588 308.303794 L 73.602588 308.346205 L 74.602588 308.376697 L 75.602588 308.402742 L 76.602588 308.423942 L 77.602588 308.478243 L 78.602588 308.506181 L 79.602588 308.535905 L 80.602588 308.5613 L 81.602588 308.5725 L 82.602588 308.582624 L 83.602588 308.58242 L 84.602588 308.57291 L 85.602588 308.561256 L 86.602588 308.530227 L 87.602588 308.519059 L 88.602588 308.488942 L 89.602588 308.429165 L 90.602588 308.391973 L 91.602588 308.352877 L 92.602588 308.310437 L 93.602588 308.277672 L 94.602588 308.210246 L 95.602588 308.17112 L 96.602588 308.128445 L 97.602588 308.057865 L 98.602588 308.021474 L 99.602588 307.963071 L 100.602588 307.852118 L 101.602588 307.78146 L 102.602588 307.66852 L 103.602588 307.622747 L 104.602588 307.561464 L 105.602588 307.512965 L 106.602588 307.432142 L 107.602588 307.313623 L 108.602588 307.243412 L 109.602588 307.16015 L 110.602588 307.127008 L 111.602588 307.075771 L 112.602588 307.007372 L 113.602588 306.941157 L 114.602588 306.86424 L 115.602588 306.836924 L 116.602588 306.810447 L 117.602588 306.787796 L 118.602588 306.768265 L 119.602588 306.741871 L 120.602588 306.6921 L 121.602588 306.657027 L 122.602588 306.621161 L 123.602588 306.605794 L 124.602588 306.590025 L 125.602588 306.586612 L 126.602588 306.584195 L 127.602588 306.584681 L 128.602588 306.58661 L 129.602588 306.599867 L 130.602588 306.608258 L 131.602588 306.629794 L 132.602588 306.652827 L 133.602588 306.67006 L 134.602588 306.688523 L 135.602588 306.708975 L 136.602588 306.725575 L 137.602588 306.788354 L 138.602588 306.863619 L 139.602588 306.896258 L 140.602588 306.963822 L 141.602588 307.017869 L 142.602588 307.051573 L 143.602588 307.141699 L 144.602588 307.170234 L 145.602588 307.20172 L 146.602588 307.232731 L 147.602588 307.287539 L 148.602588 307.352126 L 149.602588 307.390322 L 150.602588 307.486256 L 151.602588 307.535514 L 152.602588 307.579583 L 153.602588 307.619707 L 154.602588 307.728074 L 155.602588 307.769702 L 156.602588 307.831844 L 157.602588 307.901806 L 158.602588 308.00631 L 159.602588 308.043298 L 160.602588 308.089175 L 161.602588 308.15767 L 162.602588 308.206416 L 163.602588 308.284013 L 164.602588 308.314554 L 165.602588 308.384068 L 166.602588 308.408041 L 167.602588 308.436663 L 168.602588 308.478456 L 169.602588 308.500032 L 170.602588 308.51398 L 171.602588 308.540702 L 172.602588 308.550012 L 173.602588 308.562459 L 174.602588 308.573514 L 175.602588 308.579178 L 176.602588 308.583942 L 177.602588 308.578394 L 178.602588 308.565106 L 179.602588 308.557589 L 180.602588 308.532804 L 181.602588 308.509235 L 182.602588 308.473055 L 183.602588 308.447093 L 184.602588 308.424771 L 185.602588 308.356011 L 186.602588 308.281476 L 187.602588 308.187497 L 188.602588 308.136445 L 189.602588 308.082511 L 190.602588 308.04726 L 191.602588 307.941172 L 192.602588 307.888908 L 193.602588 307.852001 L 194.602588 307.82097 L 195.602588 307.759815 L 196.602588 307.692395 L 197.602588 307.643489 L 198.602588 307.578297 L 199.602588 307.540109 L 200.602588 307.498113 L 201.602588 307.456096 L 202.602588 307.39658 L 203.602588 307.28342 L 204.602588 307.231169 L 205.602588 307.191751 L 206.602588 307.14465 L 207.602588 307.08787 L 208.602588 307.055207 L 209.602588 307.019029 L 210.602588 306.986939 L 211.602588 306.952659 L 212.602588 306.894281 L 213.602588 306.849096 L 214.602588 306.819472 L 215.602588 306.769086 L 216.602588 306.743889 L 217.602588 306.722838 L 218.602588 306.68787 L 219.602588 306.66358 L 220.602588 306.649513 L 221.602588 306.630571 L 222.602588 306.61491 L 223.602588 306.602358 L 224.602588 306.596522 L 225.602588 306.58964 L 226.602588 306.584466 L 227.602588 306.586249 L 228.602588 306.588974 L 229.602588 306.600128 L 230.602588 306.628363 L 231.602588 306.672151 L 232.602588 306.69284 L 233.602588 306.733813 L 234.602588 306.773888 L 235.602588 306.792998 L 236.602588 306.815507 L 237.602588 306.882158 L 238.602588 306.931868 L 239.602588 307.005574 L 240.602588 307.036888 L 241.602588 307.11351 L 242.602588 307.151808 L 243.602588 307.225925 L 244.602588 307.329983 L 245.602588 307.399814 L 246.602588 307.505048 L 247.602588 307.560063 L 248.602588 307.683538 L 249.602588 307.754097 L 250.602588 307.869936 L 251.602588 307.920117 L 252.602588 307.955721 L 253.602588 308.047128 L 254.602588 308.100636 L 255.602588 308.188544 L 256.602588 308.257729 L 257.602588 308.304493 L 258.602588 308.376537 L 259.602588 308.426679 L 260.602588 308.444069 L 261.602588 308.471072 L 262.602588 308.490499 L 263.602588 308.509837 L 264.602588 308.548086 L 265.602588 308.564519 L 266.602588 308.572888 L 267.602588 308.577207 L 268.602588 308.583762 L 269.602588 308.581216 L 270.602588 308.575757 L 271.602588 308.559329 L 272.602588 308.527394 L 273.602588 308.489414 L 274.602588 308.45461 L 275.602588 308.391538 L 276.602588 308.370111 L 277.602588 308.319493 L 278.602588 308.294536 L 279.602588 308.238902 L 280.602588 308.207673 L 281.602588 308.157529 L 282.602588 308.125036 L 283.602588 308.044624 L 284.602588 307.975698 L 285.602588 307.860001 L 286.602588 307.784522 L 287.602588 307.668997 L 288.602588 307.589513 L 289.602588 307.481072 L 290.602588 307.441704 L 291.602588 307.338836 L 292.602588 307.239038 L 293.602588 307.193541 L 294.602588 307.159219 L 295.602588 307.107263 L 296.602588 307.067616 L 297.602588 307.032102 L 298.602588 306.964457 L 299.602588 306.925375 L 300.602588 306.874894 L 301.602588 306.825588 L 302.602588 306.774518 L 303.602588 306.730279 L 304.602588 306.708259 L 305.602588 306.692703 L 306.602588 306.650256 L 307.602588 306.635388 L 308.602588 306.61266 L 309.602588 306.592344 L 310.602588 306.586547 L 311.602588 306.584065 L 312.602588 306.587122 L 313.602588 306.598718 L 314.602588 306.615638 L 315.602588 306.647299 L 316.602588 306.661382 L 317.602588 306.714054 L 318.602588 306.763143 L 319.602588 306.817844 L 320.602588 306.862192 L 321.602588 306.932184 L 322.602588 306.982567 L 323.602588 307.036474 L 324.602588 307.105913 L 325.602588 307.163301 L 326.602588 307.213466 L 327.602588 307.290628 L 328.602588 307.348818 L 329.602588 307.409456 L 330.602588 307.446657 L 331.602588 307.511749 L 332.602588 307.616879 L 333.602588 307.677181 L 334.602588 307.773503 L 335.602588 307.805506 L 336.602588 307.856523 L 337.602588 307.973315 L 338.602588 308.008762 L 339.602588 308.064642 L 340.602588 308.095018 L 341.602588 308.183404 L 342.602588 308.228168 L 343.602588 308.309056 L 344.602588 308.369202 L 345.602588 308.432288 L 346.602588 308.455236 L 347.602588 308.471406 L 348.602588 308.500335 L 349.602588 308.530687 L 350.602588 308.543261 L 351.602588 308.56814 L 352.602588 308.580224 L 353.602588 308.583986 L 354.602588 308.57955 L 355.602588 308.567211 L 356.602588 308.552798 L 357.602588 308.536725 L 358.602588 308.501204 L 359.602588 308.48127 L 360.602588 308.424681 L 361.602588 308.357487 L 362.602588 308.330117 L 363.602588 308.295969 L 364.602588 308.247289 L 365.602588 308.199004 L 366.602588 308.139927 L 367.602588 308.044322 L 368.602588 308.001182 L 369.602588 307.951334 L 370.602588 307.8928 L 371.602588 307.845214 L 372.602588 307.784086 L 373.602588 307.728001 L 374.602588 307.65383 L 375.602588 307.536592 L 376.602588 307.480868 L 377.602588 307.372642 L 378.602588 307.266492 L 379.602588 307.15892 L 380.602588 307.124412 L 381.602588 307.021105 L 382.602588 306.945381 L 383.602588 306.905946 L 384.602588 306.866562 L 385.602588 306.84408 L 386.602588 306.788267 L 387.602588 306.762215 L 388.602588 306.73198 L 389.602588 306.681209 L 390.602588 306.662558 L 391.602588 306.640849 L 392.602588 306.628203 L 393.602588 306.60921 L 394.602588 306.59182 L 395.602588 306.584782 L 396.602588 306.585806 L 397.602588 306.59281 L 398.602588 306.60218 L 399.602588 306.625578 L 400.602588 306.650661 L 401.602588 306.66306 L 402.602588 306.696153 L 403.602588 306.71252 L 404.602588 306.730925 L 405.602588 306.780062 L 406.602588 306.823875 L 407.602588 306.86696 L 408.602588 306.889901 L 409.602588 306.930164 L 411.599771 307.015024 " + style="fill: none; stroke: #ffffff; stroke-width: 4; stroke-linecap: round" + id="path11" /> + <path + d="M 59.602588 307.584 L 60.602588 307.615436 L 61.602588 307.652377 L 62.602588 307.750123 L 63.602588 307.782645 L 64.602588 307.85627 L 65.602588 307.894835 L 66.602588 307.930248 L 67.602588 307.987888 L 68.602588 308.058274 L 69.602588 308.110239 L 70.602588 308.169328 L 71.602588 308.257649 L 72.602588 308.303794 L 73.602588 308.346205 L 74.602588 308.376697 L 75.602588 308.402742 L 76.602588 308.423942 L 77.602588 308.478243 L 78.602588 308.506181 L 79.602588 308.535905 L 80.602588 308.5613 L 81.602588 308.5725 L 82.602588 308.582624 L 83.602588 308.58242 L 84.602588 308.57291 L 85.602588 308.561256 L 86.602588 308.530227 L 87.602588 308.519059 L 88.602588 308.488942 L 89.602588 308.429165 L 90.602588 308.391973 L 91.602588 308.352877 L 92.602588 308.310437 L 93.602588 308.277672 L 94.602588 308.210246 L 95.602588 308.17112 L 96.602588 308.128445 L 97.602588 308.057865 L 98.602588 308.021474 L 99.602588 307.963071 L 100.602588 307.852118 L 101.602588 307.78146 L 102.602588 307.66852 L 103.602588 307.622747 L 104.602588 307.561464 L 105.602588 307.512965 L 106.602588 307.432142 L 107.602588 307.313623 L 108.602588 307.243412 L 109.602588 307.16015 L 110.602588 307.127008 L 111.602588 307.075771 L 112.602588 307.007372 L 113.602588 306.941157 L 114.602588 306.86424 L 115.602588 306.836924 L 116.602588 306.810447 L 117.602588 306.787796 L 118.602588 306.768265 L 119.602588 306.741871 L 120.602588 306.6921 L 121.602588 306.657027 L 122.602588 306.621161 L 123.602588 306.605794 L 124.602588 306.590025 L 125.602588 306.586612 L 126.602588 306.584195 L 127.602588 306.584681 L 128.602588 306.58661 L 129.602588 306.599867 L 130.602588 306.608258 L 131.602588 306.629794 L 132.602588 306.652827 L 133.602588 306.67006 L 134.602588 306.688523 L 135.602588 306.708975 L 136.602588 306.725575 L 137.602588 306.788354 L 138.602588 306.863619 L 139.602588 306.896258 L 140.602588 306.963822 L 141.602588 307.017869 L 142.602588 307.051573 L 143.602588 307.141699 L 144.602588 307.170234 L 145.602588 307.20172 L 146.602588 307.232731 L 147.602588 307.287539 L 148.602588 307.352126 L 149.602588 307.390322 L 150.602588 307.486256 L 151.602588 307.535514 L 152.602588 307.579583 L 153.602588 307.619707 L 154.602588 307.728074 L 155.602588 307.769702 L 156.602588 307.831844 L 157.602588 307.901806 L 158.602588 308.00631 L 159.602588 308.043298 L 160.602588 308.089175 L 161.602588 308.15767 L 162.602588 308.206416 L 163.602588 308.284013 L 164.602588 308.314554 L 165.602588 308.384068 L 166.602588 308.408041 L 167.602588 308.436663 L 168.602588 308.478456 L 169.602588 308.500032 L 170.602588 308.51398 L 171.602588 308.540702 L 172.602588 308.550012 L 173.602588 308.562459 L 174.602588 308.573514 L 175.602588 308.579178 L 176.602588 308.583942 L 177.602588 308.578394 L 178.602588 308.565106 L 179.602588 308.557589 L 180.602588 308.532804 L 181.602588 308.509235 L 182.602588 308.473055 L 183.602588 308.447093 L 184.602588 308.424771 L 185.602588 308.356011 L 186.602588 308.281476 L 187.602588 308.187497 L 188.602588 308.136445 L 189.602588 308.082511 L 190.602588 308.04726 L 191.602588 307.941172 L 192.602588 307.888908 L 193.602588 307.852001 L 194.602588 307.82097 L 195.602588 307.759815 L 196.602588 307.692395 L 197.602588 307.643489 L 198.602588 307.578297 L 199.602588 307.540109 L 200.602588 307.498113 L 201.602588 307.456096 L 202.602588 307.39658 L 203.602588 307.28342 L 204.602588 307.231169 L 205.602588 307.191751 L 206.602588 307.14465 L 207.602588 307.08787 L 208.602588 307.055207 L 209.602588 307.019029 L 210.602588 306.986939 L 211.602588 306.952659 L 212.602588 306.894281 L 213.602588 306.849096 L 214.602588 306.819472 L 215.602588 306.769086 L 216.602588 306.743889 L 217.602588 306.722838 L 218.602588 306.68787 L 219.602588 306.66358 L 220.602588 306.649513 L 221.602588 306.630571 L 222.602588 306.61491 L 223.602588 306.602358 L 224.602588 306.596522 L 225.602588 306.58964 L 226.602588 306.584466 L 227.602588 306.586249 L 228.602588 306.588974 L 229.602588 306.600128 L 230.602588 306.628363 L 231.602588 306.672151 L 232.602588 306.69284 L 233.602588 306.733813 L 234.602588 306.773888 L 235.602588 306.792998 L 236.602588 306.815507 L 237.602588 306.882158 L 238.602588 306.931868 L 239.602588 307.005574 L 240.602588 307.036888 L 241.602588 307.11351 L 242.602588 307.151808 L 243.602588 307.225925 L 244.602588 307.329983 L 245.602588 307.399814 L 246.602588 307.505048 L 247.602588 307.560063 L 248.602588 307.683538 L 249.602588 307.754097 L 250.602588 307.869936 L 251.602588 307.920117 L 252.602588 307.955721 L 253.602588 308.047128 L 254.602588 308.100636 L 255.602588 308.188544 L 256.602588 308.257729 L 257.602588 308.304493 L 258.602588 308.376537 L 259.602588 308.426679 L 260.602588 308.444069 L 261.602588 308.471072 L 262.602588 308.490499 L 263.602588 308.509837 L 264.602588 308.548086 L 265.602588 308.564519 L 266.602588 308.572888 L 267.602588 308.577207 L 268.602588 308.583762 L 269.602588 308.581216 L 270.602588 308.575757 L 271.602588 308.559329 L 272.602588 308.527394 L 273.602588 308.489414 L 274.602588 308.45461 L 275.602588 308.391538 L 276.602588 308.370111 L 277.602588 308.319493 L 278.602588 308.294536 L 279.602588 308.238902 L 280.602588 308.207673 L 281.602588 308.157529 L 282.602588 308.125036 L 283.602588 308.044624 L 284.602588 307.975698 L 285.602588 307.860001 L 286.602588 307.784522 L 287.602588 307.668997 L 288.602588 307.589513 L 289.602588 307.481072 L 290.602588 307.441704 L 291.602588 307.338836 L 292.602588 307.239038 L 293.602588 307.193541 L 294.602588 307.159219 L 295.602588 307.107263 L 296.602588 307.067616 L 297.602588 307.032102 L 298.602588 306.964457 L 299.602588 306.925375 L 300.602588 306.874894 L 301.602588 306.825588 L 302.602588 306.774518 L 303.602588 306.730279 L 304.602588 306.708259 L 305.602588 306.692703 L 306.602588 306.650256 L 307.602588 306.635388 L 308.602588 306.61266 L 309.602588 306.592344 L 310.602588 306.586547 L 311.602588 306.584065 L 312.602588 306.587122 L 313.602588 306.598718 L 314.602588 306.615638 L 315.602588 306.647299 L 316.602588 306.661382 L 317.602588 306.714054 L 318.602588 306.763143 L 319.602588 306.817844 L 320.602588 306.862192 L 321.602588 306.932184 L 322.602588 306.982567 L 323.602588 307.036474 L 324.602588 307.105913 L 325.602588 307.163301 L 326.602588 307.213466 L 327.602588 307.290628 L 328.602588 307.348818 L 329.602588 307.409456 L 330.602588 307.446657 L 331.602588 307.511749 L 332.602588 307.616879 L 333.602588 307.677181 L 334.602588 307.773503 L 335.602588 307.805506 L 336.602588 307.856523 L 337.602588 307.973315 L 338.602588 308.008762 L 339.602588 308.064642 L 340.602588 308.095018 L 341.602588 308.183404 L 342.602588 308.228168 L 343.602588 308.309056 L 344.602588 308.369202 L 345.602588 308.432288 L 346.602588 308.455236 L 347.602588 308.471406 L 348.602588 308.500335 L 349.602588 308.530687 L 350.602588 308.543261 L 351.602588 308.56814 L 352.602588 308.580224 L 353.602588 308.583986 L 354.602588 308.57955 L 355.602588 308.567211 L 356.602588 308.552798 L 357.602588 308.536725 L 358.602588 308.501204 L 359.602588 308.48127 L 360.602588 308.424681 L 361.602588 308.357487 L 362.602588 308.330117 L 363.602588 308.295969 L 364.602588 308.247289 L 365.602588 308.199004 L 366.602588 308.139927 L 367.602588 308.044322 L 368.602588 308.001182 L 369.602588 307.951334 L 370.602588 307.8928 L 371.602588 307.845214 L 372.602588 307.784086 L 373.602588 307.728001 L 374.602588 307.65383 L 375.602588 307.536592 L 376.602588 307.480868 L 377.602588 307.372642 L 378.602588 307.266492 L 379.602588 307.15892 L 380.602588 307.124412 L 381.602588 307.021105 L 382.602588 306.945381 L 383.602588 306.905946 L 384.602588 306.866562 L 385.602588 306.84408 L 386.602588 306.788267 L 387.602588 306.762215 L 388.602588 306.73198 L 389.602588 306.681209 L 390.602588 306.662558 L 391.602588 306.640849 L 392.602588 306.628203 L 393.602588 306.60921 L 394.602588 306.59182 L 395.602588 306.584782 L 396.602588 306.585806 L 397.602588 306.59281 L 398.602588 306.60218 L 399.602588 306.625578 L 400.602588 306.650661 L 401.602588 306.66306 L 402.602588 306.696153 L 403.602588 306.71252 L 404.602588 306.730925 L 405.602588 306.780062 L 406.602588 306.823875 L 407.602588 306.86696 L 408.602588 306.889901 L 409.602588 306.930164 L 411.599771 307.015024 " + style="fill: none; stroke: #000000; stroke-linecap: round" + id="path12" /> + <path + d="M 405.999771 304.784 L 406.880139 305.259331 L 407.758046 305.739585 L 408.608759 306.274226 L 409.488643 306.750528 L 410.350144 307.263593 L 411.460761 307.862019 L 410.550496 307.72152 L 409.630292 308.117178 L 408.704387 308.501437 L 407.786721 308.902172 L 406.865868 309.296534 L 405.698505 309.78147 " + style="fill: none; stroke: #ffffff; stroke-width: 4; stroke-linecap: round" + id="path13" /> + <path + d="M 405.999771 304.784 L 406.880139 305.259331 L 407.758046 305.739585 L 408.608759 306.274226 L 409.488643 306.750528 L 410.350144 307.263593 L 411.460761 307.862019 L 410.550496 307.72152 L 409.630292 308.117178 L 408.704387 308.501437 L 407.786721 308.902172 L 406.865868 309.296534 L 405.698505 309.78147 " + style="fill: none; stroke: #000000; stroke-linecap: round" + id="path14" /> + </g> + <g + id="patch_4"> + <path + d="M 57.6 305.58215 L 57.631436 304.58215 L 57.668377 303.58215 L 57.766123 302.58215 L 57.798645 301.58215 L 57.87227 300.58215 L 57.910835 299.58215 L 57.946248 298.58215 L 58.003888 297.58215 L 58.074274 296.58215 L 58.126239 295.58215 L 58.185328 294.58215 L 58.273649 293.58215 L 58.319794 292.58215 L 58.362205 291.58215 L 58.392697 290.58215 L 58.418742 289.58215 L 58.439942 288.58215 L 58.494243 287.58215 L 58.522181 286.58215 L 58.551905 285.58215 L 58.5773 284.58215 L 58.5885 283.58215 L 58.598624 282.58215 L 58.59842 281.58215 L 58.58891 280.58215 L 58.577256 279.58215 L 58.546227 278.58215 L 58.535059 277.58215 L 58.504942 276.58215 L 58.445165 275.58215 L 58.407973 274.58215 L 58.368877 273.58215 L 58.326437 272.58215 L 58.293672 271.58215 L 58.226246 270.58215 L 58.18712 269.58215 L 58.144445 268.58215 L 58.073865 267.58215 L 58.037474 266.58215 L 57.979071 265.58215 L 57.868118 264.58215 L 57.79746 263.58215 L 57.68452 262.58215 L 57.638747 261.58215 L 57.577464 260.58215 L 57.528965 259.58215 L 57.448142 258.58215 L 57.329623 257.58215 L 57.259412 256.58215 L 57.17615 255.58215 L 57.143008 254.58215 L 57.091771 253.58215 L 57.023372 252.58215 L 56.957157 251.58215 L 56.88024 250.58215 L 56.852924 249.58215 L 56.826447 248.58215 L 56.803796 247.58215 L 56.784265 246.58215 L 56.757871 245.58215 L 56.7081 244.58215 L 56.673027 243.58215 L 56.637161 242.58215 L 56.621794 241.58215 L 56.606025 240.58215 L 56.602612 239.58215 L 56.600195 238.58215 L 56.600681 237.58215 L 56.60261 236.58215 L 56.615867 235.58215 L 56.624258 234.58215 L 56.645794 233.58215 L 56.668827 232.58215 L 56.68606 231.58215 L 56.704523 230.58215 L 56.724975 229.58215 L 56.741575 228.58215 L 56.804354 227.58215 L 56.879619 226.58215 L 56.912258 225.58215 L 56.979822 224.58215 L 57.033869 223.58215 L 57.067573 222.58215 L 57.157699 221.58215 L 57.186234 220.58215 L 57.21772 219.58215 L 57.248731 218.58215 L 57.303539 217.58215 L 57.368126 216.58215 L 57.406322 215.58215 L 57.502256 214.58215 L 57.551514 213.58215 L 57.595583 212.58215 L 57.635707 211.58215 L 57.744074 210.58215 L 57.785702 209.58215 L 57.847844 208.58215 L 57.917806 207.58215 L 58.02231 206.58215 L 58.059298 205.58215 L 58.105175 204.58215 L 58.17367 203.58215 L 58.222416 202.58215 L 58.300013 201.58215 L 58.330554 200.58215 L 58.400068 199.58215 L 58.424041 198.58215 L 58.452663 197.58215 L 58.494456 196.58215 L 58.516032 195.58215 L 58.52998 194.58215 L 58.556702 193.58215 L 58.566012 192.58215 L 58.578459 191.58215 L 58.589514 190.58215 L 58.595178 189.58215 L 58.599942 188.58215 L 58.594394 187.58215 L 58.581106 186.58215 L 58.573589 185.58215 L 58.548804 184.58215 L 58.525235 183.58215 L 58.489055 182.58215 L 58.463093 181.58215 L 58.440771 180.58215 L 58.372011 179.58215 L 58.297476 178.58215 L 58.203497 177.58215 L 58.152445 176.58215 L 58.098511 175.58215 L 58.06326 174.58215 L 57.957172 173.58215 L 57.904908 172.58215 L 57.868001 171.58215 L 57.83697 170.58215 L 57.775815 169.58215 L 57.708395 168.58215 L 57.659489 167.58215 L 57.594297 166.58215 L 57.556109 165.58215 L 57.514113 164.58215 L 57.472096 163.58215 L 57.41258 162.58215 L 57.29942 161.58215 L 57.247169 160.58215 L 57.207751 159.58215 L 57.16065 158.58215 L 57.10387 157.58215 L 57.071207 156.58215 L 57.035029 155.58215 L 57.002939 154.58215 L 56.968659 153.58215 L 56.910281 152.58215 L 56.865096 151.58215 L 56.835472 150.58215 L 56.785086 149.58215 L 56.759889 148.58215 L 56.738838 147.58215 L 56.70387 146.58215 L 56.67958 145.58215 L 56.665513 144.58215 L 56.646571 143.58215 L 56.63091 142.58215 L 56.618358 141.58215 L 56.612522 140.58215 L 56.60564 139.58215 L 56.600466 138.58215 L 56.602249 137.58215 L 56.604974 136.58215 L 56.616128 135.58215 L 56.644363 134.58215 L 56.688151 133.58215 L 56.70884 132.58215 L 56.749813 131.58215 L 56.789888 130.58215 L 56.808998 129.58215 L 56.831507 128.58215 L 56.898158 127.58215 L 56.947868 126.58215 L 57.021574 125.58215 L 57.052888 124.58215 L 57.12951 123.58215 L 57.167808 122.58215 L 57.241925 121.58215 L 57.345983 120.58215 L 57.415814 119.58215 L 57.521048 118.58215 L 57.576063 117.58215 L 57.699538 116.58215 L 57.770097 115.58215 L 57.885936 114.58215 L 57.936117 113.58215 L 57.971721 112.58215 L 58.063128 111.58215 L 58.116636 110.58215 L 58.204544 109.58215 L 58.273729 108.58215 L 58.320493 107.58215 L 58.392537 106.58215 L 58.442679 105.58215 L 58.460069 104.58215 L 58.487072 103.58215 L 58.506499 102.58215 L 58.525837 101.58215 L 58.564086 100.58215 L 58.580519 99.58215 L 58.588888 98.58215 L 58.593207 97.58215 L 58.599762 96.58215 L 58.597216 95.58215 L 58.591757 94.58215 L 58.575329 93.58215 L 58.543394 92.58215 L 58.505414 91.58215 L 58.47061 90.58215 L 58.407538 89.58215 L 58.386111 88.58215 L 58.335493 87.58215 L 58.310536 86.58215 L 58.254902 85.58215 L 58.223673 84.58215 L 58.173529 83.58215 L 58.141036 82.58215 L 58.060624 81.58215 L 57.991698 80.58215 L 57.876001 79.58215 L 57.800522 78.58215 L 57.684997 77.58215 L 57.605513 76.58215 L 57.497072 75.58215 L 57.457704 74.58215 L 57.354836 73.58215 L 57.255038 72.58215 L 57.209541 71.58215 L 57.175219 70.58215 L 57.123263 69.58215 L 57.083616 68.58215 L 57.048102 67.58215 L 56.980457 66.58215 L 56.941375 65.58215 L 56.890894 64.58215 L 56.841588 63.58215 L 56.790518 62.58215 L 56.746279 61.58215 L 56.724259 60.58215 L 56.708703 59.58215 L 56.666256 58.58215 L 56.651388 57.58215 L 56.62866 56.58215 L 56.608344 55.58215 L 56.602547 54.58215 L 56.600065 53.58215 L 56.603122 52.58215 L 56.614718 51.58215 L 56.631638 50.58215 L 56.663299 49.58215 L 56.677382 48.58215 L 56.730054 47.58215 L 56.779143 46.58215 L 56.833844 44.592945 " + style="fill: none; stroke: #ffffff; stroke-width: 4; stroke-linecap: round" + id="path15" /> + <path + d="M 57.6 305.58215 L 57.631436 304.58215 L 57.668377 303.58215 L 57.766123 302.58215 L 57.798645 301.58215 L 57.87227 300.58215 L 57.910835 299.58215 L 57.946248 298.58215 L 58.003888 297.58215 L 58.074274 296.58215 L 58.126239 295.58215 L 58.185328 294.58215 L 58.273649 293.58215 L 58.319794 292.58215 L 58.362205 291.58215 L 58.392697 290.58215 L 58.418742 289.58215 L 58.439942 288.58215 L 58.494243 287.58215 L 58.522181 286.58215 L 58.551905 285.58215 L 58.5773 284.58215 L 58.5885 283.58215 L 58.598624 282.58215 L 58.59842 281.58215 L 58.58891 280.58215 L 58.577256 279.58215 L 58.546227 278.58215 L 58.535059 277.58215 L 58.504942 276.58215 L 58.445165 275.58215 L 58.407973 274.58215 L 58.368877 273.58215 L 58.326437 272.58215 L 58.293672 271.58215 L 58.226246 270.58215 L 58.18712 269.58215 L 58.144445 268.58215 L 58.073865 267.58215 L 58.037474 266.58215 L 57.979071 265.58215 L 57.868118 264.58215 L 57.79746 263.58215 L 57.68452 262.58215 L 57.638747 261.58215 L 57.577464 260.58215 L 57.528965 259.58215 L 57.448142 258.58215 L 57.329623 257.58215 L 57.259412 256.58215 L 57.17615 255.58215 L 57.143008 254.58215 L 57.091771 253.58215 L 57.023372 252.58215 L 56.957157 251.58215 L 56.88024 250.58215 L 56.852924 249.58215 L 56.826447 248.58215 L 56.803796 247.58215 L 56.784265 246.58215 L 56.757871 245.58215 L 56.7081 244.58215 L 56.673027 243.58215 L 56.637161 242.58215 L 56.621794 241.58215 L 56.606025 240.58215 L 56.602612 239.58215 L 56.600195 238.58215 L 56.600681 237.58215 L 56.60261 236.58215 L 56.615867 235.58215 L 56.624258 234.58215 L 56.645794 233.58215 L 56.668827 232.58215 L 56.68606 231.58215 L 56.704523 230.58215 L 56.724975 229.58215 L 56.741575 228.58215 L 56.804354 227.58215 L 56.879619 226.58215 L 56.912258 225.58215 L 56.979822 224.58215 L 57.033869 223.58215 L 57.067573 222.58215 L 57.157699 221.58215 L 57.186234 220.58215 L 57.21772 219.58215 L 57.248731 218.58215 L 57.303539 217.58215 L 57.368126 216.58215 L 57.406322 215.58215 L 57.502256 214.58215 L 57.551514 213.58215 L 57.595583 212.58215 L 57.635707 211.58215 L 57.744074 210.58215 L 57.785702 209.58215 L 57.847844 208.58215 L 57.917806 207.58215 L 58.02231 206.58215 L 58.059298 205.58215 L 58.105175 204.58215 L 58.17367 203.58215 L 58.222416 202.58215 L 58.300013 201.58215 L 58.330554 200.58215 L 58.400068 199.58215 L 58.424041 198.58215 L 58.452663 197.58215 L 58.494456 196.58215 L 58.516032 195.58215 L 58.52998 194.58215 L 58.556702 193.58215 L 58.566012 192.58215 L 58.578459 191.58215 L 58.589514 190.58215 L 58.595178 189.58215 L 58.599942 188.58215 L 58.594394 187.58215 L 58.581106 186.58215 L 58.573589 185.58215 L 58.548804 184.58215 L 58.525235 183.58215 L 58.489055 182.58215 L 58.463093 181.58215 L 58.440771 180.58215 L 58.372011 179.58215 L 58.297476 178.58215 L 58.203497 177.58215 L 58.152445 176.58215 L 58.098511 175.58215 L 58.06326 174.58215 L 57.957172 173.58215 L 57.904908 172.58215 L 57.868001 171.58215 L 57.83697 170.58215 L 57.775815 169.58215 L 57.708395 168.58215 L 57.659489 167.58215 L 57.594297 166.58215 L 57.556109 165.58215 L 57.514113 164.58215 L 57.472096 163.58215 L 57.41258 162.58215 L 57.29942 161.58215 L 57.247169 160.58215 L 57.207751 159.58215 L 57.16065 158.58215 L 57.10387 157.58215 L 57.071207 156.58215 L 57.035029 155.58215 L 57.002939 154.58215 L 56.968659 153.58215 L 56.910281 152.58215 L 56.865096 151.58215 L 56.835472 150.58215 L 56.785086 149.58215 L 56.759889 148.58215 L 56.738838 147.58215 L 56.70387 146.58215 L 56.67958 145.58215 L 56.665513 144.58215 L 56.646571 143.58215 L 56.63091 142.58215 L 56.618358 141.58215 L 56.612522 140.58215 L 56.60564 139.58215 L 56.600466 138.58215 L 56.602249 137.58215 L 56.604974 136.58215 L 56.616128 135.58215 L 56.644363 134.58215 L 56.688151 133.58215 L 56.70884 132.58215 L 56.749813 131.58215 L 56.789888 130.58215 L 56.808998 129.58215 L 56.831507 128.58215 L 56.898158 127.58215 L 56.947868 126.58215 L 57.021574 125.58215 L 57.052888 124.58215 L 57.12951 123.58215 L 57.167808 122.58215 L 57.241925 121.58215 L 57.345983 120.58215 L 57.415814 119.58215 L 57.521048 118.58215 L 57.576063 117.58215 L 57.699538 116.58215 L 57.770097 115.58215 L 57.885936 114.58215 L 57.936117 113.58215 L 57.971721 112.58215 L 58.063128 111.58215 L 58.116636 110.58215 L 58.204544 109.58215 L 58.273729 108.58215 L 58.320493 107.58215 L 58.392537 106.58215 L 58.442679 105.58215 L 58.460069 104.58215 L 58.487072 103.58215 L 58.506499 102.58215 L 58.525837 101.58215 L 58.564086 100.58215 L 58.580519 99.58215 L 58.588888 98.58215 L 58.593207 97.58215 L 58.599762 96.58215 L 58.597216 95.58215 L 58.591757 94.58215 L 58.575329 93.58215 L 58.543394 92.58215 L 58.505414 91.58215 L 58.47061 90.58215 L 58.407538 89.58215 L 58.386111 88.58215 L 58.335493 87.58215 L 58.310536 86.58215 L 58.254902 85.58215 L 58.223673 84.58215 L 58.173529 83.58215 L 58.141036 82.58215 L 58.060624 81.58215 L 57.991698 80.58215 L 57.876001 79.58215 L 57.800522 78.58215 L 57.684997 77.58215 L 57.605513 76.58215 L 57.497072 75.58215 L 57.457704 74.58215 L 57.354836 73.58215 L 57.255038 72.58215 L 57.209541 71.58215 L 57.175219 70.58215 L 57.123263 69.58215 L 57.083616 68.58215 L 57.048102 67.58215 L 56.980457 66.58215 L 56.941375 65.58215 L 56.890894 64.58215 L 56.841588 63.58215 L 56.790518 62.58215 L 56.746279 61.58215 L 56.724259 60.58215 L 56.708703 59.58215 L 56.666256 58.58215 L 56.651388 57.58215 L 56.62866 56.58215 L 56.608344 55.58215 L 56.602547 54.58215 L 56.600065 53.58215 L 56.603122 52.58215 L 56.614718 51.58215 L 56.631638 50.58215 L 56.663299 49.58215 L 56.677382 48.58215 L 56.730054 47.58215 L 56.779143 46.58215 L 56.833844 44.592945 " + style="fill: none; stroke: #000000; stroke-linecap: round" + id="path16" /> + <path + d="M 54.8 50.192945 L 55.275331 49.312576 L 55.755585 48.434669 L 56.290226 47.583956 L 56.766528 46.704072 L 57.279593 45.842571 L 57.878019 44.731954 L 57.73752 45.642219 L 58.133178 46.562423 L 58.517437 47.488328 L 58.918172 48.405994 L 59.312534 49.326847 L 59.79747 50.49421 " + style="fill: none; stroke: #ffffff; stroke-width: 4; stroke-linecap: round" + id="path17" /> + <path + d="M 54.8 50.192945 L 55.275331 49.312576 L 55.755585 48.434669 L 56.290226 47.583956 L 56.766528 46.704072 L 57.279593 45.842571 L 57.878019 44.731954 L 57.73752 45.642219 L 58.133178 46.562423 L 58.517437 47.488328 L 58.918172 48.405994 L 59.312534 49.326847 L 59.79747 50.49421 " + style="fill: none; stroke: #000000; stroke-linecap: round" + id="path18" /> + </g> + </g> + </g> + <defs + id="defs18"> + <clipPath + id="p53efc7421d"> + <rect + x="57.6" + y="41.472" + width="357.12" + height="266.112" + id="rect18" /> + </clipPath> + </defs> + <path + style="fill:#ffffff;stroke:#000000;stroke-width:0;stroke-linecap:round;stroke-opacity:0.18525;fill-opacity:1" + d="m 402.11605,300.06616 2.16807,0.15101 -0.0108,-1.35908 -2.54559,0.35595 z" + id="path19" /> + <path + style="fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:0;stroke-linecap:round;stroke-opacity:0.18525" + d="m 404.52142,306.22518 2.04941,0.0971 -0.1618,0.98156 -1.77975,-0.31281 z" + id="path20" /> + <path + style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:0;stroke-linecap:round;stroke-opacity:0.18525" + d="M 63.984775,40.686206 63.812194,51.041125 69.766273,51.170562 69.075944,39.69386 Z" + id="path21" /> + <path + style="fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:0;stroke-linecap:round;stroke-opacity:0.18525" + d="m 56.105329,51.747633 0.04315,-1.876829 h 1.008527 l -0.02157,0.328984 -0.711901,1.661102 z" + id="path22" /> +</svg> diff --git a/experts.rst b/experts.rst deleted file mode 100644 index fd783d917e..0000000000 --- a/experts.rst +++ /dev/null @@ -1,373 +0,0 @@ -.. _experts: - -Experts Index -============= - -This document has tables that list Python Modules, Tools, Platforms and -Interest Areas and names for each item that indicate a maintainer or an -expert in the field. This list is intended to be used by issue submitters, -issue triage people, and other issue participants to find people to add to -the nosy list or to contact directly by email for help and decisions on -feature requests and bug fixes. People on this list may be asked to render -final judgement on a feature or bug. If no active maintainer is listed for -a given module, then questionable changes should go to python-dev, while -any other issues can and should be decided by any committer. - -Unless a name is followed by a '*', you should never assign an issue to -that person, only make them nosy. Names followed by a '*' may be assigned -issues involving the module or topic. - -.. TODO document automatic assignment/nosy: people need not add them manually - -The Platform and Interest Area tables list broader fields in which various -people have expertise. These people can also be contacted for help, -opinions, and decisions when issues involve their areas. - -If a listed maintainer does not respond to requests for comment for an -extended period (three weeks or more), they should be marked as inactive -in this list by placing the word 'inactive' in parenthesis behind their -tracker id. They are of course free to remove that inactive mark at -any time. - -Committers should update these tables as their areas of expertise widen. -New topics may be added to the Interest Area table at will. - -The existence of this list is not meant to indicate that these people -*must* be contacted for decisions; it is, rather, a resource to be used -by non-committers to find responsible parties, and by committers who do -not feel qualified to make a decision in a particular context. - -See also :PEP:`291` and :PEP:`360` for information about certain modules -with special rules. - - -Stdlib ------- -==================== ============================================= -Module Maintainers -==================== ============================================= -__future__ -__main__ gvanrossum, ncoghlan -_dummy_thread brett.cannon -_thread -_testbuffer skrah -abc -aifc r.david.murray -argparse rhettinger* -array -ast benjamin.peterson -asynchat josiahcarlson, giampaolo.rodola*, stutzbach -asyncio yselivanov, asvetlov -asyncore josiahcarlson, giampaolo.rodola*, stutzbach -atexit -audioop serhiy.storchaka -base64 -bdb -binascii -binhex -bisect rhettinger* -builtins -bz2 -calendar rhettinger* -cgi ethan.furman*, Rhodri James -cgitb ethan.furman*, Rhodri James -chunk -cmath mark.dickinson -cmd -code -codecs lemburg, doerwalter -codeop -collections rhettinger* -collections.abc rhettinger*, stutzbach -colorsys -compileall -concurrent.futures pitrou, bquinlan -configparser lukasz.langa* -contextlib ncoghlan, yselivanov -contextvars -copy alexandre.vassalotti -copyreg alexandre.vassalotti -cProfile -crypt jafo* -csv skip.montanaro (inactive) -ctypes theller (inactive), belopolsky, amaury.forgeotdarc, - meador.inge -curses twouters -dataclasses eric.smith -datetime belopolsky, p-ganssle -dbm -decimal facundobatista, rhettinger, mark.dickinson, skrah -difflib tim.peters (inactive) -dis yselivanov -distutils eric.araujo, dstufft -doctest tim.peters (inactive) -dummy_threading brett.cannon -email barry, r.david.murray*, maxking -encodings lemburg -ensurepip ncoghlan, dstufft, pradyunsg -enum eli.bendersky*, barry, ethan.furman* -errno twouters -exceptions -faulthandler vstinner -fcntl twouters -filecmp -fileinput -fnmatch -formatter -fpectl twouters -fractions mark.dickinson, rhettinger -ftplib giampaolo.rodola* -functools rhettinger* -gc pitrou -getopt -getpass -gettext -glob -grp -gzip -hashlib christian.heimes, gregory.p.smith -heapq rhettinger*, stutzbach -hmac christian.heimes, gregory.p.smith -html ezio.melotti -http -idlelib kbk (inactive), terry.reedy*, roger.serwy (inactive) -imaplib -imghdr -imp -importlib brett.cannon -inspect yselivanov -io benjamin.peterson, stutzbach -ipaddress pmoody -itertools rhettinger* -json bob.ippolito (inactive), ezio.melotti, rhettinger -keyword -lib2to3 benjamin.peterson -libmpdec skrah -linecache -locale lemburg -logging vinay.sajip -lzma -mailbox -mailcap -marshal -math mark.dickinson, rhettinger, stutzbach -mimetypes -mmap twouters -modulefinder theller (inactive), jvr -msilib -msvcrt -multiprocessing davin*, pitrou, jnoller (inactive), sbt (inactive) -netrc -nis -nntplib -numbers -operator -optparse aronacher -os -os.path serhiy.storchaka -ossaudiodev -parser benjamin.peterson -pathlib -pdb -pickle alexandre.vassalotti -pickletools alexandre.vassalotti -pipes -pkgutil -platform lemburg -plistlib -poplib -posix larry -pprint fdrake -profile -pstats -pty twouters* -pwd -py_compile -pybench lemburg -pyclbr -pydoc -queue rhettinger* -quopri -random rhettinger, mark.dickinson -re effbot (inactive), ezio.melotti, serhiy.storchaka -readline twouters -reprlib -resource twouters -rlcompleter -runpy ncoghlan -sched -secrets -select -selectors neologix, giampaolo.rodola -shelve -shlex -shutil tarek, giampaolo.rodola -signal -site -smtpd giampaolo.rodola -smtplib -sndhdr -socket -socketserver -spwd -sqlite3 ghaering -ssl janssen, christian.heimes, dstufft, alex -stat christian.heimes -statistics steven.daprano, rhettinger -string -stringprep -struct mark.dickinson, meador.inge -subprocess astrand (inactive), giampaolo.rodola -sunau -symbol -symtable benjamin.peterson -sys -sysconfig tarek -syslog jafo* -tabnanny tim.peters (inactive) -tarfile lars.gustaebel -telnetlib -tempfile -termios twouters -test ezio.melotti -textwrap -threading pitrou -time belopolsky, p-ganssle -timeit -tkinter gpolo, serhiy.storchaka -token -tokenize meador.inge -trace belopolsky -traceback -tracemalloc vstinner -tty twouters* -turtle gregorlingl, willingc -types yselivanov -typing gvanrossum, levkivskyi* -unicodedata lemburg, ezio.melotti -unittest michael.foord*, ezio.melotti, rbcollins -unittest.mock michael.foord* -urllib orsenthil -uu -uuid -venv vinay.sajip -warnings -wave -weakref fdrake -webbrowser -winreg stutzbach -winsound effbot (inactive) -wsgiref pje -xdrlib -xml.dom -xml.dom.minidom -xml.dom.pulldom -xml.etree effbot (inactive), eli.bendersky*, scoder -xml.parsers.expat -xml.sax -xml.sax.handler -xml.sax.saxutils -xml.sax.xmlreader -xmlrpc -zipapp paul.moore -zipfile alanmcintyre, serhiy.storchaka, twouters -zipimport twouters* -zlib twouters -==================== ============================================= - - -Tools ------ -================== =========== -Tool Maintainers -================== =========== -Argument Clinic larry -pybench lemburg -================== =========== - - -Platforms ---------- -=================== =========== -Platform Maintainers -=================== =========== -AIX David.Edelsohn -Cygwin jlt63, stutzbach -FreeBSD -HP-UX -Linux -Mac OS X ronaldoussoren, ned.deily -NetBSD1 -OS2/EMX aimacintyre -Solaris/OpenIndiana jcea -Windows tim.golden, zach.ware, steve.dower, paul.moore -JVM/Java frank.wierzbicki -=================== =========== - - -Miscellaneous -------------- -================== ========================================================== -Interest Area Maintainers -================== ========================================================== -algorithms rhettinger* -argument clinic larry -ast/compiler benjamin.peterson, brett.cannon, yselivanov -autoconf/makefiles twouters* -bsd -bug tracker ezio.melotti -buildbots zach.ware -bytecode benjamin.peterson, yselivanov -context managers ncoghlan -core workflow mariatta -coverity scan christian.heimes, brett.cannon, twouters -cryptography gregory.p.smith, dstufft -data formats mark.dickinson -database lemburg -devguide eric.araujo, ezio.melotti, willingc, mariatta -documentation ezio.melotti, eric.araujo, mdk, willingc -emoji mariatta -extension modules petr.viktorin, ncoghlan -filesystem giampaolo.rodola -f-strings eric.smith* -GUI -i18n lemburg, eric.araujo -import machinery brett.cannon, ncoghlan, eric.snow -io benjamin.peterson, stutzbach -locale lemburg -mathematics mark.dickinson, lemburg, stutzbach, rhettinger -memory management tim.peters, lemburg, twouters -memoryview skrah -networking giampaolo.rodola, -object model benjamin.peterson, twouters -packaging tarek, lemburg, alexis, eric.araujo, dstufft, paul.moore -performance brett.cannon, vstinner, serhiy.storchaka, yselivanov, rhettinger -pip ncoghlan, dstufft, paul.moore, Marcus.Smith, pradyunsg -py3 transition benjamin.peterson -release management tarek, lemburg, benjamin.peterson, barry, - gvanrossum, anthonybaxter, eric.araujo, ned.deily, - georg.brandl, mdk -str.format eric.smith* -testing michael.foord, ezio.melotti -test coverage -threads -time and dates lemburg, belopolsky, p-ganssle -unicode lemburg, ezio.melotti, vstinner, benjamin.peterson, -version control eric.araujo, ezio.melotti -================== ========================================================== - - -Documentation Translations --------------------------- -============= ============ -Translation Coordinator -============= ============ -French mdk -Japanese inada.naoki -Korean flowdas -Bengali India kushal.das -Hungarian gbtami -Portuguese rougeth -Chinese (TW) adrianliaw -Chinese (CN) zhsj -============= ============ diff --git a/extensions.rst b/extensions.rst deleted file mode 100644 index 896d2f9a7d..0000000000 --- a/extensions.rst +++ /dev/null @@ -1,15 +0,0 @@ -.. _extensions: - -Updating standard library extension modules -=========================================== - -In this section, we could explain how to write a CPython extension with the C language, but the topic can take a complete book. - -For this reason, we prefer to give you some links where you can read a very good documentation. - -Read the following references: - -* https://docs.python.org/dev/c-api/ -* https://docs.python.org/dev/extending/ -* https://www.python.org/dev/peps/pep-0399/ -* https://pythonextensionpatterns.readthedocs.io/en/latest/ diff --git a/gdb.rst b/gdb.rst deleted file mode 100644 index 8a1fc4504e..0000000000 --- a/gdb.rst +++ /dev/null @@ -1,325 +0,0 @@ -.. _gdb: - -gdb Support -=========== - -.. highlight:: none - -If you experience low-level problems such as crashes or deadlocks -(e.g. when tinkering with parts of CPython which are written in C), -it can be convenient to use a low-level debugger such as gdb in -order to diagnose and fix the issue. By default, however, gdb (or any -of its front-ends) doesn't know about high-level information specific to the -CPython interpreter, such as which Python function is currently executing, -or what type or value has a given Python object represented by a standard -``PyObject *`` pointer. We hereafter present two ways to overcome this -limitation. - - -gdb 7 and later ---------------- - -In gdb 7, support for `extending gdb with Python -<https://sourceware.org/gdb/current/onlinedocs/gdb/Python.html#Python>`_ was -added. When CPython is built you will notice a ``python-gdb.py`` file in the -root directory of your checkout. Read the module docstring for details on how -to use the file to enhance gdb for easier debugging of a CPython process. - -To activate support, you must add the directory containing ``python-gdb.py`` -to GDB's "auto-load-safe-path". Put this in your ``~/.gdbinit`` file:: - - add-auto-load-safe-path /path/to/checkout - -You can also add multiple paths, separated by ``:``. - -This is what a backtrace looks like (truncated) when this extension is -enabled:: - - #0 0x000000000041a6b1 in PyObject_Malloc (nbytes=Cannot access memory at address 0x7fffff7fefe8 - ) at Objects/obmalloc.c:748 - #1 0x000000000041b7c0 in _PyObject_DebugMallocApi (id=111 'o', nbytes=24) at Objects/obmalloc.c:1445 - #2 0x000000000041b717 in _PyObject_DebugMalloc (nbytes=24) at Objects/obmalloc.c:1412 - #3 0x000000000044060a in _PyUnicode_New (length=11) at Objects/unicodeobject.c:346 - #4 0x00000000004466aa in PyUnicodeUCS2_DecodeUTF8Stateful (s=0x5c2b8d "__lltrace__", size=11, errors=0x0, consumed= - 0x0) at Objects/unicodeobject.c:2531 - #5 0x0000000000446647 in PyUnicodeUCS2_DecodeUTF8 (s=0x5c2b8d "__lltrace__", size=11, errors=0x0) - at Objects/unicodeobject.c:2495 - #6 0x0000000000440d1b in PyUnicodeUCS2_FromStringAndSize (u=0x5c2b8d "__lltrace__", size=11) - at Objects/unicodeobject.c:551 - #7 0x0000000000440d94 in PyUnicodeUCS2_FromString (u=0x5c2b8d "__lltrace__") at Objects/unicodeobject.c:569 - #8 0x0000000000584abd in PyDict_GetItemString (v= - {'Yuck': <type at remote 0xad4730>, '__builtins__': <module at remote 0x7ffff7fd5ee8>, '__file__': 'Lib/test/crashers/nasty_eq_vs_dict.py', '__package__': None, 'y': <Yuck(i=0) at remote 0xaacd80>, 'dict': {0: 0, 1: 1, 2: 2, 3: 3}, '__cached__': None, '__name__': '__main__', 'z': <Yuck(i=0) at remote 0xaace60>, '__doc__': None}, key= - 0x5c2b8d "__lltrace__") at Objects/dictobject.c:2171 - -(Notice how the dictionary argument to ``PyDict_GetItemString`` is displayed -as its ``repr()``, rather than an opaque ``PyObject *`` pointer.) - -The extension works by supplying a custom printing routine for values of type -``PyObject *``. If you need to access lower-level details of an object, then -cast the value to a pointer of the appropriate type. For example:: - - (gdb) p globals - $1 = {'__builtins__': <module at remote 0x7ffff7fb1868>, '__name__': - '__main__', 'ctypes': <module at remote 0x7ffff7f14360>, '__doc__': None, - '__package__': None} - - (gdb) p *(PyDictObject*)globals - $2 = {ob_refcnt = 3, ob_type = 0x3dbdf85820, ma_fill = 5, ma_used = 5, - ma_mask = 7, ma_table = 0x63d0f8, ma_lookup = 0x3dbdc7ea70 - <lookdict_string>, ma_smalltable = {{me_hash = 7065186196740147912, - me_key = '__builtins__', me_value = <module at remote 0x7ffff7fb1868>}, - {me_hash = -368181376027291943, me_key = '__name__', - me_value ='__main__'}, {me_hash = 0, me_key = 0x0, me_value = 0x0}, - {me_hash = 0, me_key = 0x0, me_value = 0x0}, - {me_hash = -9177857982131165996, me_key = 'ctypes', - me_value = <module at remote 0x7ffff7f14360>}, - {me_hash = -8518757509529533123, me_key = '__doc__', me_value = None}, - {me_hash = 0, me_key = 0x0, me_value = 0x0}, { - me_hash = 6614918939584953775, me_key = '__package__', me_value = None}}} - -The pretty-printers try to closely match the ``repr()`` implementation of the -underlying implementation of Python, and thus vary somewhat between Python 2 -and Python 3. - -An area that can be confusing is that the custom printer for some types look a -lot like gdb's built-in printer for standard types. For example, the -pretty-printer for a Python 3 ``int`` gives a ``repr()`` that is not -distinguishable from a printing of a regular machine-level integer:: - - (gdb) p some_machine_integer - $3 = 42 - - (gdb) p some_python_integer - $4 = 42 - - (gdb) p *(PyLongObject*)some_python_integer - $5 = {ob_base = {ob_base = {ob_refcnt = 8, ob_type = 0x3dad39f5e0}, ob_size = 1}, - ob_digit = {42}} - -A similar confusion can arise with the ``str`` type, where the output looks a -lot like gdb's built-in printer for ``char *``:: - - (gdb) p ptr_to_python_str - $6 = '__builtins__' - -The pretty-printer for ``str`` instances defaults to using single-quotes (as -does Python's ``repr`` for strings) whereas the standard printer for ``char *`` -values uses double-quotes and contains a hexadecimal address:: - - (gdb) p ptr_to_char_star - $7 = 0x6d72c0 "hello world" - -Here's how to see the implementation details of a ``str`` instance (for Python -3, where a ``str`` is a ``PyUnicodeObject *``):: - - (gdb) p *(PyUnicodeObject*)$6 - $8 = {ob_base = {ob_refcnt = 33, ob_type = 0x3dad3a95a0}, length = 12, - str = 0x7ffff2128500, hash = 7065186196740147912, state = 1, defenc = 0x0} - -As well as adding pretty-printing support for ``PyObject *``, -the extension adds a number of commands to gdb: - -``py-list`` - List the Python source code (if any) for the current frame in the selected - thread. The current line is marked with a ">":: - - (gdb) py-list - 901 if options.profile: - 902 options.profile = False - 903 profile_me() - 904 return - 905 - >906 u = UI() - 907 if not u.quit: - 908 try: - 909 gtk.main() - 910 except KeyboardInterrupt: - 911 # properly quit on a keyboard interrupt... - - Use ``py-list START`` to list at a different line number within the python - source, and ``py-list START,END`` to list a specific range of lines within - the python source. - -``py-up`` and ``py-down`` - The ``py-up`` and ``py-down`` commands are analogous to gdb's regular ``up`` - and ``down`` commands, but try to move at the level of CPython frames, rather - than C frames. - - gdb is not always able to read the relevant frame information, depending on - the optimization level with which CPython was compiled. Internally, the - commands look for C frames that are executing ``PyEval_EvalFrameEx`` (which - implements the core bytecode interpreter loop within CPython) and look up - the value of the related ``PyFrameObject *``. - - They emit the frame number (at the C level) within the thread. - - For example:: - - (gdb) py-up - #37 Frame 0x9420b04, for file /usr/lib/python2.6/site-packages/ - gnome_sudoku/main.py, line 906, in start_game () - u = UI() - (gdb) py-up - #40 Frame 0x948e82c, for file /usr/lib/python2.6/site-packages/ - gnome_sudoku/gnome_sudoku.py, line 22, in start_game(main=<module at remote 0xb771b7f4>) - main.start_game() - (gdb) py-up - Unable to find an older python frame - - so we're at the top of the python stack. Going back down:: - - (gdb) py-down - #37 Frame 0x9420b04, for file /usr/lib/python2.6/site-packages/gnome_sudoku/main.py, line 906, in start_game () - u = UI() - (gdb) py-down - #34 (unable to read python frame information) - (gdb) py-down - #23 (unable to read python frame information) - (gdb) py-down - #19 (unable to read python frame information) - (gdb) py-down - #14 Frame 0x99262ac, for file /usr/lib/python2.6/site-packages/gnome_sudoku/game_selector.py, line 201, in run_swallowed_dialog (self=<NewOrSavedGameSelector(new_game_model=<gtk.ListStore at remote 0x98fab44>, puzzle=None, saved_games=[{'gsd.auto_fills': 0, 'tracking': {}, 'trackers': {}, 'notes': [], 'saved_at': 1270084485, 'game': '7 8 0 0 0 0 0 5 6 0 0 9 0 8 0 1 0 0 0 4 6 0 0 0 0 7 0 6 5 0 0 0 4 7 9 2 0 0 0 9 0 1 0 0 0 3 9 7 6 0 0 0 1 8 0 6 0 0 0 0 2 8 0 0 0 5 0 4 0 6 0 0 2 1 0 0 0 0 0 4 5\n7 8 0 0 0 0 0 5 6 0 0 9 0 8 0 1 0 0 0 4 6 0 0 0 0 7 0 6 5 1 8 3 4 7 9 2 0 0 0 9 0 1 0 0 0 3 9 7 6 0 0 0 1 8 0 6 0 0 0 0 2 8 0 0 0 5 0 4 0 6 0 0 2 1 0 0 0 0 0 4 5', 'gsd.impossible_hints': 0, 'timer.__absolute_start_time__': <float at remote 0x984b474>, 'gsd.hints': 0, 'timer.active_time': <float at remote 0x984b494>, 'timer.total_time': <float at remote 0x984b464>}], dialog=<gtk.Dialog at remote 0x98faaa4>, saved_game_model=<gtk.ListStore at remote 0x98fad24>, sudoku_maker=<SudokuMaker(terminated=False, played=[], batch_siz...(truncated) - swallower.run_dialog(self.dialog) - (gdb) py-down - #11 Frame 0x9aead74, for file /usr/lib/python2.6/site-packages/gnome_sudoku/dialog_swallower.py, line 48, in run_dialog (self=<SwappableArea(running=<gtk.Dialog at remote 0x98faaa4>, main_page=0) at remote 0x98fa6e4>, d=<gtk.Dialog at remote 0x98faaa4>) - gtk.main() - (gdb) py-down - #8 (unable to read python frame information) - (gdb) py-down - Unable to find a newer python frame - - and we're at the bottom of the python stack. - -``py-bt`` - The ``py-bt`` command attempts to display a Python-level backtrace of the - current thread. - - For example:: - - (gdb) py-bt - #8 (unable to read python frame information) - #11 Frame 0x9aead74, for file /usr/lib/python2.6/site-packages/gnome_sudoku/dialog_swallower.py, line 48, in run_dialog (self=<SwappableArea(running=<gtk.Dialog at remote 0x98faaa4>, main_page=0) at remote 0x98fa6e4>, d=<gtk.Dialog at remote 0x98faaa4>) - gtk.main() - #14 Frame 0x99262ac, for file /usr/lib/python2.6/site-packages/gnome_sudoku/game_selector.py, line 201, in run_swallowed_dialog (self=<NewOrSavedGameSelector(new_game_model=<gtk.ListStore at remote 0x98fab44>, puzzle=None, saved_games=[{'gsd.auto_fills': 0, 'tracking': {}, 'trackers': {}, 'notes': [], 'saved_at': 1270084485, 'game': '7 8 0 0 0 0 0 5 6 0 0 9 0 8 0 1 0 0 0 4 6 0 0 0 0 7 0 6 5 0 0 0 4 7 9 2 0 0 0 9 0 1 0 0 0 3 9 7 6 0 0 0 1 8 0 6 0 0 0 0 2 8 0 0 0 5 0 4 0 6 0 0 2 1 0 0 0 0 0 4 5\n7 8 0 0 0 0 0 5 6 0 0 9 0 8 0 1 0 0 0 4 6 0 0 0 0 7 0 6 5 1 8 3 4 7 9 2 0 0 0 9 0 1 0 0 0 3 9 7 6 0 0 0 1 8 0 6 0 0 0 0 2 8 0 0 0 5 0 4 0 6 0 0 2 1 0 0 0 0 0 4 5', 'gsd.impossible_hints': 0, 'timer.__absolute_start_time__': <float at remote 0x984b474>, 'gsd.hints': 0, 'timer.active_time': <float at remote 0x984b494>, 'timer.total_time': <float at remote 0x984b464>}], dialog=<gtk.Dialog at remote 0x98faaa4>, saved_game_model=<gtk.ListStore at remote 0x98fad24>, sudoku_maker=<SudokuMaker(terminated=False, played=[], batch_siz...(truncated) - swallower.run_dialog(self.dialog) - #19 (unable to read python frame information) - #23 (unable to read python frame information) - #34 (unable to read python frame information) - #37 Frame 0x9420b04, for file /usr/lib/python2.6/site-packages/gnome_sudoku/main.py, line 906, in start_game () - u = UI() - #40 Frame 0x948e82c, for file /usr/lib/python2.6/site-packages/gnome_sudoku/gnome_sudoku.py, line 22, in start_game (main=<module at remote 0xb771b7f4>) - main.start_game() - - The frame numbers correspond to those displayed by gdb's standard - ``backtrace`` command. - -``py-print`` - The ``py-print`` command looks up a Python name and tries to print it. - It looks in locals within the current thread, then globals, then finally - builtins:: - - (gdb) py-print self - local 'self' = <SwappableArea(running=<gtk.Dialog at remote 0x98faaa4>, - main_page=0) at remote 0x98fa6e4> - (gdb) py-print __name__ - global '__name__' = 'gnome_sudoku.dialog_swallower' - (gdb) py-print len - builtin 'len' = <built-in function len> - (gdb) py-print scarlet_pimpernel - 'scarlet_pimpernel' not found - -``py-locals`` - The ``py-locals`` command looks up all Python locals within the current - Python frame in the selected thread, and prints their representations:: - - (gdb) py-locals - self = <SwappableArea(running=<gtk.Dialog at remote 0x98faaa4>, - main_page=0) at remote 0x98fa6e4> - d = <gtk.Dialog at remote 0x98faaa4> - -You can of course use other gdb commands. For example, the ``frame`` command -takes you directly to a particular frame within the selected thread. -We can use it to go a specific frame shown by ``py-bt`` like this:: - - (gdb) py-bt - (output snipped) - #68 Frame 0xaa4560, for file Lib/test/regrtest.py, line 1548, in <module> () - main() - (gdb) frame 68 - #68 0x00000000004cd1e6 in PyEval_EvalFrameEx (f=Frame 0xaa4560, for file Lib/test/regrtest.py, line 1548, in <module> (), throwflag=0) at Python/ceval.c:2665 - 2665 x = call_function(&sp, oparg); - (gdb) py-list - 1543 # Run the tests in a context manager that temporary changes the CWD to a - 1544 # temporary and writable directory. If it's not possible to create or - 1545 # change the CWD, the original CWD will be used. The original CWD is - 1546 # available from test_support.SAVEDCWD. - 1547 with test_support.temp_cwd(TESTCWD, quiet=True): - >1548 main() - -The ``info threads`` command will give you a list of the threads within the -process, and you can use the ``thread`` command to select a different one:: - - (gdb) info threads - 105 Thread 0x7fffefa18710 (LWP 10260) sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:86 - 104 Thread 0x7fffdf5fe710 (LWP 10259) sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:86 - * 1 Thread 0x7ffff7fe2700 (LWP 10145) 0x00000038e46d73e3 in select () at ../sysdeps/unix/syscall-template.S:82 - -You can use ``thread apply all COMMAND`` or (``t a a COMMAND`` for short) to run -a command on all threads. You can use this with ``py-bt`` to see what every -thread is doing at the Python level:: - - (gdb) t a a py-bt - - Thread 105 (Thread 0x7fffefa18710 (LWP 10260)): - #5 Frame 0x7fffd00019d0, for file /home/david/coding/python-svn/Lib/threading.py, line 155, in _acquire_restore (self=<_RLock(_Verbose__verbose=False, _RLock__owner=140737354016512, _RLock__block=<thread.lock at remote 0x858770>, _RLock__count=1) at remote 0xd7ff40>, count_owner=(1, 140737213728528), count=1, owner=140737213728528) - self.__block.acquire() - #8 Frame 0x7fffac001640, for file /home/david/coding/python-svn/Lib/threading.py, line 269, in wait (self=<_Condition(_Condition__lock=<_RLock(_Verbose__verbose=False, _RLock__owner=140737354016512, _RLock__block=<thread.lock at remote 0x858770>, _RLock__count=1) at remote 0xd7ff40>, acquire=<instancemethod at remote 0xd80260>, _is_owned=<instancemethod at remote 0xd80160>, _release_save=<instancemethod at remote 0xd803e0>, release=<instancemethod at remote 0xd802e0>, _acquire_restore=<instancemethod at remote 0xd7ee60>, _Verbose__verbose=False, _Condition__waiters=[]) at remote 0xd7fd10>, timeout=None, waiter=<thread.lock at remote 0x858a90>, saved_state=(1, 140737213728528)) - self._acquire_restore(saved_state) - #12 Frame 0x7fffb8001a10, for file /home/david/coding/python-svn/Lib/test/lock_tests.py, line 348, in f () - cond.wait() - #16 Frame 0x7fffb8001c40, for file /home/david/coding/python-svn/Lib/test/lock_tests.py, line 37, in task (tid=140737213728528) - f() - - Thread 104 (Thread 0x7fffdf5fe710 (LWP 10259)): - #5 Frame 0x7fffe4001580, for file /home/david/coding/python-svn/Lib/threading.py, line 155, in _acquire_restore (self=<_RLock(_Verbose__verbose=False, _RLock__owner=140737354016512, _RLock__block=<thread.lock at remote 0x858770>, _RLock__count=1) at remote 0xd7ff40>, count_owner=(1, 140736940992272), count=1, owner=140736940992272) - self.__block.acquire() - #8 Frame 0x7fffc8002090, for file /home/david/coding/python-svn/Lib/threading.py, line 269, in wait (self=<_Condition(_Condition__lock=<_RLock(_Verbose__verbose=False, _RLock__owner=140737354016512, _RLock__block=<thread.lock at remote 0x858770>, _RLock__count=1) at remote 0xd7ff40>, acquire=<instancemethod at remote 0xd80260>, _is_owned=<instancemethod at remote 0xd80160>, _release_save=<instancemethod at remote 0xd803e0>, release=<instancemethod at remote 0xd802e0>, _acquire_restore=<instancemethod at remote 0xd7ee60>, _Verbose__verbose=False, _Condition__waiters=[]) at remote 0xd7fd10>, timeout=None, waiter=<thread.lock at remote 0x858860>, saved_state=(1, 140736940992272)) - self._acquire_restore(saved_state) - #12 Frame 0x7fffac001c90, for file /home/david/coding/python-svn/Lib/test/lock_tests.py, line 348, in f () - cond.wait() - #16 Frame 0x7fffac0011c0, for file /home/david/coding/python-svn/Lib/test/lock_tests.py, line 37, in task (tid=140736940992272) - f() - - Thread 1 (Thread 0x7ffff7fe2700 (LWP 10145)): - #5 Frame 0xcb5380, for file /home/david/coding/python-svn/Lib/test/lock_tests.py, line 16, in _wait () - time.sleep(0.01) - #8 Frame 0x7fffd00024a0, for file /home/david/coding/python-svn/Lib/test/lock_tests.py, line 378, in _check_notify (self=<ConditionTests(_testMethodName='test_notify', _resultForDoCleanups=<TestResult(_original_stdout=<cStringIO.StringO at remote 0xc191e0>, skipped=[], _mirrorOutput=False, testsRun=39, buffer=False, _original_stderr=<file at remote 0x7ffff7fc6340>, _stdout_buffer=<cStringIO.StringO at remote 0xc9c7f8>, _stderr_buffer=<cStringIO.StringO at remote 0xc9c790>, _moduleSetUpFailed=False, expectedFailures=[], errors=[], _previousTestClass=<type at remote 0x928310>, unexpectedSuccesses=[], failures=[], shouldStop=False, failfast=False) at remote 0xc185a0>, _threads=(0,), _cleanups=[], _type_equality_funcs={<type at remote 0x7eba00>: <instancemethod at remote 0xd750e0>, <type at remote 0x7e7820>: <instancemethod at remote 0xd75160>, <type at remote 0x7e30e0>: <instancemethod at remote 0xd75060>, <type at remote 0x7e7d20>: <instancemethod at remote 0xd751e0>, <type at remote 0x7f19e0...(truncated) - _wait() - -.. note:: This is only available for Python 2.7, 3.2 and higher. - - -gdb 6 and earlier ------------------ - -The file at ``Misc/gdbinit`` contains a gdb configuration file which provides -extra commands when working with a CPython process. To register these commands -permanently, either copy the commands to your personal gdb configuration file -or symlink ``~/.gdbinit`` to ``Misc/gdbinit``. To use these commands from -a single gdb session without registering them, type ``source Misc/gdbinit`` -from your gdb session. - - -Updating auto-load-safe-path to allow test_gdb to run ------------------------------------------------------ - -``test_gdb`` attempts to automatically load additional Python specific -hooks into gdb in order to test them. Unfortunately, the command line -options it uses to do this aren't always supported correctly. - -If ``test_gdb`` is being skipped with an "auto-loading has been declined" -message, then it is necessary to identify any Python build directories as -auto-load safe. One way to achieve this is to add a line like the following -to ``~/.gdbinit`` (edit the specific list of paths as appropriate):: - - add-auto-load-safe-path ~/devel/py3k:~/devel/py32:~/devel/py27 diff --git a/fixingissues.rst b/getting-started/fixing-issues.rst similarity index 62% rename from fixingissues.rst rename to getting-started/fixing-issues.rst index 7821d41205..f277cbf60d 100644 --- a/fixingissues.rst +++ b/getting-started/fixing-issues.rst @@ -1,10 +1,12 @@ +.. _fixing-issues: .. _fixingissues: -Fixing "easy" Issues (and Beyond) +================================= +Fixing "easy" issues (and beyond) ================================= When you feel comfortable enough to want to help tackle issues by trying to -create a patch to fix an issue, you can start by looking at the `"easy" +create a pull request to fix an issue, you can start by looking at the `"easy" issues`_. These issues *should* be ones where it should take no longer than a day or weekend to fix. But because the "easy" classification is typically done at triage time it can turn out to be inaccurate, so do feel free to leave a @@ -15,11 +17,9 @@ are not considered easy and try to fix those. It must be warned, though, that it is quite possible that a bug that has been left open has been left into that state because of the difficulty compared to the benefit of the fix. It could also still be open because no consensus has been reached on how to fix the -issue (although having a patch that proposes a fix can turn the tides of the -discussion to help bring it to a close). Regardless of why the issue is open, +issue, although having a pull request that proposes a fix can turn the tides of the +discussion to help bring it to a close. Regardless of why the issue is open, you can also always provide useful comments if you do attempt a fix, successful or not. -.. _"easy" issues: https://bugs.python.org/issue?status=1&@sort=-activity&@dispname=Easy%20issues&@startwith=0&@filter=&@group=priority&@columns=id,activity,title,creator,status&keywords=6&@action=search&@pagesize=50 - -.. TODO: add something about no active core developer for the area? +.. _"easy" issues: https://github.com/python/cpython/issues?q=is%3Aissue+is%3Aopen+label%3Aeasy diff --git a/getting-started/generative-ai.rst b/getting-started/generative-ai.rst new file mode 100644 index 0000000000..e4aa3e7586 --- /dev/null +++ b/getting-started/generative-ai.rst @@ -0,0 +1,40 @@ +.. _generative-ai: + +============= +Generative AI +============= + +Generative AI tools have evolved rapidly, and their suggested results can be helpful. As with using any tool, the resulting contribution is +the responsibility of the contributor. We value good code, concise accurate documentation, and avoiding unneeded code +churn. Discretion, good judgment, and critical thinking are the foundation of all good contributions, regardless of the +tools used in their creation. + +Acceptable uses +=============== + +Some of the acceptable uses of generative AI include: + +- Assistance with writing comments, especially in a non-native language +- Gaining understanding of existing code +- Supplementing contributor knowledge for code, tests, and documentation + +Unacceptable uses +================= + +Maintainers may close issues and PRs that are not useful or productive, including +those that are fully generated by AI. If a contributor repeatedly opens unproductive +issues or PRs, they may be blocked. + +Considerations for success +========================== +- While AI assisted tools such as autocompletion can enhance productivity, they sometimes rewrite entire code blocks instead of making small, focused edits. + This can make it more difficult to review changes and to fully understand both the original intent of the code and the rationale behind the new modifications. + Maintaining consistency with the original code helps preserve clarity, traceability, and meaningful reviews and also helps us avoid unnecessary code churn. +- Sometimes AI assisted tools make failing unit tests pass by altering or bypassing the tests rather than addressing the underlying problem in the code. + Such changes do not represent a real fix. Authors must review the work done by AI tooling in detail to ensure it actually makes sense before proposing it as a PR. +- Keep the following principles for the quality of your contributions in mind whether you use generative AI or not: + + - Consider whether the change is necessary + - Make minimal, focused changes + - Follow existing coding style and patterns + - Write tests that exercise the change diff --git a/getting-started/getting-help.rst b/getting-started/getting-help.rst new file mode 100644 index 0000000000..fc289fd449 --- /dev/null +++ b/getting-started/getting-help.rst @@ -0,0 +1,80 @@ +.. _getting-help: +.. _help: + +Where to get help +================= + +If you are working on Python it is very possible you will come across an issue +where you need some assistance to solve it (this happens to the core team +all the time). + +Should you require help, there are a :ref:`variety of options available +<communication>` to seek assistance. If the question involves process or tool +usage then please check the rest of this guide first as it should answer your +question. + + +.. _help-discourse: + +Discourse +--------- + +Python has a hosted Discourse instance at `discuss.python.org <Discourse_>`_. +This forum has many different categories, +most of which are open for all users to read and post. +Those particularly relevant for help contributing to Python itself include: + +* `Core Development`_ for most general questions and help +* `Ideas`_ to discuss new ideas for the Python language +* `Core Workflow`_ for questions about the dev infrastructure and bots + +.. seealso:: + :ref:`communication-discourse` for more information on how to get started. + +.. _Discourse: https://discuss.python.org/ +.. _Core Development: https://discuss.python.org/c/core-dev/23 +.. _Core Workflow: https://discuss.python.org/c/core-workflow/8 +.. _Ideas: https://discuss.python.org/c/ideas/6 + + +Ask #python-dev +--------------- + +If you are comfortable with IRC you can try asking on ``#python-dev`` (on +the `Libera.Chat`_ network). Typically there are a number of experienced +contributors, ranging from triagers to the core team, who can answer +questions about developing for Python. As with the mailing lists, +``#python-dev`` is for questions involving the development *of* Python +whereas ``#python`` is for questions concerning development *with* Python. + +.. note:: + + You may not be able to access the history of this channel, so it cannot + be used as a "knowledge base" of sorts. + +.. _Libera.Chat: https://libera.chat/ + +Core mentorship +--------------- + +If you are interested in improving Python and contributing to its development, +but don’t yet feel entirely comfortable with the public channels mentioned +above, `Python Mentors`_ are here to help you. Python is fortunate to have a +community of volunteer core team members willing to mentor anyone wishing to +contribute code, work on bug fixes or improve documentation. Everyone is +welcomed and encouraged to contribute. + +.. _Python Mentors: https://www.python.org/dev/core-mentorship/ + + +File a bug +---------- + +If you strongly suspect you have stumbled on a bug (be it in the build +process, in the test suite, or in other areas), then open an issue on the +`issue tracker`_. As with every bug report it is strongly advised that +you detail which conditions triggered it (including the OS name and version, +and what you were trying to do), as well as the exact error message you +encountered. + +.. _issue tracker: https://github.com/python/cpython/issues diff --git a/getting-started/git-boot-camp.rst b/getting-started/git-boot-camp.rst new file mode 100644 index 0000000000..6376a190ca --- /dev/null +++ b/getting-started/git-boot-camp.rst @@ -0,0 +1,746 @@ +.. _git-boot-camp: +.. _gitbootcamp: + +Git bootcamp and cheat sheet +============================ + +.. include:: /include/activate-tab.rst + +.. highlight:: console + +.. note:: + + This section provides instructions on common tasks in CPython's + workflow. It's designed to assist new contributors who have + some familiarity with Git and GitHub. + + If you are new to Git and GitHub, please become comfortable with + these instructions before submitting a pull request. As there are several + ways to accomplish these tasks using Git and GitHub, this section reflects + one method suitable for new contributors. Experienced contributors may + desire a different approach. + + +In this section, we will go over some commonly used Git commands that are +relevant to CPython's workflow. + +.. note:: + Setting up Git aliases for common tasks can be useful to you. You can + get more information about that in + `Git documentation <https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases>`__ + +.. _fork-cpython: + +Forking CPython GitHub repository +--------------------------------- + +You will only need to do this once. + +1. Go to https://github.com/python/cpython. + +2. Press :guilabel:`Fork` located near the top right of the page. + +3. Uncheck "Copy the ``main`` branch only". + +4. Press the :guilabel:`Create fork` button. + +5. Your forked CPython repository will be created at ``https://github.com/<username>/cpython``. + +.. _clone-your-fork: + +Cloning a forked CPython repository +----------------------------------- + +You will only need to do this once per machine. From your command line:: + + $ git clone git@github.com:<username>/cpython.git + +It is also recommended to configure an ``upstream`` remote repository:: + + $ cd cpython + $ git remote add upstream https://github.com/python/cpython + +You can also use SSH-based or HTTPS-based URLs. + +Configure the remotes +--------------------- + +.. These steps are duplicated in setup-building in step 6 and 7. + Please update these there as well. + +Configure ``git`` to pull ``main`` from the ``upstream`` remote:: + + $ git config --local branch.main.remote upstream + +Since one should never attempt to push to ``upstream``, configure +``git`` to push always to ``origin``:: + + $ git remote set-url --push upstream git@github.com:<username>/cpython.git + +Listing the remote repositories +------------------------------- + +To list the remote repositories that are configured, along with their URLs:: + + $ git remote -v + +You should have two remote repositories: ``origin`` pointing to your forked CPython repository, +and ``upstream`` pointing to the official CPython repository: + +.. code-block:: text + + origin git@github.com:<username>/cpython.git (fetch) + origin git@github.com:<username>/cpython.git (push) + upstream https://github.com/python/cpython (fetch) + upstream git@github.com:<username>/cpython.git (push) + +To verify the upstream for ``main``:: + + $ git config branch.main.remote + +It should emit ``upstream``, indicating to track/pull changes for ``main`` from the +``upstream`` remote. + +Once this is verified, update your local clone with the upstream branches:: + + $ git fetch upstream + + +.. _set-up-name-email: + +Setting up your name and email address +-------------------------------------- + +:: + + $ git config --global user.name "Your Name" + $ git config --global user.email your.email@example.com + +The ``--global`` flag sets these parameters globally while +the ``--local`` flag sets them only for the current project. + +.. _autocrlf: + +Enabling ``autocrlf`` on Windows +-------------------------------- + +The ``autocrlf`` option will fix automatically any Windows-specific line endings. +This should be enabled on Windows, since the public repository has a hook which +will reject all commits having the wrong line endings:: + + $ git config --global core.autocrlf input + +Creating and switching branches +------------------------------- + +.. important:: + Never commit directly to the ``main`` branch. + +Create a new branch from ``main`` and switch to it:: + + $ git switch -c <branch-name> main + +This is equivalent to:: + + $ # create a new branch from main + $ git branch <branch-name> main + $ # switch to the new branch + $ git switch <branch-name> + +To find the branch you are currently on:: + + $ git branch + +The current branch will have an asterisk next to the branch name. Note, this +will only list all of your local branches. + +To list all the branches, including the remote branches:: + + $ git branch -a + +To switch to a different branch:: + + $ git switch <another-branch-name> + +Other releases are just branches in the repository. For example, to work +on the 3.12 release from the ``upstream`` remote:: + + $ git switch -c 3.12 upstream/3.12 + +.. _deleting_branches: + +Deleting branches +----------------- + +To delete a **local** branch that you no longer need:: + + $ git switch main + $ git branch -D <branch-name> + +To delete a **remote** branch:: + + $ git push origin -d <branch-name> + +You may specify more than one branch for deletion. + + +Renaming branch +--------------- + +The CPython repository's default branch was renamed from ``master`` to +``main`` after the Python 3.10b1 release. + +If you have a fork on GitHub (as described in :ref:`fork-cpython`) that was +created before the rename, you should visit the GitHub page for your fork to +rename the branch there. You only have to do this once. GitHub should +provide you with a dialog for this. If it doesn't (or the dialog was already +dismissed), you can rename the branch in your fork manually `by following +these GitHub instructions <https://github.com/github/renaming#renaming-existing-branches>`__. + +After renaming the branch in your fork, you need to update any local clones +as well. This only has to be done once per clone:: + + $ git branch -m master main + $ git fetch origin + $ git branch -u origin/main main + $ git remote set-head origin -a + +(GitHub also provides these instructions after you rename the branch.) + +If you do not have a fork on GitHub, but rather a direct clone of the main +repo created before the branch rename, you still have to update your local +clones. This still only has to be done once per clone. In that case, you can +rename your local branch as follows:: + + $ git branch -m master main + $ git fetch upstream + $ git branch -u upstream/main main + + +.. _commit-changes: + +Staging and committing files +---------------------------- + +1. To show the current changes:: + + $ git status + +2. To stage the files to be included in your commit:: + + $ git add -p # to review and add changes to existing files + $ git add <filename1> <filename2> # to add new files + +3. To commit the files that have been staged (done in step 2): + + .. code-block:: bash + + git commit -m "This is the commit message." + +Reverting changes +----------------- + +To revert changes to a file that has not been committed yet:: + + $ git checkout <filename> + +If the change has been committed, and now you want to reset it to whatever +the origin is at:: + + $ git reset --hard HEAD + +Stashing changes +---------------- + +To stash away changes that are not ready to be committed yet:: + + $ git stash + +To re-apply the last stashed change:: + + $ git stash pop + +.. _diff-changes: + +Comparing changes +----------------- + +View all non-commited changes:: + + $ git diff + +Compare to the ``main`` branch:: + + $ git diff main + +Exclude generated files from diff using an ``attr`` +`pathspec <https://git-scm.com/docs/gitglossary#def_pathspec>`__ (note the +single quotes):: + + $ git diff main ':(attr:!generated)' + +Exclude generated files from diff by default:: + + $ git config diff.generated.binary true + +The ``generated`` `attribute <https://git-scm.com/docs/gitattributes>`__ is +defined in :cpy-file:`.gitattributes`, found in the repository root. + +.. _push-changes: + +Pushing changes +--------------- + +Once your changes are ready for a review or a pull request, you will need to push +them to the remote repository. + +:: + + $ git switch <branch-name> + $ git push origin <branch-name> + +Creating a pull request +----------------------- + +1. Go to https://github.com/python/cpython. + +2. Press the :guilabel:`New pull request` button. + +3. Click the ``compare across forks`` link. + +4. Select the base repository: ``python/cpython`` and base branch: ``main``. + +5. Select the head repository: ``<username>/cpython`` and head branch: the branch + containing your changes. + +6. Press the :guilabel:`Create pull request` button. + +You should include the issue number in the title of the PR, +in the format ``gh-NNNNN: <PR Title>``. + +Linking to issues and pull requests +----------------------------------- + +You can link to issues and pull requests using ``gh-NNNNN`` (this form is +preferred over ``#NNNNN``). If the reference appears in a list, the link +will be expanded to show the status and title of the issue/PR. + +When you create a PR that includes ``gh-NNNNN`` in the title, `bedevere`_ +will automatically add a link to the issue in the first message. + +In addition, pull requests support `special keywords`_ that can be used to +link to an issue and automatically close it when the PR is merged. +However, issues often require multiple PRs before they can be closed (for +example, backports to other branches), so this features is only useful if +you know for sure that a single PR is enough to address and close the issue. + +.. _bedevere: https://github.com/python/bedevere +.. _special keywords: https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword + +Updating your CPython fork +-------------------------- + +Scenario: + +- You forked the CPython repository some time ago. +- Time passes. +- There have been new commits made in the upstream CPython repository. +- Your forked CPython repository is no longer up to date. +- You now want to update your forked CPython repository to be the same as + the upstream CPython repository. + +Please do not try to solve this by creating a pull request from +``python:main`` to ``<username>:main`` as the authors of the pull requests will +get notified unnecessarily. + +Solution:: + + $ git switch main + $ git pull upstream main + $ git push origin main + +.. note:: For the above commands to work, please follow the instructions found + in the :ref:`checkout` section. + +Another scenario: + +- You created ``some-branch`` some time ago. +- Time passes. +- You made some commits to ``some-branch``. +- Meanwhile, there are recent changes from the upstream CPython repository. +- You want to incorporate the recent changes from the upstream CPython + repository into ``some-branch``. + +Solution:: + + $ git switch some-branch + $ git fetch upstream + $ git merge upstream/main + $ git push origin some-branch + +You may see error messages like "CONFLICT" and "Automatic merge failed;" when +you run ``git merge upstream/main``. + +When it happens, you need to resolve conflict. See these articles about resolving conflicts: + +- `About merge conflicts <https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/about-merge-conflicts>`__ +- `Resolving a merge conflict using the command line <https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line>`__ + +.. _git_from_patch: + +Applying a patch to Git +----------------------- + +Scenario: + +- A patch exists but there is no pull request for it. + +Solution: + +1. Download the patch locally. + +2. Apply the patch:: + + $ git apply /path/to/patch.diff + + If there are errors, update to a revision from when the patch was + created and then try the ``git apply`` again:: + + $ git checkout $(git rev-list -n 1 --before="yyyy-mm-dd hh:mm:ss" main) + $ git apply /path/to/patch.diff + + If the patch still won't apply, then a patch tool will not be able to + apply the patch and it will need to be re-implemented manually. + +3. If the apply was successful, create a new branch and switch to it. + +4. Stage and commit the changes. + +5. If the patch was applied to an old revision, it needs to be updated and + merge conflicts need to be resolved:: + + $ git rebase main + $ git mergetool + + For very old changes, ``git merge --no-ff`` may be easier than a rebase, + with regards to resolving conflicts. + +6. Push the changes and open a pull request. + +.. _git_pr: + +Checking out others' pull requests +---------------------------------- + +Scenario: + +- A contributor made a pull request to CPython. +- Before merging it, you want to be able to test their changes locally. + +If you've got `GitHub CLI <https://cli.github.com>`__ or +`hub <https://hub.github.com>`__ installed, you can do:: + + $ gh co <pr_number> # GitHub CLI + $ hub pr checkout <pr_number> # hub + +Both of these tools will configure a remote URL for the branch, so you can +``git push`` if the pull request author checked "Allow edits from maintainers" +when creating the pull request. + +Otherwise, you can run the following commands: + +.. code-block:: shell + + $ git fetch upstream pull/NNNNN/head:pr_NNNNN + $ git switch pr_NNNNN + +Or set up a Git alias: + +.. tab:: Unix/macOS + + .. code-block:: shell + + git config --global alias.pr '!sh -c "git fetch upstream pull/${1}/head:pr_${1} && git switch pr_${1}" -' + +.. tab:: Windows + + .. code-block:: dosbatch + + git config --global alias.pr "!sh -c 'git fetch upstream pull/${1}/head:pr_${1} && git switch pr_${1}' -" + +The alias only needs to be done once. After the alias is set up, you can get a +local copy of a pull request as follows:: + + $ git pr <pr_number> + +.. _accepting-and-merging-a-pr: + +Accepting and merging a pull request +------------------------------------ + +Pull requests can be accepted and merged by a Python Core Developer. +You can read more about what to look for before accepting a change +:ref:`here <committing>`. + +All pull requests have required checks that need to pass before a change +can be merged. See :ref:`"Keeping CI green" <keeping-ci-green>` for some +simple things you can do to help the checks turn green. + +At any point, a core developer can schedule an automatic merge of the change +by clicking the gray :guilabel:`Enable auto-merge (squash)` button. You will find +it at the bottom of the pull request page. The auto-merge will only +happen if all the required checks pass, but the PR does not need to have been +approved for a successful auto-merge to take place. + +If all required checks are already finished on a PR you're reviewing, +in place of the gray :guilabel:`Enable auto-merge` button you will find a green +:guilabel:`Squash and merge` button. + +In either case, adjust and clean up the commit message. + +✅ Here's an example of a **good** commit message: + +.. code-block:: text + :class: good + + gh-12345: Improve the spam module (GH-777) + + * Add method A to the spam module + * Update the documentation of the spam module + +❌ Here's an example of a **bad** commit message: + +.. code-block:: text + :class: bad + + gh-12345: Improve the spam module (#777) + + * Improve the spam module + * merge from main + * adjust code based on review comment + * rebased + +The bad example contains bullet points that are a direct effect of the +PR life cycle, while being irrelevant to the final change. + +.. note:: + `How to Write a Git Commit Message <https://cbea.ms/git-commit/>`__ + is a nice article describing how to write a good commit message. + +Finally, press the :guilabel:`Confirm squash and merge` button. + +Cancelling an automatic merge +----------------------------- + +If you notice a problem with a pull request that was accepted and where +auto-merge was enabled, you can still cancel the workflow before GitHub +automatically merges the change. + +Press the gray :guilabel:`Disable auto-merge` button on the bottom of the +pull request page to disable automatic merging entirely. This is the +recommended approach. + +To pause automatic merging, apply the "DO-NOT-MERGE" label to the PR or +submit a review requesting changes. The latter will put an "awaiting +changes" label on the PR, which pauses the auto-merge similarly to +"DO-NOT-MERGE". After the author submits a fix and re-requests review, you can +resume the auto-merge process either by submitting an approving review or by +dismissing your previous review that requested changes. + +Note that pushing new changes after the auto-merge flow was enabled +does **NOT** stop it. + +Backporting merged changes +-------------------------- + +A pull request may need to be backported into one of the maintenance branches +after it has been accepted and merged into ``main``. It is usually indicated +by the label ``needs backport to X.Y`` on the pull request itself. + +Use the utility script +`cherry_picker.py <https://github.com/python/cherry-picker>`__ +to backport the commit. + +The commit hash for backporting is the squashed commit that was merged to +the ``main`` branch. On the merged pull request, scroll to the bottom of the +page. Find the event that says something like: + +.. code-block:: text + + <core_developer> merged commit <commit_sha1> into python:main <sometime> ago. + +By following the link to ``<commit_sha1>``, you will get the full commit hash. + +Alternatively, the commit hash can also be obtained by the following Git +commands:: + + $ git fetch upstream + $ git rev-parse ":/gh-12345" + +The above commands will print out the hash of the commit containing +``"gh-12345"`` as part of the commit message. + +When formatting the commit message for a backport commit: leave the original +one as is and delete the number of the backport pull request. + +✅ Example of good backport commit message: + +.. code-block:: text + :class: good + + gh-12345: Improve the spam module (GH-777) + + * Add method A to the spam module + * Update the documentation of the spam module + + (cherry picked from commit 62adc55) + +❌ Example of bad backport commit message: + +.. code-block:: text + :class: bad + + gh-12345: Improve the spam module (GH-777) (#888) + + * Add method A to the spam module + * Update the documentation of the spam module + +Editing a pull request prior to merging +--------------------------------------- + +When a pull request submitter has enabled the `Allow edits from maintainers`_ +option, Python Core Developers may decide to make any remaining edits needed +prior to merging themselves, rather than asking the submitter to do them. This +can be particularly appropriate when the remaining changes are bookkeeping +items like updating a news entry. + +.. _Allow edits from maintainers: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork + +To edit an open pull request that targets ``main``: + +1. In the pull request page, under the description, there is some information + about the contributor's forked CPython repository and branch name that will be useful later: + +.. code-block:: text + + <contributor> wants to merge 1 commit into python:main from <contributor>:<branch_name> + +2. Fetch the pull request, using the :ref:`git pr <git_pr>` alias:: + + $ git pr <pr_number> + + This will checkout the contributor's branch at ``<pr_number>``. + +3. Make and commit your changes on the branch. For example, merge in changes + made to ``main`` since the PR was submitted (any merge commits will be + removed by the later ``Squash and Merge`` when accepting the change):: + + $ git fetch upstream + $ git merge upstream/main + $ git add <filename> + $ git commit -m "<message>" + +4. Push the changes back to the contributor's PR branch:: + + $ git push git@github.com:<contributor>/cpython <pr_number>:<branch_name> + +5. Optionally, :ref:`delete the PR branch <deleting_branches>`. + + +GitHub CLI +---------- + +`GitHub CLI <https://cli.github.com>`__ is a command-line +interface that allows you to create, update, and check GitHub +issues and pull requests. + +You can install GitHub CLI `by following these instructions +<https://github.com/cli/cli#installation>`__. After installing, +you need to authenticate:: + + $ gh auth login + +Examples of useful commands: + +* Create a PR:: + + $ gh pr create + +* Check out another PR:: + + $ gh co <pr-id> + +* Set ``ssh`` as the Git protocol:: + + $ gh config set git_protocol ssh + +* Set the browser:: + + $ gh config set browser <browser-path> + + +Git worktree +------------ + +With Git worktrees, you can have multiple isolated working trees +associated with a single repository (the ``.git`` directory). +This allows you to work simultaneously on different version +branches, eliminating the need for multiple independent clones +that need to be maintained and updated separately. +In addition, it reduces cloning overhead and saves disk space. + +Setting up Git worktree +^^^^^^^^^^^^^^^^^^^^^^^ + +With an existing CPython clone (see :ref:`clone-your-fork`), rename the +``cpython`` directory to ``main`` and move it into a new ``cpython`` +directory, so we have a structure like: + +.. Generated with: tree -L 1 -d cpython + +.. code-block:: text + + cpython + └── main (.git is here) + +Next, create worktrees for the other branches:: + + $ cd cpython/main + $ git worktree add -b 3.11 ../3.11 upstream/3.11 + $ git worktree add -b 3.12 ../3.12 upstream/3.12 + +This gives a structure like this, with the code for each branch checked out in +its own directory: + +.. code-block:: text + + cpython + ├── 3.11 + ├── 3.12 + └── main + +Using Git worktree +^^^^^^^^^^^^^^^^^^ + +List your worktrees, for example:: + + $ git worktree list + /Users/my-name/cpython/main b3d24c40df [main] + /Users/my-name/cpython/3.11 da1736b06a [3.11] + /Users/my-name/cpython/3.12 cf29a2f25e [3.12] + +Change into a directory to work from that branch. For example:: + + $ cd ../3.12 + $ git switch -c my-3.12-bugfix-branch # create new branch + $ # make changes, test them, commit + $ git push origin my-3.12-bugfix-branch + $ # create PR + $ git switch 3.12 # switch back to the 3.12 branch + ... + +.. seealso:: + + * `Git Reference Manual <https://git-scm.com/docs/git-worktree>`__ + * `"Experiment on your code freely with Git worktree" + <https://opensource.com/article/21/4/git-worktree>`__ diff --git a/getting-started/index.rst b/getting-started/index.rst new file mode 100644 index 0000000000..05ee67a3bc --- /dev/null +++ b/getting-started/index.rst @@ -0,0 +1,15 @@ +.. _getting-started: + +=============== +Getting started +=============== + +.. toctree:: + :maxdepth: 5 + + setup-building + fixing-issues + git-boot-camp + pull-request-lifecycle + getting-help + generative-ai diff --git a/getting-started/pull-request-lifecycle.rst b/getting-started/pull-request-lifecycle.rst new file mode 100644 index 0000000000..78c8cfff06 --- /dev/null +++ b/getting-started/pull-request-lifecycle.rst @@ -0,0 +1,756 @@ +.. _pull-request-lifecycle: +.. _patch: +.. _pullrequest: + +=========================== +Lifecycle of a pull request +=========================== + +.. highlight:: bash + +Introduction +============ + +CPython uses a workflow based on pull requests. What this means is +that you create a branch in Git, make your changes, push those changes +to your fork on GitHub (``origin``), and then create a pull request against +the official CPython repository (``upstream``). + + +.. _pullrequest-quickguide: + +Quick guide +=========== + +`Clear communication`_ is key to contributing to any project, especially an +`Open Source`_ project like CPython. + +Here is a quick overview of how you can contribute to CPython: + +#. `Create an issue`_ that describes your change. If it is trivial + (like :ref:`typo fixes <typo-fixes>`), or an issue already exists, + you can skip this step. + +#. :ref:`Create a new branch in Git <pullrequest-steps>` from the + ``main`` branch + +#. Work on changes: fix a bug or add a new feature + +#. :ref:`Run tests <runtests>` and ``make patchcheck`` + +#. :ref:`Commit <commit-changes>` and :ref:`push <push-changes>` + changes to your GitHub fork + +#. `Create Pull Request`_ on GitHub to merge a branch from your fork + +#. Make sure the :ref:`continuous integration checks on your Pull Request + are green <keeping-ci-green>` (successful) + +#. Review and address `comments on your Pull Request`_ + +#. When your changes are merged, you can :ref:`delete the PR branch + <deleting_branches>` + +#. Celebrate contributing to CPython! :) + +Don't force-push +---------------- + +In order to keep the commit history intact, please avoid squashing or amending +history and then force-pushing to the PR. Reviewers often want to look at +individual commits. +When the PR is merged, everything will be squashed into a single commit. + +.. _Clear communication: https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution +.. _Open Source: https://opensource.guide/ +.. _create an issue: https://github.com/python/cpython/issues +.. _CPython: https://github.com/python/cpython +.. _use HTTPS: https://help.github.com/articles/which-remote-url-should-i-use/ +.. _Create Pull Request: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request +.. _comments on your Pull Request: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request + + +.. _pullrequest-steps: + +Step-by-step guide +================== + +You should have already :ref:`set up your system <setup>`, +:ref:`got the source code <checkout>`, and :ref:`built Python <compiling>`. + +* Update data from your ``upstream`` repository:: + + git fetch upstream + +* Create a new branch in your local clone from the ``main`` branch + in the upstream repository:: + + git checkout -b <branch-name> upstream/main + + .. note:: + Almost all changes to Python, including bug fixes, should first be + made against the ``main`` branch. See :ref:`here <good-prs>` for + more details. + +* Make changes to the code, and use ``git status`` and ``git diff`` to see them. + + (Learn more about :ref:`good-prs`) + +* Make sure the changes are fine and don't cause any test failure:: + + make patchcheck + ./python -m test + + (Learn more about :ref:`patchcheck` and about :ref:`runtests`) + +* Once you are satisfied with the changes, add the files and commit them:: + + git add <filenames> + git commit -m '<message>' + + (Learn more about :ref:`good-commits`) + +* If your code isn't linted correctly, :ref:`pre-commit <install-pre-commit>` + will block the commit with an error message, for example:: + + Doc/library/stdtypes.rst:5718: No newline at end of file. (missing-final-newline) + +* Once all linting errors have been fixed, you can push your work to your GitHub fork:: + + git push origin <branch-name> + +* Finally go on :samp:`https://github.com/{<your-username>}/cpython`: you will + see a box with the branch you just pushed and a green button that allows + you to create a pull request against the official CPython repository. + +* When people start adding review comments, you can address them by switching + to your branch, making more changes, committing them, and pushing them to + automatically update your PR:: + + git switch <branch-name> + # make changes and run tests + git add <filenames> + git commit -m '<message>' + git push origin <branch-name> + + * If a core team member reviewing your PR pushed one or more commits to your + PR branch, then after checking out your branch and before editing, run:: + + git pull origin <branch-name> # pull = fetch + merge + + If you have made local changes that have not been pushed to your fork and + there are merge conflicts, Git will warn you about this and enter conflict + resolution mode. See :ref:`resolving-merge-conflicts` below. + +* If time passes and there are merge conflicts with the main branch, GitHub + will show a warning to this end and you may be asked to address this. Merge + the changes from the main branch while resolving the conflicts locally:: + + git switch <branch-name> + git pull upstream main # pull = fetch + merge + # resolve conflicts: see "Resolving Merge Conflicts" below + git push origin <branch-name> + +* After your PR has been accepted and merged, you can :ref:`delete the branch + <deleting_branches>`:: + + git branch -D <branch-name> # delete local branch + git push origin -d <branch-name> # delete remote branch + +.. _resolving-merge-conflicts: + +Resolving merge conflicts +------------------------- + +When merging changes from different branches (or variants of a branch on +different repos), the two branches may contain incompatible changes to one +or more files. These are called "merge conflicts" and need to be manually +resolved as follows: + +#. Check which files have merge conflicts:: + + git status + +#. Edit the affected files and bring them to their intended final state. + Make sure to remove the special "conflict markers" inserted by Git. + +#. Commit the affected files:: + + git add <filenames> + git merge --continue + +When running the final command, Git may open an editor for writing a commit +message. It is usually okay to leave that as-is and close the editor. + +See `the merge command's documentation <https://git-scm.com/docs/git-merge>`__ +for a detailed technical explanation. + + +.. _good-prs: + +Making good PRs +=============== + +When creating a pull request for submission, there are several things that you +should do to help ensure that your pull request is accepted. + +#. **Make your change against the right version of Python.** In general all + changes are made against the ``main`` branch first. This includes bug fixes. + After the change is merged there, it will be :ref:`ported back <branch-merge>` + to older :ref:`maintenance releases <branchstatus>` as well. That way we + ensure all affected versions are handled. Therefore, basing a new change + directly on a maintenance branch is only used in specific circumstances, + for instance when that change does not apply to ``main`` or the change + requires a different approach in an older Python version compared to + ``main``. + +#. **Make sure to follow Python's style guidelines.** For Python code you + should follow :PEP:`8`, and for C code you should follow :PEP:`7`. If you have + one or two discrepancies those can be fixed by the core team member who merges + your pull request. But if you have systematic deviations from the style guides + your pull request will be put on hold until you fix the formatting issues. + + .. note:: + Pull requests with only code formatting changes are usually rejected. On + the other hand, fixes for typos and grammar errors in documents and + docstrings are welcome. + +#. **Be aware of backwards-compatibility considerations.** While the core + developer who eventually handles your pull request will make the final call on + whether something is acceptable, thinking about backwards-compatibility early + will help prevent having your pull request rejected on these grounds. Put + yourself in the shoes of someone whose code will be broken by the change(s) + introduced by the pull request. It is quite likely that any change made will + break someone's code, so you need to have a good reason to make a change as + you will be forcing someone to update their code. (This obviously does not + apply to new classes or functions; new arguments should be optional and have + default values which maintain the existing behavior.) If in doubt, have a look + at :PEP:`387` or :ref:`discuss <communication>` the issue with experienced + developers. + +#. **Make sure you have proper tests** to verify your pull request works as + expected. Pull requests will not be accepted without the proper tests! + +#. **Make sure all tests pass.** The entire test suite needs to + :ref:`run <runtests>` **without failure** because of your changes. + It is not sufficient to only run whichever test seems impacted by your + changes, because there might be interferences unknown to you between your + changes and some other part of the interpreter. + +#. **Keep your pull request focused and small.** A pull request should address + one issue or add one feature. Combining multiple unrelated changes makes a + pull request harder to review and increases the number of people notified + unnecessarily. + +#. Proper :ref:`documentation <documenting>` additions/changes should be included. + +.. _news-entry: +.. _what-s-new-and-news-entries: + +Updating NEWS and What's New in Python +====================================== + +Changes that require NEWS entries +--------------------------------- + +Most changes made to the codebase deserve an entry in :cpy-file:`Misc/NEWS.d`, +except for the following: + +* documentation changes +* test changes +* strictly internal changes with no user-visible effects +* changes that already have a ``NEWS`` entry +* reverts that have not yet been included in any formal release + (including alpha and beta releases) + +For the last two, note the following: + +#. **If a change is reverted prior to release**, then the corresponding + entry is simply removed. Otherwise, a new entry must be added noting + that the change has been reverted (for example, when a feature is released in + an alpha and then cut prior to the first beta). + +#. **If a change is a fix (or other adjustment) to an earlier unreleased + change and the original** ``NEWS`` **entry remains valid**, then no additional + entry is needed. + +Changes that require "What's New in Python" entries +--------------------------------------------------- + +If a change is particularly interesting for end users (for example, new features, +significant improvements, or backwards-incompatible changes), add an entry in +the "What's New in Python" document (in :cpy-file:`Doc/whatsnew/`, the 3.X.rst +file where X is the current Python version) in addition to the ``NEWS`` entry. + +In most cases, it is sufficient to reuse the wording from the ``NEWS`` entry +in the "What's New in Python" entry. + +.. note:: + + A change that needs an entry in "What's New in Python" + is very likely not suitable for inclusion in a maintenance release. + +How to add a NEWS entry +----------------------- + +``NEWS`` entries go into the ``Misc/NEWS.d`` directory as individual files. The +``NEWS`` entry can be created by using `blurb-it <https://blurb-it.herokuapp.com/>`_, +or the :pypi:`blurb` tool and its ``blurb add`` command. + +If you are unable to use the tool, then you can create the ``NEWS`` entry file +manually. The ``Misc/NEWS.d`` directory contains a sub-directory named +``next``, which contains various sub-directories representing classifications +for what was affected (for example, ``Misc/NEWS.d/next/Library`` for changes relating +to the standard library). The file name itself should be in the format +``<datetime>.gh-issue-<issue-number>.<nonce>.rst``: + +* ``<datetime>`` is today's date joined with a hyphen (``-``) to your current + local time, in the ``YYYY-MM-DD-hh-mm-ss`` format (for example, ``2017-05-27-16-46-23``). +* ``<issue-number>`` is the issue number the change is for (for example, ``12345`` + for ``gh-issue-12345``). +* ``<nonce>`` is a unique string to guarantee that the file name is + unique across branches (for example, ``Yl4gI2``). It is typically six characters + long, but it can be any length of letters and numbers. Its uniqueness + can be satisfied by typing random characters on your keyboard. + +As a result, a file name can look something like +``Misc/NEWS.d/next/Library/2017-05-27-16-46-23.gh-issue-12345.Yl4gI2.rst``. + +How to write a NEWS entry +------------------------- + +All ``NEWS`` entries end up being part of the changelog. +The changelog contains *a lot* of entries, +and its intended audience is mainly users, not core devs and contributors. +Take this into consideration when wording your ``NEWS`` entry. +Describe the user-visible effects of your change succinctly and accurately; +avoid long technical elaborations, digressions, and do not expect or require +the reader to have read the actual diff for the change. + +The contents of a ``NEWS`` file should be valid reStructuredText. An 80 character +column width should be used. There is no indentation or leading marker in the +file (for example, ``-``). There is also no need to start the entry with the issue +number since it is part of the file name. You can use +:ref:`inline markups <rest-inline-markup>` too. Here is an example of a ``NEWS`` +entry: + +.. code-block:: rst + + Fix warning message when :func:`os.chdir` fails inside + :func:`test.support.temp_cwd`. Contributed by Chris Jerdonek. + +The inline Sphinx roles like :rst:role:`:func: <py:func>` can be used help readers +find more information. You can build HTML and verify that the +link target is appropriate by using :ref:`make html <building-using-make>`. + + +Copyrights +========== + +Copyright notices are optional and informational, as international treaties +have abolished the requirement for them to protect copyrights. +However, they still serve an informative role. + +According to the US Copyright Office, valid copyright notices include the year +of first publication of the work. For example: + + Copyright (C) 2001 Python Software Foundation. + +Updating notices to add subsequent years is unnecessary and such PRs will be +closed. + +See also `python/cpython#126133 +<https://github.com/python/cpython/issues/126133#issuecomment-2460824052>`__. + + +.. _typo-fixes: + +Typo fixes +========== + +Fixing typos and grammatical errors in documentation is a +contribution that does not require a linked issue. The most appropriate +place for such fixes are the :cpy-file:`Doc/` (end-user documentation) +and :cpy-file:`InternalDocs/` directories. + + +Keep typo-fix PRs **small and focused**. Large PRs that touch many unrelated files +notify a large number of reviewers unnecessarily and are harder to review. +Large typo-fix PRs, or PRs touching directories outside those listed above, +may be closed with a reference to this section. + + +.. _patchcheck: + +``patchcheck`` +============== + +``patchcheck`` is a simple automated checklist for changes in progress that +guides a developer through common checks. To run ``patchcheck``: + +On *Unix* (including macOS):: + + make patchcheck + +On *Windows* (after any successful build): + +.. code-block:: dosbatch + + .\python.bat Tools\patchcheck\patchcheck.py + +The automated checklist runs through: + +* Has the documentation been updated? +* Has the test suite been updated? +* Has an entry under ``Misc/NEWS.d/next`` been added? + (using `blurb-it <https://blurb-it.herokuapp.com/>`__, + or the :pypi:`blurb` tool) +* Has ``configure`` been regenerated, if necessary? +* Has ``pyconfig.h.in`` been regenerated, if necessary? + +This will help you remember things that you need +to check before submitting a complete pull request. + + +.. _good-commits: + +Making good commits +=================== + +Each feature or bugfix should be addressed by a single pull request, +and for each pull request there may be several commits. In particular: + +* Do **not** fix more than one issue in the same commit (except, + of course, if one code change fixes all of them). +* Do **not** do cosmetic changes to unrelated code in the same + commit as some feature/bugfix. + +Commit messages should follow the following structure:: + + Make the spam module more spammy + + The spam module sporadically came up short on spam. This change + raises the amount of spam in the module by making it more spammy. + +The first line or sentence is meant to be a dense, to-the-point explanation +of what the purpose of the commit is. The imperative form (used in the example +above) is strongly preferred to a descriptive form such as 'the spam module is +now more spammy'. Use ``git log --oneline`` to see existing title lines. +Furthermore, the first line should not end in a period. + +If this is not enough detail for a commit, a new paragraph(s) can be added +to explain in proper depth what has happened (detail should be good enough +that a core team member reading the commit message understands the +justification for the change). + +Check :ref:`the Git bootcamp <accepting-and-merging-a-pr>` for further +instructions on how the commit message should look like when merging a pull +request. + +.. note:: + `How to Write a Git Commit Message <https://cbea.ms/git-commit/>`__ + is a nice article that describes how to write a good commit message. + + +.. _cla: + +Licensing +========= + +To accept your change we must have your formal approval for distributing +your work under the `PSF license`_. Therefore, you need to sign a +`contributor agreement`_ which allows the `Python Software Foundation`_ to +license your code for use with Python (you retain the copyright). + +.. note:: + You only have to sign this document once, it will then apply to all + your further contributions to Python. + +Here are the steps needed in order to sign the CLA: + +1. Create a change and submit it as a pull request. + +2. When ``python-cla-bot`` comments on your pull request that commit + authors are required to sign a Contributor License Agreement, click + on the button in the comment to sign it. Log in with GitHub, + click "Authorize Python CLA Bot", and then click "Sign". + +3. After signing, the comment by ``python-cla-bot`` will update to + indicate that "all commit authors signed the Contributor License + Agreement". + +.. _PSF license: https://docs.python.org/dev/license.html#terms-and-conditions-for-accessing-or-otherwise-using-python +.. _contributor agreement: https://www.python.org/psf/contrib/ +.. _contributor form: https://www.python.org/psf/contrib/contrib-form/ +.. _Python Software Foundation: https://www.python.org/psf-landing/ + +Why do I need to sign the CLA again? +------------------------------------ + +Sometimes the CLA bot asks you to sign the CLA for a backport PR, +when you've already signed it for the original PR. +This is because you need to sign the CLA for all the email addresses you commit +with. + +This can happen when you've `configured your Git client +<https://docs.github.com/en/account-and-profile/how-tos/email-preferences/setting-your-commit-email-address>`__ +with one email address, and signed the CLA with this, but have +`configured your GitHub account <https://github.com/settings/emails>`__ +with another primary email +(often this is the private ``id+username@users.noreply.github.com`` address). + +1. In the original PR, the CLA bot verifies all the emails in the commits have + signed the CLA. + +2. We then squash merge the PR, which creates a single new commit using the + author's primary email. This can be different from the one you originally + committed with. + +3. Backports often only have this new single commit. + The CLA bot then checks if the primary email has signed the CLA. + +4. The solution is to click the :guilabel:`CLA not signed -- click to sign` + button in the backport PR. + +.. tip:: Run ``git config user.email`` to see your Git client config, + and append ``.patch`` to a PR URL to see the emails used for its commits: + + * https://github.com/python/cpython/pull/1 + * https://github.com/python/cpython/pull/1.patch + + +Submitting +========== + +Once you are satisfied with your work you will want to commit your +changes to your branch. In general you can run ``git commit -a`` and +that will commit everything. You can always run ``git status`` to see +what changes are outstanding. + +When all of your changes are committed (that is, ``git status`` doesn't +list anything), you will want to push your branch to your fork:: + + git push origin <branch name> + +This will get your changes up to GitHub. + +Now you want to +`create a pull request from your fork +<https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork>`__. +If this is a pull request in response to a pre-existing issue on the +`issue tracker`_, please make sure to reference the issue number using +``gh-NNNNN:`` prefix in the pull request title and ``#NNNNN`` in the description. + +If this is a pull request for an unreported issue (assuming you already +performed a search on the issue tracker for a pre-existing issue), create a +new issue and reference it in the pull request. Please fill in as much +relevant detail as possible to prevent reviewers from having to delay +reviewing your pull request because of lack of information. + +If this issue is so simple that there's no need for an issue to track +any discussion of what the pull request is trying to solve (for example, fixing a +spelling mistake), then the pull request needs to have the "skip issue" label +added to it by someone with commit access. + +Your pull request may involve several commits as a result of addressing code +review comments. Please keep the commit history in the pull request intact by +not squashing, amending, or anything that would require a force push to GitHub. +A detailed commit history allows reviewers to view the diff of one commit to +another so they can easily verify whether their comments have been addressed. +The commits will be squashed when the pull request is merged. + + +Converting an existing patch from b.p.o to GitHub +================================================= + +When a patch exists in the `issue tracker`_ that should be converted into a +GitHub pull request, please first ask the original patch author to prepare +their own pull request. If the author does not respond after a week, it is +acceptable for another contributor to prepare the pull request based on the +existing patch. In this case, both parties should sign the :ref:`CLA <cla>`. +When creating a pull request based on another person's patch, provide +attribution to the original patch author by adding "Co-authored-by: +Author Name <email_address> ." to the pull request description and commit message. +See `the GitHub article <https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors>`__ +on how to properly add the co-author info. + +See also :ref:`Applying a Patch to Git <git_from_patch>`. + + +.. _reviewing-prs: + +Reviewing +========= + +To begin with, please be patient! There are many more people +submitting pull requests than there are people capable of reviewing +your pull request. Getting your pull request reviewed requires a +reviewer to have the spare time and motivation to look at your pull +request (we cannot force anyone to review pull requests and no one is +employed to look at pull requests). If your pull request has not +received any notice from reviewers (that is, no comment made) after one +month, first "ping" the issue on the `issue tracker`_ to remind the +subscribers that the pull request needs a review. +If you don't get a response within a week after pinging the issue, +you can post on the `Core Development Discourse category`_ +to ask for someone to review your pull request. + +When someone does manage to find the time to look at your pull request +they will most likely make comments about how it can be improved +(don't worry, even core team members of Python have their pull requests sent +back to them for changes). It is then expected that you update your +pull request to address these comments, and the review process will +thus iterate until a satisfactory solution has emerged. + +.. _how-to-review-a-pull-request: + +How to review a pull request +---------------------------- + +One of the bottlenecks in the Python development +process is the lack of code reviews. +If you browse the bug tracker, you will see that numerous issues +have a fix, but cannot be merged into the main source code repository, +because no one has reviewed the proposed solution. +Reviewing a pull request can be just as informative as providing a +pull request and it will allow you to give constructive comments on +another developer's work. This guide provides a checklist for +submitting a code review. It is a common misconception that in order +to be useful, a code review has to be perfect. This is not the case at +all! It is helpful to just test the pull request and/or play around with the +code and leave comments in the pull request or issue tracker. + +1. If you have not already done so, get a copy of the CPython repository + by following the :ref:`setup guide <setup>`, build it and run the tests. + +2. Check the bug tracker to see what steps are necessary to reproduce + the issue and confirm that you can reproduce the issue in your version + of the Python REPL (the interactive shell prompt), which you can launch + by executing ./python inside the repository. + +3. Checkout and apply the pull request (Please refer to the instruction + :ref:`git_pr`) + +4. If the changes affect any C file, run the build again. + +5. Launch the Python REPL (the interactive shell prompt) and check if + you can reproduce the issue. Now that the pull request has been applied, + the issue should be fixed (in theory, but mistakes do happen! A good review + aims to catch these before the code is merged into the Python repository). + You should also try to see if there are any corner cases in this or related + issues that the author of the fix may have missed. + +6. If you have time, run the entire test suite. If you are pressed for time, + run the tests for the module(s) where changes were applied. + However, please be aware that if you are recommending a pull request as + 'merge-ready', you should always make sure the entire test suite passes. + +Leaving a pull request review on GitHub +--------------------------------------- + +When you review a pull request, you should provide additional details and context +of your review process. + +Instead of simply "approving" the pull request, leave comments. For example: + +#. If you tested the PR, report the result and the system and version tested on, + such as 'Windows 10', 'Ubuntu 16.4', or 'Mac High Sierra'. + +#. If you request changes, try to suggest how. + +#. Comment on what is "good" about the pull request, not just the "bad". Doing + so will make it easier for the PR author to find the good in your comments. + +#. Look at any failures in CI on the current PR. See :ref:`"Keeping CI green" + <keeping-ci-green>` below for simple things you can do to help move the PR forward. + +.. _dismissing-review-from-another-core-developer: + +Dismissing review from another core team member +----------------------------------------------- + +A core team member can dismiss another team member's review if they confirmed +that the requested changes have been made. When a core team member has assigned +the PR to themselves, then it is a sign that they are actively looking after +the PR, and their review should not be dismissed. + +.. _keeping-ci-green: + +Keeping continuous integration green +==================================== + +Our change management workflows generally won't allow merging PRs with +failures. Therefore, if you see a CI failure on a PR, have a look +what it is about. + +Usually the failure will be directly related to the changes in the current +PR. If you happen to have any insight into the failure, let the author know +in a review comment. CI runs sometimes generate thousands of lines of output. +Even something as simple as finding the traceback and putting it in the +comment will be helpful to the PR author. + +If the failure doesn't look related to the change you're looking at, check +if it's not present on the `Release Status`_ Buildbot dashboard as well. +If so, that means the failure was introduced in a prior change. Using Buildbot's +UI you can find which PR introduced the issue and comment that it +affects other PRs. + +If you still don't see where the failure originates from, check for +a "This branch is out-of-date with the base branch" sign next to the +list of executed checks. Clicking :guilabel:`Update branch` next to this message +will merge in the latest changes from the base branch into the PR. + +If this still doesn't help with the failure on the PR, you can try +to re-run that particular failed check. Go to the red GitHub Action job, +click on the :guilabel:`Re-run jobs` button on the top right, and select +:guilabel:`Re-run failed jobs`. The button will only be present when all other +jobs finished running. + +Re-running failed jobs shouldn't be your first instinct but it is occasionally +helpful because distributed systems can have intermittent failures, and +some of our unit tests are sensitive to overloaded virtual machines. +If you identify such flaky behavior, look for an issue in the `issue tracker`_ +that describes this particular flakiness. Create a new issue if you can't +find one. + +:guilabel:`Update branch` button +================================ + +You can click on the :guilabel:`Update branch` button to merge the latest +changes from the base branch (usually ``main``) into the PR. +This is useful to :ref:`keep the CI green <keeping-ci-green>` for old PRs, +or to check if a CI failure has been fixed in the base branch. + +If the PR is very old, it may be useful to update the branch before merging to +ensure that the PR does not fail any CI checks that were added or changed since +CI last ran. + +Do not click :guilabel:`Update branch` without a good reason because it notifies +everyone watching the PR that there are new changes, when there are not, +and it uses up limited CI resources. + +Committing/rejecting +==================== + +Once your pull request has reached an acceptable state (and thus considered +"accepted"), it will either be merged or rejected. If it is rejected, please +do not take it personally! Your work is still appreciated regardless of whether +your pull request is merged. Balancing what *does* and *does not* go into +Python is tricky and we simply cannot accept everyone's contributions. + +But if your pull request is merged it will then go into Python's +:abbr:`VCS (version control system)` to be released +with the next feature release of Python. It may also be backported to older +versions of Python as a bugfix if the core team member doing the merge believes +it is warranted. + + +Crediting +========= + +Non-trivial contributions are often credited in What's New in Python +and a contributions's news entry as well. + +.. _issue tracker: https://github.com/python/cpython/issues +.. _Core Development Discourse category: https://discuss.python.org/c/core-dev/23 +.. _Release Status: https://buildbot.python.org/all/#/release_status diff --git a/getting-started/setup-building.rst b/getting-started/setup-building.rst new file mode 100644 index 0000000000..6acc7ee578 --- /dev/null +++ b/getting-started/setup-building.rst @@ -0,0 +1,1311 @@ +.. _setup-building: +.. _setup: + +================== +Setup and building +================== + +.. include:: /include/activate-tab.rst + +.. highlight:: console + +These instructions cover how to get a working copy of the source code and a +compiled version of the CPython interpreter (CPython is the version of Python +available from https://www.python.org/). It also gives an overview of the +directory structure of the CPython source code. + +Alternatively, if you have `Docker <https://www.docker.com/>`__ installed you +might want to use `our official images +<https://gitlab.com/python-devs/ci-images/blob/main/README.md>`__. These +contain the latest releases of several Python versions, along with Git head, +and are provided for development and testing purposes only. + +.. seealso:: + + The :ref:`quick-reference` gives brief summary of the process from + installing Git to submitting a pull request. + +.. _vcsetup: + +Install Git +=========== + +.. c_install_git_start + +CPython is developed using `Git <https://git-scm.com>`__ for version control. The Git +command line program is named ``git``; this is also used to refer to Git +itself. Git is easily available for all common operating systems. + +- **Install** + + As the CPython repo is hosted on GitHub, please refer to either the + `GitHub setup instructions <https://docs.github.com/en/get-started/getting-started-with-git/set-up-git>`__ + or the `Git project instructions <https://git-scm.com>`__ for step-by-step + installation directions. You may also want to consider a graphical client + such as `TortoiseGit <https://tortoisegit.org/>`__ or + `GitHub Desktop <https://github.com/apps/desktop>`__. + +- **Configure** + + Configure :ref:`your name and email <set-up-name-email>` and create + `an SSH key <https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account>`__ + as this will allow you to interact with GitHub without typing a username + and password each time you execute a command, such as ``git pull``, + ``git push``, or ``git fetch``. On Windows, you should also + :ref:`enable autocrlf <autocrlf>`. + +.. c_install_git_end + +.. _checkout: + +Get the source code +=================== + +.. c_get_source_code_start + +The CPython repo is hosted on GitHub. To get a copy of the source code you should +:ref:`fork the Python repository on GitHub <fork-cpython>`, :ref:`create a local +clone of your personal fork, and configure the remotes <clone-your-fork>`. + +You will only need to execute these steps once per machine: + +1. Go to https://github.com/python/cpython. + +2. Press :guilabel:`Fork` on the top right. + +3. When asked where to fork the repository, choose to fork it to your username. + +4. Your fork will be created at :samp:`https://github.com/{<username>}/cpython`. + +5. Clone your GitHub fork (replace ``<username>`` with your username):: + + $ git clone git@github.com:<username>/cpython.git + + (You can use both SSH-based or HTTPS-based URLs.) + +.. Step 6 and 7 are are duplicated in bootcamp as well. + Please update these steps in both places. + +6. Add an ``upstream`` remote, then configure ``git`` + to pull ``main`` from ``upstream`` and always push to ``origin``:: + + $ cd cpython + $ git remote add upstream https://github.com/python/cpython + $ git config --local branch.main.remote upstream + $ git remote set-url --push upstream git@github.com:<your-username>/cpython.git + +7. Verify that your setup is correct:: + + $ git remote -v + origin git@github.com:<your-username>/cpython.git (fetch) + origin git@github.com:<your-username>/cpython.git (push) + upstream https://github.com/python/cpython (fetch) + upstream git@github.com:<your-username>/cpython.git (push) + $ git config branch.main.remote + upstream + +For more information about these commands see +:ref:`Git Bootcamp and Cheat Sheet <git-boot-camp>`. + +If you did everything correctly, you should now have a copy of the code +in the ``cpython`` directory and two remotes that refer to your own GitHub fork +(``origin``) and the official CPython repository (``upstream``). + +.. XXX move the text below in pullrequest + +If you want a working copy of an already-released version of Python, +that is, a version in :ref:`maintenance mode <maintbranch>`, you can checkout +a release branch. For instance, to checkout a working copy of Python 3.13, +do ``git switch 3.13``. + +You will need to re-compile CPython when you do such an update. + +Do note that CPython will notice that it is being run from a working copy. +This means that if you edit CPython's source code in your working copy, +changes to Python code will be picked up by the interpreter for immediate +use and testing. (If you change C code, you will need to recompile the +affected files as described below.) + +Changes for the documentation can be made from the same repository; see +:ref:`documenting`. + +.. _install-pre-commit: + +Install pre-commit as a Git hook +-------------------------------- + +To make sure your code is linted correctly, we recommend setting up +`pre-commit <https://pre-commit.com#installation>`__ as a Git hook:: + + $ pre-commit install --allow-missing-config + pre-commit installed at .git/hooks/pre-commit + +Now pre-commit will run automatically on ``git commit``. + +.. c_get_source_code_end + +.. _compiling: + +Compile and build +================= + +.. c_compile_and_build_start + +CPython provides several compilation flags which help with debugging various +things. While all of the known flags can be found in the +``Misc/SpecialBuilds.txt`` file, the most critical one is the ``Py_DEBUG`` flag +which creates what is known as a "pydebug" build. This flag turns on various +extra sanity checks which help catch common issues. The use of the flag is so +common that turning on the flag is a basic compile option. + +You should always develop under a pydebug build of CPython (the only instance of +when you shouldn't is if you are taking performance measurements). Even when +working only on pure Python code the pydebug build provides several useful +checks that one should not skip. + +.. seealso:: The effects of various configure and build flags are documented in + the `Python configure docs <https://docs.python.org/dev/using/configure.html>`__. + +.. _unix-compiling: + +Unix +---- + +The core CPython interpreter only needs a C compiler to be built, +however, some of the extension modules will need development headers +for additional libraries (such as the ``zlib`` library for compression). +Depending on what you intend to work on, you might need to install these +additional requirements so that the compiled interpreter supports the +desired features. + +If you want to install these optional dependencies, consult the +:ref:`build-dependencies` section below. + +If you don't need to install them, the basic steps for building Python +for development is to configure it and then compile it. + +Configuration is typically:: + + $ ./configure --with-pydebug + +More flags are available to ``configure``, but this is the minimum you should +do to get a pydebug build of CPython. + +.. note:: + You might need to run ``make clean`` before or after re-running ``configure`` + in a particular build directory. + +Once ``configure`` is done, you can then compile CPython with:: + + $ make -s -j $(nproc) + +This will build CPython with only warnings and errors being printed to +stderr. The ``-j`` argument means that :program:`make` will concurrently run +tasks, limiting the number of parallel jobs to the number of CPU cores in your +computer. You can adjust the number passed to the ``-j`` flag to change +the limit on parallel jobs, which can trade RAM usage versus compilation time. + +At the end of the build you should see a success message, followed +by a list of extension modules that haven't been built because their +dependencies were missing: + +.. code-block:: none + + The necessary bits to build these optional modules were not found: + _gdbm + To find the necessary bits, look in configure.ac and config.log. + + Checked 106 modules (31 built-in, 74 shared, 0 n/a on macosx-13.4-arm64, 0 disabled, 1 missing, 0 failed on import) + +If the build failed and you are using a C89 or C99-compliant compiler, +please open a bug report on the `issue tracker`_. + +If you decide to :ref:`build-dependencies`, you will need to re-run both +``configure`` and ``make``. + +.. _mac-python.exe: + +Once CPython is done building you will then have a working build +that can be run in-place; ``./python`` on most machines (and what is used in +all examples), ``./python.exe`` wherever a case-insensitive filesystem is used +(for example, on macOS by default), in order to avoid conflicts with the ``Python`` +directory. There is normally no need to install your built copy +of Python! The interpreter will realize where it is being run from +and thus use the files found in the working copy. If you are worried +you might accidentally install your working copy build, you can add +``--prefix=/tmp/python`` to the configuration step. When running from your +working directory, it is best to avoid using the ``--enable-shared`` flag +to ``configure``; unless you are very careful, you may accidentally run +with code from an older, installed shared Python library rather than from +the interpreter you just built. + + +Clang +^^^^^ + +If you are using clang_ to build CPython, some flags you might want to set to +quiet some standard warnings which are specifically superfluous to CPython are +``-Wno-unused-value -Wno-empty-body -Qunused-arguments``. You can set your +``CFLAGS`` environment variable to these flags when running ``configure``. + +If you are using clang_ with ccache_, turn off the noisy +``parentheses-equality`` warnings with the ``-Wno-parentheses-equality`` flag. +These warnings are caused by clang not having enough information to detect +that extraneous parentheses in expanded macros are valid, because the +preprocessing is done separately by ccache. + +If you are using LLVM 2.8, also use the ``-no-integrated-as`` flag in order to +build the :py:mod:`ctypes` module (without the flag the rest of CPython will +still build properly). + + +Optimization +^^^^^^^^^^^^ + +If you are trying to improve CPython's performance, you will probably want +to use an optimized build of CPython. It can take a lot longer to build CPython +with optimizations enabled, and it's usually not necessary to do so. However, +it's essential if you want accurate benchmark results for a proposed performance +optimization. + +For an optimized build of Python, use +``configure --enable-optimizations --with-lto``. +This sets the default make targets up to enable Profile Guided Optimization (PGO) +and may be used to auto-enable Link Time Optimization (LTO) on some platforms. +See :option:`python:--enable-optimizations` and :option:`python:--with-lto` +to learn more about these options. + +.. code:: console + + $ ./configure --enable-optimizations --with-lto + +.. _windows-compiling: + +Windows +------- + +.. note:: If you are using the Windows Subsystem for Linux (WSL), + :ref:`clone the repository <checkout>` from a native Windows shell program + like PowerShell or the ``cmd.exe`` command prompt, + and use a build of Git targeted for Windows, + for example, the `Git for Windows download from the official Git website`_. + Otherwise, Visual Studio will not be able to find all the project's files + and will fail the build. + +For a concise step by step summary of building Python on Windows, +you can read `Victor Stinner's guide`_. + +All supported versions of Python can be built +using Microsoft Visual Studio 2017 or later. +You can download and use any of the free or paid versions of `Visual Studio`_. + +When installing it, select the :guilabel:`Python development` workload +and the optional :guilabel:`Python native development tools` component +to obtain all of the necessary build tools. +You can find Git for Windows on the :guilabel:`Individual components` tab +if you don't already have it installed. + +.. note:: If you want to build MSI installers, be aware that the build toolchain + for them has a dependency on the Microsoft .NET Framework Version 3.5 + (which may not be included on recent versions of Windows, such as Windows 10). + If you are building on a recent Windows version, use the Control Panel + (:menuselection:`Programs --> Programs and Features --> Turn Windows Features on or off`) + and ensure that the entry + :guilabel:`.NET Framework 3.5 (includes .NET 2.0 and 3.0)` is enabled. + +Your first build should use the command line to ensure any external dependencies +are downloaded: + +.. code-block:: batch + + PCbuild\build.bat -c Debug + +The above command line build uses the ``-c Debug`` argument +to build in the ``Debug`` configuration, +which enables checks and assertions helpful for developing Python. +By default, it builds in the ``Release`` configuration +and for the 64-bit ``x64`` platform rather than 32-bit ``Win32``; +use ``-c`` and ``-p`` to control build config and platform, respectively. + +After this build succeeds, you can open the ``PCbuild\pcbuild.sln`` solution +in the Visual Studio IDE to continue development, if you prefer. +When building in Visual Studio, +make sure to select build settings that match what you used with the script +(the :guilabel:`Debug` configuration and the :guilabel:`x64` platform) +from the dropdown menus in the toolbar. + +.. note:: + + If you need to change the build configuration or platform, + build once with the ``build.bat`` script set to those options first + before building with them in VS to ensure all files are rebuilt properly, + or you may encounter errors when loading modules that were not rebuilt. + + Avoid selecting the ``PGInstrument`` and ``PGUpdate`` configurations, + as these are intended for PGO builds and not for normal development. + +You can run the build of Python you've compiled with: + +.. code-block:: batch + + PCbuild\amd64\python_d.exe + +See the `PCBuild readme`_ for more details on what other software is necessary +and how to build. + +.. _Victor Stinner's guide: https://web.archive.org/web/20220907075854/https://cpython-core-tutorial.readthedocs.io/en/latest/build_cpython_windows.html +.. _Visual Studio: https://visualstudio.microsoft.com/ +.. _PCBuild readme: https://github.com/python/cpython/blob/main/PCbuild/readme.txt +.. _Git for Windows download from the official Git website: https://git-scm.com/download/win + + +.. _wasi-compiling: + +WASI +---- + +WASI_ is a system interface standard for WebAssembly_. Through a combination of +C compilers that can target WebAssembly and `wasi-libc`_ providing +POSIX-compatible shims for WASI, it's possible for CPython to run on a WASI +host/runtime as a *guest*. + +.. note:: + + The instructions below assume a Unix-based OS due to cross-compilation for + CPython being designed for ``./configure`` / ``make``. + +To build for WASI, you will need to cross-compile CPython. This requires a C +compiler just like building for :ref:`Unix <unix-compiling>` as well as: + +1. A C compiler that can target WebAssembly (for example, `WASI SDK`_) +2. A WASI host/runtime (for example, Wasmtime_) +3. A system install of Python 3.11 or newer to run the build scripts + +All of this is provided in the WASI :ref:`dev container <using-a-container>` +(which you can select as an alternative container when using a +:ref:`codespace <codespaces-whats-codespaces>`). You can also use what's +installed in the container as a reference of what versions of these tools are +known to work. + +.. note:: + + CPython has only been verified with the certain tools for WASI. Using + other compilers, hosts, or WASI versions *should* work, but the tools + and their versions specified in the container and build scripts are + tested via a :ref:`buildbot <buildbots>`. + +Building for WASI requires doing a cross-build where you have a *build* Python +to help produce a WASI build of CPython (technically it's a "host x host" +cross-build because the build Python is also the target Python while the host +build is the WASI build). This means you effectively build CPython twice: once +to have a version of Python for the build system to use and another that's the +build you ultimately care about (that is, the build Python is not meant for use +by you directly, only the build system). + +The easiest way to get a debug build of CPython for WASI is to run the +following command with Python 3.11 or newer: + +.. tab:: Python 3.15+ + + .. code-block:: shell + + python Platforms/WASI build --quiet -- --config-cache --with-pydebug + +.. tab:: Python 3.14 + + .. code-block:: shell + + python Tools/wasm/wasi build --quiet -- --config-cache --with-pydebug + +.. tab:: Python 3.13 + + .. code-block:: shell + + python Tools/wasm/wasi.py build --quiet -- --config-cache --with-pydebug + +That single command will configure and build both the build Python and the +WASI build in the ``cross-build/`` directory. + +You can also do each configuration and build step separately; the command above +is a convenience wrapper around the following commands: + +.. tab:: Python 3.15+ + + .. code-block:: shell + + $ python Platforms/WASI configure-build-python --quiet -- --config-cache --with-pydebug + $ python Platforms/WASI make-build-python --quiet + $ python Platforms/WASI configure-host --quiet -- --config-cache + $ python Platforms/WASI make-host --quiet + +.. tab:: Python 3.14 + + .. code-block:: shell + + $ python Tools/wasm/wasi configure-build-python --quiet -- --config-cache --with-pydebug + $ python Tools/wasm/wasi make-build-python --quiet + $ python Tools/wasm/wasi configure-host --quiet -- --config-cache + $ python Tools/wasm/wasi make-host --quiet + +.. tab:: Python 3.13 + + .. code-block:: shell + + $ python Tools/wasm/wasi.py configure-build-python --quiet -- --config-cache --with-pydebug + $ python Tools/wasm/wasi.py make-build-python --quiet + $ python Tools/wasm/wasi.py configure-host --quiet -- --config-cache + $ python Tools/wasm/wasi.py make-host --quiet + +.. note:: + + The ``configure-host`` command infers the use of ``--with-pydebug`` from the + build Python. + +Running the separate commands after ``build`` is useful if you, for example, +only want to run the ``make-host`` step after making code changes. + +Once everything is complete, there will be a +``cross-build/wasm32-wasip1/python.sh`` helper file which you can use to run the +``python.wasm`` file (see the output from the ``configure-host`` subcommand): + +.. code-block:: shell + + cross-build/wasm32-wasip1/python.sh --version + +You can also use ``Makefile`` targets and they will work as expected thanks to +the ``HOSTRUNNER`` environment variable having been set to a similar value as +used in ``python.sh``: + +.. code-block:: shell + + make -C cross-build/wasm32-wasip1 test + +.. note:: + + WASI uses a *capability-based* security model. This means that the WASI host + does not give full access to your machine unless you tell it to. This + also means things like files can end up being mapped to a different path + inside the WASI host. So, if you try passing a file path to + ``python.wasm``/ ``python.sh``, it needs to match the path **inside** the + WASI host, not the path on your machine (much like using a container). + +.. _WASI: https://wasi.dev +.. _wasi-libc: https://github.com/WebAssembly/wasi-libc +.. _WASI SDK: https://github.com/WebAssembly/wasi-sdk +.. _wasmtime: https://wasmtime.dev +.. _WebAssembly: https://webassembly.org + + +Emscripten +---------- + +Emscripten_ is a complete open-source compiler toolchain. It compiles C/C++ code +into WebAssembly_/JavaScript executables, for use in JavaScript runtimes, +including browsers and Node.js. + +.. note:: + + The instructions below assume a Unix-based OS due to cross-compilation for + CPython being designed for ``./configure`` / ``make``. + +To build for Emscripten, you will need to cross-compile CPython. This requires a +C compiler just like building for :ref:`Unix <unix-compiling>`. The Node Version +Manager (``nvm``) must also be on your path. + +Building for Emscripten requires doing a cross-build where you have a *build* +Python to help produce an Emscripten build of CPython. This means you build +CPython twice: once to have a version of Python for the build system to use and +another that's the build you ultimately care about (that is, the build Python is +not meant for use by you directly, only the build system). + +The simplest way to build Emscripten is to run: + +.. code-block:: sh + + python3 Platforms/emscripten build all --emsdk-cache=./cross-build/emsdk + +This will: + +1. Build a copy of Python that can run on the host machine (the "build" python); +2. Download a copy of the Emscripten SDK matching the version required by the + version of Python being compiled; +3. Ensure that a required version of Node is installed; +4. Download the code for all the binary dependencies of Python (such as + ``libFFI`` and ``xz``), and compile them for Emscripten; and +5. Build a copy of Python that can run on Emscripten (the "host" python). + +If you omit the ``--emsdk-cache`` environment variable, the build script will +assume that the current environment has the Emscripten tools available. You are +responsible for downloading and activating those tools in your environment. The +version of Emscripten and Node that is required to build Python is defined in +the :cpy-file:`Platforms/emscripten/config.toml` configuration file. + +There are three environment variables that can be used to control the operation of +the ``Platforms/emscripten`` build script: + +* ``EMSDK_CACHE`` controls the location of the emscripten SDK. You can use this instead + environment variable instead of passing the ``--emsdk-cache`` flag. +* ``CACHE_DIR`` defines the location where downloaded artefacts, such + as precompiled ``libFFI`` and ``xz`` binaries, will be stored. +* ``CROSS_BUILD_DIR`` defines the name of the ``cross-build`` directory + that will be used for builds. This can be useful if you need to maintain + builds of multiple versions of Python. + +It is possible (but not necessary) to enable ``ccache`` for Emscripten builds +by setting the ``EM_COMPILER_WRAPPER`` environment, but this step will only +take effect if it is done **after** ``emsdk_env.sh`` is sourced (otherwise, the +sourced script removes the environment variable): + +.. code-block:: sh + + export EM_COMPILER_WRAPPER=ccache + +To get a debug build of CPython for Emscripten, use: + +.. code-block:: shell + + python3 Platforms/emscripten build all -- --with-pydebug + +That single command will configure and build both the build Python and the +Emscripten build in ``cross-build/build`` and +``cross-build/wasm32-emscripten/build/python/``, respectively. + +The ``Platforms/emscripten`` script has a number of other entry points that allow for +fine-grained execution of each part of an iOS build; run ``python3 +Platforms/emscripten --help`` for more details. + +Once the build is complete, you can run Python code using: + +.. code-block:: shell + + python3 Platforms/emscripten run ./path/to/script.py + +You can run the CPython test suite using: + +.. code-block:: shell + + python3 Platforms/emscripten run --test + +Additional instructions for running the resulting builds (through Node.js and/or +through web browsers) are available in the CPython repository at +:cpy-file:`Platforms/emscripten/README.md`. + +.. _Emscripten: https://emscripten.org/ +.. _WebAssembly: https://webassembly.org + +Android +------- + +Build and test instructions for Android are maintained in the CPython repository +at :cpy-file:`Platforms/Android/README.md`. + +iOS +--- + +Compiling Python for iOS requires a macOS machine, on a recent version of macOS, +running a recent version of Xcode. Apple expects developers to keep their +operating systems and tools up-to-date; if your macOS version is more than one +major release out of date, or your Xcode version is more than a couple of minor +versions out of date, you'll likely encounter difficulties. It is not possible +to compile for iOS using Windows or Linux as a build machine. + +A complete build for Python on iOS requires compiling CPython four times: once for +macOS; then once for each of the three underlying platforms used by iOS: + +* An ARM64 device (an iPhone or iPad); +* An ARM64 simulator running on a recent macOS machine; and +* An x86_64 simulator running on older macOS machine. + +You will need an existing Python 3 interpreter to build Python. From the root of +a CPython code checkout, run the following: + +.. tab:: Python 3.15+ + + .. code-block:: shell + + $ python3 Platforms/Apple build iOS all + +.. tab:: Python 3.14 + + .. code-block:: shell + + $ python3 Apple build iOS all + +.. tab:: Python 3.13 + + Python 3.13 requires explicitly invoking ``configure`` and ``make`` for each + platform. For example, to build for the ARM64 simulator, run: + + .. code-block:: shell + + $ export PATH="$(pwd)/iOS/Resources/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin" + $ ./configure \ + LIBLZMA_CFLAGS="-Ipath/to/xz/include" \ + LIBLZMA_LIBS="-Lpath/to/xz/lib -llzma" \ + BZIP2_CFLAGS="-Ipath/to/bzip2/include" \ + BZIP2_LIBS="-Lpath/to/bzip2/lib -lbz2" \ + LIBFFI_CFLAGS="-Ipath/to/libffi/include" \ + LIBFFI_LIBS="-Lpath/to/libffi/lib -lffi" \ + --with-openssl="path/to/openssl" \ + --host=arm64-apple-ios-simulator \ + --build=arm64-apple-darwin \ + --with-build-python=path/to/python3.13 \ + --enable-framework + $ make -j4 all + $ make install + + The ``--host`` argument should be one of ``arm64-apple-ios-simulator``, + ``x64_64-apple-ios-simulator`` or ``arm64-apple-ios``. Your ``PATH`` should + be kept to a minimum to avoid inadvertently linking ARM64 macOS binaries into + your iOS project. You must specify a path to pre-compiled binary dependencies. + + Once you have built an Apple Framework for each architecture, you will need + to manually construct an XCframework. + +This will: + +1. Build a copy of Python that can run on macOS (the "build" python); +2. Download pre-compiled binaries for dependencies of CPython (such as + ``libFFI`` and ``xz``) +3. Build a copy of Python for each supported iOS architecture (x86_64 simulator, + ARM64 simulator, and ARM64 device); and +4. Generate a release artefact for iOS + +Once this build completes, the ``cross-build/iOS`` folder will contain a +``Python.xcframework``, and the ``cross-build/dist`` folder will contain a +release tarball. + +To run the test suite on iOS, run: + +.. tab:: Python 3.15+ + + .. code-block:: shell + + $ python3 Platforms/Apple test iOS + +.. tab:: Python 3.14 + + .. code-block:: shell + + $ python3 Apple test iOS + +.. tab:: Python 3.13 + + .. code-block:: shell + + $ make testios + +The full test suite takes approximately 12 minutes to run on a 2022 M1 MacBook +Pro, plus a couple of extra minutes to build the testbed application and boot +the simulator. You should see an iOS simulator appear during the +testing process; the simulator will boot to an iOS landing screen, the testbed +app will be installed, and then started. The screen of the simulator will be +black while the test suite is running. When the test suite completes, success or +failure will be reported at the command line. + +Two environment variables can be used to configure the operation of the Apple +build script: + +* ``CACHE_DIR`` defines the location where downloaded artefacts, such + as precompiled ``libFFI`` and ``xz`` binaries, will be stored. +* ``CROSS_BUILD_DIR`` defines the name of the ``cross-build`` directory + that will be used for builds. This can be useful if you need to maintain + builds of multiple versions of Python. + +The ``Platforms/Apple`` script has a number of other entry points that allow for +fine-grained execution of each part of an iOS build; run ``python3 +Platforms/Apple --help`` for more details. + +You can also run the test suite in Xcode itself. This is required if you want to +run on a physical device. See the `iOS README +<https://github.com/python/cpython/blob/main/iOS/README.rst#debugging-test-failures>`__ +for details. + +.. c_compile_and_build_end + +.. _build-dependencies: +.. _deps-on-linux: +.. _macOS and OS X: +.. _macOS: + +Install dependencies +==================== + +.. c_install_dependencies_start + +This section explains how to install libraries which are needed to compile +some of CPython's modules (for example, ``zlib``). + +.. tab:: Linux + + For Unix-based systems, we try to use system libraries whenever available. + This means optional components will only build if the relevant system headers + are available. The best way to obtain the appropriate headers will vary by + distribution, but the appropriate commands for some popular distributions + are below. + + On **Fedora**, **RHEL**, **CentOS** and other ``dnf``-based systems:: + + $ sudo dnf install git pkg-config + $ sudo dnf install dnf-plugins-core # install this to use 'dnf builddep' + $ sudo dnf builddep python3 + + Some optional development dependencies are not included in the above. + To install some additional dependencies for optional build and test components:: + + $ sudo dnf install \ + gcc gcc-c++ gdb lzma glibc-devel libstdc++-devel openssl-devel \ + readline-devel zlib-devel libzstd-devel libffi-devel bzip2-devel \ + xz-devel sqlite sqlite-devel sqlite-libs libuuid-devel gdbm-libs \ + perf expat expat-devel mpdecimal python3-pip + + + On **Debian**, **Ubuntu**, and other ``apt``-based systems, try to get the + dependencies for the Python you're working on by using the ``apt`` command. + + First, make sure you have enabled the source packages in the sources list. + You can do this by adding the location of the source packages, including + URL, distribution name and component name, to ``/etc/apt/sources.list``. + Take Ubuntu 22.04 LTS (Jammy Jellyfish) for example:: + + $ deb-src http://archive.ubuntu.com/ubuntu/ jammy main + + Alternatively, uncomment lines with ``deb-src`` using an editor, for + example:: + + $ sudo nano /etc/apt/sources.list + + For other distributions, like Debian, change the URL and names to correspond + with the specific distribution. + + Then you should update the packages index:: + + $ sudo apt-get update + + Now you can install the build dependencies via ``apt``:: + + $ sudo apt-get build-dep python3 + $ sudo apt-get install pkg-config + + If you want to build all optional modules, install the following packages and + their dependencies:: + + $ sudo apt-get install build-essential gdb lcov pkg-config \ + libbz2-dev libffi-dev libgdbm-dev libgdbm-compat-dev liblzma-dev \ + libncurses5-dev libreadline6-dev libsqlite3-dev libssl-dev \ + lzma lzma-dev tk-dev uuid-dev zlib1g-dev libmpdec-dev libzstd-dev \ + inetutils-inetd + + Note that Debian 12 and Ubuntu 24.04 do not have the ``libmpdec-dev`` + package. You can safely remove it from the install list above and the + Python build will use a bundled version. But we recommend using the system + `libmpdec <https://www.bytereef.org/mpdecimal/doc/libmpdec/>`__ library. + Either build it from sources or install this package from + https://deb.sury.org. + +.. tab:: macOS + + For **macOS systems** (versions 10.9+), + the Developer Tools can be downloaded and installed automatically; + you do not need to download the complete Xcode application. + + If necessary, run the following:: + + $ xcode-select --install + + This will also ensure that the system header files are installed into + ``/usr/include``. + + .. _Homebrew: https://brew.sh + + .. _MacPorts: https://www.macports.org + + Also note that macOS does not include several libraries used by the Python + standard library, including ``libzma``, so expect to see some extension module + build failures unless you install local copies of them. As of OS X 10.11, + Apple no longer provides header files for the deprecated system version of + OpenSSL which means that you will not be able to build the ``_ssl`` extension. + One solution is to install these libraries from a third-party package + manager, like Homebrew_ or MacPorts_, and then add the appropriate paths + for the header and library files to your ``configure`` command. + + .. tab:: Homebrew + + For **Homebrew**, install dependencies using ``brew``:: + + $ brew install pkg-config openssl@3 xz gdbm tcl-tk mpdecimal zstd + + .. tab:: Python 3.11+ + + For Python 3.11 and newer:: + + $ GDBM_CFLAGS="-I$(brew --prefix gdbm)/include" \ + GDBM_LIBS="-L$(brew --prefix gdbm)/lib -lgdbm" \ + ./configure --with-pydebug \ + --with-openssl="$(brew --prefix openssl@3)" + + .. tab:: Python 3.10 + + For Python 3.10:: + + $ CPPFLAGS="-I$(brew --prefix gdbm)/include -I$(brew --prefix xz)/include" \ + LDFLAGS="-L$(brew --prefix gdbm)/lib -L$(brew --prefix xz)/lib" \ + ./configure --with-pydebug \ + --with-openssl="$(brew --prefix openssl@3)" \ + --with-tcltk-libs="$(pkg-config --libs tcl tk)" \ + --with-tcltk-includes="$(pkg-config --cflags tcl tk)" \ + --with-dbmliborder=gdbm:ndbm + + (``--with-dbmliborder`` is a workaround for a Homebrew-specific change + to ``gdbm``; see `#89452 <https://github.com/python/cpython/issues/89452>`__ + for details.) + + .. tab:: MacPorts + + For **MacPorts**, install dependencies using ``port``:: + + $ sudo port install pkgconfig openssl xz gdbm tk +quartz mpdecimal zstd + + .. tab:: Python 3.13+ + + For Python 3.13 and newer:: + + $ GDBM_CFLAGS="-I$(dirname $(dirname $(which port)))/include" \ + GDBM_LIBS="-L$(dirname $(dirname $(which port)))/lib -lgdbm" \ + ./configure --with-pydebug \ + --with-system-libmpdec + + .. tab:: Python 3.11-3.12 + + For Python 3.11 and 3.12:: + + $ GDBM_CFLAGS="-I$(dirname $(dirname $(which port)))/include" \ + GDBM_LIBS="-L$(dirname $(dirname $(which port)))/lib -lgdbm" \ + ./configure --with-pydebug + + And finally, run ``make``:: + + $ make -s -j8 + + There will sometimes be optional modules added for a new release which + won't yet be identified in the OS-level build dependencies. In those cases, + just ask for assistance in the *Core Development* category on :ref:`help-discourse`. + + Explaining how to build optional dependencies on a Unix-based system without + root access is beyond the scope of this guide. + + For more details on various options and considerations for building, refer + to the `macOS README + <https://github.com/python/cpython/blob/main/Mac/README.rst>`__. + + .. note:: While you need a C compiler to build CPython, you don't need any + knowledge of the C language to contribute! Vast areas of CPython are + written completely in Python: as of this writing, CPython contains slightly + more Python code than C. + +.. tab:: Windows + + On Windows, extensions are already included and built automatically. + +.. tab:: Android + + The BeeWare project maintains `scripts for building Android dependencies`_, + and distributes `pre-compiled Android binaries`_ for each of them. + These binaries are automatically downloaded and used by the CPython + build script at :cpy-file:`Platforms/Android`. + + .. _scripts for building Android dependencies: https://github.com/beeware/cpython-android-source-deps + .. _pre-compiled Android binaries: https://github.com/beeware/cpython-android-source-deps/releases + +.. tab:: iOS + + The BeeWare project maintains `scripts for building iOS dependencies`_, + and distributes `pre-compiled iOS binaries`_ for each of them. + These binaries are automatically downloaded and used by the CPython + build script at :cpy-file:`Platforms/Apple`. + + If you are building for Python 3.13, you will need to manually download + and install these binaries, and provide the path to the binaries as part + of the call to ``configure``. + + .. _scripts for building iOS dependencies: https://github.com/beeware/cpython-apple-source-deps + .. _pre-compiled iOS binaries: https://github.com/beeware/cpython-apple-source-deps/releases + +.. c_install_dependencies_end + +.. _regenerate_configure: + +Regenerate ``configure`` +======================== + +.. c_regenerate_configure_start + +If a change is made to Python which relies on some POSIX system-specific +functionality (such as using a new system call), it is necessary to update the +:cpy-file:`configure` script to test for availability of the functionality. +Python's :file:`configure` script is generated from :cpy-file:`configure.ac` +using `GNU Autoconf <https://www.gnu.org/software/autoconf/>`__. + +After editing :file:`configure.ac`, run ``make regen-configure`` to generate +:file:`configure`, :cpy-file:`pyconfig.h.in`, and :cpy-file:`aclocal.m4`. +When submitting a pull request with changes made to :file:`configure.ac`, +make sure you also commit the changes in the generated files. + +Python's :file:`configure.ac` script requires a specific version of +GNU Autoconf. +For Python 3.12 and newer, GNU Autoconf v2.71 is required. +For Python 3.11 and earlier, GNU Autoconf v2.69 is required. + +The recommended and by far the easiest way to regenerate :file:`configure` is:: + + $ make regen-configure + +This will use Podman or Docker to do the regeneration with the proper version +of GNU Autoconf. + +If you cannot (or don't want to) use ``make regen-configure``, +install the :program:`autoconf-archive` and :program:`pkg-config` utilities, +and make sure the :file:`pkg.m4` macro file located in the appropriate +:program:`aclocal` location:: + + $ ls $(aclocal --print-ac-dir) | grep pkg.m4 + +.. note:: + + Running :program:`autoreconf` is not the same as running :program:`autoconf`. + For example, running :program:`autoconf` by itself will not regenerate + :file:`pyconfig.h.in`. + :program:`autoreconf` runs :program:`autoconf` and a number of other tools + repeatedly as appropriate. + +.. c_regenerate_configure_end + +Regenerate the ABI dump +======================= + +.. c_regenerate_abi_start + +Maintenance branches (not ``main``) have a special file located in +``Doc/data/pythonX.Y.abi`` that allows us to know if a given pull request +affects the public ABI. This file is used by the GitHub CI in a check +called ``Check if the ABI has changed`` that will fail if a given pull request +has changes to the ABI and the ABI file is not updated. + +This check acts as a fail-safe and **doesn't necessarily mean that the pull +request cannot be merged**. When this check fails you should add the relevant +release manager to the PR so that they are aware of the change and they can +validate if the change can be made or not. + +.. important:: + ABI changes are allowed before the first release candidate. After the first release + candidate, all further releases must have the same ABI for ensuring compatibility + with native extensions and other tools that interact with the Python interpreter. + See the documentation about the :ref:`release candidate <rc>` phase. + +When the PR check fails, the associated run will have the updated ABI file +attached as an artifact. After release manager approval, you can download and +add this file into your PR to pass the check. + +You can regenerate the ABI file by yourself by invoking the ``regen abidump`` +Make target. Note that for doing this you need to regenerate the ABI file in +the same environment that the GitHub CI uses to check for it. This is because +different platforms may include some platform-specific details that make the +check fail even if the Python ABI is the same. The easier way to regenerate +the ABI file using the same platform as the CI uses is by using Docker:: + + # In the CPython root: + $ docker run -v$(pwd):/src:Z -w /src --rm -it ubuntu:22.04 \ + bash /src/.github/workflows/regen-abidump.sh + +Note that the ``ubuntu`` version used to execute the script matters and +**must** match the version used by the CI to check the ABI. See the +``.github/workflows/build.yml`` file for more information. + +.. c_regenerate_abi_end + +.. _build_troubleshooting: + +Troubleshoot the build +====================== + +.. c_build_troubleshooting_start + +This section lists some of the common problems that may arise during the +compilation of Python, with proposed solutions. + +Avoid recreating auto-generated files +------------------------------------- + +Under some circumstances you may encounter Python errors in scripts like +``Parser/asdl_c.py`` or ``Python/makeopcodetargets.py`` while running ``make``. +Python auto-generates some of its own code, and a full build from scratch needs +to run the auto-generation scripts. However, this makes the Python build require +an already installed Python interpreter; this can also cause version mismatches +when trying to build an old (2.x) Python with a new (3.x) Python installed, or +vice versa. + +To overcome this problem, auto-generated files are also checked into the +Git repository. So if you don't touch the auto-generation scripts, there's +no real need to auto-generate anything. + +.. c_build_troubleshooting_end + +Editors and tools +================= + +Python is used widely enough that practically all code editors have some form +of support for writing Python code. Various coding tools also include Python +support. + +For editors and tools which the core developers have felt some special comment +is needed for coding *in* Python, see :ref:`resources`. + +.. _build_directory_structure: + +Directory structure +=================== + +.. c_directory_structure_start + +There are several top-level directories in the CPython source tree. Knowing what +each one is meant to hold will help you find where a certain piece of +functionality is implemented. Do realize, though, there are always exceptions to +every rule. + +``Doc`` + The official documentation. This is what https://docs.python.org/ uses. + See also :ref:`building-doc`. + +``Grammar`` + Contains the :abbr:`PEG (Parser Expression Grammar)` grammar file for + Python. + +``Include`` + Contains all interpreter-wide header files. + +``Lib`` + The part of the standard library implemented in pure Python. + +``Mac`` + Mac-specific code (for example, using IDLE as a macOS application). + +``Misc`` + Things that do not belong elsewhere. Typically this is varying kinds of + developer-specific documentation. + +``Modules`` + The part of the standard library (plus some other code) that is implemented + in C. + +``Objects`` + Code for all built-in types. + +``PC`` + Windows-specific code. + +``PCbuild`` + Build files for the version of MSVC currently used for the Windows + installers provided on python.org. + +``Parser`` + Code related to the parser. The definition of the AST nodes is also kept + here. + +``Programs`` + Source code for C executables, including the main function for the + CPython interpreter. + +``Python`` + The code that makes up the core CPython runtime. This includes the + compiler, eval loop and various built-in modules. + +``Tools`` + Various tools that are (or have been) used to maintain Python. + +.. c_directory_structure_end + + +.. _using-a-container: + +Using a container +================= + +There are various ways to use a container to build CPython without installing +additional tools on your machine. All approaches use the container defined in +the `cpython-devcontainers repo`_ in some way. + +.. _using-codespaces: + +Contribute using GitHub Codespaces +---------------------------------- + +.. c_codespaces_start + +.. _codespaces-whats-codespaces: + +What is GitHub Codespaces? +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you'd like to start contributing to CPython without needing to set up a local +developer environment, you can use +`GitHub Codespaces <https://github.com/features/codespaces>`__. +Codespaces is a cloud-based development environment offered by GitHub that +allows developers to write, build, test, and debug code directly within their +web browser or in Visual Studio Code (VS Code). + +To help you get started, CPython contains a +`devcontainer folder <https://github.com/python/cpython/tree/main/.devcontainer>`__ +with a JSON configuration file that provides consistent and versioned codespace +configurations for all users of the project. It also contains a Dockerfile that +allows you to set up the same environment but locally in a Docker container if +you'd prefer to use that directly. + +.. _codespaces-create-a-codespace: + +Create a CPython codespace +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Here are the basic steps needed to contribute a pull request using Codespaces. +You first need to navigate to the +`CPython repo <https://github.com/python/cpython>`__ hosted on GitHub. + +Then you will need to: + +1. Launch the codespace + + - Press the ``,`` key to launch the codespace setup screen for the current + branch + + - For the default dev container (which is what you very likely want), click + the green :guilabel:`Create new codespace` button + - For alternative containers, click :guilabel:`Change options` and + choose the appropriate container + + - Alternatively, click the green :guilabel:`Code` button and choose + the :guilabel:`codespaces` tab + + - For the default dev container (which is what you very likely want), click + the green :guilabel:`Create codespace on main` button + - For alternative containers, go to the :guilabel:`…` menu and choose + :guilabel:`New with options…` + +2. A screen should appear that lets you know your codespace is being set up. + (Note: Since the CPython devcontainer is provided, codespaces will use the + configuration it specifies.) +3. A `web version of VS Code <https://vscode.dev/>`__ will open inside your web + browser, already linked up with your code and a terminal to the remote + codespace where CPython and its documentation have already been built. +4. Use the terminal with the usual Git commands to create a new branch, commit + and push your changes once you're ready! + +If you close your repository and come back later you can always resume your +codespace by navigating to the CPython repo, selecting the codespaces tab and +selecting your most recent codespaces session. You should then be able to pick +up from where you left off! + +.. _codespaces-use-locally: + +Use Codespaces locally +^^^^^^^^^^^^^^^^^^^^^^ + +On the bottom left side of the codespace screen you will see a green or grey +square that says :guilabel:`Codespaces`. You can click this for additional +options. If you prefer working in a locally installed copy of VS Code you can +select the option ``Open in VS Code``. You will still be working on the remote +codespace instance, thus using the remote instance's compute power. The compute +power may be a much higher spec than your local machine which can be helpful. + +.. c_codespaces_end + +.. _devcontainer-directly: + +Using the dev container directly +-------------------------------- + +If you want more control over the environment, or to work offline, +you can use the same container used in +:ref:`GitHub Codespaces <using-codespaces>` directly. +This is meant for users who have (or want to get) some experience +with containers. +These instructions assume a Unix-like environment with +`Docker <https://www.docker.com/>`__ or `Podman <https://podman.io/>`__ +installed. The instructions also assume you want the default dev container; +tweak the commands as appropriate if you want to use an alternative container +(e.g. the WASI dev container). + +.. _devcontainer-image: + +Using the pre-built container image +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +`Dev container images <https://github.com/python/cpython-devcontainers/pkgs/container/devcontainer>`__ +are available from the +`GitHub Container Registry (GHCR) account for the Python org <https://github.com/orgs/python/packages>`__. + +To run the container and launch a Bash shell, run one of the following commands +in a clone of the CPython repository. + +.. tab:: Podman + + .. code-block:: bash + + podman run -it --rm --volume $PWD:/workspace:Z --workdir /workspace ghcr.io/python/devcontainer:latest + +.. tab:: Docker + + .. code-block:: bash + + docker run -it --rm --volume $PWD:/workspace --workdir /workspace ghcr.io/python/devcontainer:latest + + +Note that the container has read/write access to the working directory. +You may want to use a separate clone of CPython, or run ``make clean`` +to remove caches and build output generated for your host OS. + +.. _devcontainer-build: + +Building yourself +^^^^^^^^^^^^^^^^^ + +If you prefer, you can build the container image yourself. In a clone of the +`cpython-devcontainers repo`_, +build the container and name it ``cpython-dev``: + +.. tab:: Podman + + .. code-block:: shell + + podman build devcontainer/ --tag cpython-dev + +.. tab:: Docker + + .. code-block:: shell + + docker build devcontainer/ --tag cpython-dev + +The same command will update any existing ``cpython-dev`` container. +Run it again from time to time -- especially if the container stops +working for you. + +To run the container and launch a Bash shell, run one of the following commands +in a clone of the CPython repository. + +.. tab:: Podman + + .. code-block:: shell + + podman run -it --rm --volume $PWD:/workspace:Z --workdir /workspace cpython-dev bash + +.. tab:: Docker + + .. code-block:: shell + + docker run -it --rm --volume $PWD:/workspace --workdir /workspace cpython-dev bash + + +The same caveats outlined above when running from a container image from GHCR +also apply here. + + +.. _cpython-devcontainers repo: https://github.com/python/cpython-devcontainers +.. include:: ../links.rst diff --git a/gitbootcamp.rst b/gitbootcamp.rst deleted file mode 100644 index 7a8405a22b..0000000000 --- a/gitbootcamp.rst +++ /dev/null @@ -1,483 +0,0 @@ -.. highlight:: console - -.. _gitbootcamp: - -Git Bootcamp and Cheat Sheet -============================ - -.. note:: - - This section provides instructions on common tasks in CPython's - workflow. It's designed to assist new contributors who have - some familiarity with git and GitHub. - - If you are new to git and GitHub, please become comfortable with - these instructions before submitting a pull request. As there are several - ways to accomplish these tasks using git and GitHub, this section reflects - one method suitable for new contributors. Experienced contributors may - desire a different approach. - - -In this section, we will go over some commonly used Git commands that are -relevant to CPython's workflow. - -.. note:: - Setting up git aliases for common tasks can be useful to you. You can - get more information about that in - `git documentation <https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases>`_ - -.. contents:: - -.. _fork-cpython: - -Forking CPython GitHub Repository ---------------------------------- - -You will only need to do this once. - -1. Go to https://github.com/python/cpython. - -2. Press ``Fork`` on the top right. - -3. When asked where to fork the repository, choose to fork it to your username. - -4. Your forked CPython repository will be created at https://github.com/<username>/cpython. - -.. _clone-your-fork: - -Cloning a Forked CPython Repository ------------------------------------ - -You will only need to do this once. From your command line:: - - git clone git@github.com:<username>/cpython.git - -It is also recommended to configure an ``upstream`` remote repository:: - - cd cpython - git remote add upstream git@github.com:python/cpython.git - -You can also use SSH-based or HTTPS-based URLs. - -Listing the Remote Repositories -------------------------------- - -To list the remote repositories that are configured, along with their URLs:: - - git remote -v - -You should have two remote repositories: ``origin`` pointing to your forked CPython repository, -and ``upstream`` pointing to the official CPython repository:: - - origin git@github.com:<username>/cpython.git (fetch) - origin git@github.com:<username>/cpython.git (push) - upstream git@github.com:python/cpython.git (fetch) - upstream git@github.com:python/cpython.git (push) - - -.. _set-up-name-email: - -Setting Up Your Name and Email Address --------------------------------------- - -.. code-block:: bash - - git config --global user.name "Your Name" - git config --global user.email your.email@example.com - -The ``--global`` flag sets these parameters globally while -the ``--local`` flag sets them only for the current project. - -.. _autocrlf: - -Enabling ``autocrlf`` on Windows --------------------------------- - -The ``autocrlf`` option will fix automatically any Windows-specific line endings. -This should be enabled on Windows, since the public repository has a hook which -will reject all changesets having the wrong line endings:: - - git config --global core.autocrlf input - -Creating and Switching Branches -------------------------------- - -.. important:: - Never commit directly to the ``master`` branch. - -Create a new branch and switch to it:: - - # creates a new branch off master and switch to it - git checkout -b <branch-name> master - -This is equivalent to:: - - # create a new branch from master, without checking it out - git branch <branch-name> master - # check out the branch - git checkout <branch-name> - -To find the branch you are currently on:: - - git branch - -The current branch will have an asterisk next to the branch name. Note, this -will only list all of your local branches. - -To list all the branches, including the remote branches:: - - git branch -a - -To switch to a different branch:: - - git checkout <another-branch-name> - -Other releases are just branches in the repository. For example, to work -on the 2.7 release from the ``upstream`` remote:: - - git checkout -b 2.7 upstream/2.7 - -.. _deleting_branches: - -Deleting Branches ------------------ - -To delete a **local** branch that you no longer need:: - - git checkout master - git branch -D <branch-name> - -To delete a **remote** branch:: - - git push origin -d <branch-name> - -You may specify more than one branch for deletion. - -Staging and Committing Files ----------------------------- - -1. To show the current changes:: - - git status - -2. To stage the files to be included in your commit:: - - git add <filename1> <filename2> - -3. To commit the files that have been staged (done in step 2): - - .. code-block:: bash - - git commit -m "bpo-XXXX: This is the commit message." - -Reverting Changes ------------------ - -To revert changes to a file that has not been committed yet:: - - git checkout <filename> - -If the change has been committed, and now you want to reset it to whatever -the origin is at:: - - git reset --hard HEAD - -Stashing Changes ----------------- - -To stash away changes that are not ready to be committed yet:: - - git stash - -To re-apply the last stashed change:: - - git stash pop - -.. _commit-changes: - -Committing Changes ------------------- - -Add the files you want to commit:: - - git add <filename> - -Commit the files: - -.. code-block:: bash - - git commit -m "<message>" - -.. _push-changes: - -Pushing Changes ---------------- - -Once your changes are ready for a review or a pull request, you will need to push -them to the remote repository. - -:: - - git checkout <branch-name> - git push origin <branch-name> - -Creating a Pull Request ------------------------ - -1. Go to https://github.com/python/cpython. - -2. Press the ``New pull request`` button. - -3. Click the ``compare across forks`` link. - -4. Select the base repository: ``python/cpython`` and base branch: ``master``. - -5. Select the head repository: ``<username>/cpython`` and head branch: the branch - containing your changes. - -6. Press the ``Create pull request`` button. - -Syncing with Upstream ---------------------- - -Scenario: - -- You forked the CPython repository some time ago. -- Time passes. -- There have been new commits made in the upstream CPython repository. -- Your forked CPython repository is no longer up to date. -- You now want to update your forked CPython repository to be the same as - the upstream CPython repository. - -Solution:: - - git checkout master - git pull upstream master - git push origin master - -Another scenario: - -- You created ``some-branch`` some time ago. -- Time passes. -- You made some commits to ``some-branch``. -- Meanwhile, there are recent changes from the upstream CPython repository. -- You want to incorporate the recent changes from the upstream CPython - repository into ``some-branch``. - -Solution:: - - git checkout some-branch - git fetch upstream - git merge upstream/master - git push origin some-branch - -You may see error messages like "CONFLICT" and "Automatic merge failed;" when -you run ``git merge upstream/master``. - -When it happens, you need to resolve conflict. See these articles about resolving conflicts: - -- `About merge conflicts <https://help.github.com/en/articles/about-merge-conflicts>`_ -- `Resolving a merge conflict using the command line <https://help.github.com/en/articles/resolving-a-merge-conflict-using-the-command-line>`_ - -.. _git_from_mercurial: - -Applying a Patch from Mercurial to Git --------------------------------------- - -Scenario: - -- A Mercurial patch exists but there is no pull request for it. - -Solution: - -1. Download the patch locally. - -2. Apply the patch:: - - git apply /path/to/issueNNNN-git.patch - - If there are errors, update to a revision from when the patch was - created and then try the ``git apply`` again: - - .. code-block:: bash - - git checkout $(git rev-list -n 1 --before="yyyy-mm-dd hh:mm:ss" master) - git apply /path/to/issueNNNN-git.patch - - If the patch still won't apply, then a patch tool will not be able to - apply the patch and it will need to be re-implemented manually. - -3. If the apply was successful, create a new branch and switch to it. - -4. Stage and commit the changes. - -5. If the patch was applied to an old revision, it needs to be updated and - merge conflicts need to be resolved:: - - git rebase master - git mergetool - -6. Push the changes and open a pull request. - -.. _git_pr: - -Downloading Other's Patches ---------------------------- - -Scenario: - -- A contributor made a pull request to CPython. -- Before merging it, you want to be able to test their changes locally. - -On Unix and MacOS, set up the following git alias:: - - $ git config --global alias.pr '!sh -c "git fetch upstream pull/${1}/head:pr_${1} && git checkout pr_${1}" -' - -On Windows, reverse the single (``'``) and double (``"``) quotes: - -.. code-block:: bash - - git config --global alias.pr "!sh -c 'git fetch upstream pull/${1}/head:pr_${1} && git checkout pr_${1}' -" - -The alias only needs to be done once. After the alias is set up, you can get a -local copy of a pull request as follows:: - - git pr <pr_number> - -.. note:: - - `hub <https://github.com/github/hub>`_ command line utility makes this - workflow very easy. You can check out the branch by - ``hub pr checkout <pr_number> [<branch_name>]``. - This command configures remote URL for the branch too. - So you can ``git push`` if the pull request author checked - "Allow edits from maintainers" when creating the pull request. - -.. _accepting-and-merging-a-pr: - -Accepting and Merging a Pull Request ------------------------------------- - -Pull requests can be accepted and merged by a Python Core Developer. - -1. At the bottom of the pull request page, click the ``Squash and merge`` - button. - -2. Replace the reference to GitHub pull request ``#NNNN`` with ``GH-NNNN``. - If the title is too long, the pull request number can be added to the - message body. - -3. Adjust and clean up the commit message. - - Example of good commit message:: - - bpo-12345: Improve the spam module (GH-777) - - * Add method A to the spam module - * Update the documentation of the spam module - - Example of bad commit message:: - - bpo-12345: Improve the spam module (#777) - - * Improve the spam module - * merge from master - * adjust code based on review comment - * rebased - - .. note:: - `How to Write a Git Commit Message <https://chris.beams.io/posts/git-commit/>`_ - is a nice article describing how to write a good commit message. - -4. Press the ``Confirm squash and merge`` button. - -Backporting Merged Changes --------------------------- - -A pull request may need to be backported into one of the maintenance branches -after it has been accepted and merged into ``master``. It is usually indicated -by the label ``needs backport to X.Y`` on the pull request itself. - -Use the utility script -`cherry_picker.py <https://github.com/python/cherry-picker>`_ -from the `core-workflow <https://github.com/python/core-workflow>`_ -repository to backport the commit. - -The commit hash for backporting is the squashed commit that was merged to -the ``master`` branch. On the merged pull request, scroll to the bottom of the -page. Find the event that says something like:: - - <core_developer> merged commit <commit_sha1> into python:master <sometime> ago. - -By following the link to ``<commit_sha1>``, you will get the full commit hash. - -Alternatively, the commit hash can also be obtained by the following git -commands: - -.. code-block:: bash - - git fetch upstream - git rev-parse ":/bpo-12345" - -The above commands will print out the hash of the commit containing -``"bpo-12345"`` as part of the commit message. - -When formatting the commit message for a backport commit: leave the original -one as is and delete the number of the backport pull request. - -Example of good backport commit message:: - - bpo-12345: Improve the spam module (GH-777) - - * Add method A to the spam module - * Update the documentation of the spam module - - (cherry picked from commit 62adc55) - -Example of bad backport commit message:: - - bpo-12345: Improve the spam module (GH-777) (#888) - - * Add method A to the spam module - * Update the documentation of the spam module - -Editing a Pull Request Prior to Merging ---------------------------------------- - -When a pull request submitter has enabled the `Allow edits from maintainers`_ -option, Python Core Developers may decide to make any remaining edits needed -prior to merging themselves, rather than asking the submitter to do them. This -can be particularly appropriate when the remaining changes are bookkeeping -items like updating ``Misc/ACKS``. - -.. _Allow edits from maintainers: https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/ - -To edit an open pull request that targets ``master``: - -1. In the pull request page, under the description, there is some information - about the contributor's forked CPython repository and branch name that will be useful later:: - - <contributor> wants to merge 1 commit into python:master from <contributor>:<branch_name> - -2. Fetch the pull request, using the :ref:`git pr <git_pr>` alias:: - - git pr <pr_number> - - This will checkout the contributor's branch at ``<pr_number>``. - -3. Make and commit your changes on the branch. For example, merge in changes - made to ``master`` since the PR was submitted (any merge commits will be - removed by the later ``Squash and Merge`` when accepting the change): - - .. code-block:: bash - - git fetch upstream - git merge upstream/master - git add <filename> - git commit -m "<message>" - -4. Push the changes back to the contributor's PR branch:: - - git push git@github.com:<contributor>/cpython <pr_number>:<branch_name> - -5. Optionally, :ref:`delete the PR branch <deleting_branches>`. diff --git a/grammar.rst b/grammar.rst deleted file mode 100644 index 912dbaef51..0000000000 --- a/grammar.rst +++ /dev/null @@ -1,65 +0,0 @@ -.. _grammar: - -Changing CPython's Grammar -========================== - -Abstract --------- - -There's more to changing Python's grammar than editing -:file:`Grammar/Grammar`. This document aims to be a -checklist of places that must also be fixed. - -It is probably incomplete. If you see omissions, submit a bug or patch. - -This document is not intended to be an instruction manual on Python -grammar hacking, for several reasons. - - -Rationale ---------- - -People are getting this wrong all the time; it took well over a -year before someone `noticed <https://bugs.python.org/issue676521>`_ -that adding the floor division -operator (``//``) broke the :mod:`parser` module. - - -Checklist ---------- - -Note: sometimes things mysteriously don't work. Before giving up, try ``make clean``. - -* :file:`Grammar/Grammar`: OK, you'd probably worked this one out. :-) After changing - it, run ``make regen-grammar``, to regenerate :file:`Include/graminit.h` and - :file:`Python/graminit.c`. (This runs Python's parser generator, ``Python/pgen``). - -* :file:`Grammar/Tokens` is a place for adding new token types. After - changing it, run ``make regen-token`` to regenerate :file:`Include/token.h`, - :file:`Parser/token.c`, :file:`Lib/token.py` and - :file:`Doc/library/token-list.inc`. If you change both ``Grammar`` and ``Tokens``, - run ``make regen-tokens`` before ``make regen-grammar``. - -* :file:`Parser/Python.asdl` may need changes to match the Grammar. Then run ``make - regen-ast`` to regenerate :file:`Include/Python-ast.h` and :file:`Python/Python-ast.c`. - -* :file:`Parser/tokenizer.c` contains the tokenization code. This is where you would - add a new type of comment or string literal, for example. - -* :file:`Python/ast.c` will need changes to create the AST objects involved with the - Grammar change. - -* The :doc:`compiler` has its own page. - -* The :mod:`parser` module. Add some of your new syntax to ``test_parser``, - bang on :file:`Modules/parsermodule.c` until it passes. - -* Add some usage of your new syntax to ``test_grammar.py``. - -* Certain changes may require tweaks to the library module :mod:`pyclbr`. - -* :file:`Lib/tokenize.py` needs changes to match changes to the tokenizer. - -* :file:`Lib/lib2to3/Grammar.txt` may need changes to match the Grammar. - -* Documentation must be written! diff --git a/help.rst b/help.rst deleted file mode 100644 index 2df8022dc9..0000000000 --- a/help.rst +++ /dev/null @@ -1,108 +0,0 @@ -.. _help: - -Where to Get Help -================= - -If you are working on Python it is very possible you will come across an issue -where you need some assistance to solve it (this happens to core developers -all the time). - -Should you require help, there are a :ref:`variety of options available -<communication>` to seek assistance. If the question involves process or tool -usage then please check the rest of this guide first as it should answer your -question. - - -Ask #python-dev ---------------- - -If you are comfortable with IRC you can try asking on ``#python-dev`` (on -the `freenode`_ network). Typically there are a number of experienced -developers, ranging from triagers to core developers, who can answer -questions about developing for Python. Just remember that ``#python-dev`` -is for questions involving the development *of* Python whereas ``#python`` -is for questions concerning development *with* Python. - -.. _freenode: https://freenode.net/ - - -Zulip ------ - -An alternative to IRC is our own `Zulip`_ instance. There are different streams -for asking help with core development, as well as core developers' office -hour stream. It is preferred that you ask questions here first or schedule -an office hour, before posting to python-dev mailing list or filing bugs. - -.. _Zulip: https://python.zulipchat.com - - -Core Mentorship ---------------- - -If you are interested in improving Python and contributing to its development, -but don’t yet feel entirely comfortable with the public channels mentioned -above, `Python Mentors`_ are here to help you. Python is fortunate to have a -community of volunteer core developers willing to mentor anyone wishing to -contribute code, work on bug fixes or improve documentation. Everyone is -welcomed and encouraged to contribute. - -.. _Python Mentors: https://www.python.org/dev/core-mentorship/ - - -.. _office hour: - -Core Developers Office Hours ----------------------------- - -Several core developers have set aside time to host mentorship office hours. -During the office hour, core developers are available to help contributors with -our process, answer questions, and help lower the barrier of contributing and -becoming Python core developers. - -The PSF's code of conduct applies for interactions with core developers -during office hours. - -+------------------+-------------------------------+------------------------------------------------+ -| Core Developer | Schedule | Details | -+==================+===============================+================================================+ -| Zachary Ware | See details link | Schedule at https://calendly.com/zware | -+------------------+-------------------------------+------------------------------------------------+ -| Mariatta Wijaya | Thursdays 7PM - 8PM Pacific | In `Python's Zulip Chat`_, Core > Office | -| | (Vancouver, Canada Timezone) | Hour stream. A reminder will be posted to both | -| | | Zulip and `Mariatta's twitter`_ account | -| | | 24 hours before the start. | -+------------------+-------------------------------+------------------------------------------------+ - -.. _Python's Zulip Chat: https://python.zulipchat.com/#narrow/stream/116503-core/topic/Office.20Hour -.. _Mariatta's twitter: https://twitter.com/mariatta - - -Mailing Lists -------------- - -Further options for seeking assistance include the `python-ideas`_ and -`python-dev`_ mailing lists. Python-ideas contains discussion of speculative -Python language ideas for possible inclusion into the language. If an idea -gains traction it can then be discussed and honed to the point of becoming a -solid proposal and presented on python-dev. Python-dev contains discussion -of current Python design issues, release mechanics, and maintenance of -existing releases. As with ``#python-dev``, these mailing lists are for -questions involving the development *of* Python, **not** for development -*with* Python. - -.. _python-ideas: https://mail.python.org/mailman/listinfo/python-ideas -.. _python-dev: https://mail.python.org/mailman/listinfo/python-dev - - -File a Bug ----------- - -If you strongly suspect you have stumbled on a bug (be it in the build -process, in the test suite, or in other areas), then open an issue on the -`issue tracker`_. As with every bug report it is strongly advised that -you detail which conditions triggered it (including the OS name and version, -and what you were trying to do), as well as the exact error message you -encountered. - -.. _issue tracker: https://bugs.python.org diff --git a/include/activate-tab.rst b/include/activate-tab.rst new file mode 100644 index 0000000000..229542bf42 --- /dev/null +++ b/include/activate-tab.rst @@ -0,0 +1,7 @@ +.. raw:: html + + <script> + document.addEventListener('DOMContentLoaded', function() { + activateTab(getOS()); + }); + </script> diff --git a/index.rst b/index.rst index 4fb1baadf9..18aca244e1 100644 --- a/index.rst +++ b/index.rst @@ -1,192 +1,171 @@ +.. _devguide-main: + ======================== Python Developer's Guide ======================== +.. include:: include/activate-tab.rst + .. highlight:: bash This guide is a comprehensive resource for :ref:`contributing <contributing>` to Python_ -- for both new and experienced contributors. It is -:ref:`maintained <helping-with-the-developers-guide>` by the same -community that maintains Python. We welcome your contributions to Python! +:ref:`maintained <devguide>` by the same +community that maintains Python. We welcome your contributions! + + +.. _contributing: + +Contributing +------------ + +We encourage everyone to contribute to Python. To help you, we have put up this +developer's guide. If you still have questions after reviewing the material in +this guide, then the `Core Python Mentorship`_ group is available to help guide new +contributors through the process. + +Guide for contributing to Python: + +.. list-table:: + :widths: 10 10 10 + :header-rows: 1 + + * - Documentation + - Code + - Triage + * - + * :ref:`docquality` + * :ref:`documenting` + * :ref:`style-guide` + * :ref:`rst-primer` + * :ref:`translating` + * :ref:`devguide` + - + * :ref:`setup` + * :ref:`help` + * :ref:`pullrequest` + * :ref:`runtests` + * :ref:`fixingissues` + * :ref:`communication` + * :ref:`gitbootcamp` + * :ref:`devcycle` + - + * :ref:`tracker` + * :ref:`triaging` + * :ref:`helptriage` + * :ref:`experts` + * :ref:`labels` + * :ref:`gh-faq` + * :ref:`triage-team` + +We **recommend** that sections of this guide be read as needed. You +can stop where you feel comfortable and begin contributing immediately without +reading and understanding everything. If you do choose to skip +around within the guide, be aware that sections build on each other, +so you may find it necessary to backtrack to fill in +missing concepts and terminology. + +A number of individuals from the Python community have contributed to a series +of excellent guides at `Open Source Guides <https://opensource.guide/>`__. +For example, +`How to Contribute to Open Source <https://opensource.guide/how-to-contribute/>`__. + .. _quick-reference: -Quick Reference +Quick reference --------------- -Here are the basic steps needed to get :ref:`set up <setup>` and contribute a -patch. This is meant as a checklist, once you know the basics. For complete +Here are the basic steps needed to get set up and open a pull request. +This is meant as a checklist, once you know the basics. For complete instructions please see the :ref:`setup guide <setup>`. 1. Install and set up :ref:`Git <vcsetup>` and other dependencies - (see the :ref:`Get Setup <setup>` page for detailed information). + (see the :ref:`Git Setup <setup>` page for detailed information). -2. Fork `the CPython repository <https://github.com/python/cpython>`_ +2. Fork `the CPython repository <https://github.com/python/cpython>`__ to your GitHub account and :ref:`get the source code <checkout>` using:: git clone https://github.com/<your_username>/cpython cd cpython -3. Build Python, on UNIX and Mac OS use:: +3. Build Python: - ./configure --with-pydebug && make -j + .. tab:: Unix - and on Windows use: + .. code-block:: shell - .. code-block:: dosbatch + ./configure --with-pydebug && make -j $(nproc) - PCbuild\build.bat -e -d + .. tab:: macOS - See also :ref:`more detailed instructions <compiling>`, - :ref:`how to install and build dependencies <build-dependencies>`, - and the platform-specific pages for :ref:`UNIX <unix-compiling>`, - :ref:`Mac OS <MacOS>`, and :ref:`Windows <windows-compiling>`. + .. code-block:: shell + + ./configure --with-pydebug && make -j8 -4. :doc:`Run the tests <runtests>`:: + .. tab:: Windows - ./python -m test -j3 + .. code-block:: dosbatch - On :ref:`most <mac-python.exe>` Mac OS X systems, replace :file:`./python` - with :file:`./python.exe`. On Windows, use :file:`python.bat`. With Python - 2.7, replace ``test`` with ``test.regrtest``. + PCbuild\build.bat -e -d -5. Create a new branch where your work for the issue will go, e.g.:: + See also :ref:`more detailed instructions <compiling>`, + :ref:`how to install and build dependencies <build-dependencies>`, + and the platform-specific pages for :ref:`Unix <unix-compiling>`, + :ref:`macOS <macOS>`, and :ref:`Windows <windows-compiling>`. - git checkout -b fix-issue-12345 master +4. :ref:`Run the tests <runtests>`: - If an issue does not already exist, please `create it - <https://bugs.python.org/>`_. Trivial issues (e.g. typo fixes) do not - require any issue to be created. + .. tab:: Unix -6. Once you fixed the issue, run the tests, run ``make patchcheck``, and if - everything is ok, commit. + .. code-block:: shell -7. Push the branch on your fork on GitHub and :doc:`create a pull request - <pullrequest>`. Include the issue number using ``bpo-NNNN`` in the - pull request description. For example:: + ./python -m test -j3 - bpo-12345: Fix some bug in spam module + .. tab:: macOS -.. note:: + .. code-block:: shell - First time contributors will need to sign the Contributor Licensing - Agreement (CLA) as described in the :ref:`Licensing <cla>` section of - this guide. + ./python.exe -m test -j8 -Quick Links ------------ + .. note:: + :ref:`Most <mac-python.exe>` macOS systems use + :file:`./python.exe` in order to avoid filename conflicts with + the ``Python`` directory. -Here are some links that you probably will reference frequently while -contributing to Python: + .. tab:: Windows -* `Issue tracker`_ -* `Buildbot status`_ -* :doc:`help` -* PEPs_ (Python Enhancement Proposals) -* :doc:`gitbootcamp` - -.. _branchstatus: - -Status of Python branches -------------------------- - -+------------------+--------------+-------------+----------------+----------------+-------------------+ -| Branch | Schedule | Status | First release | End-of-life | Release manager | -+==================+==============+=============+================+================+===================+ -| master | :pep:`596` | features | *TBD* | *TBD* | Łukasz Langa | -+------------------+--------------+-------------+----------------+----------------+-------------------+ -| 3.8 | :pep:`569` | prerelease | *2019-10-21* | *2024-10* | Łukasz Langa | -+------------------+--------------+-------------+----------------+----------------+-------------------+ -| 3.7 | :pep:`537` | bugfix | 2018-06-27 | *2023-06-27* | Ned Deily | -+------------------+--------------+-------------+----------------+----------------+-------------------+ -| 2.7 | :pep:`373` | bugfix | 2010-07-03 | *2020-01-01* | Benjamin Peterson | -+------------------+--------------+-------------+----------------+----------------+-------------------+ -| 3.6 | :pep:`494` | security | 2016-12-23 | *2021-12-23* | Ned Deily | -+------------------+--------------+-------------+----------------+----------------+-------------------+ -| 3.5 | :pep:`478` | security | 2015-09-13 | *2020-09-13* | Larry Hastings | -+------------------+--------------+-------------+----------------+----------------+-------------------+ - -.. Remember to update the end-of-life table in devcycle.rst. - -The master branch is currently the future Python 3.9, and is the only -branch that accepts new features. The latest release for each Python -version can be found on the `download page <https://www.python.org/downloads/>`_. - -Status: - -:features: new features, bugfixes, and security fixes are accepted. -:prerelease: feature fixes, bugfixes, and security fixes are accepted for the - upcoming feature release. -:bugfix: bugfixes and security fixes are accepted, new binaries are still - released. (Also called **maintenance** mode) -:security: only security fixes are accepted and no more binaries are released, - but new source-only versions can be released -:end-of-life: release cycle is frozen; no further changes can be pushed to it. - -Dates in *italic* are scheduled and can be adjusted. - -By default, the end-of-life is scheduled 5 years after the first release, -but can be adjusted by the release manager of each branch. The support for -Python 2.7 has currently been extended to 2020-01-01. Versions older than -2.7 have reached end-of-life. - -See also the :ref:`devcycle` page for more information about branches. + .. code-block:: dosbatch -.. _contributing: + .\python.bat -m test -j3 -Contributing ------------- +5. Create a new branch where your work for the issue will go, for example:: -We encourage everyone to contribute to Python and that's why we have put up this -developer's guide. If you still have questions after reviewing the material in -this guide, then the `Core Python Mentorship`_ group is available to help guide new -contributors through the process. + git checkout -b fix-issue-12345 main -A number of individuals from the Python community have contributed to a series -of excellent guides at `Open Source Guides <https://opensource.guide/>`_. + If an issue does not already exist, please `create it + <https://github.com/python/cpython/issues>`__. Trivial issues (for example, typos) do + not require an issue. -Core developers and contributors alike will find the following guides useful: +6. Push the branch on your fork on GitHub and :ref:`create a pull request + <pullrequest>`. Include the issue number using ``gh-NNNNNN`` in the + pull request title. For example: -* `How to Contribute to Open Source <https://opensource.guide/how-to-contribute/>`_ -* `Building Welcoming Communities <https://opensource.guide/building-community/>`_ + .. code-block:: text -Guide for contributing to Python: + gh-12345: Fix some bug in spam module -+------------------------+---------------------+-----------------------+---------------------+ -| New Contributors | Documentarians | Triagers | Core Developers | -+========================+=====================+=======================+=====================+ -| :doc:`setup` | :doc:`docquality` | :doc:`tracker` | :doc:`coredev` | -+------------------------+---------------------+-----------------------+---------------------+ -| :doc:`help` | :doc:`documenting` | :doc:`triaging` | :doc:`developers` | -+------------------------+---------------------+-----------------------+---------------------+ -| :doc:`pullrequest` | :ref:`style-guide` | :ref:`helptriage` | :doc:`committing` | -+------------------------+---------------------+-----------------------+---------------------+ -| :doc:`runtests` | :ref:`rst-primer` | :doc:`experts` | :doc:`devcycle` | -+------------------------+---------------------+-----------------------+---------------------+ -| :doc:`fixingissues` | :ref:`translating` | | :doc:`motivations` | -+------------------------+---------------------+-----------------------+---------------------+ -| :doc:`communication` | | | :ref:`office hour` | -+------------------------+---------------------+-----------------------+---------------------+ -| :doc:`gitbootcamp` | | | | -+------------------------+---------------------+-----------------------+---------------------+ - -Advanced tasks and topics for once you are comfortable: - -* :doc:`silencewarnings` -* Fixing issues found by the :doc:`buildbots <buildbots>` -* :doc:`coverity` -* Helping out with reviewing `open pull requests`_. - See :ref:`how to review a Pull Request <how-to-review-a-pull-request>`. -* :doc:`fixingissues` - -It is **recommended** that the above documents be read as needed. New -contributors will build understanding of the CPython workflow by reading the -sections mentioned in this table. You -can stop where you feel comfortable and begin contributing immediately without -reading and understanding these documents all at once. If you do choose to skip -around within the documentation, be aware that it is written assuming preceding -documentation has been read so you may find it necessary to backtrack to fill in -missing concepts and terminology. +7. Add a News entry into the ``Misc/NEWS.d/`` directory as individual file. The + news entry can be created by using `blurb-it <https://blurb-it.herokuapp.com/>`__, + or the :pypi:`blurb` tool and its ``blurb add`` + command. Please read more about ``blurb`` in its + `repository <https://github.com/python/blurb>`__. + +.. note:: + + First time contributors will need to sign the Contributor Licensing + Agreement (CLA) as described in the :ref:`Licensing <cla>` section of + this guide. Proposing changes to Python itself @@ -202,138 +181,126 @@ developer's toolkit. While these kinds of change are much rarer than those described above, they do happen and that process is also described as part of this guide: -* :doc:`stdlibchanges` -* :doc:`langchanges` - +* :ref:`stdlibchanges` +* :ref:`langchanges` -Other Interpreter Implementations ---------------------------------- -This guide is specifically for contributing to the Python reference interpreter, -also known as CPython (while most of the standard library is written in Python, -the interpreter core is written in C and integrates most easily with the C and -C++ ecosystems). +Key resources +------------- -There are other Python implementations, each with a different focus. Like -CPython, they always have more things they would like to do than they have -developers to work on them. Some major examples that may be of interest are: +* Coding style guides -* PyPy_: A Python interpreter focused on high speed (JIT-compiled) operation - on major platforms -* Jython_: A Python interpreter focused on good integration with the Java - Virtual Machine (JVM) environment -* IronPython_: A Python interpreter focused on good integration with the - Common Language Runtime (CLR) provided by .NET and Mono -* Stackless_: A Python interpreter focused on providing lightweight - microthreads while remaining largely compatible with CPython specific - extension modules + * :PEP:`7` (Style Guide for C Code) + * :PEP:`8` (Style Guide for Python Code) +* `Issue tracker`_ -Key Resources -------------- + * :ref:`experts` -* Coding style guides - * :PEP:`7` (Style Guide for C Code) - * :PEP:`8` (Style Guide for Python Code) -* `Issue tracker`_ - * `Meta tracker <http://psf.upfronthosting.co.za/roundup/meta>`_ (issue - tracker for the issue tracker) - * :doc:`experts` * `Buildbot status`_ * Source code - * `Browse online <https://github.com/python/cpython/>`_ - * `Snapshot of the *master* branch <https://github.com/python/cpython/archive/master.zip>`_ - * `Daily OS X installer <http://buildbot.python.org/daily-dmg/>`_ + + * `Browse online <https://github.com/python/cpython/>`__ + * `Download a snapshot <https://github.com/python/cpython/archive/main.zip>`__ + of the ``main`` branch + * PEPs_ (Python Enhancement Proposals) -* :doc:`help` -* :doc:`developers` +* `The Python Discourse <https://discuss.python.org/>`__ +* :ref:`help` +* :ref:`developers` +* :ref:`gitbootcamp` .. _resources: -Additional Resources +Additional resources -------------------- -* Anyone can clone the sources for this guide. See - :ref:`helping-with-the-developers-guide`. +* Anyone can clone the sources for this guide. See :ref:`devguide`. * Help with ... - * :doc:`exploring` - * :doc:`grammar` - * :doc:`compiler` + + * :ref:`internals` + * :ref:`grammar` + * Tool support - * :doc:`gdb` - * :doc:`clang` - * Various tools with configuration files as found in the `Misc directory`_ - * Information about editors and their configurations can be found in the - `wiki <https://wiki.python.org/moin/PythonEditors>`_ -* `python.org maintenance`_ -* :ref:`Search this guide <search>` + * :ref:`gdb` + * :ref:`clang` + * Various tools with configuration files as found in the + :cpy-file:`Misc/` directory + +* `python.org maintenance`_ -Code of Conduct +Code of conduct --------------- + Please note that all interactions on `Python Software Foundation <https://www.python.org/psf-landing/>`__-supported infrastructure is `covered <https://www.python.org/psf/records/board/minutes/2014-01-06/#management-of-the-psfs-web-properties>`__ -by the `PSF Code of Conduct <https://www.python.org/psf/codeofconduct/>`__, +by the `PSF Code of Conduct <https://policies.python.org/python.org/code-of-conduct/>`__, which includes all infrastructure used in the development of Python itself -(e.g. mailing lists, issue trackers, GitHub, etc.). +(for example, Discourse, issue trackers, GitHub, and so on). In general this means everyone is expected to be open, considerate, and respectful of others no matter what their position is within the project. + +Other interpreter implementations +--------------------------------- + +This guide is specifically for contributing to the Python reference interpreter, +also known as CPython (while most of the standard library is written in Python, +the interpreter core is written in C and integrates most easily with the C and +C++ ecosystems). + +There are other Python implementations, each with a different focus. Like +CPython, they always have more things they would like to do than they have +developers to work on them. Some major examples that may be of interest are: + +* PyPy_: A Python interpreter focused on high speed (JIT-compiled) operation + on major platforms. +* GraalPy_: A Python interpreter which has first-class support for + embedding in Java, built on GraalVM. +* Jython_: A Python interpreter focused on good integration with the Java + Virtual Machine (JVM) environment. +* IronPython_: A Python interpreter focused on good integration with the + Common Language Runtime (CLR) provided by .NET and Mono. +* MicroPython_: A tiny Python interpreter with small subset of the Python + standard library that is optimised to run on microcontrollers and in + constrained environments. +* CircuitPython_: A fork of MicroPython designed to simplify experimenting + and learning to code on low-cost microcontroller boards. + + .. _contents: -Full Table of Contents +Full table of contents ---------------------- .. toctree:: - :numbered: :maxdepth: 3 - setup - help - pullrequest - runtests - coverage - docquality - documenting - silencewarnings - fixingissues - tracker - triaging - communication - porting - coredev - developers - committing - devcycle - buildbots - stdlibchanges - langchanges - experts - gdb - exploring - grammar - compiler - extensions - coverity - clang - buildworker - motivations - gitbootcamp - appendix - -.. _Buildbot status: https://www.python.org/dev/buildbot/ -.. _Misc directory: https://github.com/python/cpython/tree/master/Misc -.. _PEPs: https://www.python.org/dev/peps/ + getting-started/index + developer-workflow/index + triage/index + documentation/index + testing/index + development-tools/index + core-team/index + internals + versions + + +.. _Buildbot status: https://buildbot.python.org/ +.. _PEPs: https://peps.python.org/ .. _python.org maintenance: https://pythondotorg.readthedocs.io/ .. _Python: https://www.python.org/ .. _Core Python Mentorship: https://www.python.org/dev/core-mentorship/ -.. _PyPy: http://www.pypy.org/ -.. _Jython: http://www.jython.org/ -.. _IronPython: http://ironpython.net/ -.. _Stackless: http://www.stackless.com/ -.. _Issue tracker: https://bugs.python.org/ -.. _open pull requests: https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Apr%20is%3Aopen%20label%3A%22awaiting%20review%22 +.. _PyPy: https://pypy.org +.. _GraalPy: https://www.graalvm.org/python/ +.. _Jython: https://www.jython.org/ +.. _IronPython: https://ironpython.net/ +.. _MicroPython: https://micropython.org/ +.. _CircuitPython: https://circuitpython.org/ +.. _Issue tracker: https://github.com/python/cpython/issues diff --git a/exploring.rst b/internals.rst similarity index 53% rename from exploring.rst rename to internals.rst index 0aae5c41cb..89897eb19c 100644 --- a/exploring.rst +++ b/internals.rst @@ -1,70 +1,23 @@ -.. _exploring: +.. _internals: -Exploring CPython's Internals -============================= - -This is a quick guide for people who are interested in learning more about -CPython's internals. It provides a summary of the source code structure -and contains references to resources providing a more in-depth view. - - -CPython Source Code Layout --------------------------- - -This guide gives an overview of CPython's code structure. -It serves as a summary of file locations for modules and builtins. - -For Python modules, the typical layout is: - -* :file:`Lib/{<module>}.py` -* :file:`Modules/_{<module>}.c` (if there's also a C accelerator module) -* :file:`Lib/test/test_{<module>}.py` -* :file:`Doc/library/{<module>}.rst` - -For extension-only modules, the typical layout is: - -* :file:`Modules/{<module>}module.c` -* :file:`Lib/test/test_{<module>}.py` -* :file:`Doc/library/{<module>}.rst` - -For builtin types, the typical layout is: - -* :file:`Objects/{<builtin>}object.c` -* :file:`Lib/test/test_{<builtin>}.py` -* :file:`Doc/library/stdtypes.rst` - -For builtin functions, the typical layout is: - -* :file:`Python/bltinmodule.c` -* :file:`Lib/test/test_builtin.py` -* :file:`Doc/library/functions.rst` - -Some exceptions: - -* builtin type ``int`` is at :file:`Objects/longobject.c` -* builtin type ``str`` is at :file:`Objects/unicodeobject.c` -* builtin module ``sys`` is at :file:`Python/sysmodule.c` -* builtin module ``marshal`` is at :file:`Python/marshal.c` -* Windows-only module ``winreg`` is at :file:`PC/winreg.c` - - -Additional References ---------------------- - -For over 20 years the CPython code base has been changing and evolving. -Here's a sample of resources about the architecture of CPython aimed at -building your understanding of both the 2.x and 3.x versions of CPython: +=================== +CPython's internals +=================== +The CPython code base is constantly changing and evolving. +Here's a sample of references about CPython's architecture aimed at +building your understanding of CPython internals and its evolution: .. csv-table:: **Current references** :header: "Title", "Brief", "Author", "Version" :widths: 50, 50, 20, 5 + "`CPython's InternalDocs`_", "Docs on CPython internals maintained in the source tree", "", "" "`A guide from parser to objects, observed using GDB`_", "Code walk from Parser, AST, Sym Table and Objects", Louie Lu, 3.7.a0 "`Green Tree Snakes`_", "The missing Python AST docs", Thomas Kluyver, 3.6 "`Yet another guided tour of CPython`_", "A guide for how CPython REPL works", Guido van Rossum, 3.5 "`Python Asynchronous I/O Walkthrough`_", "How CPython async I/O, generator and coroutine works", Philip Guo, 3.5 - "`Coding Patterns for Python Extensions`_", "Reliable patterns of coding Python Extensions in C", Paul Ross, 3.4 + "`Coding Patterns for Python Extensions`_", "Reliable patterns of coding Python Extensions in C", Paul Ross, 3.9+ "`Your Guide to the CPython Source Code`_", "Your Guide to the CPython Source Code", Anthony Shaw, 3.8 .. csv-table:: **Historical references** @@ -76,6 +29,7 @@ building your understanding of both the 2.x and 3.x versions of CPython: "`A guide from parser to objects, observed using Eclipse`_", "Code walk from Parser, AST, Sym Table and Objects", Prashanth Raghu, 2.7.12 "`CPython internals: A ten-hour codewalk through the Python interpreter source code`_", "Code walk from source code to generators", Philip Guo, 2.7.8 +.. _CPython's InternalDocs: https://github.com/python/cpython/blob/main/InternalDocs/README.md .. _A guide from parser to objects, observed using GDB: https://hackmd.io/s/ByMHBMjFe @@ -83,7 +37,7 @@ building your understanding of both the 2.x and 3.x versions of CPython: .. _Yet another guided tour of CPython: https://paper.dropbox.com/doc/Yet-another-guided-tour-of-CPython-XY7KgFGn88zMNivGJ4Jzv -.. _Python Asynchronous I/O Walkthrough: http://pgbovine.net/python-async-io-walkthrough.htm +.. _Python Asynchronous I/O Walkthrough: https://www.youtube.com/playlist?list=PLpEcQSRWP2IjVRlTUptdD05kG-UkJynQT .. _Coding Patterns for Python Extensions: https://pythonextensionpatterns.readthedocs.io/en/latest/ @@ -95,4 +49,4 @@ building your understanding of both the 2.x and 3.x versions of CPython: .. _A guide from parser to objects, observed using Eclipse: https://docs.google.com/document/d/1nzNN1jeNCC_bg1LADCvtTuGKvcyMskV1w8Ad2iLlwoI/ -.. _CPython internals\: A ten-hour codewalk through the Python interpreter source code: http://pgbovine.net/cpython-internals.htm +.. _CPython internals\: A ten-hour codewalk through the Python interpreter source code: https://www.youtube.com/playlist?list=PLzV58Zm8FuBL6OAv1Yu6AwXZrnsFbbR0S diff --git a/langchanges.rst b/langchanges.rst deleted file mode 100644 index 6a7d1c304a..0000000000 --- a/langchanges.rst +++ /dev/null @@ -1,97 +0,0 @@ -.. _langchanges: - -Changing the Python Language -============================ -On occasion people come up with an idea on how to change or improve Python as a -programming language. This document is meant to explain exactly what changes -have a reasonable chance of being considered and what the process is to propose -changes to the language. - - -What Qualifies --------------- -First and foremost, it must be understood that changes to the Python -programming language are difficult to make. When the language changes, -**every** Python programmer already in existence and all Python programmers to -come will end up eventually learning about the change you want to propose. -Books will need updating, code will be changed, and a new way to do things will -need to be learned. Changes to the Python programming language are never taken -lightly. - -Because of the seriousness that language changes carry, any change must be -beneficial to a large proportion of Python users. If the change only benefits a -small percentage of Python developers then the change will not be made. A good -way to see if your idea would work for a large portion of the Python community -is to ask on :ref:`python-list or python-ideas <communication>`. You can also -go through Python's stdlib and find examples of code which would benefit from -your proposed change (which helps communicate the usefulness of your change to -others). For further guidance, see :ref:`suggesting-changes`. - -Your proposed change also needs to be *Pythonic*. While Guido is the only -person who can truly classify something as Pythonic, you can read the `Zen of -Python`_ for guidance. - -.. _Zen of Python: https://www.python.org/dev/peps/pep-0020/ - - -.. index:: PEP process - -PEP Process ------------ -Once you are certain you have a language change proposal which will appeal to -the general Python community, you can begin the process of officially proposing -the change. This process is the Python Enhancement Proposal (PEP) process. -:PEP:`1` describes it in detail. - -You will first need a PEP that you will present to python-ideas. You may be a -little hazy on the technical details as various core developers can help with -that, but do realize that if you do not present your idea to python-ideas or -python-list ahead of time you may find out it is technically not possible -(e.g., Python's parser will not support the grammar change as it is an LL(1) -parser). Expect extensive comments on the PEP, some of which will be negative. - -Once your PEP has been modified to be of proper quality and to take into -account comments made on python-ideas, it may proceed to python-dev. There it -will be assigned a PEP dictator and another general discussion will occur. Once -again, you will need to modify your PEP to incorporate the large amount of -comments you will receive. - -The PEP dictator decides if your PEP is accepted (typically based on whether -most core developers support the PEP). If that occurs then your proposed -language change will be introduced in the next release of Python. Otherwise -your PEP will be recorded as rejected along with an explanation as to why so -that others do not propose the same language change in the future. - - -.. index:: - single: PEP process - -.. _suggesting-changes: - -Suggesting new features and language changes --------------------------------------------- - -The `python-ideas`_ mailing list is specifically intended for discussion of -new features and language changes. Please don't be disappointed if your -idea isn't met with universal approval: as the long list of Rejected and -Withdrawn PEPs in the `PEP Index`_ attests, and as befits a reasonably mature -programming language, getting significant changes into Python isn't a simple -task. - -If the idea is reasonable, someone will suggest posting it as a feature -request on the `issue tracker`_, or, for larger changes, writing it up as -a `draft PEP`_. - -Sometimes core developers will differ in opinion, or merely be collectively -unconvinced. When there isn't an obvious victor then the -`Status Quo Wins a Stalemate`_ as outlined in the linked post. - -For some examples on language changes that were accepted please read -`Justifying Python Language Changes`_. - -.. _python-ideas: https://mail.python.org/mailman/listinfo/python-ideas -.. _issue tracker: https://bugs.python.org -.. _PEP Index: https://www.python.org/dev/peps/ -.. _draft PEP: https://www.python.org/dev/peps/pep-0001/ -.. _Status Quo Wins a Stalemate: https://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate.html -.. _Justifying Python Language Changes: https://www.curiousefficiency.org/posts/2011/02/justifying-python-language-changes.html diff --git a/links.rst b/links.rst new file mode 100644 index 0000000000..4f0eb58814 --- /dev/null +++ b/links.rst @@ -0,0 +1,6 @@ +.. Links for use anywhere. Include this file to use them. + +.. _issue tracker: https://github.com/python/cpython/issues + +.. _clang: https://clang.llvm.org/ +.. _ccache: https://ccache.dev/ diff --git a/make.bat b/make.bat index aeb35f313f..fec822e953 100644 --- a/make.bat +++ b/make.bat @@ -11,19 +11,17 @@ if "%PYTHON%" == "" ( ) set BUILDDIR=_build -set ALLSPHINXOPTS=-d %BUILDDIR%/doctrees %SPHINXOPTS% . -if NOT "%PAPER%" == "" ( - set ALLSPHINXOPTS=-D latex_paper_size=%PAPER% %ALLSPHINXOPTS% -) +set SPHINXOPTS=--fail-on-warning +set _ALL_SPHINX_OPTS=%SPHINXOPTS% if "%1" == "check" goto check -if "%1" == "serve" goto serve if "%1" == "" goto help if "%1" == "help" ( :help echo.Please use `make ^<target^>` where ^<target^> is one of echo. html to make standalone HTML files + echo. htmlview to open the index page built by the html target in your browser echo. dirhtml to make HTML files named index.html in directories echo. singlehtml to make a single large HTML file echo. pickle to make pickle files @@ -38,8 +36,7 @@ if "%1" == "help" ( echo. changes to make an overview over all changed/added/deprecated items echo. linkcheck to check all external links for integrity echo. doctest to run all doctests embedded in the documentation if enabled - echo. check to check for stylistic and formal issues using rstlint - echo. serve to serve devguide on the localhost ^(8000^) + echo. check to check for stylistic and formal issues using sphinx-lint goto end ) @@ -49,7 +46,15 @@ if "%1" == "clean" ( goto end ) -rem Targets other than "clean", "check", "serve", "help", or "" need the +if "%1" == "versions" ( + %PYTHON% _tools/generate_release_cycle.py + if errorlevel 1 exit /b 1 + echo. + echo Release cycle data generated. + goto end +) + +rem Targets other than "clean", "check", "help", or "" need the rem Sphinx build command, which the user may define via SPHINXBUILD. if not defined SPHINXBUILD ( @@ -62,141 +67,44 @@ if not defined SPHINXBUILD ( ) set PYTHON=venv\Scripts\python set SPHINXBUILD=venv\Scripts\sphinx-build + set SPHINXAUTOBUILD=venv\Scripts\sphinx-autobuild ) -if "%1" == "html" ( - %SPHINXBUILD% -b html %ALLSPHINXOPTS% %BUILDDIR%/html - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The HTML pages are in %BUILDDIR%/html. - goto end -) - -if "%1" == "dirhtml" ( - %SPHINXBUILD% -b dirhtml %ALLSPHINXOPTS% %BUILDDIR%/dirhtml - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The HTML pages are in %BUILDDIR%/dirhtml. - goto end -) +if "%1" == "htmlview" ( + cmd /C %this% html -if "%1" == "singlehtml" ( - %SPHINXBUILD% -b singlehtml %ALLSPHINXOPTS% %BUILDDIR%/singlehtml - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The HTML pages are in %BUILDDIR%/singlehtml. - goto end -) - -if "%1" == "pickle" ( - %SPHINXBUILD% -b pickle %ALLSPHINXOPTS% %BUILDDIR%/pickle - if errorlevel 1 exit /b 1 - echo. - echo.Build finished; now you can process the pickle files. - goto end -) - -if "%1" == "json" ( - %SPHINXBUILD% -b json %ALLSPHINXOPTS% %BUILDDIR%/json - if errorlevel 1 exit /b 1 - echo. - echo.Build finished; now you can process the JSON files. - goto end -) - -if "%1" == "htmlhelp" ( - %SPHINXBUILD% -b htmlhelp %ALLSPHINXOPTS% %BUILDDIR%/htmlhelp - if errorlevel 1 exit /b 1 - echo. - echo.Build finished; now you can run HTML Help Workshop with the ^ -.hhp project file in %BUILDDIR%/htmlhelp. - goto end -) - -if "%1" == "qthelp" ( - %SPHINXBUILD% -b qthelp %ALLSPHINXOPTS% %BUILDDIR%/qthelp - if errorlevel 1 exit /b 1 - echo. - echo.Build finished; now you can run "qcollectiongenerator" with the ^ -.qhcp project file in %BUILDDIR%/qthelp, like this: - echo.^> qcollectiongenerator %BUILDDIR%\qthelp\PythonDevelopersGuide.qhcp - echo.To view the help file: - echo.^> assistant -collectionFile %BUILDDIR%\qthelp\PythonDevelopersGuide.ghc - goto end -) - -if "%1" == "devhelp" ( - %SPHINXBUILD% -b devhelp %ALLSPHINXOPTS% %BUILDDIR%/devhelp - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. - goto end -) - -if "%1" == "epub" ( - %SPHINXBUILD% -b epub %ALLSPHINXOPTS% %BUILDDIR%/epub - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The epub file is in %BUILDDIR%/epub. - goto end -) - -if "%1" == "latex" ( - %SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex - if errorlevel 1 exit /b 1 - echo. - echo.Build finished; the LaTeX files are in %BUILDDIR%/latex. - goto end -) - -if "%1" == "text" ( - %SPHINXBUILD% -b text %ALLSPHINXOPTS% %BUILDDIR%/text - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The text files are in %BUILDDIR%/text. - goto end -) - -if "%1" == "man" ( - %SPHINXBUILD% -b man %ALLSPHINXOPTS% %BUILDDIR%/man - if errorlevel 1 exit /b 1 - echo. - echo.Build finished. The manual pages are in %BUILDDIR%/man. - goto end -) + if EXIST "%BUILDDIR%\html\index.html" ( + echo.Opening "%BUILDDIR%\html\index.html" in the default web browser... + start "" "%BUILDDIR%\html\index.html" + ) -if "%1" == "changes" ( - %SPHINXBUILD% -b changes %ALLSPHINXOPTS% %BUILDDIR%/changes - if errorlevel 1 exit /b 1 - echo. - echo.The overview file is in %BUILDDIR%/changes. goto end ) -if "%1" == "linkcheck" ( - %SPHINXBUILD% -b linkcheck %ALLSPHINXOPTS% %BUILDDIR%/linkcheck - if errorlevel 1 exit /b 1 - echo. - echo.Link check complete; look for any errors in the above output ^ -or in %BUILDDIR%/linkcheck/output.txt. - goto end +if "%1" == "htmllive" ( + %SPHINXAUTOBUILD% --re-ignore="/\.idea/|/venv/" --open-browser --delay 0 --port 55301 . %BUILDDIR%/html + if errorlevel 1 exit /b 1 + goto end ) -if "%1" == "doctest" ( - %SPHINXBUILD% -b doctest %ALLSPHINXOPTS% %BUILDDIR%/doctest - if errorlevel 1 exit /b 1 - echo. - echo.Testing of doctests in the sources finished, look at the ^ -results in %BUILDDIR%/doctest/output.txt. - goto end -) +%SPHINXBUILD% -M %1 "." %BUILDDIR% %_ALL_SPHINX_OPTS% +goto end :check -cmd /C %PYTHON% tools\rstlint.py -i tools -i venv -goto end +if not defined SPHINXLINT ( + rem If it is not defined, we build in a virtual environment + if not exist venv ( + echo. Setting up the virtual environment + %PYTHON% -m venv venv + echo. Installing requirements + venv\Scripts\python -m pip install -r requirements.txt + ) + set PYTHON=venv\Scripts\python + set SPHINXLINT=%PYTHON% -m sphinxlint +) -:serve -cmd /C %PYTHON% tools\serve.py %BUILDDIR%\html +rem Ignore the tools and venv dirs and check that the default role is not used. +cmd /S /C "%SPHINXLINT% -i tools -i venv --enable default-role" goto end :end diff --git a/make.ps1 b/make.ps1 new file mode 100644 index 0000000000..c8ad842c9b --- /dev/null +++ b/make.ps1 @@ -0,0 +1,100 @@ +# Command file for Sphinx documentation + +param ( + [string]$target = "help" +) + +Set-StrictMode -Version 3.0 +$ErrorActionPreference = "Stop" + +$BUILDDIR = "_build" +$SPHINXOPTS = "--fail-on-warning" +$_ALL_SPHINX_OPTS = $SPHINXOPTS + +$_PYTHON = $Env:PYTHON ?? "py -3" +$_SPHINX_BUILD = $Env:SPHINXBUILD ?? ".\venv\Scripts\sphinx-build" +$_SPHINX_LINT = $Env:SPHINXLINT ?? ".\venv\Scripts\sphinx-lint" +$_VENV_DIR = "venv" + +function New-VirtualEnviromnent +{ + Write-Host "Creating venv in $_VENV_DIR" + if (Get-Command "uv" -ErrorAction SilentlyContinue) { + & uv venv $_VENV_DIR + $Env:VIRTUAL_ENV = $_VENV_DIR + & uv pip install -r requirements.txt + Remove-Item Env:VIRTUAL_ENV + } else { + & $_PYTHON -m venv venv + Write-Host "Installing requirements" + & venv\Scripts\python -m pip install -r requirements.txt + $Script:_PYTHON = "venv\Scripts\python" + } +} + +function Invoke-SphinxBuild +{ + param ( + [string]$BuilderName, + [string]$BuildDir, + [string]$Options + ) + if (-Not (Test-Path -Path $_VENV_DIR)) { New-VirtualEnviromnent } + & $_SPHINX_BUILD -M $BuilderName "." $BuildDir $Options.Split(" ") +} + +function Invoke-Check { + if (-Not (Test-Path -Path $_VENV_DIR)) { New-VirtualEnviromnent } + & $_SPHINX_LINT -i tools -i venv --enable default-role +} + +if ($target -Eq "help") { + Write-Host "Please use `make <target>` where <target> is one of" + Write-Host " venv to create a venv with necessary tools" + Write-Host " html to make standalone HTML files" + Write-Host " linkcheck to check all external links for integrity" + Write-Host " htmlview to open the index page built by the html target in your browser" + Write-Host " clean to remove the venv and build files" + Write-Host " check to check for stylistic and formal issues using sphinx-lint" + Write-Host " versions to update release cycle after changing release-cycle.json" + Exit +} + +if ($target -Eq "clean") { + $ToClean = @( + $BUILDDIR, + $_VENV_DIR, + "include/branches.csv", "include/end-of-life.csv", + "_static/release-cycle.svg", "_static/release-cycle-all.svg" + ) + foreach ($item in $ToClean) { + if (Test-Path -Path $item) { + Remove-Item -Path $item -Force -Recurse + } + } + Exit $LASTEXITCODE +} + +if ($target -Eq "check") { + Invoke-Check + Exit $LASTEXITCODE +} + +if ($target -Eq "versions") { + & $_PYTHON _tools/generate_release_cycle.py + if ($LASTEXITCODE -Ne 0) { exit 1 } + Write-Host "Release cycle data generated." + Exit $LASTEXITCODE +} + +if ($target -Eq "htmlview") { + Invoke-SphinxBuild "html" "$BUILDDIR" "$_ALL_SPHINX_OPTS" + if (Test-Path -Path "$BUILDDIR\html\index.html") { + Write-Host "Opening $BUILDDIR\html\index.html in the default web browser..." + Start-Process "$BUILDDIR\html\index.html" + } + Exit $LASTEXITCODE +} + +Invoke-SphinxBuild "$target" "$BUILDDIR" "$_ALL_SPHINX_OPTS" +Exit $LASTEXITCODE diff --git a/pullrequest.rst b/pullrequest.rst deleted file mode 100644 index cdeab54b32..0000000000 --- a/pullrequest.rst +++ /dev/null @@ -1,447 +0,0 @@ -.. _patch: - -Lifecycle of a Pull Request -=========================== - -.. highlight:: bash - -Introduction ------------- - -CPython uses a workflow based on pull requests. What this means is -that you create a branch in Git, make your changes, push those changes -to your fork on GitHub (``origin``), and then create a pull request against -the official CPython repository (``upstream``). - - -.. _pullrequest-quickguide: - -Quick Guide ------------ - -`Clear communication`_ is key to contributing to any project, especially an -`Open Source`_ project like CPython. - -Here is a quick overview of how you can contribute to CPython: - -#. `Create an issue`_ that describes your change [*]_ - -#. :ref:`Create a new branch in Git <pullrequest-steps>` - -#. Work on changes (e.g. fix a bug or add a new feature) - -#. :ref:`Run tests <runtests>` and ``make patchcheck`` - -#. :ref:`Commit <commit-changes>` and :ref:`push <push-changes>` - changes to your GitHub fork - -#. `Create Pull Request`_ on GitHub to merge a branch from your fork - -#. Review and address `comments on your Pull Request`_ - -#. When your changes are merged, you can :ref:`delete the PR branch - <deleting_branches>` - -#. Celebrate contributing to CPython! :) - -.. [*] If an issue is trivial (e.g. typo fixes), or if an issue already exists, - you can skip this step. - -.. _Clear communication: https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution -.. _Open Source: https://opensource.guide/ -.. _create an issue: https://bugs.python.org/ -.. _CPython: https://github.com/python/cpython -.. _use HTTPS: https://help.github.com/articles/which-remote-url-should-i-use/ -.. _Create Pull Request: https://help.github.com/articles/creating-a-pull-request/ -.. _comments on your Pull Request: https://help.github.com/articles/commenting-on-a-pull-request/ - - -.. _pullrequest-steps: - -Step-by-step Guide ------------------- - -You should have already :ref:`set up your system <setup>`, -:ref:`got the source code <checkout>`, and :ref:`built Python <compiling>`. - -* Update data from your ``upstream`` repository:: - - git fetch upstream - -* Create a new branch in your local clone:: - - git checkout -b <branch-name> upstream/master - -* Make changes to the code, and use ``git status`` and ``git diff`` to see them. - - (Learn more about :ref:`good-prs`) - -* Make sure the changes are fine and don't cause any test failure:: - - make patchcheck - ./python -m test - - (Learn more about :ref:`patchcheck` and about :doc:`runtests`) - -* Once you are satisfied with the changes, add the files and commit them:: - - git add <filenames> - git commit -m '<message>' - - (Learn more about :ref:`good-commits`) - -* Then push your work to your GitHub fork:: - - git push origin <branch-name> - -* If someone else added new changesets and you get an error:: - - git fetch upstream - git rebase upstream/master - git push --force-with-lease origin <branch-name> - -* Finally go on :samp:`https://github.com/{<your-username>}/cpython`: you will - see a box with the branch you just pushed and a green button that allows - you to create a pull request against the official CPython repository. - -* When people start adding review comments, you can address them by switching - to your branch, making more changes, committing them, and pushing them to - automatically update your PR:: - - git checkout <branch-name> - # make changes and run tests - git add <filenames> - git commit -m '<message>' - git push origin <branch-name> - -* After your PR has been accepted and merged, you can :ref:`delete the branch - <deleting_branches>`:: - - git branch -D <branch-name> # delete local branch - git push origin -d <branch-name> # delete remote branch - -.. note:: - You can still upload a patch to bugs.python.org_, but the GitHub pull request - workflow is **strongly** preferred. - - -.. _good-prs: - -Making Good PRs ---------------- - -When creating a pull request for submission, there are several things that you -should do to help ensure that your pull request is accepted. - -First, make sure to follow Python's style guidelines. For Python code you -should follow :PEP:`8`, and for C code you should follow :PEP:`7`. If you have -one or two discrepancies those can be fixed by the core developer who merges -your pull request. But if you have systematic deviations from the style guides -your pull request will be put on hold until you fix the formatting issues. - -Second, be aware of backwards-compatibility considerations. While the core -developer who eventually handles your pull request will make the final call on -whether something is acceptable, thinking about backwards-compatibility early -will help prevent having your pull request rejected on these grounds. Put -yourself in the shoes of someone whose code will be broken by the change(s) -introduced by the pull request. It is quite likely that any change made will -break someone's code, so you need to have a good reason to make a change as -you will be forcing someone to update their code. (This obviously does not -apply to new classes or functions; new arguments should be optional and have -default values which maintain the existing behavior.) If in doubt, have a look -at :PEP:`387` or :ref:`discuss <communication>` the issue with experienced -developers. - -Third, make sure you have proper tests to verify your pull request works as -expected. Pull requests will not be accepted without the proper tests! - -Fourth, make sure the entire test suite :ref:`runs <runtests>` **without -failure** because of your changes. It is not sufficient to only run whichever -test seems impacted by your changes, because there might be interferences -unknown to you between your changes and some other part of the interpreter. - -Fifth, proper :ref:`documentation <documenting>` -additions/changes should be included. - - -.. _patchcheck: - -``patchcheck`` --------------- - -``patchcheck`` is a simple automated patch checklist that guides a developer -through the common patch generation checks. To run ``patchcheck``: - - On *UNIX* (including Mac OS X):: - - make patchcheck - - On *Windows* (after any successful build): - - .. code-block:: dosbatch - - python.bat Tools\scripts\patchcheck.py - -The automated patch checklist runs through: - -* Are there any whitespace problems in Python files? - (using ``Tools/scripts/reindent.py``) -* Are there any whitespace problems in C files? -* Are there any whitespace problems in the documentation? - (using ``Tools/scripts/reindent-rst.py``) -* Has the documentation been updated? -* Has the test suite been updated? -* Has an entry under ``Misc/NEWS.d/next`` been added? -* Has ``Misc/ACKS`` been updated? -* Has ``configure`` been regenerated, if necessary? -* Has ``pyconfig.h.in`` been regenerated, if necessary? - -The automated patch check doesn't actually *answer* all of these -questions. Aside from the whitespace checks, the tool is -a memory aid for the various elements that can go into -making a complete patch. - - -.. _good-commits: - -Making Good Commits -------------------- - -Each feature or bugfix should be addressed by a single pull request, -and for each pull request there may be several commits. In particular: - -* Do **not** fix more than one issue in the same commit (except, - of course, if one code change fixes all of them). -* Do **not** do cosmetic changes to unrelated code in the same - commit as some feature/bugfix. - -Commit messages should follow the following structure:: - - bpo-42: the spam module is now more spammy (GH-NNNN) - - The spam module sporadically came up short on spam. This change - raises the amount of spam in the module by making it more spammy. - -The first line or sentence is meant to be a dense, to-the-point explanation -of what the purpose of the commit is. If this is not enough detail for a -commit, a new paragraph(s) can be added to explain in proper depth what has -happened (detail should be good enough that a core developer reading the -commit message understands the justification for the change). - -Check :ref:`the git bootcamp <accepting-and-merging-a-pr>` for further -instructions on how the commit message should look like when merging a pull -request. - - -.. _cla: - -Licensing ---------- - -To accept your change we must have your formal approval for distributing -your work under the `PSF license`_. Therefore, you need to sign a -`contributor agreement`_ which allows the `Python Software Foundation`_ to -license your code for use with Python (you retain the copyright). - -.. note:: - You only have to sign this document once, it will then apply to all - your further contributions to Python. - -Here are the steps needed in order to sign the CLA: - -1. If you don't have an account on `bugs.python.org <https://bugs.python.org>`_ - (aka b.p.o), please - `register <https://bugs.python.org/user?@template=register>`_ to create one. - -2. Make sure your GitHub username is listed in the `"Your Details" - <https://cloud.githubusercontent.com/assets/2680980/23276970/d14a380c-f9d1-11e6-883d-e13b6b211239.png>`_ - section at b.p.o. - -3. Fill out and sign the PSF `contributor form`_. The "bugs.python.org username" - requested by the form is the "Login name" field under "Your Details". - -After signing the CLA, please **wait at least one US business day** and -then check the status by going to the `check-python-cla <https://check-python-cla.herokuapp.com>`_ -website. The check will also be run automatically the next time you push changes -to your PR. - - -.. _PSF license: https://docs.python.org/dev/license.html#terms-and-conditions-for-accessing-or-otherwise-using-python -.. _contributor agreement: https://www.python.org/psf/contrib/ -.. _contributor form: https://www.python.org/psf/contrib/contrib-form/ -.. _Python Software Foundation: https://www.python.org/psf/ - - -Submitting ----------- - -Once you are satisfied with your work you will want to commit your -changes to your branch. In general you can run ``git commit -a`` and -that will commit everything. You can always run ``git status`` to see -what changes are outstanding. - -When all of your changes are committed (i.e. ``git status`` doesn't -list anything), you will want to push your branch to your fork:: - - git push origin <branch name> - -This will get your changes up to GitHub. - -Now you want to -`create a pull request from your fork -<https://help.github.com/articles/creating-a-pull-request-from-a-fork/>`_. -If this is a pull request in response to a pre-existing issue on the -`issue tracker`_, please make sure to reference the issue number using -``bpo-NNNN`` in the pull request title or message. - -If this is a pull request for an unreported issue (assuming you already -performed a search on the issue tracker for a pre-existing issue), create a -new issue and reference it in the pull request. Please fill in as much -relevant detail as possible to prevent reviewers from having to delay -reviewing your pull request because of lack of information. - -If this issue is so simple that there's no need for an issue to track -any discussion of what the pull request is trying to solve (e.g. fixing a -spelling mistake), then the pull request needs to have the "skip issue" label -added to it by someone with commit access. - -Your pull request may involve several commits as a result of addressing code -review comments. Please keep the commit history in the pull request intact by -not squashing, amending, or anything that would require a force push to GitHub. -A detailed commit history allows reviewers to view the diff of one commit to -another so they can easily verify whether their comments have been addressed. -The commits will be squashed when the pull request is merged. - - -.. _issue tracker: https://bugs.python.org - -Converting an Existing Patch from b.p.o to GitHub -------------------------------------------------- - -When a patch exists in the `issue tracker`_ that should be converted into a -GitHub pull request, please first ask the original patch author to prepare -their own pull request. If the author does not respond after a week, it is -acceptable for another contributor to prepare the pull request based on the -existing patch. In this case, both parties should sign the :ref:`CLA <cla>`. -When creating a pull request based on another person's patch, provide -attribution to the original patch author by adding "Co-authored-by: -Author Name <email_address> ." to the pull request description and commit message. -See `the GitHub article <https://help.github.com/articles/creating-a-commit-with-multiple-authors/>`_ -on how to properly add the co-author info. - -See also :ref:`Applying a Patch from Mercurial to Git <git_from_mercurial>`. - -Reviewing ---------- - -To begin with, please be patient! There are many more people -submitting pull requests than there are people capable of reviewing -your pull request. Getting your pull request reviewed requires a -reviewer to have the spare time and motivation to look at your pull -request (we cannot force anyone to review pull requests and no one is -employed to look at pull requests). If your pull request has not -received any notice from reviewers (i.e., no comment made) after one -month, first "ping" the issue on the `issue tracker`_ to remind the -nosy list that the pull request needs a review. If you don't get a response -within a week after pinging the issue, then you can try emailing -python-dev@python.org to ask for someone to review your pull request. - -When someone does manage to find the time to look at your pull request -they will most likely make comments about how it can be improved -(don't worry, even core developers of Python have their pull requests sent -back to them for changes). It is then expected that you update your -pull request to address these comments, and the review process will -thus iterate until a satisfactory solution has emerged. - -.. _how-to-review-a-pull-request: - - -How to Review a Pull Request -'''''''''''''''''''''''''''' - -One of the bottlenecks in the Python development -process is the lack of code reviews. -If you browse the bug tracker, you will see that numerous issues -have a fix, but cannot be merged into the main source code repository, -because no one has reviewed the proposed solution. -Reviewing a pull request can be just as informative as providing a -pull request and it will allow you to give constructive comments on -another developer's work. This guide provides a checklist for -submitting a code review. It is a common misconception that in order -to be useful, a code review has to be perfect. This is not the case at -all! It is helpful to just test the pull request and/or play around with the -code and leave comments in the pull request or issue tracker. - -1. If you have not already done so, get a copy of the CPython repository - by following the :ref:`setup guide <setup>`, build it and run the tests. - -2. Check the bug tracker to see what steps are necessary to reproduce - the issue and confirm that you can reproduce the issue in your version - of the Python REPL (the interactive shell prompt), which you can launch - by executing ./python inside the repository. - -3. Checkout and apply the pull request (Please refer to the instruction - :ref:`git_pr`) - -4. If the changes affect any C file, run the build again. - -5. Launch the Python REPL (the interactive shell prompt) and check if - you can reproduce the issue. Now that the pull request has been applied, - the issue should be fixed (in theory, but mistakes do happen! A good review - aims to catch these before the code is merged into the Python repository). - You should also try to see if there are any corner cases in this or related - issues that the author of the fix may have missed. - -6. If you have time, run the entire test suite. If you are pressed for time, - run the tests for the module(s) where changes were applied. - However, please be aware that if you are recommending a pull request as - 'merge-ready', you should always make sure the entire test suite passes. - -Leaving a Pull Request Review on GitHub ---------------------------------------- - -When you review a pull request, you should provide additional details and context -of your review process. - -Instead of simply "approving" the pull request, leave comments. For example: - -#. If you tested the PR, report the result and the system and version tested on, - such as 'Windows 10', 'Ubuntu 16.4', or 'Mac High Sierra'. - -#. If you request changes, try to suggest how. - -#. Comment on what is "good" about the pull request, not just the "bad". Doing - so will make it easier for the PR author to find the good in your comments. - -Dismissing Review from Another Core Developer ---------------------------------------------- - -A core developer can dismiss another core developer's review if they confirmed -that the requested changes have been made. When a core developer has assigned -the PR to themselves, then it is a sign that they are actively looking after -the PR, and their review should not be dismissed. - - -Committing/Rejecting --------------------- - -Once your pull request has reached an acceptable state (and thus considered -"accepted"), it will either be merged or rejected. If it is rejected, please -do not take it personally! Your work is still appreciated regardless of whether -your pull request is merged. Balancing what *does* and *does not* go into -Python is tricky and we simply cannot accept everyone's contributions. - -But if your pull request is merged it will then go into Python's -:abbr:`VCS (version control system)` to be released -with the next major release of Python. It may also be backported to older -versions of Python as a bugfix if the core developer doing the merge believes -it is warranted. - - -Crediting ---------- - -Non-trivial contributions are credited in the ``Misc/ACKS`` file (and, most -often, in a contribution's news entry as well). You may be -asked to make these edits on the behalf of the core developer who -accepts your pull request. diff --git a/requirements.txt b/requirements.txt index 2a84c8173d..3b40508f67 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,2 +1,11 @@ -Sphinx -python-docs-theme +furo>=2022.6.4 +jinja2 +linklint +sphinx-autobuild>=2024.9.19 +sphinx-inline-tabs>=2023.4.21 +sphinx-lint==1.0.2 +sphinx-notfound-page>=1.0.0 +sphinx_copybutton>=0.3.3 +sphinxext-opengraph>=0.13.0 +sphinxext-rediraffe +Sphinx>=8.2.3 diff --git a/runtests.rst b/runtests.rst deleted file mode 100644 index ef410bdd23..0000000000 --- a/runtests.rst +++ /dev/null @@ -1,135 +0,0 @@ -.. _runtests: - -Running & Writing Tests -======================= - -.. note:: - - This document assumes you are working from an - :ref:`in-development <indevbranch>` checkout of Python. If you - are not then some things presented here may not work as they may depend - on new features not available in earlier versions of Python. - -Running -------- - -The shortest, simplest way of running the test suite is the following command -from the root directory of your checkout (after you have -:ref:`built Python <compiling>`):: - - ./python -m test - -You may need to change this command as follows throughout this section. -On :ref:`most <mac-python.exe>` Mac OS X systems, replace :file:`./python` -with :file:`./python.exe`. On Windows, use :file:`python.bat`. If using -Python 2.7, replace ``test`` with ``test.regrtest``. - -If you don't have easy access to a command line, you can run the test suite from -a Python or IDLE shell:: - - >>> from test import autotest - -This will run the majority of tests, but exclude a small portion of them; these -excluded tests use special kinds of resources: for example, accessing the -Internet, or trying to play a sound or to display a graphical interface on -your desktop. They are disabled by default so that running the test suite -is not too intrusive. To enable some of these additional tests (and for -other flags which can help debug various issues such as reference leaks), read -the help text:: - - ./python -m test -h - -If you want to run a single test file, simply specify the test file name -(without the extension) as an argument. You also probably want to enable -verbose mode (using ``-v``), so that individual failures are detailed:: - - ./python -m test -v test_abc - -To run a single test case, use the ``unittest`` module, providing the import -path to the test case:: - - ./python -m unittest -v test.test_abc.TestABC - -If you have a multi-core or multi-CPU machine, you can enable parallel testing -using several Python processes so as to speed up things:: - - ./python -m test -j0 - -If you are running a version of Python prior to 3.3 you must specify the number -of processes to run simultaneously (e.g. ``-j2``). - -.. _strenuous_testing: - -Finally, if you want to run tests under a more strenuous set of settings, you -can run ``test`` as:: - - ./python -bb -E -Wd -m test -r -w -uall - -The various extra flags passed to Python cause it to be much stricter about -various things (the ``-Wd`` flag should be ``-W error`` at some point, but the -test suite has not reached a point where all warnings have been dealt with and -so we cannot guarantee that a bug-free Python will properly complete a test run -with ``-W error``). The ``-r`` flag to the test runner causes it to run tests in -a more random order which helps to check that the various tests do not interfere -with each other. The ``-w`` flag causes failing tests to be run again to see -if the failures are transient or consistent. -The ``-uall`` flag allows the use of all available -resources so as to not skip tests requiring, e.g., Internet access. - -To check for reference leaks (only needed if you modified C code), use the -``-R`` flag. For example, ``-R 3:2`` will first run the test 3 times to settle -down the reference count, and then run it 2 more times to verify if there are -any leaks. - -You can also execute the ``Tools/scripts/run_tests.py`` script as found in a -CPython checkout. The script tries to balance speed with thoroughness. But if -you want the most thorough tests you should use the strenuous approach shown -above. - - -Unexpected Skips -^^^^^^^^^^^^^^^^ - -Sometimes when running the test suite, you will see "unexpected skips" -reported. These represent cases where an entire test module has been -skipped, but the test suite normally expects the tests in that module to -be executed on that platform. - -Often, the cause is that an optional module hasn't been built due to missing -build dependencies. In these cases, the missing module reported when the test -is skipped should match one of the modules reported as failing to build when -:ref:`compiling`. - -In other cases, the skip message should provide enough detail to help figure -out and resolve the cause of the problem (for example, the default security -settings on some platforms will disallow some tests) - - -Writing -------- - -Writing tests for Python is much like writing tests for your own code. Tests -need to be thorough, fast, isolated, consistently repeatable, and as simple as -possible. We try to have tests both for normal behaviour and for error -conditions. Tests live in the ``Lib/test`` directory, where every file that -includes tests has a ``test_`` prefix. - -One difference with ordinary testing is that you are encouraged to rely on the -:py:mod:`test.support` module. It contains various helpers that are tailored to -Python's test suite and help smooth out common problems such as platform -differences, resource consumption and cleanup, or warnings management. -That module is not suitable for use outside of the standard library. - -When you are adding tests to an existing test file, it is also recommended -that you study the other tests in that file; it will teach you which precautions -you have to take to make your tests robust and portable. - - -Benchmarks ----------- -Benchmarking is useful to test that a change does not degrade performance. - -`The Python Benchmark Suite <https://github.com/python/performance>`_ -has a collection of benchmarks for all Python implementations. Documentation -about running the benchmarks is in the `README.txt -<https://github.com/python/performance/blob/master/README.rst>`_ of the repo. diff --git a/setup.rst b/setup.rst deleted file mode 100644 index 16cf82d303..0000000000 --- a/setup.rst +++ /dev/null @@ -1,550 +0,0 @@ -.. _setup: - -=============== -Getting Started -=============== - -.. highlight:: console - -These instructions cover how to get a working copy of the source code and a -compiled version of the CPython interpreter (CPython is the version of Python -available from https://www.python.org/). It also gives an overview of the -directory structure of the CPython source code. - -Alternatively, if you have `Docker <https://www.docker.com/>`_ installed you -might want to use `our official images -<https://gitlab.com/python-devs/ci-images/blob/master/README.md>`_. These -contain the latest releases of several Python versions, along with git head, -and are provided for development and testing purposes only. - -.. seealso:: - - The :ref:`quick-reference` gives brief summary of the process from - installing git to submitting a pull request. - -.. _vcsetup: - -Install ``git`` -=============== - -CPython is developed using `git <https://git-scm.com>`_ for version control. The git -command line program is named ``git``; this is also used to refer to git -itself. git is easily available for all common operating systems. - -- **Install** - - As the CPython repo is hosted on GitHub, please refer to either the - `GitHub setup instructions <https://help.github.com/articles/set-up-git/>`_ - or the `git project instructions <https://git-scm.com>`_ for step-by-step - installation directions. You may also want to consider a graphical client - such as `TortoiseGit <https://tortoisegit.org/>`_ or - `GitHub Desktop <https://desktop.github.com/>`_. - -- **Configure** - - Configure :ref:`your name and email <set-up-name-email>` and create - `an SSH key <https://help.github.com/articles/adding-a-new-ssh-key-to-your-github-account/>`_ - as this will allow you to interact with GitHub without typing a username - and password each time you execute a command, such as ``git pull``, - ``git push``, or ``git fetch``. On Windows, you should also - :ref:`enable autocrlf <autocrlf>`. - - -.. _checkout: - -Get the source code -=================== - -The CPython repo is hosted on GitHub. To get a copy of the source code you should -:ref:`fork the Python repository on GitHub <fork-cpython>`, :ref:`create a local -clone of your personal fork, and configure the remotes <clone-your-fork>`. - -You will only need to execute these steps once: - -1. Go to https://github.com/python/cpython. - -2. Press :guilabel:`Fork` on the top right. - -3. When asked where to fork the repository, choose to fork it to your username. - -4. Your fork will be created at :samp:`https://github.com/{<username>}/cpython`. - -5. Clone your GitHub fork (replace ``<username>`` with your username):: - - $ git clone git@github.com:<username>/cpython.git - - (You can use both SSH-based or HTTPS-based URLs.) - -6. Configure an ``upstream`` remote:: - - $ cd cpython - $ git remote add upstream git@github.com:python/cpython.git - -7. Verify that your setup is correct:: - - $ git remote -v - origin git@github.com:<your-username>/cpython.git (fetch) - origin git@github.com:<your-username>/cpython.git (push) - upstream git@github.com:python/cpython.git (fetch) - upstream git@github.com:python/cpython.git (push) - -If you did everything correctly, you should now have a copy of the code -in the ``cpython`` directory and two remotes that refer to your own GitHub fork -(``origin``) and the official CPython repository (``upstream``). - -.. XXX move the text below in pullrequest - -If you want a working copy of an already-released version of Python, -i.e., a version in :ref:`maintenance mode <maintbranch>`, you can checkout -a release branch. For instance, to checkout a working copy of Python 3.7, -do ``git checkout 3.7``. - -You will need to re-compile CPython when you do such an update. - -Do note that CPython will notice that it is being run from a working copy. -This means that if you edit CPython's source code in your working copy, -changes to Python code will be picked up by the interpreter for immediate -use and testing. (If you change C code, you will need to recompile the -affected files as described below.) - -Patches for the documentation can be made from the same repository; see -:ref:`documenting`. - - -.. _compiling: - -Compile and build -================= - -CPython provides several compilation flags which help with debugging various -things. While all of the known flags can be found in the -``Misc/SpecialBuilds.txt`` file, the most critical one is the ``Py_DEBUG`` flag -which creates what is known as a "pydebug" build. This flag turns on various -extra sanity checks which help catch common issues. The use of the flag is so -common that turning on the flag is a basic compile option. - -You should always develop under a pydebug build of CPython (the only instance of -when you shouldn't is if you are taking performance measurements). Even when -working only on pure Python code the pydebug build provides several useful -checks that one should not skip. - - -.. _unix-compiling: - -UNIX ----- - -The core CPython interpreter only needs a C compiler to be built, -however, some of the extension modules will need development headers -for additional libraries (such as the ``zlib`` library for compression). -Depending on what you intend to work on, you might need to install these -additional requirements so that the compiled interpreter supports the -desired features. - -If you want to install these optional dependencies, consult the -:ref:`build-dependencies` section below. - -If you don't need to install them, the basic steps for building Python -for development is to configure it and then compile it. - -Configuration is typically: - -.. code-block:: bash - - ./configure --with-pydebug - -More flags are available to ``configure``, but this is the minimum you should -do to get a pydebug build of CPython. - -Once ``configure`` is done, you can then compile CPython with: - -.. code-block:: bash - - make -s -j2 - -This will build CPython with only warnings and errors being printed to -stderr and utilize up to 2 CPU cores. If you are using a multi-core machine -with more than 2 cores (or a single-core machine), you can adjust the number -passed into the ``-j`` flag to match the number of cores you have (or if your -version of Make supports it, you can use ``-j`` without a number and Make -will not limit the number of steps that can run simultaneously.). - -At the end of the build you should see a success message, possibly followed -by a list of extension modules that haven't been built because their -dependencies were missing: - -.. code-block:: none - - Python build finished successfully! - The necessary bits to build these optional modules were not found: - _bz2 _dbm _gdbm - _lzma _sqlite3 _ssl - _tkinter _uuid readline - zlib - To find the necessary bits, look in setup.py in detect_modules() - for the module's name. - -If the build failed and you are using a C89 or C99-compliant compiler, -please `open a bug report <https://bugs.python.org>`_. - -If you decide to :ref:`build-dependencies`, you will need to re-run both -``configure`` and ``make``. - -.. _mac-python.exe: - -Once CPython is done building you will then have a working build -that can be run in-place; ``./python`` on most machines (and what is used in -all examples), ``./python.exe`` wherever a case-insensitive filesystem is used -(e.g. on OS X by default), in order to avoid conflicts with the ``Python`` -directory. There is normally no need to install your built copy -of Python! The interpreter will realize where it is being run from -and thus use the files found in the working copy. If you are worried -you might accidentally install your working copy build, you can add -``--prefix=/tmp/python`` to the configuration step. When running from your -working directory, it is best to avoid using the ``--enable-shared`` flag -to ``configure``; unless you are very careful, you may accidentally run -with code from an older, installed shared Python library rather than from -the interpreter you just built. - - -Clang -''''' - -If you are using clang_ to build CPython, some flags you might want to set to -quiet some standard warnings which are specifically superfluous to CPython are -``-Wno-unused-value -Wno-empty-body -Qunused-arguments``. You can set your -``CFLAGS`` environment variable to these flags when running ``configure``. - -If you are using clang_ with ccache_, turn off the noisy -``parentheses-equality`` warnings with the ``-Wno-parentheses-equality`` flag. -These warnings are caused by clang not having enough information to detect -that extraneous parentheses in expanded macros are valid, because the -preprocessing is done separately by ccache. - -If you are using LLVM 2.8, also use the ``-no-integrated-as`` flag in order to -build the :py:mod:`ctypes` module (without the flag the rest of CPython will -still build properly). - - -.. _windows-compiling: - -Windows -------- - -For a quick guide to building you can read `this documentation`_ from Victor -Stinner. - -**Python 3.6** and later can use Microsoft Visual Studio 2017. You can download -and use any of the free or paid versions of `Visual Studio 2017`_. - -When installing Visual Studio 2017, select the **Python development** workload -and the optional **Python native development tools** component to obtain all of -the necessary build tools. If you do not already have git installed, you can -find git for Windows on the **Individual components** tab of the installer. - -.. note:: If you want to build MSI installers, be aware that the build toolchain - for them has a dependency on the Microsoft .NET Framework Version 3.5 (which - may not be configured on recent versions of Windows, such as Windows 10). If - you are building on a recent Windows version, use the Control Panel (Programs - | Programs and Features | Turn Windows Features on or off) and ensure that the - entry ".NET Framework 3.5 (includes .NET 2.0 and 3.0)" is enabled. - -Your first build should use the command line to ensure any external dependencies -are downloaded: - -.. code-block:: dosbatch - - PCBuild\build.bat - -After this build succeeds, you can open the ``PCBuild\pcbuild.sln`` solution in -Visual Studio to continue development. - -See the `readme`_ for more details on what other software is necessary and how -to build. - -.. note:: **Python 2.7** uses Microsoft Visual Studio 2008, which is most easily - obtained through an MSDN subscription. To use the build files in the - `PCbuild directory`_ you will also need Visual Studio 2010, see the `2.7 - readme`_ for more details. If you have VS 2008 but not 2010 you can use the - build files in the `PC/VS9.0 directory`_, see the `VS9 readme`_ for details. - -.. note:: If you are using the Windows Subsystem for Linux (WSL), clone the - repository from a native Windows terminal program like cmd.exe command prompt - or PowerShell as well as use a build of git targeted for Windows, e.g., the - official one from `<https://git-scm.com>`_. Otherwise, Visual Studio will - not be able to find all the project's files and will fail the build. - -.. _this documentation: https://cpython-core-tutorial.readthedocs.io/en/latest/build_cpython_windows.html -.. _Visual Studio 2017: https://www.visualstudio.com/ -.. _readme: https://github.com/python/cpython/blob/master/PCbuild/readme.txt -.. _PCbuild directory: https://github.com/python/cpython/tree/2.7/PCbuild/ -.. _2.7 readme: https://github.com/python/cpython/blob/2.7/PCbuild/readme.txt -.. _PC/VS9.0 directory: https://github.com/python/cpython/tree/2.7/PC/VS9.0/ -.. _VS9 readme: https://github.com/python/cpython/blob/2.7/PC/VS9.0/readme.txt - - -.. _build-dependencies: - -Install dependencies -==================== - -This section explains how to install additional extensions (e.g. ``zlib``) -on :ref:`Linux <deps-on-linux>` and :ref:`macOs/OS X <macOS>`. On Windows, -extensions are already included and built automatically. - -.. _deps-on-linux: - -Linux ------ - -For UNIX based systems, we try to use system libraries whenever available. -This means optional components will only build if the relevant system headers -are available. The best way to obtain the appropriate headers will vary by -distribution, but the appropriate commands for some popular distributions -are below. - -On **Fedora**, **Red Hat Enterprise Linux** and other ``yum`` based systems:: - - $ sudo yum install yum-utils - $ sudo yum-builddep python3 - -On **Fedora** and other ``DNF`` based systems:: - - $ sudo dnf install dnf-plugins-core # install this to use 'dnf builddep' - $ sudo dnf builddep python3 - -On **Debian**, **Ubuntu**, and other ``apt`` based systems, try to get the -dependencies for the Python you're working on by using the ``apt`` command. - -First, make sure you have enabled the source packages in the sources list. -You can do this by adding the location of the source packages, including -URL, distribution name and component name, to ``/etc/apt/sources.list``. -Take Ubuntu Bionic for example:: - - deb-src http://archive.ubuntu.com/ubuntu/ bionic main - -For other distributions, like Debian, change the URL and names to correspond -with the specific distribution. - -Then you should update the packages index:: - - $ sudo apt-get update - -Now you can install the build dependencies via ``apt``:: - - $ sudo apt-get build-dep python3.6 - -If that package is not available for your system, try reducing the minor -version until you find a package that is available. - - -.. _MacOS: - -macOS and OS X --------------- - -For **macOS systems** (versions 10.12+) and **OS X 10.9 and later**, -the Developer Tools can be downloaded and installed automatically; -you do not need to download the complete Xcode application. - -If necessary, run the following:: - - $ xcode-select --install - -This will also ensure that the system header files are installed into -``/usr/include``. - -On **Mac OS X systems** (versions 10.0 - 10.7) and **OS X 10.8**, use the C -compiler and other development utilities provided by Apple's Xcode Developer -Tools. The Developer Tools are not shipped with Mac OS X. - -For these **older releases (versions 10.0 - 10.8)**, you will need to download either the -correct version of the Command Line Tools, if available, or install them from the -full Xcode app or package for that OS X release. Older versions may be -available either as a no-cost download through Apple's App Store or from -`the Apple Developer web site <https://developer.apple.com/>`_. - -.. _Homebrew: https://brew.sh - -.. _MacPorts: https://www.macports.org - -Also note that OS X does not include several libraries used by the Python -standard library, including ``libzma``, so expect to see some extension module -build failures unless you install local copies of them. As of OS X 10.11, -Apple no longer provides header files for the deprecated system version of -OpenSSL which means that you will not be able to build the ``_ssl`` extension. -One solution is to install these libraries from a third-party package -manager, like Homebrew_ or MacPorts_, and then add the appropriate paths -for the header and library files to your ``configure`` command. For example, - -with **Homebrew**:: - - $ brew install openssl xz gdbm - -and ``configure`` Python versions >= 3.7:: - - ./configure --with-pydebug --with-openssl=$(brew --prefix openssl) - -or ``configure`` Python versions < 3.7:: - - $ CPPFLAGS="-I$(brew --prefix openssl)/include" \ - LDFLAGS="-L$(brew --prefix openssl)/lib" \ - ./configure --with-pydebug - -and ``make``:: - - $ make -s -j2 - -or **MacPorts**:: - - $ sudo port install pkgconfig openssl xz gdbm - -and ``configure``:: - - $ CPPFLAGS="-I/opt/local/include" \ - LDFLAGS="-L/opt/local/lib" \ - ./configure --with-pydebug - -and ``make``:: - - $ make -s -j2 - -There will sometimes be optional modules added for a new release which -won't yet be identified in the OS level build dependencies. In those cases, -just ask for assistance on the core-mentorship list. If working on bug -fixes for Python 2.7, use ``python`` in place of ``python3`` in the above -commands. - -Explaining how to build optional dependencies on a UNIX based system without -root access is beyond the scope of this guide. - -.. _clang: https://clang.llvm.org/ -.. _ccache: https://ccache.samba.org/ - -.. note:: While you need a C compiler to build CPython, you don't need any - knowledge of the C language to contribute! Vast areas of CPython are - written completely in Python: as of this writing, CPython contains slightly - more Python code than C. - - -.. _regenerate_configure: - -Regenerate ``configure`` -======================== - -If a change is made to Python which relies on some POSIX system-specific -functionality (such as using a new system call), it is necessary to update the -``configure`` script to test for availability of the functionality. - -Python's ``configure`` script is generated from ``configure.ac`` using Autoconf. -Instead of editing ``configure``, edit ``configure.ac`` and then run -``autoreconf`` to regenerate ``configure`` and a number of other files (such as -``pyconfig.h``). - -When submitting a patch with changes made to ``configure.ac``, you should also -include the generated files. - -Note that running ``autoreconf`` is not the same as running ``autoconf``. For -example, ``autoconf`` by itself will not regenerate ``pyconfig.h.in``. -``autoreconf`` runs ``autoconf`` and a number of other tools repeatedly as is -appropriate. - -Python's ``configure.ac`` script typically requires a specific version of -Autoconf. At the moment, this reads: ``AC_PREREQ(2.65)``. - -If the system copy of Autoconf does not match this version, you will need to -install your own copy of Autoconf. - -.. _build_troubleshooting: - -Troubleshoot the build -====================== - -This section lists some of the common problems that may arise during the -compilation of Python, with proposed solutions. - -Avoid recreating auto-generated files -------------------------------------- - -Under some circumstances you may encounter Python errors in scripts like -``Parser/asdl_c.py`` or ``Python/makeopcodetargets.py`` while running ``make``. -Python auto-generates some of its own code, and a full build from scratch needs -to run the auto-generation scripts. However, this makes the Python build require -an already installed Python interpreter; this can also cause version mismatches -when trying to build an old (2.x) Python with a new (3.x) Python installed, or -vice versa. - -To overcome this problem, auto-generated files are also checked into the -Git repository. So if you don't touch the auto-generation scripts, there's -no real need to auto-generate anything. - -Editors and Tools -================= - -Python is used widely enough that practically all code editors have some form -of support for writing Python code. Various coding tools also include Python -support. - -For editors and tools which the core developers have felt some special comment -is needed for coding *in* Python, see :ref:`resources`. - - -Directory structure -=================== - -There are several top-level directories in the CPython source tree. Knowing what -each one is meant to hold will help you find where a certain piece of -functionality is implemented. Do realize, though, there are always exceptions to -every rule. - -``Doc`` - The official documentation. This is what https://docs.python.org/ uses. - See also :ref:`building-doc`. - -``Grammar`` - Contains the :abbr:`EBNF (Extended Backus-Naur Form)` grammar file for - Python. - -``Include`` - Contains all interpreter-wide header files. - -``Lib`` - The part of the standard library implemented in pure Python. - -``Mac`` - Mac-specific code (e.g., using IDLE as an OS X application). - -``Misc`` - Things that do not belong elsewhere. Typically this is varying kinds of - developer-specific documentation. - -``Modules`` - The part of the standard library (plus some other code) that is implemented - in C. - -``Objects`` - Code for all built-in types. - -``PC`` - Windows-specific code. - -``PCbuild`` - Build files for the version of MSVC currently used for the Windows - installers provided on python.org. - -``Parser`` - Code related to the parser. The definition of the AST nodes is also kept - here. - -``Programs`` - Source code for C executables, including the main function for the - CPython interpreter (in versions prior to Python 3.5, these files are - in the Modules directory). - -``Python`` - The code that makes up the core CPython runtime. This includes the - compiler, eval loop and various built-in modules. - -``Tools`` - Various tools that are (or have been) used to maintain Python. - diff --git a/testing/buildbots.rst b/testing/buildbots.rst new file mode 100644 index 0000000000..fc420d3f79 --- /dev/null +++ b/testing/buildbots.rst @@ -0,0 +1,265 @@ +.. _buildbots: + +====================== +Working with buildbots +====================== + +.. highlight:: bash + +To assert that there are no regressions in the :ref:`development and maintenance +branches <devcycle>`, Python has a set of dedicated machines (called *buildbots* +or *build workers*) used for continuous integration. They span a number of +hardware/operating system combinations. Furthermore, each machine hosts +several *builders*, one per active branch: when a new change is pushed +to this branch on the public `GitHub repository <https://github.com/python/cpython>`__, +all corresponding builders will schedule a new build to be run as soon as possible. + +The build steps run by the buildbots are: + +* Check out the source tree for the change which triggered the build +* Compile Python +* Run the test suite using :ref:`strenuous settings <strenuous_testing>` +* Clean up the build tree + +It is the responsibility of core team members to check the automatic +build results after they push a change to the repository. It is therefore +important that they are acquainted with the way these results are presented, +and how various kinds of failures can be explained and diagnosed. + + +In case of trouble +================== + +Please read this page in full. If your questions aren't answered here and you +need assistance with the buildbots, a good way to get help is to either: + +* contact the `python-buildbots@python.org + <https://mail.python.org/archives/list/python-buildbots@python.org/>`__ + mailing list where all buildbot worker owners are subscribed; or +* contact the release manager of the branch you have issues with. + + +Buildbot failures on pull requests +================================== + +The Bedevere bot on GitHub will put a message on your merged pull request +if building your commit on a stable buildbot worker fails. Take care to +evaluate the failure, even if it looks unrelated at first glance. + +Not all failures will generate a notification since not all builds are executed +after each commit. In particular, reference leaks builds take several hours to +complete so they are done periodically. This is why it's important for you to +be able to check the results yourself, too. + + +Triggering on pull requests +=========================== + +To trigger buildbots on a pull request you need to be a CPython triager or a +core team member. If you are not, ask someone to trigger them on your behalf. + +The simplest way to trigger most buildbots on your PR is with the +:gh-label:`🔨 test-with-buildbots` and :gh-label:`🔨 test-with-refleak-buildbots` +labels. (See :ref:`github-pr-labels`.) + +These will run buildbots on the most recent commit. If you want to trigger the +buildbots again on a later commit, you'll have to remove the label and add it +again. + +If you want to test a pull request against specific platforms, you can trigger +one or more buildbots by posting a comment that begins with: + +.. code-block:: none + + !buildbot regex-matching-target + +For example to run both the iOS and Android buildbots, you can use: + +.. code-block:: none + + !buildbot ios|android + +Bedevere will post a comment indicating which buildbots, if +any, were matched. If none were matched, or you do not have the +necessary permissions to trigger a request, it will tell you that too. + +The ``!buildbot`` comment will also only run buildbots on the most recent +commit. To trigger the buildbots again on a later commit, you will have to +repeat the comment. + + +Checking results of automatic builds +==================================== + +The Web interface at https://buildbot.python.org/#/ has several ways of +visualizing recent build results: + +* A `release status dashboard <https://buildbot.python.org/#/release_status>`__ + that shows the status of buildbots for each active branch, + summarizing whether the builds are ready for release. + +* A `waterfall view <https://buildbot.python.org/#/waterfall>`__ + that presents a vertical rundown of recent builds for each builder. + When interested in one build, click on it for more detail such as logs and + which commits it corresponds to. + +* A `console view <https://buildbot.python.org/#/console>`__, + which works best on a wide, high resolution + monitor. Clicking on the colored circles will allow you to open a new page + containing whatever information about that particular build is of interest to + you. You can also access builder information by clicking on the builder + status bubbles in the top line. + +Note that the buildbot web pages are often slow to load, be patient. + +Some buildbots are much faster than others. Over time, you will learn which +ones produce the quickest results after a build, and which ones take the +longest time. + +Also, when several commits are pushed in a quick succession in the same +branch, it often happens that a single build is scheduled for all these +commits. + + +Stability +========= + +A subset of the buildbots are marked as +`"stable" <https://buildbot.python.org/#/builders?tags=%2Bstable>`__. +They are taken into account when making a new release. +The rule is that all tier 1 and 2 stable builders must be free of +persistent failures when the release is cut (see :pep:`11` for more information). +It is absolutely **vital** that core team members fix or revert any issue they +introduce on the stable buildbots, as soon as possible. + +This does not mean that other builders' test results can be taken lightly, +either. Some of them are known for having platform-specific issues that +prevent some tests from succeeding (or even terminating at all), but +introducing additional failures should generally not be an option. + + +Flags-dependent failures +======================== + +Sometimes, while you have run the :ref:`whole test suite <runtests>` before +committing, you may witness unexpected failures on the buildbots. One source +of such discrepancies is if different flags have been passed to the test runner +or to Python itself. To reproduce, make sure you use the same flags as the +buildbots: they can be found out simply by clicking the **stdio** link for +the failing build's tests. For example:: + + ./python -E -m test --slow-ci --timeout=1200 -j2 --junit-xml test-results.xml -j10 + + +Ordering-dependent failures +=========================== + +Sometimes the failure is even subtler, as it relies on the order in which +the tests are run. The buildbots *randomize* test order (by using the ``-r`` +option to the test runner) to maximize the probability that potential +interferences between library modules are exercised; the downside is that it +can make for seemingly sporadic failures. + +The ``--randseed`` option makes it easy to reproduce the exact randomization +used in a given build. Again, open the ``stdio`` link for the failing test +run, and check the beginning of the test output proper. + +Let's assume, for the sake of example, that the output starts with: + +.. code-block:: none + :emphasize-lines: 9 + + ./python -E -m test --slow-ci --timeout=2400 -j2 -u-cpu,-urlfetch,-network --junit-xml test-results.xml -j4 + == CPython 3.15.0a6+ (heads/main:d625f7da33b, Feb 13 2026, 17:27:29) [GCC 12.2.0] + == Linux-6.12.20+rpt-rpi-v8-aarch64-with-glibc2.36 little-endian + == Python build: release + == cwd: /home/stan/buildarea/3.x.stan-raspbian.nondebug/build/build/test_python_worker_181905æ + == CPU count: 4 + == encodings: locale=ISO-8859-1 FS=utf-8 + == resources: all,-cpu,-network,-urlfetch + Using random seed: 1000348774 + 0:00:00 load avg: 3.34 Run 500 tests in parallel using 4 worker processes (timeout: 40 min, worker timeout: 45 min) + 0:00:01 load avg: 3.34 [ 1/500] test_colorsys passed + 0:00:01 load avg: 3.34 [ 2/500] test_float passed + +You can reproduce the exact same order by adding the ``--randseed 1000348774`` option:: + + ./python -E -m test --slow-ci --timeout=2400 -j2 -u-cpu,-urlfetch,-network --junit-xml test-results.xml -j4 --randseed 1000348774 + +It will run the following sequence (trimmed for brevity): + +.. code-block:: none + + [ 1/500] test_colorsys + [ 2/500] test_float + [ 3/500] test.test_io.test_memoryio + [ 4/500] test_profile + [ 5/500] test_picklebuffer + [ 6/500] test_zipimport + [ 7/500] test_devpoll + ... + +If this is enough to reproduce the failure on your setup, you can then +bisect the test sequence to look for the specific interference causing the +failure. Copy and paste the test sequence in a text file, then use the +``--fromfile`` (or ``-f``) option of the test runner to run the exact +sequence recorded in that text file:: + + ./python -E -m test --slow-ci --timeout=2400 -j2 -u-cpu,-urlfetch,-network --junit-xml test-results.xml -j4 --fromfile mytestsequence.txt + +In the example sequence above, if ``test_zipimport`` had failed, you would +first test the following sequence: + +.. code-block:: none + + [ 1/500] test_colorsys + [ 2/500] test_float + [ 3/500] test.test_io.test_memoryio + [ 6/500] test_zipimport + +And, if it succeeds, the following one instead (which, hopefully, shall +fail): + +.. code-block:: none + + [ 4/500] test_profile + [ 5/500] test_picklebuffer + [ 6/500] test_zipimport + +Then, recursively, narrow down the search until you get a single pair of +tests which triggers the failure. It is very rare that such an interference +involves more than **two** tests. If this is the case, we can only wish you +good luck! + +.. note:: + You cannot use the ``-j`` option (for parallel testing) when diagnosing + ordering-dependent failures. Using ``-j`` isolates each test in a + pristine subprocess and, therefore, prevents you from reproducing any + interference between tests. + + +Transient failures +================== + +While we try to make the test suite as reliable as possible, some tests do +not reach a perfect level of reproducibility. Some of them will sometimes +display spurious failures, depending on various conditions. Here are common +offenders: + +* Network-related tests, such as ``test_poplib``, ``test_urllibnet``, and so on. + Their failures can stem from adverse network conditions, or imperfect + thread synchronization in the test code, which often has to run a + server in a separate thread. + +* Tests dealing with delicate issues such as inter-thread or inter-process + synchronization, or Unix signals: ``test_multiprocessing``, + ``test_threading``, ``test_subprocess``, ``test_threadsignals``. + +When you think a failure might be transient, it is recommended you confirm by +waiting for the next build. Still, even if the failure does turn out sporadic +and unpredictable, the issue should be reported on the bug tracker; even +better if it can be diagnosed and suppressed by fixing the test's +implementation, or by making its parameters - such as a timeout - more robust. + +.. seealso:: + :ref:`buildworker` diff --git a/coverage.rst b/testing/coverage.rst similarity index 73% rename from coverage.rst rename to testing/coverage.rst index b0d5e9c3cb..48c2efc985 100644 --- a/coverage.rst +++ b/testing/coverage.rst @@ -1,7 +1,10 @@ .. _coverage: -Increase Test Coverage ====================== +Increase test coverage +====================== + +.. include:: /include/activate-tab.rst Python development follows a practice that all semantic changes and additions to the language and :abbr:`stdlib (standard library)` are accompanied by @@ -35,8 +38,8 @@ explicit coverage of the module is from its own set of tests instead of from implicit testing by other code that happens to use the module. -Common Gotchas -"""""""""""""" +Common gotchas +============== Please realize that coverage reports on modules already imported before coverage data starts to be recorded will be wrong. Typically you can tell a module falls @@ -46,22 +49,22 @@ statements have been covered. In these instances you can ignore the global statement coverage and simply focus on the local statement coverage. When writing new tests to increase coverage, do take note of the style of tests -already provided for a module (e.g., whitebox, blackbox, etc.). As +already provided for a module (for example, whitebox, blackbox, etc.). As some modules are primarily maintained by a single core developer they may have -a specific preference as to what kind of test is used (e.g., whitebox) and -prefer that other types of tests not be used (e.g., blackbox). When in doubt, +a specific preference as to what kind of test is used (for example, whitebox) and +prefer that other types of tests not be used (for example, blackbox). When in doubt, stick with whitebox testing in order to properly exercise the code. -Measuring Coverage -"""""""""""""""""" +Measuring coverage +================== It should be noted that a quirk of running coverage over Python's own stdlib is that certain modules are imported as part of interpreter startup. Those modules required by Python itself will not be viewed as executed by the coverage tools -and thus look like they have very poor coverage (e.g., the :py:mod:`stat` +and thus look like they have very poor coverage (for example, the :py:mod:`stat` module). In these instances the module will appear to not have any coverage of -global statements but will have proper coverage of local statements (e.g., +global statements but will have proper coverage of local statements (for example, function definitions will not be traced, but the function bodies will). Calculating the coverage of modules in this situation will simply require manually looking at what local statements were not executed. @@ -78,30 +81,53 @@ provided by the stdlib then you can :ref:`use test.regrtest .. _install_coverage: -Install Coverage -'''''''''''''''' +Install coverage +^^^^^^^^^^^^^^^^ By default, pip will not install into the in-development version of Python you just built, and this built version of Python will not see packages installed into your default version of Python. One option is to use a virtual environment -to install coverage:: +to install coverage. + +.. tab:: Unix + + Run: + + .. code-block:: shell + + ./python -m venv ../cpython-venv + source ../cpython-venv/bin/activate + pip install coverage + +.. tab:: macOS + + On :ref:`most <mac-python.exe>` macOS systems run: + + .. code-block:: shell + + ./python.exe -m venv ../cpython-venv + source ../cpython-venv/bin/activate + pip install coverage - ./python -m venv ../cpython-venv - source ../cpython-venv/bin/activate - pip install coverage +.. tab:: Windows -On :ref:`most <mac-python.exe>` Mac OS X systems, replace :file:`./python` -with :file:`./python.exe`. On Windows, use :file:`python.bat`. + Run: + + .. code-block:: dosbatch + + python.bat -m venv ..\\cpython-venv + ..\\cpython-venv\\Scripts\\activate.bat + pip install coverage You can now use python without the ./ for the rest of these instructions, as long as your venv is activated. For more info on venv see `Virtual Environment -<https://docs.python.org/3/tutorial/venv.html>`_ documentation. +<https://docs.python.org/3/tutorial/venv.html>`__ documentation. If this does not work for you for some reason, you should try using the in-development version of coverage.py to see if it has been updated as needed. -To do this you should clone/check out the development version of coverage.py: +To do this you should clone/check out the development version of coverage.py:: - git clone https://github.com/nedbat/coveragepy.git + git clone https://github.com/nedbat/coveragepy You will need to use the full path to the installation. @@ -110,11 +136,11 @@ it. For this, you will again need to use the full path to that installation. .. _coverage_usage: -Basic Usage -''''''''''' +Basic usage +^^^^^^^^^^^ The following command will tell you if your copy of coverage works (substitute -``COVERAGEDIR`` with the directory where your clone exists, e.g. +``COVERAGEDIR`` with the directory where your clone exists, for example, ``../coveragepy``):: ./python COVERAGEDIR @@ -157,15 +183,15 @@ you visually see what lines of code were not tested:: This will generate an HTML report in a directory named ``htmlcov`` which ignores any errors that may arise and ignores modules for which test coverage is -unimportant (e.g. tests, temp files, etc.). You can then open the +unimportant (for example, tests, temp files, etc.). You can then open the ``htmlcov/index.html`` file in a web browser to view the coverage results along with pages that visibly show what lines of code were or were not executed. .. _branch_coverage: -Branch Coverage -''''''''''''''' +Branch coverage +^^^^^^^^^^^^^^^ For the truly daring, you can use another powerful feature of coverage.py: branch coverage. Testing every possible branch path through code, while a great @@ -181,38 +207,6 @@ This will lead to the report stating not only what lines were not covered, but also what branch paths were not executed. -Coverage Results For Modules Imported Early On -'''''''''''''''''''''''''''''''''''''''''''''' - -For the *truly truly* daring, you can use a hack to get coverage.py to include -coverage for modules that are imported early on during CPython's startup (e.g. -the encodings module). Do not worry if you can't get this to work or it doesn't -make any sense; it's entirely optional and only important for a small number of -modules. - -If you still choose to try this, the first step is to build coverage.py's C -extension code. Assuming that coverage.py's clone is at ``COVERAGEDIR`` and -your clone of CPython is at ``CPYTHONDIR``, you execute the following in your -coverage.py clone:: - - CPPFLAGS="-I CPYTHONDIR -I CPYTHONDIR/Include" CPYTHONDIR/python setup.py build_ext --inplace - -This will build coverage.py's C extension code in-place, allowing the previous -instructions on how to gather coverage to continue to work. - -To get coverage.py to be able to gather the most accurate coverage data on as -many modules as possible -**with a HORRIBLE HACK that you should NEVER use in your own code**, run the -following from your CPython clone:: - - PYTHONPATH=COVERAGEDIR/coverage/fullcoverage ./python COVERAGEDIR run --pylib Lib/test/regrtest.py - -This will give you the most complete coverage possible for CPython's standard -library. - -.. _coverage.py: https://coverage.readthedocs.io/en/latest/ - - .. _coverage_by_regrtest: Using test.regrtest @@ -232,41 +226,69 @@ you want the coverage data to end up it will go somewhere you don't expect. If you are running coverage over the entire test suite, make sure to add ``-x test_importlib test_runpy test_trace`` to exclude those tests as they trigger exceptions during coverage; see - https://bugs.python.org/issue10541 and https://bugs.python.org/issue10991. + `python/cpython#54750 <https://github.com/python/cpython/issues/54750>`__ and + `python/cpython#55200 <https://github.com/python/cpython/issues/55200>`__. Once the tests are done you will find the directory you specified contains files for each executed module along with which lines were executed how many times. -Filing the Issue -"""""""""""""""" -Once you have increased coverage, you need to create an issue on the -`issue tracker`_ and submit a :doc:`pull request <pullrequest>`. On the -issue set the "Components" to "Test" and "Versions" to the version of Python you -worked on (i.e., the in-development version). - -.. _issue tracker: https://bugs.python.org +Filing the issue +================ +Once you have increased coverage, +you need to create an issue on the `issue tracker`_ and +submit a :ref:`pull request <pullrequest>`. Measuring coverage of C code with gcov and lcov -""""""""""""""""""""""""""""""""""""""""""""""" +=============================================== It's also possible to measure the function, line and branch coverage of Python's C code. Right now only GCC with `gcov`_ is supported. In order to -create an instrumented build of Python with gcov, run:: +create an instrumented build of Python with gcov, run: + +.. tab:: Unix/macOS - make coverage + .. code-block:: shell + + make coverage + +.. tab:: Windows + + .. code-block:: dosbatch + + .\make coverage Then run some code and gather coverage data with the ``gcov`` command. In -order to create a HTML report you can install `lcov`_. The command:: +order to create a HTML report you can install `lcov`_. The command: + +.. tab:: Unix/macOS - make coverage-lcov + .. code-block:: shell + + make coverage-lcov + +.. tab:: Windows + + .. code-block:: dosbatch + + .\make coverage-lcov assembles coverage data, removes 3rd party and system libraries and finally -creates a report. You can skip both steps and just run:: +creates a report. You can skip both steps and just run: + +.. tab:: Unix/macOS - make coverage-report + .. code-block:: shell + + make coverage-report + +.. tab:: Windows + + .. code-block:: dosbatch + + .\make coverage-report if you like to generate a coverage report for Python's stdlib tests. It takes about 20 to 30 minutes on a modern computer. @@ -276,5 +298,7 @@ about 20 to 30 minutes on a modern computer. Multiple test jobs may not work properly. C coverage reporting has only been tested with a single test process. +.. _issue tracker: https://github.com/python/cpython/issues .. _gcov: https://gcc.gnu.org/onlinedocs/gcc/Gcov.html -.. _lcov: http://ltp.sourceforge.net/coverage/lcov.php +.. _lcov: https://github.com/linux-test-project/lcov +.. _coverage.py: https://coverage.readthedocs.io/en/latest/ diff --git a/testing/index.rst b/testing/index.rst new file mode 100644 index 0000000000..55bdd3d08b --- /dev/null +++ b/testing/index.rst @@ -0,0 +1,14 @@ +.. _testing: + +===================== +Testing and buildbots +===================== + +.. toctree:: + :maxdepth: 5 + + run-write-tests + silence-warnings + coverage + buildbots + new-buildbot-worker diff --git a/testing/new-buildbot-worker.rst b/testing/new-buildbot-worker.rst new file mode 100644 index 0000000000..aea43a782a --- /dev/null +++ b/testing/new-buildbot-worker.rst @@ -0,0 +1,675 @@ +.. _new-buildbot-worker: +.. _buildworker: + +==================== +New buildbot workers +==================== + +.. highlight:: bash + +Python's :ref:`buildbots` system was discussed earlier. We sometimes refer to +the collection of *build workers* as our "buildbot fleet". The machines that +comprise the fleet are voluntarily contributed resources. Many are run by +individual volunteers out of their own pockets and time, while others are +supported by corporations. Even the corporate sponsored buildbots, however, +tend to exist because some individual championed them, made them a reality, and +is committed to maintaining them. + +Anyone can contribute a buildbot to the fleet. This document describes how +to go about setting up a buildbot worker, getting it added, and some hints about +buildbot maintenance. + +Anyone running a buildbot that is part of the fleet should subscribe to the +`python-buildbots <https://mail.python.org/mailman3/lists/python-buildbots.python.org/>`__ +mailing list. This mailing list is also the place to contact if you want to +contribute a buildbot but have questions. + +As for what kind of buildbot to run...take a look at our `current fleet +<builders_>`__. Pretty much anything that isn't +on that list would be interesting: different Linux/Unix distributions, +different versions of the various OSes, other OSes if you or someone are +prepared to make the test suite actually pass on that new OS. Even if you only +want to run an OS that's already on our list there may be utility in setting it +up; we also need to build and test python under various alternate build +configurations. Post to the mailing list and talk about what you'd like to +contribute. + + +Preparing for buildbot worker setup +=================================== + +Since the goal is to build Python from source, the system will need to have +everything required to do normal python development: a compiler, a linker, and +(except on Windows) the "development" headers for any of the optional modules +(zlib, OpenSSL, and so on) supported by the platform. Follow the steps outlined in +:ref:`setup` for the target platform, all the way through to having a working +compiled Python. + +In order to set up the buildbot software, you will need to obtain an identifier +and password for your worker so it can join the fleet. Open an issue in the +`configuration repository <https://github.com/python/buildmaster-config/issues/new?template=new_worker.yml>`__ +to discuss adding your worker and to obtain the +needed workername and password. You can do some of the steps that follow +before having the credentials, but it is easiest to have them before +the "buildbot worker" step below. + + +Setting up the buildbot worker +============================== + +Conventional always-on machines +------------------------------- + +You need a recent version of the `buildbot <https://buildbot.net/>`__ worker +software. On most platforms the distribution's package manager provides the +``buildbot-worker`` package, which also creates a dedicated service account, +systemd unit (or equivalent), and the necessary directories. For platforms +where no package exists, ``pip install buildbot-worker`` is the fallback, but +you will need to create the service account, directories, and service unit +manually. You may also want to set the buildbot up using a virtual +environment, depending on how you manage your system; you'll need to adjust +the steps below as appropriate if you choose that path. + +.. tab:: Linux + + .. tab:: Fedora / RHEL / CentOS + + **Fedora**:: + + dnf install buildbot-worker + + **RHEL 8** (requires EPEL):: + + subscription-manager repos --enable codeready-builder-for-rhel-8-$(arch)-rpms + dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm + dnf install buildbot-worker + + **RHEL 9** (requires EPEL):: + + subscription-manager repos --enable codeready-builder-for-rhel-9-$(arch)-rpms + dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm + dnf install buildbot-worker + + **CentOS Stream 9 / 10** (requires CRB + EPEL):: + + dnf config-manager --set-enabled crb + dnf install epel-release epel-next-release + dnf install buildbot-worker + + The RPM creates a ``buildbot-worker`` system user, installs a + templated systemd unit ``buildbot-worker@.service``, and creates + ``/var/lib/buildbot/worker/`` as the base directory for worker + instances. + + .. tip:: + + If your system has most of its disk space on ``/home`` rather than + on the root partition, create the worker data under ``/home`` and + symlink it so the packaged systemd unit still works:: + + mkdir -p /home/buildbot-worker/worker + ln -s /home/buildbot-worker/worker /var/lib/buildbot/worker + + Adjust ownership and paths to match your distro's conventions. + + Create the worker (replace ``WORKERNAME`` and ``WORKERPASSWD`` with + the credentials provided to you from your buildmaster-config issue):: + + sudo -u buildbot-worker buildbot-worker create-worker \ + /var/lib/buildbot/worker/WORKERNAME \ + buildbot-api.python.org:9020 WORKERNAME WORKERPASSWD + + Edit ``info/admin``, ``info/host``, and ``buildbot.tac`` in the worker + directory (see below for recommended settings). + + Enable and start the service:: + + systemctl enable --now buildbot-worker@WORKERNAME.service + + .. tab:: Debian / Ubuntu + + :: + + apt install buildbot-worker + + The package creates a ``buildbot`` system user, installs a templated + systemd unit ``buildbot-worker@.service``, and creates + ``/var/lib/buildbot/workers/`` as the base directory for worker + instances. + + .. tip:: + + If your system has most of its disk space on ``/home`` rather than + on the root partition, create the worker data under ``/home`` and + symlink it so the packaged systemd unit still works:: + + mkdir -p /home/buildbot/workers + ln -s /home/buildbot/workers /var/lib/buildbot/workers + + Adjust ownership and paths to match your distro's conventions. + + Create the worker (replace ``WORKERNAME`` and ``WORKERPASSWD`` with + the credentials provided to you from your buildmaster-config issue):: + + sudo -u buildbot buildbot-worker create-worker \ + /var/lib/buildbot/workers/WORKERNAME \ + buildbot-api.python.org:9020 WORKERNAME WORKERPASSWD + + Edit ``info/admin``, ``info/host``, and ``buildbot.tac`` in the worker + directory (see below for recommended settings). + + Enable and start the service:: + + systemctl enable --now buildbot-worker@WORKERNAME.service + + .. tab:: Other / pip + + For distros without a ``buildbot-worker`` package, install via pip:: + + pip install buildbot-worker + + **NixOS** users should use the built-in ``services.buildbot-worker`` + NixOS module; see the + `nixpkgs module source <https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/continuous-integration/buildbot/worker.nix>`__ + for available options. + + **Arch Linux** has buildbot packages in the AUR, but they are + currently unmaintained. Using pip is more reliable. + + pip does **not** create a system user, directories, or service unit. + Set these up manually. On distros with ``useradd``:: + + useradd --system --shell /sbin/nologin \ + --home-dir /var/lib/buildbot/worker --create-home buildbot-worker + + On Alpine Linux (BusyBox):: + + adduser -S -D -H -h /var/lib/buildbot/worker -s /sbin/nologin buildbot-worker + + Then create the directories:: + + mkdir -p /var/lib/buildbot/worker + chown buildbot-worker:buildbot-worker /var/lib/buildbot/worker + + Create the worker (replace ``WORKERNAME`` and ``WORKERPASSWD`` with + the credentials provided to you from your buildmaster-config issue):: + + sudo -u buildbot-worker buildbot-worker create-worker \ + /var/lib/buildbot/worker/WORKERNAME \ + buildbot-api.python.org:9020 WORKERNAME WORKERPASSWD + + Edit ``info/admin``, ``info/host``, and ``buildbot.tac`` in the worker + directory (see below for recommended settings). + + On systemd-based distros, a service unit must also be installed; see + the service management section below. + + +.. tab:: Unix + + .. tab:: FreeBSD + + :: + + pkg install devel/py-buildbot-worker + + The package creates a ``buildbot`` system user, installs an + ``rc.d`` service with profile support, and creates + ``/var/db/buildbot/workers/`` as the base directory for worker + instances. + + Create the worker (replace ``WORKERNAME`` and ``WORKERPASSWD`` with + the credentials provided to you from your buildmaster-config issue):: + + su -m buildbot -c "buildbot-worker create-worker \ + /var/db/buildbot/workers/WORKERNAME \ + buildbot-api.python.org:9020 WORKERNAME WORKERPASSWD" + + Edit ``info/admin``, ``info/host``, and ``buildbot.tac`` in the worker + directory (see below for recommended settings). + + Enable and start the service. The rc.d script uses profile names as + shell variable identifiers, so pick a short name without hyphens + (it does not need to match the worker name):: + + sysrc buildbot_worker_enable=YES + sysrc buildbot_worker_profiles="myworker" + sysrc buildbot_worker_myworker_enable=YES + sysrc buildbot_worker_myworker_basedir=/var/db/buildbot/workers/WORKERNAME + service buildbot-worker start + + .. tab:: OpenBSD + + :: + + pkg_add buildbot-worker + + The package creates a ``_buildslave`` system user, installs an + ``rc.d`` service, and creates ``/var/buildslave/`` as the default + worker directory. + + Create the worker (replace ``WORKERNAME`` and ``WORKERPASSWD`` with + the credentials provided to you from your buildmaster-config issue):: + + su -m _buildslave -c "buildbot-worker create-worker \ + /var/buildslave \ + buildbot-api.python.org:9020 WORKERNAME WORKERPASSWD" + + Edit ``info/admin``, ``info/host``, and ``buildbot.tac`` in the worker + directory (see below for recommended settings). + + Enable and start the service:: + + rcctl enable buildbot_worker + rcctl start buildbot_worker + + The ``rc.d`` script supports a single worker. To run multiple + workers, create each in a subdirectory and point the service flags + at the desired one (or create additional ``rc.d`` scripts):: + + su -m _buildslave -c "buildbot-worker create-worker \ + /var/buildslave/WORKERNAME \ + buildbot-api.python.org:9020 WORKERNAME WORKERPASSWD" + rcctl enable buildbot_worker + rcctl set buildbot_worker flags /var/buildslave/WORKERNAME + rcctl start buildbot_worker + + +.. tab:: macOS + + * Create a buildbot user using the macOS control panel user admin. It + should be a "standard" user. + * Log in as the buildbot user. + * Install the buildbot worker [#]_ by running ``pip install buildbot-worker``. + + In a terminal window for the buildbot user, issue the following commands (you + can put the ``buildarea`` wherever you want to):: + + mkdir buildarea + buildbot-worker create-worker buildarea buildbot-api.python.org:9020 WORKERNAME WORKERPASSWD + + +.. tab:: Windows + + * Create a buildbot user as a "standard" user. + * Install the latest version of Python from python.org. + * Open a Command Prompt. + * Execute ``python -m pip install pywin32 buildbot-worker`` (note that + ``python.exe`` is not added to ``PATH`` by default, making the + ``python`` command accessible is left as an exercise for the user). + + On Windows, `the maximum length for a path is limited + <https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation>`__. + This might cause some tests to fail, unless long paths support is enabled. + + Use this PowerShell command to check whether long paths are enabled:: + + Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" + + If the value is not "1", you can enable long paths using this PowerShell command:: + + New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force + + + In a terminal window for the buildbot user, issue the following commands. + (You can put the ``buildarea`` wherever you want to.) + Note that the ``buildbot-worker`` command will be in the + :file:`Scripts` directory of your Python installation. Here and in the rest + of the guide, you may need to launch it using the full path. + + .. code-block:: + + mkdir buildarea + buildbot-worker create-worker buildarea buildbot-api.python.org:9020 WORKERNAME WORKERPASSWD + + +The ``info/admin`` file in the worker directory should contain your contact +information, and ``info/host`` should describe the host configuration. This +information is displayed on the buildbot web interface. Since these pages are +publicly visible, consider obfuscating your email address (for example, +``user AT example.com``) to avoid spam from web scrapers. + +The recommended ``buildbot.tac`` settings are: + +* ``keepalive = 60`` -- the buildmaster uses a 60-second keepalive interval; + the default of ``600`` is too high and can cause spurious disconnections. +* ``delete_leftover_dirs = 1`` -- automatically cleans up build directories + that the master no longer needs. + +.. tip:: + + Build directories and ``twistd.log`` rotations can accumulate over time. + Monitor free disk space on the partition that holds the worker directory, + even with ``delete_leftover_dirs`` enabled. + +Service management +~~~~~~~~~~~~~~~~~~ + +You will also want to make sure that the worker is started when the +machine reboots: + +.. tab:: Linux + + .. tab:: Distro package + + If you installed via a distro package (Fedora, RHEL, CentOS, Debian, + or Ubuntu), the service was already enabled in the installation + step above. + + .. tab:: Manual systemd + + If you installed via pip, you need to install a systemd unit yourself. + The upstream buildbot project provides a + `contributed template unit <https://github.com/buildbot/buildbot/blob/master/worker/contrib/systemd/buildbot-worker%40.service>`__ + along with + `sysusers.d and tmpfiles.d configs <https://github.com/buildbot/buildbot/tree/master/common/contrib/systemd>`__. + + Create ``/etc/systemd/system/buildbot-worker@.service`` with the + following contents:: + + [Unit] + Description=Buildbot Worker %i + Documentation=man:buildbot-worker(1) https://docs.buildbot.net/ + After=network.target + ConditionDirectoryNotEmpty=/var/lib/buildbot/worker/%i + ConditionFileNotEmpty=/var/lib/buildbot/worker/%i/buildbot.tac + + [Service] + Type=simple + User=buildbot-worker + Group=buildbot-worker + WorkingDirectory=/var/lib/buildbot/worker/ + StateDirectory=buildbot/worker + ExecStart=/usr/local/bin/buildbot-worker start --nodaemon %i + Restart=always + ProtectSystem=full + ProtectHome=yes + PrivateDevices=yes + PrivateTmp=yes + + [Install] + WantedBy=multi-user.target + + Adjust ``User``, ``Group``, ``WorkingDirectory``, and the + ``ExecStart`` path to match your setup. If your worker data is + symlinked from ``/home`` (see the filesystem layout tip above), + change ``ProtectHome=yes`` to ``ProtectHome=no`` so systemd can + follow the symlink. Then:: + + systemctl daemon-reload + systemctl enable --now buildbot-worker@WORKERNAME.service + + .. tab:: SysV init + + For distros without systemd (such as Alpine Linux with OpenRC), + upstream provides a + `SysV init script <https://github.com/buildbot/buildbot/blob/master/worker/contrib/init-scripts/buildbot-worker.init.sh>`__ + with a + `default configuration file <https://github.com/buildbot/buildbot/blob/master/worker/contrib/init-scripts/buildbot-worker.default>`__. + Install these as ``/etc/init.d/buildbot-worker`` and + ``/etc/default/buildbot-worker`` respectively, then configure the + worker instances in the default file. + + .. tab:: cron job + + If neither systemd nor a SysV init script is practical, you can use + a cron job. Add the following line to ``/etc/crontab``:: + + @reboot buildbot-worker restart /path/to/workerdir + + Note that ``restart`` is used rather than ``start`` in case a crash + has left a ``twistd.pid`` file behind. + +.. tab:: Unix + + If you installed via a package on FreeBSD or OpenBSD, the service + was already enabled in the installation step above. To manage it + manually: + + On FreeBSD:: + + service buildbot-worker status + service buildbot-worker restart + + On OpenBSD:: + + rcctl check buildbot_worker + rcctl restart buildbot_worker + + If you installed via pip, you will need to write an ``rc.d`` script + or use the cron job approach described in the Linux tab. + +.. tab:: macOS + + * Create a bin directory for your buildbot user:: + + mkdir bin + + * Place the following script, named ``run_worker.sh``, into that directory:: + + #!/bin/bash + export PATH=/usr/local/bin:/Library/Frameworks/Python.framework/Versions/Current/bin:$PATH + export LC_CTYPE=en_US.utf-8 + cd /Users/buildbot/buildarea + twistd --nodaemon --python=buildbot.tac --logfile=buildbot.log --prefix=worker + + * Place a file with the following contents into ``/Library/LaunchDaemons``: + + .. code-block:: xml + + <?xml version="1.0" encoding="UTF-8"?> + <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" + "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> + <plist version="1.0"> + <dict> + <key>Label</key> + <string>net.buildbot.worker</string> + <key>UserName</key> + <string>buildbot</string> + <key>WorkingDirectory</key> + <string>/Users/buildbot/buildarea</string> + <key>ProgramArguments</key> + <array> + <string>/Users/buildbot/bin/run_worker.sh</string> + </array> + <key>StandardOutPath</key> + <string>twistd.log</string> + <key>StandardErrorPath</key> + <string>twistd.log</string> + <key>KeepAlive</key> + <true/> + <key>SessionCreate</key> + <true/> + </dict> + </plist> + + The recommended name for the file is ``net.buildbot.worker``. + +.. tab:: Windows + + * Add a Scheduled Task to run ``buildbot-worker start buildarea`` as the + buildbot user "when the computer starts up". It is best to provide + absolute paths to the ``buildbot-worker`` command and the :file:`buildarea` + directory. It is also recommended to set the task to run in the + directory that contains the :file:`buildarea` directory. + + * Alternatively (note: don't do both!), set up the worker + service as described in the `buildbot documentation + <https://docs.buildbot.net/current/manual/installation/misc.html#launching-worker-as-windows-service>`__. + +If you have not already started the worker through a service manager, you +can start it manually for initial testing:: + + buildbot-worker start /path/to/workerdir + +Then you can either wait for someone to make a commit, or you can pick a +builder associated with your worker from the `list of builders +<builders_>`__ and force a build. + +In any case you should initially monitor builds on your builders to make sure +the tests are passing and to resolve any platform issues that may be revealed +by tests that fail. Unfortunately we do not currently have a way to notify you +only of failures on your builders, so doing periodic spot checks is also a good +idea. + +---- + +Latent workers +-------------- + +We also support running `latent workers +<https://docs.buildbot.net/current/manual/configuration/workers.html#latent-workers>`__ +on the AWS EC2 service. To set up such a worker: + +* Start an instance of your chosen base AMI and set it up as a + conventional worker. +* After the instance is fully set up as a conventional worker (including + worker name and password, and admin and host information), create an AMI + from the instance and stop the instance. +* Contact the buildmaster administrator who gave you your worker + name and password and give them the following information: + + * Instance size (such as ``m4.large``) + * Full region specification (such as ``us-west-2``) + * AMI ID (such as ``ami-1234beef``) + * An Access Key ID and Access Key. It is recommended to set up + a separate IAM user with full access to EC2 and provide the access key + information for that user rather than for your main account. + +The buildmaster cannot guarantee that it will always shut down your +instance(s), so it is recommended to periodically check and make sure +there are no "zombie" instances running on your account, created by the +buildbot master. Also, if you notice that your worker seems to have been +down for an unexpectedly long time, please ping the `python-buildbots +<https://mail.python.org/mailman3/lists/python-buildbots.python.org/>`__ list to +request that the master be restarted. + +Latent workers should also be updated periodically to include operating system +or other software updates, but when to do such maintenance is largely up to you +as the worker owner. There are a couple different options for doing such +updates: + +* Start an instance from your existing AMI, do updates on that instance, + and save a new AMI from the updated instance. Note that (especially for + Windows workers) you should do at least one restart of the instance after + doing updates to be sure that any post-reboot update work is done before + creating the new AMI. +* Create an entirely new setup from a newer base AMI using your existing + worker name and password. + +Whichever way you choose to update your AMI, you'll need to provide the +buildmaster administrators with the new AMI ID. + + +Buildbot worker operation +========================= + +Most of the time, running a worker is a "set and forget" operation, +depending on the level of involvement you want to have in resolving bugs +revealed by your builders. There are, however, times when it is helpful or +even necessary for you to get involved. As noted above, you should be +subscribed to ``python-buildbots@python.org`` so that you will be made +aware of any fleet-wide issues. + +Necessary tasks include, obviously, keeping the buildbot running. Currently +the system for notifying buildbot owners when their workers go offline is not +working; this is something we hope to resolve. So currently it is helpful if +you periodically check the status of your worker. We will also contact you +via your contact address in ``info/admin`` when we notice there is a +problem that has not been resolved for some period of time and you have +not responded to a posting on the python-buildbots list about it. + +We currently do not have a minimum version requirement for the worker +software. However, this is something we will probably establish as we tune the +fleet, so another task will be to occasionally upgrade the buildbot worker software. +Coordination for this will be done via ``python-buildbots@python.org``. + +The most interesting extra involvement is when your worker reveals a unique +or almost-unique problem: a test that is failing on your system but not on +other systems. In this case you should be prepared to offer debugging help to +the people working on the bug: running tests by hand on the worker machine +or, if possible, providing ssh access to a committer to run experiments to try +to resolve the issue. + + +Required ports +============== + +The worker operates as a *client* to the *buildmaster*. This means that +all network connections are *outbound*. This is true also for the network +tests in the test suite. Most consumer firewalls will allow any outbound +traffic, so normally you do not need to worry about what ports the buildbot +uses. However, corporate firewalls are sometimes more restrictive, so here is +a table listing all of the outbound ports used by the buildbot and the python +test suite (this list may not be complete as new tests may have been added +since this table was last vetted): + +======= ========================== ================================================ +Port Host Description +======= ========================== ================================================ +20, 21 ftp.debian.org test_urllib2net +53 your DNS server test_socket, and others implicitly +80 python.org (several tests) + example.com +119 news.gmane.org test_nntplib (Python versions < 3.13) +443 (various) test_ssl +465 smtp.gmail.com test_smtpnet +587 smtp.gmail.com test_smtpnet +9020 buildbot-api.python.org connection to buildmaster +======= ========================== ================================================ + +Many tests will also create local TCP sockets and connect to them, usually +using either ``localhost`` or ``127.0.0.1``. + + +Required resources +================== + +Based on the last time we did a `survey +<https://mail.python.org/pipermail/python-dev/2012-March/117978.html>`__ on +buildbot requirements, the recommended resource allocations for a python +buildbot are at least: + +* 2 CPUs +* 512 MB RAM +* 30 GB free disk space + +Many tests won't run in this configuration, since they require +substantially more memory, but these resources should be sufficient. +Builders with minimal settings might need more maintenance: they check +that Python's resource-hungry tests are tagged and skipped correctly. + + +Security considerations +======================= + +We only allow builds to be triggered against commits to the +`CPython repository on GitHub <https://github.com/python/cpython>`__. +This means that the code your buildbot will run will have been vetted by a committer. +However, mistakes and bugs happen, as could a compromise, so keep this in mind when +siting your buildbot on your network and establishing the security around it. +Treat the buildbot like you would any resource that is public facing and might +get hacked (use a VM and/or jail/chroot/solaris zone, put it in a DMZ, and so on). +While the buildbot does not have any ports open for inbound traffic (and is not +public facing in that sense), committer mistakes do happen, and security flaws +are discovered in both released and unreleased code, so treating the buildbot +as if it were fully public facing is a good policy. + +Code runs differently as privileged and unprivileged users. We would love to +have builders running as privileged accounts, but security considerations do +make that difficult, as access to root can provide access to surprising +resources (such as spoofed IP packets, changes in MAC addresses, and so on) even on a +VM setup. But if you are confident in your setup, we'd love to have a buildbot +that runs python as root. + +Note that the above is a summary of a `discussion +<https://mail.python.org/pipermail/python-dev/2011-October/113935.html>`__ on +python-dev about buildbot security that includes examples of the tests for +which privilege matters. There was no final consensus, but the information is +useful as a point of reference. + +.. [#] If the buildbot is going to do Framework builds, it is better to + use the Apple-shipped Python so as to avoid any chance of the buildbot + picking up components from the installed python.org python. + +.. _builders: https://buildbot.python.org/#/builders diff --git a/testing/run-write-tests.rst b/testing/run-write-tests.rst new file mode 100644 index 0000000000..405d10f039 --- /dev/null +++ b/testing/run-write-tests.rst @@ -0,0 +1,286 @@ +.. _run-write-tests: +.. _runtests: + +========================= +Running and writing tests +========================= + +.. include:: /include/activate-tab.rst + +.. note:: + + This document assumes you are working from an + :ref:`in-development <indevbranch>` checkout of Python. If you + are not then some things presented here may not work as they may depend + on new features not available in earlier versions of Python. + +Running +======= + +The shortest, simplest way of running the test suite is the following command +from the root directory of your checkout (after you have +:ref:`built Python <compiling>`): + +.. tab:: Unix + + .. code-block:: shell + + ./python -m test + +.. tab:: macOS + + .. code-block:: shell + + ./python.exe -m test + + This works on :ref:`most <mac-python.exe>` macOS systems. + +.. tab:: Windows + + .. code-block:: dosbatch + + .\python.bat -m test + +This will run the majority of tests, but exclude a small portion of them; these +excluded tests use special kinds of resources: for example, accessing the +Internet, or trying to play a sound or to display a graphical interface on +your desktop. They are disabled by default so that running the test suite +is not too intrusive. To enable some of these additional tests (and for +other flags which can help debug various issues such as reference leaks), read +the help text: + +.. tab:: Unix + + .. code-block:: shell + + ./python -m test -h + +.. tab:: macOS + + .. code-block:: shell + + ./python.exe -m test -h + +.. tab:: Windows + + .. code-block:: dosbatch + + .\python.bat -m test -h + +If you want to run a single test file, simply specify the test file name +(without the extension) as an argument. You also probably want to enable +verbose mode (using ``-v``), so that individual failures are detailed: + +.. tab:: Unix + + .. code-block:: shell + + ./python -m test -v test_abc + +.. tab:: macOS + + .. code-block:: shell + + ./python.exe -m test -v test_abc + +.. tab:: Windows + + .. code-block:: dosbatch + + .\python.bat -m test -v test_abc + +To run a single test case, use the ``unittest`` module, providing the import +path to the test case: + +.. tab:: Unix + + .. code-block:: shell + + ./python -m unittest -v test.test_abc.TestABC_Py + +.. tab:: macOS + + .. code-block:: shell + + ./python.exe -m unittest -v test.test_abc.TestABC_Py + +.. tab:: Windows + + .. code-block:: dosbatch + + .\python.bat -m unittest -v test.test_abc.TestABC_Py + +Some test modules also support direct invocation, +which might be useful for IDEs and local debugging: + +.. tab:: Unix + + .. code-block:: shell + + ./python Lib/test/test_typing.py + +.. tab:: macOS + + .. code-block:: shell + + ./python.exe Lib/test/test_typing.py + +.. tab:: Windows + + .. code-block:: dosbatch + + .\python.bat Lib/test/test_typing.py + +But, there are several important notes: + +1. This way of running tests exists only + for local developer needs and is discouraged for anything else +2. Some modules do not support it at all. One example is ``test_importlib``. + In other words: if some module does not have ``unittest.main()``, then + most likely it does not support direct invocation. + +If you have a multi-core or multi-CPU machine, you can enable parallel testing +using several Python processes so as to speed up things: + +.. tab:: Unix + + .. code-block:: shell + + ./python -m test -j0 + +.. tab:: macOS + + .. code-block:: shell + + ./python.exe -m test -j0 + +.. tab:: Windows + + .. code-block:: dosbatch + + .\python.bat -m test -j0 + +.. _strenuous_testing: + +Finally, if you want to run tests under a more strenuous set of settings, you +can run ``test`` as: + +.. tab:: Unix + + .. code-block:: shell + + ./python -bb -E -Wd -m test -r -w -uall + +.. tab:: macOS + + .. code-block:: shell + + ./python.exe -bb -E -Wd -m test -r -w -uall + +.. tab:: Windows + + .. code-block:: dosbatch + + .\python.bat -bb -E -Wd -m test -r -w -uall + +The various extra flags passed to Python cause it to be much stricter about +various things (the ``-Wd`` flag should be ``-W error`` at some point, but the +test suite has not reached a point where all warnings have been dealt with and +so we cannot guarantee that a bug-free Python will properly complete a test run +with ``-W error``). The ``-r`` flag to the test runner causes it to run tests in +a more random order which helps to check that the various tests do not interfere +with each other. The ``-w`` flag causes failing tests to be run again to see +if the failures are transient or consistent. +The ``-uall`` flag allows the use of all available +resources so as to not skip tests requiring, for example, Internet access. + +To check for reference leaks (only needed if you modified C code), +you can enable reference leak checking during testing using the ``-R`` flag. +For example, using the command:: + + python -m test <test_name> -R : + +This default setting performs a few initial warm-up runs to stabilize the reference count, +followed by additional runs to check for leaks. + +If you want more control over the number of runs, you can specify ``warmups`` and ``repeats`` explicitly:: + + python -m test <test_name> -R <warmups>:<repeats> + +For instance, ``-R 3:2`` will first run the test 3 times to settle down the +reference count, and then run it 2 more times to check for leaks. + +You can also execute the ``Tools/scripts/run_tests.py`` script as found in a +CPython checkout. The script tries to balance speed with thoroughness. But if +you want the most thorough tests you should use the strenuous approach shown +above. + +Locale support +-------------- + +Some tests require specific locales to run successfully. These locales are +often non-default, non-English, non-UTF-8 locales. If a necessary locale is +unavailable, the test is skipped or runs in the dry-run mode. +Additional locales that you may find helpful to set up on developer's machines +or buildbots include: + +* ``en_US`` (``en_US.utf8``, ``en_US.iso88591``) --- the standard default +* ``de_DE`` (``de_DE.UTF-8``) or ``fr_FR`` (``fr_FR.utf8``, ``fr_FR.iso88591``, + ``fr_FR.iso885915@euro``) --- common non-English locales +* ``tr_TR`` (``tr_TR.iso88599``) --- Turkish has different rules for upper/lower + cases of "i" and "I". +* ``ps_AF`` --- used in ``test_decimal`` + +On Linux and macOS, the ``locale`` command can be used to list available +locales and change the settings. Environment variables ``LANG`` and those +prefixed with ``LC_`` can be used to set the locale. + +Unexpected skips +---------------- + +Sometimes when running the test suite, you will see "unexpected skips" +reported. These represent cases where an entire test module has been +skipped, but the test suite normally expects the tests in that module to +be executed on that platform. + +Often, the cause is that an optional module hasn't been built due to missing +build dependencies. In these cases, the missing module reported when the test +is skipped should match one of the modules reported as failing to build when +:ref:`compiling`. + +In other cases, the skip message should provide enough detail to help figure +out and resolve the cause of the problem (for example, the default security +settings on some platforms will disallow some tests) + + +Writing +======= + +Writing tests for Python is much like writing tests for your own code. Tests +need to be thorough, fast, isolated, consistently repeatable, and as simple as +possible. We try to have tests both for normal behaviour and for error +conditions. Tests live in the ``Lib/test`` directory, where every file that +includes tests has a ``test_`` prefix. + +One difference with ordinary testing is that you are encouraged to rely on the +:py:mod:`test.support` module. It contains various helpers that are tailored to +Python's test suite and help smooth out common problems such as platform +differences, resource consumption and cleanup, or warnings management. +That module is not suitable for use outside of the standard library. + +When you are adding tests to an existing test file, it is also recommended +that you study the other tests in that file; it will teach you which precautions +you have to take to make your tests robust and portable. + +For tests of the C API, see Tests sections in :ref:`c-api`. + + +Benchmarks +========== + +Benchmarking is useful to test that a change does not degrade performance. + +`The Python Benchmark Suite <https://github.com/python/pyperformance>`__ +has a collection of benchmarks for all Python implementations. Documentation +about running the benchmarks is in the `README.txt +<https://github.com/python/pyperformance/blob/main/README.rst>`__ of the repo. diff --git a/silencewarnings.rst b/testing/silence-warnings.rst similarity index 74% rename from silencewarnings.rst rename to testing/silence-warnings.rst index 97f4a36b35..81de500bfc 100644 --- a/silencewarnings.rst +++ b/testing/silence-warnings.rst @@ -1,13 +1,15 @@ +.. _silence-warnings: .. _silencewarnings: -Silence Warnings From the Test Suite +==================================== +Silence warnings from the test suite ==================================== When running Python's test suite, no warnings should result when you run it under :ref:`strenuous testing conditions <strenuous_testing>` (you can ignore the extra flags passed to ``test`` that cause randomness and parallel execution if you want). Unfortunately new warnings are added to Python on occasion which -take some time to eliminate (e.g., ``ResourceWarning``). Typically the easy +take some time to eliminate (for example, ``ResourceWarning``). Typically the easy warnings are dealt with quickly, but the more difficult ones that require some thought and work do not get fixed immediately. @@ -15,4 +17,4 @@ If you decide to tackle a warning you have found, open an issue on the `issue tracker`_ (if one has not already been opened) and say you are going to try and tackle the issue, and then proceed to fix the issue. -.. _issue tracker: https://bugs.python.org +.. _issue tracker: https://github.com/python/cpython/issues diff --git a/tools/rstlint.py b/tools/rstlint.py deleted file mode 100755 index ed236fd33c..0000000000 --- a/tools/rstlint.py +++ /dev/null @@ -1,319 +0,0 @@ -#!/usr/bin/env python3 -# -*- coding: utf-8 -*- - -# Check for stylistic and formal issues in .rst and .py -# files included in the documentation. -# -# 01/2009, Georg Brandl - -# TODO: - wrong versions in versionadded/changed -# - wrong markup after versionchanged directive - -from __future__ import with_statement - -import os -import re -import sys -import getopt -from os.path import join, splitext, abspath, exists -from collections import defaultdict - -directives = [ - # standard docutils ones - 'admonition', - 'attention', - 'caution', - 'class', - 'compound', - 'container', - 'contents', - 'csv-table', - 'danger', - 'date', - 'default-role', - 'epigraph', - 'error', - 'figure', - 'footer', - 'header', - 'highlights', - 'hint', - 'image', - 'important', - 'include', - 'line-block', - 'list-table', - 'meta', - 'note', - 'parsed-literal', - 'pull-quote', - 'raw', - 'replace', - 'restructuredtext-test-directive', - 'role', - 'rubric', - 'sectnum', - 'sidebar', - 'table', - 'target-notes', - 'tip', - 'title', - 'topic', - 'unicode', - 'warning', - # Sphinx and Python docs custom ones - 'acks', - 'attribute', - 'autoattribute', - 'autoclass', - 'autodata', - 'autoexception', - 'autofunction', - 'automethod', - 'automodule', - 'centered', - 'cfunction', - 'class', - 'classmethod', - 'cmacro', - 'cmdoption', - 'cmember', - 'code-block', - 'confval', - 'cssclass', - 'ctype', - 'currentmodule', - 'cvar', - 'data', - 'decorator', - 'decoratormethod', - 'deprecated-removed', - 'deprecated(?!-removed)', - 'describe', - 'directive', - 'doctest', - 'envvar', - 'event', - 'exception', - 'function', - 'glossary', - 'highlight', - 'highlightlang', - 'impl-detail', - 'index', - 'literalinclude', - 'method', - 'miscnews', - 'module', - 'moduleauthor', - 'opcode', - 'pdbcommand', - 'productionlist', - 'program', - 'role', - 'sectionauthor', - 'seealso', - 'sourcecode', - 'staticmethod', - 'tabularcolumns', - 'testcode', - 'testoutput', - 'testsetup', - 'toctree', - 'todo', - 'todolist', - 'versionadded', - 'versionchanged', -] - -all_directives = '(' + '|'.join(directives) + ')' -seems_directive_re = re.compile(r'(?<!\.)\.\. %s([^a-z:]|:(?!:))' % all_directives) -default_role_re = re.compile(r'(^| )`\w([^`]*?\w)?`($| )') -leaked_markup_re = re.compile(r'[a-z]::\s|`|\.\.\s*\w+:') - - -checkers = {} - -checker_props = {'severity': 1, 'falsepositives': False} - - -def checker(*suffixes, **kwds): - """Decorator to register a function as a checker.""" - - def deco(func): - for suffix in suffixes: - checkers.setdefault(suffix, []).append(func) - for prop in checker_props: - setattr(func, prop, kwds.get(prop, checker_props[prop])) - return func - - return deco - - -@checker('.py', severity=4) -def check_syntax(fn, lines): - """Check Python examples for valid syntax.""" - code = ''.join(lines) - if '\r' in code: - if os.name != 'nt': - yield 0, '\\r in code file' - code = code.replace('\r', '') - try: - compile(code, fn, 'exec') - except SyntaxError as err: - yield err.lineno, 'not compilable: %s' % err - - -@checker('.rst', severity=2) -def check_suspicious_constructs(fn, lines): - """Check for suspicious reST constructs.""" - inprod = False - for lno, line in enumerate(lines): - if seems_directive_re.search(line): - yield lno + 1, 'comment seems to be intended as a directive' - if '.. productionlist::' in line: - inprod = True - elif not inprod and default_role_re.search(line): - yield lno + 1, 'default role used' - elif inprod and not line.strip(): - inprod = False - - -@checker('.py', '.rst') -def check_whitespace(fn, lines): - """Check for whitespace and line length issues.""" - for lno, line in enumerate(lines): - if '\r' in line: - yield lno + 1, '\\r in line' - if '\t' in line: - yield lno + 1, 'OMG TABS!!!1' - if line[:-1].rstrip(' \t') != line[:-1]: - yield lno + 1, 'trailing whitespace' - - -@checker('.rst', severity=0) -def check_line_length(fn, lines): - """Check for line length; this checker is not run by default.""" - for lno, line in enumerate(lines): - if len(line) > 81: - # don't complain about tables, links and function signatures - if ( - line.lstrip()[0] not in '+|' - and 'http://' not in line - and not line.lstrip().startswith( - ('.. function', '.. method', '.. cfunction') - ) - ): - yield lno + 1, "line too long" - - -@checker('.html', severity=2, falsepositives=True) -def check_leaked_markup(fn, lines): - """Check HTML files for leaked reST markup; this only works if - the HTML files have been built. - """ - for lno, line in enumerate(lines): - if leaked_markup_re.search(line): - yield lno + 1, 'possibly leaked markup: %r' % line - - -def main(argv): - usage = '''\ -Usage: %s [-v] [-f] [-s sev] [-i path]* [path] - -Options: -v verbose (print all checked file names) - -f enable checkers that yield many false positives - -s sev only show problems with severity >= sev - -i path ignore subdir or file path -''' % argv[0] - - try: - gopts, args = getopt.getopt(argv[1:], 'vfs:i:') - except getopt.GetoptError: - print(usage) - return 2 - - verbose = False - severity = 1 - ignore = [] - falsepos = False - for opt, val in gopts: - if opt == '-v': - verbose = True - elif opt == '-f': - falsepos = True - elif opt == '-s': - severity = int(val) - elif opt == '-i': - ignore.append(abspath(val)) - - if len(args) == 0: - path = '.' - elif len(args) == 1: - path = args[0] - else: - print(usage) - return 2 - - if not exists(path): - print('Error: path %s does not exist' % path) - return 2 - - count = defaultdict(int) - - for root, dirs, files in os.walk(path): - # ignore subdirs in ignore list - if abspath(root) in ignore: - del dirs[:] - continue - - for fn in files: - fn = join(root, fn) - if fn[:2] == './': - fn = fn[2:] - - # ignore files in ignore list - if abspath(fn) in ignore: - continue - - ext = splitext(fn)[1] - checkerlist = checkers.get(ext, None) - if not checkerlist: - continue - - if verbose: - print('Checking %s...' % fn) - - try: - with open(fn, 'r', encoding='utf-8') as f: - lines = list(f) - except (IOError, OSError) as err: - print('%s: cannot open: %s' % (fn, err)) - count[4] += 1 - continue - - for checker in checkerlist: - if checker.falsepositives and not falsepos: - continue - csev = checker.severity - if csev >= severity: - for lno, msg in checker(fn, lines): - print('[%d] %s:%d: %s' % (csev, fn, lno, msg)) - count[csev] += 1 - if verbose: - print() - if not count: - if severity > 1: - print('No problems with severity >= %d found.' % severity) - else: - print('No problems found.') - else: - for severity in sorted(count): - number = count[severity] - print('%d problem%s with severity %d found.' % - (number, 's' if number > 1 else '', severity)) - return int(bool(count)) - - -if __name__ == '__main__': - sys.exit(main(sys.argv)) diff --git a/tools/serve.py b/tools/serve.py deleted file mode 100755 index 98b1e5d46c..0000000000 --- a/tools/serve.py +++ /dev/null @@ -1,37 +0,0 @@ -#!/usr/bin/env python3 -''' -Small wsgiref based web server. Takes a path to serve from and an -optional port number (defaults to 8000), then tries to serve files. -Mime types are guessed from the file names, 404 errors are raised -if the file is not found. Used for the make serve target in Doc. -''' -import sys -import os -import mimetypes -from wsgiref import simple_server, util - - -def app(environ, respond): - - fn = os.path.join(path, environ['PATH_INFO'][1:]) - if '.' not in fn.split(os.path.sep)[-1]: - fn = os.path.join(fn, 'index.html') - type = mimetypes.guess_type(fn)[0] - - if os.path.exists(fn): - respond('200 OK', [('Content-Type', type)]) - return util.FileWrapper(open(fn, "rb")) - else: - respond('404 Not Found', [('Content-Type', 'text/plain')]) - return [b'not found'] - - -if __name__ == '__main__': - path = sys.argv[1] - port = int(sys.argv[2]) if len(sys.argv) > 2 else 8000 - httpd = simple_server.make_server('', port, app) - print("Serving {} on http://localhost:{}, control-C to stop".format(path, port)) - try: - httpd.serve_forever() - except KeyboardInterrupt: - print("\b\bShutting down.") diff --git a/tools/static/custom.css b/tools/static/custom.css deleted file mode 100644 index 84d378196e..0000000000 --- a/tools/static/custom.css +++ /dev/null @@ -1,13 +0,0 @@ -div.related { - background-color: #6BA81E; - color: #DDD; - border-radius: 5px; -} - -div.related a { - color: #FFF; -} - -div.related a:hover { - color: #EEF; -} diff --git a/tools/templates/customsourcelink.html b/tools/templates/customsourcelink.html deleted file mode 100644 index 2487a0b041..0000000000 --- a/tools/templates/customsourcelink.html +++ /dev/null @@ -1,12 +0,0 @@ -{%- if show_source and has_source and sourcename %} - <div role="note" aria-label="source link"> - <h3>{{ _('This Page') }}</h3> - <ul class="this-page-menu"> - <li> - <a href="https://github.com/python/devguide/blob/master/{{ sourcename|replace('.rst.txt', '.rst') }}" - rel="nofollow">{{ _('Show Source') }} - </a> - </li> - </ul> - </div> -{%- endif %} diff --git a/tools/templates/globaltoc.html b/tools/templates/globaltoc.html deleted file mode 100644 index 6ad89af594..0000000000 --- a/tools/templates/globaltoc.html +++ /dev/null @@ -1,11 +0,0 @@ -{# - basic/globaltoc.html - ~~~~~~~~~~~~~~~~~~~~ - - Sphinx sidebar template: global table of contents. - - :copyright: Copyright 2007-2019 by the Sphinx team, see AUTHORS. - :license: BSD, see LICENSE for details. -#} -<h3><a href="{{ pathto(master_doc) }}">{{ _('Sections') }}</a></h3> -{{ toctree() }} diff --git a/tracker.rst b/tracker.rst deleted file mode 100644 index 9f28aa3c62..0000000000 --- a/tracker.rst +++ /dev/null @@ -1,242 +0,0 @@ -============== -Issue Tracking -============== - -.. _tracker: - -Using the Issue Tracker -======================= - -If you think you have found a bug in Python, you can report it to the -`issue tracker`_. The `issue tracker`_ is also commonly referred to as -`bugs.python.org` and `bpo`. Documentation bugs can also be reported there. - -You can report bugs with the issue tracker itself to the `meta tracker`_. - -If you would like to file an issue about this devguide, please do so at the -`devguide repo`_. - - -Checking if a bug already exists --------------------------------- - -The first step before filing an issue report is to see whether the problem has -already been reported. Checking if the problem is an existing issue will: - -* help you see if the problem has already been resolved or has been fixed for - the next release -* save time for you and the developers -* help you learn what needs to be done to fix it -* determine if additional information, such as how to replicate the issue, - is needed - -To do see if the issue already exists, search the bug database using the -search box on the top of the issue tracker page. An `advanced search`_ is also -available by clicking on "Search" in the sidebar. - - -Reporting an issue ------------------- - -If the problem you're reporting is not already in the `issue tracker`_, you -need to log in by entering your user and password in the form on the left. -If you don't already have a tracker account, select the "Register" link or, -if you use `OpenID <https://openid.net>`_, one of the OpenID provider logos in -the sidebar. - -It is not possible to submit a bug report anonymously. - -Once logged in, you can submit a bug by clicking on the "Create New" link -in the sidebar. - -The submission form has a number of fields, and they are described in detail -in the :ref:`triaging` page. This is a short summary: - -* in the **Title** field, enter a *very* short description of the problem; - less than ten words is good; -* in the **Type** field, select the type of your problem (usually behavior); -* if you know which **Components** and **Versions** are affected by the issue, - you can select these too; otherwise, leave them blank; -* last but not least, you have to describe the problem in detail, including - what you expected to happen, what did happen, and how to replicate the - problem in the **Comment** field. Be sure to include whether any extension - modules were involved, and what hardware and software platform you were using - (including version information as appropriate). - - -Understanding the issue's progress and status ---------------------------------------------- - -The triaging team will take care of setting other fields, and possibly assign -the issue to a specific developer. You will automatically receive an update -each time an action is taken on the bug. - - -Disagreement With a Resolution on the Issue Tracker -=================================================== - -As humans, we will have differences of opinions from time to time. First and -foremost, please be respectful that care, thought, and volunteer time went into -the resolution. - -With this in mind, take some time to consider any comments made in association -with the resolution of the issue. On reflection, the resolution steps may seem -more reasonable than you initially thought. - -If you still feel the resolution is incorrect, then raise a thoughtful question -on `python-dev`_. Further argument and disrespectful discourse on `python-dev`_ -after a consensus has been reached amongst the core developers is unlikely to -win any converts. - -As a reminder, issues closed by a core developer have already been carefully -considered. Please do not reopen a closed issue. - -.. _python-dev: https://mail.python.org/mailman/listinfo/python-dev - - -.. _helptriage: - -Helping Triage Issues -===================== - -Once you know your way around how Python's source files are -structured and you are comfortable working with patches, a great way to -contribute is to help triage issues. Do realize, though, that experience -working on Python is needed in order to effectively help triage. - -Around the clock, new issues are being opened on the `issue tracker`_ and -existing issues are being updated. Every issue needs to be triaged to make -sure various things are in proper order. Even without special privileges you -can help with this process. - - -Classifying Reports -------------------- - -For bugs, an issue needs to: - -* clearly explain the bug so it can be reproduced -* include all relevant platform details -* state what version(s) of Python are affected by the bug. - -These are things you can help with once you have experience developing for -Python: - -* try reproducing the bug: For instance, if a bug is not clearly explained - enough for you to reproduce it then there is a good chance a core developer - won't be able to either. -* see if the issue happens on a different Python version: It is always helpful - to know if a bug not only affects the in-development version of Python, but - whether it also affects other versions in maintenance mode. -* write a unit test: If the bug lacks a unit test that should end up in - Python's test suite, having that written can be very helpful. - -This is all helpful as it allows triagers (i.e., -:ref:`people with the Developer role on the issue tracker <devrole>`) to -properly classify an issue so it can be handled by the right core developers in -a timely fashion. - - -Reviewing Patches ------------------ - -If an issue has a patch attached that has not been reviewed, you can help by -making sure the patch: - -* follows the style guides -* applies cleanly to an up-to-date clone -* is a good solution to the problem it is trying to solve -* includes proper tests -* includes proper documentation changes -* submitter is listed in ``Misc/ACKS``, either already or the patch adds them - -Doing all of this allows core developers and :ref:`triagers <devrole>` to more -quickly look for subtle issues that only people with extensive experience -working on Python's code base will notice. - - -Finding an Issue You Can Help With ----------------------------------- - -If you want to help triage issues, you might also want to search for issues -in modules which you have a working knowledge. Search for the name of a module -in the issue tracker or use the `advanced search`_ to search for specific -components (e.g. "Windows" if you are a Windows developer, "Extension Modules" -if you are familiar with C, etc.). Finally you can use the "Random issue" link -in the sidebar to pick random issues until you find an issue that you like. -You may find old issues that can be closed, either because they -are no longer valid or they have a patch that is ready to be committed, -but no one has had the time to do so. - -In the sidebar you can also find links to summaries for easy issues and -issues with a patch. - - -.. _devrole: - -Gaining the "Developer" Role on the Issue Tracker -================================================= - -When you have consistently shown the ability to properly -help triage issues without guidance, you may request that you -be given the "Developer" role on the `issue tracker`_. You can make the request -of any person who already has the Developer role. If they decide you are ready -to gain the extra privileges on the tracker they will then act as a mentor to -you until you are ready to do things entirely on your own. There is no set rule -as to how many issues you need to have helped with before or how long you have -been participating. The key requirements are that you show the desire to -help, you are able to work well with others (especially those already with the -Developer role), and that have a firm grasp of how to do things on the issue -tracker properly on your own. - -Gaining the Developer role will allow you to set any value on any issue in the -tracker, releasing you from the burden of having to ask others to set values on -an issue for you in order to properly triage something. This will not only help -speed up and simplify your work in helping out, but also help lessen the -workload for everyone by gaining your help. - - -The Meta Tracker -================ - -If you find an issue with the `issue tracker`_, you can report it to the -`meta tracker`_. The meta tracker is where you file issues against anything -you come across when working with the issue tracker itself (e.g you can't -attach a file, the layout is broken on your browser, Rietveld gave you an -error, etc.). - -If you want to contribute to the tracker you can get a checkout of the source -and install a local instance where to experiment. You can find detailed -instructions on the `Tracker Development`_ page. - - -.. seealso:: - - | *Issues with Python and documentation* - - `The Python issue tracker <https://bugs.python.org/>`_ - Where to report issues about Python. - - `The New-bugs-announce mailing list <https://mail.python.org/mailman/listinfo/new-bugs-announce>`_ - Where all the new issues created on the tracker are reported. - - `The Python-bugs-list mailing list <https://mail.python.org/mailman/listinfo/python-bugs-list>`_ - Where all the changes to issues are reported. - - *The meta tracker and its development* - - `The meta tracker <https://github.com/python/psf-infra-meta/issues>`_ - Where to report issues about the tracker itself. - - `The Tracker development wiki page <https://wiki.python.org/moin/TrackerDevelopment>`_ - Instructions about setting up a local instance of the bug tracker. - - `The Tracker-discuss mailing list <https://mail.python.org/mailman/listinfo/tracker-discuss>`_ - Discussions about the bug tracker. - - -.. _issue tracker: https://bugs.python.org/ -.. _meta tracker: https://github.com/python/psf-infra-meta/issues -.. _advanced search: https://bugs.python.org/issue?@template=search -.. _Tracker Development: https://wiki.python.org/moin/TrackerDevelopment -.. _devguide repo: https://github.com/python/devguide/issues diff --git a/triage/github-bpo-faq.rst b/triage/github-bpo-faq.rst new file mode 100644 index 0000000000..f4f8b16dd4 --- /dev/null +++ b/triage/github-bpo-faq.rst @@ -0,0 +1,124 @@ +.. _github-bpo-faq: +.. _gh-faq: + +=========================== +GitHub issues for BPO users +=========================== + +Here are some frequently asked questions about how to do things in +GitHub issues that you used to be able to do on `bpo`_. + +Before you ask your own question, make sure you read :ref:`tracker` +and :ref:`triaging` (specifically including :ref:`gh-labels`) as those +pages include a lot of introductory material. + +How to format my comments nicely? +================================= + +There is a wonderful `beginner guide to writing and formatting on GitHub +<https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github>`__. +Highly recommended. + +One pro-tip we can sell you right here is that if you want to paste +some longer log as a comment, attach a file instead (see how below). +If you still insist on pasting it in your comment, do it like this:: + + <details> + <summary>This is the summary text, click me to expand</summary> + + Here goes the long, long text. + It will be collapsed by default! + </details> + +How to attach files to an issue? +================================ + +Drag them into the comment field, wait until the file uploads, and GitHub +will automatically put a link to your file in your comment text. + +How to link to file paths in the repository when writing comments? +================================================================== + +Use Markdown links. If you link to the default GitHub path, the file +will link to the latest current version on the given branch. + +You can get a permanent link to a given revision of a given file by +`pressing "y" <https://docs.github.com/en/repositories/working-with-files/using-files/getting-permanent-links-to-files>`__. + +How to do advanced searches? +============================ + +Use the `GitHub search syntax`_ or the interactive `advanced search`_ form +that generates search queries for you. + +Where is the "nosy list"? +========================= + +Subscribe another person to the issue by tagging them in the comment with +``@username``. + +If you want to subscribe yourself to an issue, click the +:guilabel:`🔔 Subscribe` button in the sidebar. + +Similarly, if you were tagged by somebody else but +decided this issue is not for you, you might click the +:guilabel:`🔕 Unsubscribe` button in the sidebar. + +There is no exact equivalent of the "nosy list" feature, so to preserve +this information during the transfer, we list the previous members of +this list in the first message on the migrated issue. + +How to add issue dependencies? +============================== + +Add a checkbox list like this in the issue description:: + + - [x] #739 + - [ ] https://github.com/octo-org/octo-repo/issues/740 + - [ ] Add delight to the experience when all tasks are complete :tada: + +then those will become sub-tasks on the given issue. Moreover, GitHub will +automatically mark a task as complete if the other referenced issue is +closed. More details in the `official GitHub documentation +<https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/about-task-lists>`__. + +What on earth is a "mannequin"? +=============================== + +For issues migrated to GitHub from `bpo`_ where the authors or commenters +are not core developers, we opted not to link to their GitHub accounts +directly. Users not in the `python organization on GitHub +<https://github.com/orgs/python/people>`__ might not like comments to +appear under their name from an automated import. Others never linked GitHub on +`bpo`_ in the first place so linking their account, if any, would be impossible. + +In those cases a "mannequin" account is present to help follow the conversation +that happened in the issue. In case the user did share their GitHub account +name in their `bpo`_ profile, we use that. Otherwise, their classic `bpo`_ +username is used instead. + +Where did the "resolution" field go? +==================================== + +Based on historical data we found it not being used very often. + +Where did the "low", "high", and "critical" priorities go? +========================================================== + +Based on historical data we found those not being used very often. + +How to find a random issue? +=========================== + +This is not supported by GitHub. + +Where are regression labels? +============================ + +We rarely updated this information and it turned out not to be +particularly useful outside of the change log. + + +.. _bpo: https://bugs.python.org/ +.. _GitHub search syntax: https://docs.github.com/en/search-github/getting-started-with-searching-on-github/understanding-the-search-syntax +.. _advanced search: https://github.com/search/advanced diff --git a/triage/index.rst b/triage/index.rst new file mode 100644 index 0000000000..a054ad62f2 --- /dev/null +++ b/triage/index.rst @@ -0,0 +1,12 @@ +=================== +Issues and triaging +=================== + +.. toctree:: + :maxdepth: 5 + + issue-tracker + triaging + labels + github-bpo-faq + triage-team diff --git a/triage/issue-tracker.rst b/triage/issue-tracker.rst new file mode 100644 index 0000000000..4dd0815e4c --- /dev/null +++ b/triage/issue-tracker.rst @@ -0,0 +1,158 @@ +.. _issue-tracker: +.. _tracker: + +============= +Issue tracker +============= + + +Using the issue tracker +======================= + +If you think you have found a bug in Python, you can report it to the +`issue tracker`_. The `issue tracker`_ is now hosted on GitHub, alongside +the codebase and pull requests. Documentation bugs can also be reported there. + +If you would like to file an issue about this devguide, please do so at the +`devguide repo`_. + +.. note:: + Prior to moving the issue tracker to GitHub, + Python used to use a dedicated `Roundup`_ instance as its issue tracker. + That `old bug tracker`_ was hosted under the domain ``bugs.python.org`` + (sometimes called ``bpo`` for short). A read-only version is + available on that domain for historical purposes. All ``bpo`` data has been + migrated to the current `issue tracker`_ on GitHub. + + If you're familiar with ``bpo`` and would like to learn more about GitHub + issues, please read this page, and the :ref:`triaging` page as they + provide good introductory material. There is also a :ref:`gh-faq` + document to answer some of the more popular questions. + +Checking if a bug already exists +-------------------------------- + +The first step before filing an issue report is to see whether the problem has +already been reported. Checking if the problem is an existing issue will: + +* help you see if the problem has already been resolved or has been fixed for + the next release +* save time for you and the developers +* help you learn what needs to be done to fix it +* determine if additional information, such as how to replicate the issue, + is needed + +To see if an issue already exists, search the bug database using the search box +above the list of bugs on the issues page. A form-based `advanced search`_ query +builder is also available on GitHub to help creating the text query you need. + +Reporting an issue +------------------ + +If the problem you're reporting is not already in the `issue tracker`_, you +can report it using the green :guilabel:`New issue` button on the right of the search +box above the list of bugs. If you're not already signed in to GitHub, it +will ask you to do so now. + +First you need to select what kind of problem you want to report. The +available choices include, for example: + +* **Bug report**: an existing feature isn't working as expected. +* **Documentation**: there is missing, invalid, or misleading documentation. +* **Feature or enhancement**: suggest a new feature for Python. +* **Report a security vulnerability**: privately report a security vulnerability. + +Depending on your choice, a dedicated form template will appear. +In particular, you'll notice that the last button actually takes you to +the `Python Discourse`_ (``discuss.python.org``), +where many Python-related discussions take place. + +The submission form has only two fields that you need to fill: + +* in the **Title** field, enter a *very* short description of the problem; + less than ten words is good; +* in the **Write** field, describe the problem in detail using hints from + the template that was put in that field for you. Be sure to include what + you expected to happen, what did happen, and how to replicate the + problem. Be sure to include whether any extension modules were involved, + and what hardware and software platform you were using (including version + information as appropriate). In particular, *what version of Python* you + were using. + +You can tag someone, with :samp:`@{username}` in a comment, +if you think the issue should be brought to their attention. +Use the :ref:`experts` to know who wants to be +tagged or assigned for specific areas. + +There are a number of additional fields like **Assignees**, **Labels**, +and **Projects**. Those are filled by triagers and core +developers and are covered in the :ref:`triaging` page. You don't need +to worry about those when reporting issues as a Python user. + +Adding special links +-------------------- + +The following abbreviations can be used in a comment to generate a link: + +* :samp:`GH-{NNN}`: to link to another issue or PR; +* :samp:`PEP-{NNN}`: to link to a specific PEP; +* :samp:`BPO-{NNN}`: to link to a bugs.python.org issue; + +See also the `list of autolinks supported by GitHub <autolinks_>`_. + +Following issues +---------------- + +If you want to subscribe yourself to an issue, click the :guilabel:`🔔 Subscribe` +button in the sidebar. Similarly, if you were tagged by somebody else but +decided this issue is not for you, click the :guilabel:`🔕 Unsubscribe` +button in the sidebar. Note that you are automatically subscribed to +issues you created. + +Tracking dependencies and duplicates +------------------------------------ + +It is possible to use `checklists`_ to track dependencies or, +in case of meta-issues, to link to the other related issues. + +By writing :samp:`Duplicate of #{NNN}` in a comment, you can +`mark issues and PRs as duplicates <duplicates_>`_. + + +Disagreement with a resolution on the issue tracker +=================================================== + +As humans, we will have differences of opinions from time to time. First and +foremost, please be respectful that care, thought, and volunteer time went into +the resolution. + +With this in mind, take some time to consider any comments made in association +with the resolution of the issue. On reflection, the resolution steps may seem +more reasonable than you initially thought. + +If you still feel the resolution is incorrect, then raise a thoughtful question +on the `Core Development Discourse category`_. +Further argument and disrespectful responses +after a consensus has been reached amongst the core developers is unlikely to +win any converts. + +As a reminder, issues closed by a core developer have already been carefully +considered. Please do not reopen a closed issue. An issue can be closed with +reason either as ``complete`` or ``not planned``. + +.. seealso:: + + `The Python issue tracker <issue tracker_>`_ + Where to report issues about Python. + + +.. _issue tracker: https://github.com/python/cpython/issues +.. _advanced search: https://github.com/search/advanced +.. _devguide repo: https://github.com/python/devguide/issues +.. _Roundup: https://www.roundup-tracker.org/ +.. _Python Discourse: https://discuss.python.org/ +.. _autolinks: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/autolinked-references-and-urls +.. _checklists: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/about-task-lists +.. _duplicates: https://docs.github.com/en/issues/tracking-your-work-with-issues/administering-issues/marking-issues-or-pull-requests-as-a-duplicate +.. _Core Development Discourse category: https://discuss.python.org/c/core-dev/23 +.. _old bug tracker: https://bugs.python.org/ diff --git a/triage/labels.rst b/triage/labels.rst new file mode 100644 index 0000000000..96e0d8f58e --- /dev/null +++ b/triage/labels.rst @@ -0,0 +1,177 @@ +.. _labels: +.. _gh-labels: + +============= +GitHub labels +============= + +Triagers, core developers and bots can add labels on GitHub +to categorize issues and pull requests. +Many labels are shared for both use cases, while some are dedicated +only to one. Below is a possibly inexhaustive list, but it should get +you going. For a full list, see `here <https://github.com/python/cpython/issues/labels>`__. + + +.. _general-purpose-labels: +.. _Type: +.. _labels-type: + +Type labels +=========== + +These labels are used to specify the type of issue: + +* :gh-label:`type-bug`: for unexpected behaviors, bugs, or exceptions + (not hard crashes). +* :gh-label:`type-crash`: for hard crashes of the interpreter, possibly with a + core dump. +* :gh-label:`type-feature`: for feature requests or enhancements. + Feature requests do not need :ref:`version labels <Version labels>`; + it is implicit that features are added to the ``main`` branch only. + The `Ideas Discourse category`_ can be used to discuss enhancements + before filing an issue. +* :gh-label:`type-refactor`: for general code refactoring that + does not change user-facing behaviour. +* :gh-label:`type-security`: for security issues. + See also `Reporting security issues in Python`_. + + +.. _Component: +.. _labels-component: + +Component labels +================ + +These labels are mostly used to specify which :ref:`part of the codebase +<build_directory_structure>` is affected by the issue/PR: + +* :gh-label:`stdlib`: for standard library modules in the :cpy-file:`Lib` + directory (written in Python). +* :gh-label:`extension-modules`: for standard library modules in the + :cpy-file:`Modules` directory (written in C). +* :gh-label:`interpreter-core`: for changes related to the interpreter core in + the :cpy-file:`Objects`, :cpy-file:`Python`, :cpy-file:`Grammar`, + and :cpy-file:`Parser` dirs (written mostly in C). +* :gh-label:`docs`: for documentation in the :cpy-file:`Doc` directory + (written in :ref:`reStructuredText <markup>`), docstrings, and code comments. +* :gh-label:`tests`: for tests in the :cpy-file:`Lib/test` directory + (written in Python) and other changes related to tests, :mod:`unittest`, + or :mod:`doctest`. + +OS labels +========= + +These labels are used to specify which operating systems are affected. +Since most issues either affect all systems or are specific to Unix, +we don't have a dedicated Unix label. + +* :gh-label:`OS-android` +* :gh-label:`OS-freebsd` +* :gh-label:`OS-ios` +* :gh-label:`OS-linux` +* :gh-label:`OS-windows` + +Use the :gh-label:`OS-unsupported` label for issues on platforms outside the +support tiers defined in :pep:`11`. Applying this label adds the issue to +`a GitHub project <https://github.com/orgs/python/projects/27/views/1>`__ where +it can be categorized further. +See also the :ref:`Platform experts list <platform-experts>`. + +.. _Expert labels: +.. _Topic labels: + +Topic labels +============ + +These labels are used to denote the specific topic area, if any, of +the issue/PR. This includes both specific modules/packages and generic +interest areas. + +Adding these labels is also a way to notify the relevant experts, since +they are encouraged to subscribe to them. Depending on the label, +this might also automatically add the issue to a GitHub project. + +You can see the `full list of topic labels on GitHub +<https://github.com/python/cpython/labels?q=topic>`__. + + +.. _Version labels: + +Version labels +============== + +These labels are used to indicate which versions of Python are affected. +The available version labels (with the form :samp:`3.{N}`) are updated +whenever new feature releases are created or retired. + +See also :ref:`the branch status page <branchstatus>` +for a list of active branches. + + +.. _Keywords: +.. _Other: +.. _Priority: +.. _labels-other: + +Other labels +============ + +* :gh-label:`build`/:gh-label:`performance`: for issues related + to the build process or performance, respectively. +* :gh-label:`easy`: for issues that are considered easy. +* :gh-label:`infra`: for issues related to the infrastructure of the + project (for example, GitHub Actions, dependabot, the buildbots). +* :gh-label:`pending`: for issues/PRs that will be closed unless further + feedback is provided. +* :gh-label:`release-blocker`/:gh-label:`deferred-blocker`: for issues/PRs + that, unless fixed, will hold the current or next release respectively. + Triagers may set these labels for issues that must be fixed before a release, + and the :ref:`branch's release manager <branchstatus>` + will review them and determine if they indeed qualify, + removing or retaining the label as appropriate. +* :gh-label:`sprint`: for easier filtering of issues/PRs being worked on + during official sprints. +* :gh-label:`stale`: for issues/PRs that have been inactive for a while. +* :gh-label:`triaged`: for issues that have been accepted as valid by a triager. + + +.. _GitHub Labels for PRs: +.. _github-pr-labels: + +Labels specific to PRs +====================== + +The following labels only apply to :ref:`Pull Requests <pullrequest>`. +They are either set automatically by bots, or added by humans +to trigger specific bot behaviors. + +* :gh-label:`DO-NOT-MERGE`: for PRs that shouldn't be merged in their current + state. It also prevents `miss-islington`_ from being able to automatically + merge the PR. +* :samp:`needs backport to {X.Y}`: used to indicate which branches the PR + should be backported to. Once the PR is merged, ``miss-islington`` will + automatically attempt to create backport PRs for the versions indicated + by these labels. + See also :ref:`the status of the Python branches <branchstatus>` for a list + of branches and the type of PRs that can be backported to them. +* :gh-label:`skip issue <skip%20issue>`: for trivial changes (such as + typo fixes, comment + changes, and section rephrases) that don't require a corresponding issue. +* :gh-label:`skip news <skip%20news>`: for PRs that don't need a NEWS entry. + The :ref:`news-entry` section covers in details in which cases the NEWS entry + can be skipped. +* :gh-label:`🔨 test-with-buildbots <%3Ahammer%3A%20test-with-buildbots>`: used + to test the latest commit with the :ref:`buildbot fleet <buildbots>` whenever + more testing is required before merging. This may take multiple hours to + complete. +* :gh-label:`🔨 test-with-refleak-buildbots <%3Ahammer%3A%20test-with-refleak-buildbots>`: + Run the reference leak buildbots on the latest commit. Useful for when the + code might be leaky. +* :samp:`awaiting {action}`: these labels are applied and used by `bedevere`_ + to indicate the stage of a PR and should not be applied manually. + + +.. _Reporting security issues in Python: https://www.python.org/dev/security/ +.. _Ideas Discourse category: https://discuss.python.org/c/ideas/6 +.. _miss-islington: https://github.com/python/miss-islington +.. _bedevere: https://github.com/python/bedevere/#pr-state-machine diff --git a/triage/triage-team.rst b/triage/triage-team.rst new file mode 100644 index 0000000000..7acebc130c --- /dev/null +++ b/triage/triage-team.rst @@ -0,0 +1,99 @@ +.. _triage-team: +.. _triagers: + +=========== +Triage Team +=========== + +The Python triage team is a group dedicated towards improving workflow +efficiency through thoughtful review and triage of open issues and pull +requests. This helps contributors receive timely feedback and enables core +developers to focus on reviewed items which reduces their workload. The +expectations of this role expand upon the "Triager" role on the +:ref:`issue tracker <tracker>`. The responsibilities listed below are primarily centered +around the Python GitHub repositories. This extends beyond CPython, and, as +needed, to other repos such as devguide and core-workflow. + +Responsibilities include: + +* Classifying issues and PRs +* Applying appropriate :ref:`labels <gh-labels>` to issues/PRs +* Notifying appropriate core developers +* :ref:`Reviewing PRs <reviewing-prs>` +* Assisting contributors + +Although triagers have the power to close PRs, they should generally not do so +without first consulting a core developer. By having triagers and core developers work together, +the author receives a careful consideration of their PR. This encourages future +contributions, regardless of whether their PR is accepted or closed. + +Nonetheless, triagers should feel free to close a PR if they judge that the +chance of the PR being merged would be exceedingly low, even if substantial +revisions were made to the PR. This includes (but is not limited to) the +following: + +* PRs proposing solely cosmetic changes +* PRs proposing changes to deprecated modules +* PRs that are no longer relevant. This includes: + + - PRs proposing fixes for bugs that can no longer be reproduced + - PRs proposing changes that have been rejected by Python core developers + elsewhere (for example, in an issue or a PEP rejection notice) + +If a triager has any doubt about whether to close a PR, +they should consult a core developer before taking any action. + +Triagers can also make use of the :gh-label:`pending` and :gh-label:`stale` +labels to suggest that a PR may be suitable for closure. +For more information, see the entries in the :ref:`labels-other` section. + +Note that it is of paramount importance to treat every contributor to the Python +project kindly and with respect. Regardless of whether they're entirely new +or a veteran core developer, they're actively choosing to voluntarily donate their +time towards the improvement of Python. As is the case with any member of +the Python Software Foundation, always follow the `PSF Code of Conduct`_. + +.. _PSF Code of Conduct: https://policies.python.org/python.org/code-of-conduct/ + + +Becoming a member of the Python triage team +=========================================== + +All Python core developers are welcome to invite a Python contributor to the +Python triage team. Triagers will be responsible to handle not just issues, but +also pull requests, and even managing backports. A Python triager has access to +more repositories than just CPython. + +When you have consistently shown the ability to properly +help triage issues without guidance, you may request that you +be given the "Triager" role on the :ref:`issue tracker <tracker>`. +You can make the request to any core developer. If they decide you are ready +to gain the extra privileges on the tracker they will then act as a mentor to +you until you are ready to do things entirely on your own. There is no set rule +as to how many issues you need to have helped with before or how long you have +been participating. The key requirements are that you show the desire to +help, you are able to work well with others (especially those already with the +Triager role), and that have a firm grasp of how to do things on the issue +tracker properly on your own. + +Gaining the Triager role will allow you to set any value on any issue in the +tracker, releasing you from the burden of having to ask others to set values on +an issue for you in order to properly triage something. This will not only help +speed up and simplify your work in helping out, but also help lessen the +workload for everyone by gaining your help. + +Any existing active contributor to the Python repository on GitHub can +transition into becoming a Python triager. They can request this to any core +developer, either confidentially via a DM in Discourse, or +publicly by opening an `issue in the core-workflow repository +<https://github.com/python/core-workflow/issues/new?template=triage_membership.md>`__. +If the core developer decides you are ready to gain the extra privileges on the +tracker, they will ask a :ref:`Python organization admin <current owners>` +to invite you to the Python organisation, and then act as a mentor to you until +you are ready to do things entirely on your own. + +For every new triager, it would be great to announce them in the +`Committers category <https://discuss.python.org/c/committers/5>`__ +on the `Python Discourse <https://discuss.python.org/>`__ +(`example announcement +<https://discuss.python.org/t/abhilash-raj-has-been-granted-triage-role-on-github/2089>`__). diff --git a/triage/triaging.rst b/triage/triaging.rst new file mode 100644 index 0000000000..207c59082f --- /dev/null +++ b/triage/triaging.rst @@ -0,0 +1,112 @@ +.. _triaging: + +================= +Triaging an issue +================= + +This section of the devguide documents the :ref:`issue tracker <tracker>` for +users and developers. + + +Checklist for triaging +====================== + +* Read the initial message and the comments. +* Check that the title is reasonably concise, while including enough specifics + so that those scanning the list of issues can quickly identify its topic. +* For pull requests, ensure that the corresponding issue is added before + the title (:samp:`gh-NNNNN: {Title}`). +* Set all the relevant :ref:`labels <gh-labels>`. +* Where appropriate, set the :guilabel:`Assignees`, :guilabel:`Reviewers`, + :guilabel:`Project` fields, and possibly @mention relevant people. +* You might also leave a brief comment about the proposed next action needed. + If there is a long message list, a summary can be very helpful. +* If the issue is clearly invalid (unrelated to CPython, duplicate, spam, etc), + you can use GitHub's "Close as not planned" option. + +Assignees +--------- + +This field indicates who is expected to take the next step in resolving +the issue. + +It is acceptable to assign an issue to someone if the issue cannot move +forward without their help; for example, they need to make a technical decision on +how to proceed. Also consult the :ref:`experts` as certain +stdlib modules should always be assigned to a specific person. + +Note that in order to assign an issue to someone, that person **must** be +a team member, likely a triager or a core developer. + +.. The Assignees subsection was copied from the labels.rst page in #930. + For consistency, the other fields mentioned above should be documented too. + + +.. _helptriage: + +Helping triage issues +===================== + +Once you know your way around how Python's source files are +structured and you are comfortable with the workflow, a great way to +contribute is to help triage issues. Do realize, though, that experience +working on Python is needed in order to effectively help triage. + +Around the clock, new issues are being opened on the :ref:`issue tracker +<tracker>` and existing issues are being updated. Every issue needs to be +triaged to make sure everything runs smoothly. + +Classifying reports +------------------- + +For bugs, an issue needs to: + +* clearly explain the bug so it can be reproduced +* include all relevant platform details +* state what version(s) of Python are affected by the bug. + +These are things you can help with once you have experience developing for +Python: + +* Try reproducing the bug: if it is not explained clearly + enough for you to reproduce it, then there is a good chance a core developer + won't be able to either. +* See if the issue happens on a different Python version: it is always helpful + to know if a bug not only affects the in-development version of Python, but + whether it also affects other versions in maintenance mode. +* Write a unit test: if the bug lacks a unit test that should end up in + Python's test suite, having that written can be very helpful. + +This is all helpful as it allows members of the :ref:`triage team <triage-team>` +to properly classify an issue so it can be handled by the right core developers +in a timely fashion. + +Reviewing pull requests +----------------------- + +If an issue has a linked pull request that has not been reviewed, +you can help by making sure the pull request: + +* is a good solution to the problem it is trying to solve +* follows the style guides (:pep:`7`, :pep:`8`, :ref:`style-guide`, etc.) +* includes proper tests +* includes proper documentation changes +* includes a :ref:`NEWS entry <news-entry>` (if needed) +* doesn't have conflicts with the ``main`` branch +* :ref:`doesn't have failing CI checks <keeping-ci-green>` + +Doing all of this allows core developers and :ref:`triagers <triage-team>` +to more quickly look for subtle issues that only people with extensive +experience working on Python's code base will notice. + +See also :ref:`committing`. + +Finding an issue you can help with +---------------------------------- + +If you want to help with triaging, you might also want to search for issues +in modules for which you have a working knowledge. Search for the name of a +module in the issue tracker, filter by label, or use the `advanced search`_ +to find these issues. + +.. _advanced search: https://github.com/search/advanced diff --git a/triaging.rst b/triaging.rst deleted file mode 100644 index fe40fe7201..0000000000 --- a/triaging.rst +++ /dev/null @@ -1,608 +0,0 @@ -.. _triaging: - -Triaging an Issue -================= - -This section of the devguide documents the `issue tracker`_ for users -and developers. - -Contributors with the Developer role on the `issue tracker`_ can triage issues -directly without any assistance. - -Additionally, this section provides an overview of the Python triage team. - -Python triage team ------------------- - -The Python triage team is a group dedicated towards improving workflow -efficiency through thoughtful review and triage of open issues and pull -requests. This helps contributors receive timely feedback and enables core -developers to focus on reviewed items which reduces their workload. The -expectations of this role expand upon the "Developer" role on the -`issue tracker`_. The responsibilities listed below are primarily centered -around the Python GitHub repositories. This extends beyond CPython, and, as -needed, to other repos such as devguide and core-workflow. - -Responsibilities include: - -* PR/issue management - - Renaming PRs - - Reviewing PRs - - Assisting contributors - - Notifying appropriate core developers -* Applying appropriate labels to PRs/Issues - - Skip news - - Skip issue - - Good first issue - - Other categorizations - -As triagers gain experience, they may have some intuition of when a PR should -be closed. Triagers can recommend closing a PR, but the final decision must be -made by a core developer. By having triagers and core developers work together, -the author receives a careful consideration of their PR. This encourages future -contributions, regardless of whether their PR is accepted or closed. - -Triagers can make use of the ``invalid`` and ``stale`` labels to suggest that a -PR may be suitable for closure. For more information, see the -:ref:`GitHub PR labels <github-pr-labels>` section. - -It is also of paramount importance to treat every contributor to the Python -project kindly and with respect. Regardless of whether they're entirely new -or a veteran core developer, they're actively choosing to voluntarily donate their -time towards the improvement of Python. As is the case with any member of -the Python Software Foundation, always follow the `PSF Code of Conduct`_. - -Becoming a member of the Python triage team -------------------------------------------- - -Any Python core developers are welcome to invite a Python contributor to the -Python triage team. Do note that the responsibilities of a Python triager -is more elevated than a developer on bpo. For example, the Python triager -has access to more repositories than just CPython. Triagers will be responsible -to handle not just issues, but also pull requests, and even managing backports. - -Any existing developers on b.p.o can transition into becoming a Python triager. -They can request this to any core developer, and the core developer -can pass the request to the `Python organization admin -<https://devguide.python.org/devcycle/?highlight=organization%20admin#current-owners>`_ -on GitHub. The request -can be made confidentially via a DM in Zulip or Discourse, or publicly by opening -an `issue in the core-workflow repository -<https://github.com/python/core-workflow/issues/new?template=triage_membership.md>`_. - -Any contributor who is not already a developer on b.p.o can also self-nominate -to be a member of Python triage team. They can request this to any core developer, -confidentially via DM in Zulip or Discourse, or publicly by opening an issue in core-workflow. -If a core developer agrees and is willing to vouch for them, the core developer -can pass the request to the GitHub administrator. They should also be added as -developer on bpo. - -For every new triager, it would be great to announce them in the python-committers -mailing list and core-workflow category in Discourse. `Example announcement -<https://discuss.python.org/t/abhilash-raj-has-been-granted-triage-role-on-github/2089>`_. - -.. _github-pr-labels: - -GitHub Labels for PRs -''''''''''''''''''''' - -An important component of triaging PRs for the CPython repo involves -appropriately categorizing them through the usage of labels. - -Labels for PRs include: - -DO-NOT-MERGE - Used on PRs to prevent miss-islington from being able - to automatically merge to pull request. This label is appropriate when a PR - has a non-trivial conflict with the branch it is being merged into. - -expert-asyncio - Used for PRs which involve changes to the asyncio module - or other asynchronous frameworks that utilize it. - -invalid - Used manually for PRs that do not meet basic requirements and - automatically added by bedevere when PR authors attempt to merge maintenace - branches into the master branch. During events such as the October - Hacktoberfest, this label will prevent the PR from counting toward the - author's contributions. - -needs backport to X.Y - Used for PRs which are appropriate to backport to - branches prior to master. Generally, backports to the maintenance branches - are primarily bugfixes and documentation clarifications. Backports to the - security branches are strictly reserved for PRs involving security fixes, such as - crashes, privilege escalation, and DoS. The use of this label will cause - miss-islington to attempt to automatically merge the PR into the branches - specified. - -OS-X - Used for PRs involving changes which only have an effect upon - a specific operating system. Current variations of the label include - OS-Windows and OS-Mac. - -skip issue - Used for PRs which involve trivial changes, such as typo fixes, - comment changes, and section rephrases. The majority of PRs require - an issue to be attached to, but if there are no code changes and the - section being modified retains the same meaning, this label might be - appropriate. - -skip news - Similar to the skip issue label, this label is used for PRs which - involve trivial changes, backports, or already have a relevant news entry - in another PR. Any potentially impactful changes should have a - corresponding news entry, but for trivial changes it's commonly at the - discretion of the PR author if they wish to opt-out of making one. - -sprint - Used for PRs authored during an in-person sprint, such as - at PyCon, EuroPython, or other official Python events. The label is - used to prioritize the review of those PRs during the sprint. - -stale - Used for PRs that include changes which are no longer relevant or when the - author hasn't responded to feedback in a long period of time. This label - helps core developers quickly identify PRs that are candidates for closure - or require a ping to the author. - -type-bugfix - Used for PRs that address unintentional behavior, but do not - pose significant security concerns. Generally, bugfixes will be attached - to a specific issue where the unintended behavior was first reported. - -type-documentation - Used for PRs that exclusively involve changes to - the documentation. Documentation includes `*.rst` files, docstrings, - and code comments. - -type-enhancement - Used for PRs that provide additional functionality - or capabilities beyond the existing specifications. - -type-performance - Used for PRs that provide performance optimizations. - -type-security - Used for PRs that involve critical security issues. Less severe - security concerns can instead use the type-bugfix label. - -type-tests - Used for PRs that exclusively involve changes to the tests. - -Fields in the Issue Tracker ---------------------------- - -The major elements found in an issue report include: - -* Classification (including *Title*) - These fields categorize the issue. - The fields include *Title*, *Type*, *Stage*, *Components*, and *Version*. -* Process - These fields indicate the state of the issue and its progress - toward resolution. The fields are *Status*, *Resolution*, *Dependencies*, - *Superseder*, *Assigned To*, *Nosy List*, *Priority*, *Keywords*, *Comment*, - *File*, *File Description*, *Remote hg repo*, *GitHub PR*. -* Messages -* History - -Title -''''' -A brief description of the issue. Review whether the title is too generic or -specifies an incorrect term or library. - -(Optional) Add a prefix at the start of the title to indicate the module, e.g. -IDLE, doc, or asyncio. - -Type -'''' -Describes the type of issue. If an issue does not fit within any -specific type, please do not set a type. - -+----------------+----------------------------------------------------------+ -| Type | Description | -+================+==========================================================+ -| behavior | Unexpected behavior, result, or exception. Most bugs | -| | will have this type. | -+----------------+----------------------------------------------------------+ -| compile error | Errors reported by the compiler while compiling Python. | -+----------------+----------------------------------------------------------+ -| crash | Hard crashes of the Python interpreter -- possibly with | -| | a core dump or a Windows error box. | -+----------------+----------------------------------------------------------+ -| enhancement | Issues that propose the addition of new functionality, | -| | such as new functions, classes, modules, or even new | -| | arguments for existing functions. Also used for | -| | improvements in the documentation, test suite and | -| | other refactorings. A good place to discuss enhancements | -| | prior to filing an issue is `python-ideas`_ mailing | -| | list. | -+----------------+----------------------------------------------------------+ -| performance | Situations where too much time is necessary to complete | -| | the task. For example, a common task now takes | -| | significantly longer to complete. | -+----------------+----------------------------------------------------------+ -| resource usage | Situations where too many resources (e.g. memory) are | -| | used. | -+----------------+----------------------------------------------------------+ -| security | Issues that might have security implications. Report | -| | security vulnerabilities using the procedure found in | -| | the `Reporting security issues in Python`_ page on the | -| | python.org website. | -+----------------+----------------------------------------------------------+ - -Stage -''''' -A needed next action to advance the issue. The *stage* needn't be set until -it is clear that the issue has been initially triaged and determined work -will be needed. - -+---------------+----------------------------------------------------------+ -| Stage | Description | -+===============+==========================================================+ -| test needed | The steps which are needed to reproduce the issue. The | -| | bug reporter should post a script, instructions, or | -| | example to help someone test or reproduce the issue. | -+---------------+----------------------------------------------------------+ -| needs patch | A patch or pull request is needed to solve the problem | -| | (i.e. fixing the bug or adding the requested | -| | improvement). | -+---------------+----------------------------------------------------------+ -| patch review | A patch or pull request exists, but it needs review. | -| | Any triager or core developer may do the review. | -+---------------+----------------------------------------------------------+ -| commit review | A triager performed a patch review and it looks good. | -| | This signals to core developers the patch or pull | -| | request needs a quick once-over to make sure nothing was | -| | overlooked before committing it. | -+---------------+----------------------------------------------------------+ -| resolved | The issue is considered closed and addressed (e.g. patch | -| | or pull request committed; expected behavior). | -+---------------+----------------------------------------------------------+ - -Components -'''''''''' -The area or Python library affected by the issue. This is a multi-select field. - -Choosing certain components, such as `Documentation`, may cause the issue to -be auto-assigned, i.e. the issue tracker may automatically fill in the -`Assigned To`_ field after you press ``Submit changes``. - -One or more components may be selected for an issue: - -+-------------------+------------------------------------------------------+ -| Component | Description | -+===================+======================================================+ -| 2to3 (*2.x to* | The 2to3 conversion tool in `Lib/lib2to3`_. | -| *3 conversion* | | -| *tool*) | | -+-------------------+------------------------------------------------------+ -| Build | The build process. | -+-------------------+------------------------------------------------------+ -| ctypes | The ctypes package in `Lib/ctypes`_. | -+-------------------+------------------------------------------------------+ -| Demos and Tools | The files in Tools_ and `Tools/demo`_. | -+-------------------+------------------------------------------------------+ -| Distutils | The distutils package in `Lib/distutils`_. | -+-------------------+------------------------------------------------------+ -| Documentation | The documentation in Doc_ (source used to build HTML | -| | docs for https://docs.python.org/). | -+-------------------+------------------------------------------------------+ -| email | The email package and related modules. | -+-------------------+------------------------------------------------------+ -| Extension Modules | C modules in Modules_. | -+-------------------+------------------------------------------------------+ -| IDLE | The `Lib/idlelib`_ package. | -+-------------------+------------------------------------------------------+ -| Installation | The installation process. | -+-------------------+------------------------------------------------------+ -| Interpreter Core | The interpreter core. | -| | The built-in objects in `Objects`_, the `Python`_, | -| | `Grammar`_ and `Parser`_ dirs. | -+-------------------+------------------------------------------------------+ -| IO | The I/O system, `Lib/io.py`_ and `Modules/_io`_. | -+-------------------+------------------------------------------------------+ -| Library (Lib) | Python modules in Lib_. | -+-------------------+------------------------------------------------------+ -| Macintosh | The Mac OS X operating system. | -+-------------------+------------------------------------------------------+ -| Regular | The `Lib/re.py`_ and `Modules/_sre.c`_ modules. | -| Expressions | | -+-------------------+------------------------------------------------------+ -| Tests | The unittest framework in `Lib/unittest`_ | -| | The doctest framework `Lib/doctest.py`_. | -| | The CPython tests in `Lib/test`_. | -| | The test runner in `Lib/test/regrtest.py`_. | -| | The test support utilities in `Lib/test/support`_. | -+-------------------+------------------------------------------------------+ -| Tkinter | The `Lib/tkinter`_ package. | -+-------------------+------------------------------------------------------+ -| Unicode | Unicode, codecs, str vs bytes, | -| | `Objects/unicodeobject.c`_. | -+-------------------+------------------------------------------------------+ -| Windows | The Windows operating system. | -+-------------------+------------------------------------------------------+ -| XML | The `Lib/xml`_ package. | -+-------------------+------------------------------------------------------+ - -Versions -'''''''' -The known versions of Python that the issue affects and should be fixed for. - -Thus if an issue for a new feature is assigned for e.g., Python 3.8 but is not -applied before Python 3.8.0 is released, this field should be updated to say -Python 3.9 as the version and drop Python 3.8. - -Priority -'''''''' -What is the severity and urgency? - -+------------------+--------------------------------------------------------+ -| Priority | Description | -+==================+========================================================+ -| low | This is for low-impact bugs. | -+------------------+--------------------------------------------------------+ -| normal | The default value for most issues filed. | -+------------------+--------------------------------------------------------+ -| high | Try to fix the issue before the next final release. | -+------------------+--------------------------------------------------------+ -| critical | Should definitely be fixed for next final release. | -+------------------+--------------------------------------------------------+ -| deferred blocker | The issue will not hold up the next release, *n*. It | -| | will be promoted to a *release blocker* for the | -| | following release, *n+1*. | -+------------------+--------------------------------------------------------+ -| release blocker | The issue **must** be fixed before *any* release is | -| | made, e.g., will block the next release even if it is | -| | an alpha release. | -+------------------+--------------------------------------------------------+ - -As a guideline, *critical* and above are usually reserved for crashes, -serious regressions or breakage of very important APIs. Whether a bug -is a *release blocker* for the current `release schedule`_ is decided by the -release manager. Triagers may recommend this priority and should add the -release manager to the *nosy list*. If needed, consult the -`release schedule`_ and the release's associated PEP for the release -manager's name. - -Keywords -'''''''' -Various informational flags about the issue. Multiple values are possible. - -+---------------+------------------------------------------------------------+ -| Keyword | Description | -+===============+============================================================+ -| buildbot | A buildbot triggered the issue being reported. | -+---------------+------------------------------------------------------------+ -| easy | Fixing the issue should not take longer than a day for | -| | someone new to contributing to Python to solve. | -+---------------+------------------------------------------------------------+ -| newcomer | Issue suitable for newcomer/first time contributors. | -| friendly | Not suitable for experienced contributors. Typically it is | -| | straightforward, well-defined, low-risk, and optionally | -| | someone is able to mentor the new contributor. | -+---------------+------------------------------------------------------------+ -| gsoc | The issue would fit as, or is related to, a GSoC_ project. | -+---------------+------------------------------------------------------------+ -| needs review | The patch or pull request attached to the issue is in need | -| | of a review. | -+---------------+------------------------------------------------------------+ -| patch | There is a patch or pull request attached to the issue. | -+---------------+------------------------------------------------------------+ -| 3.3regression | The issue is a regression in 3.3. | -+---------------+------------------------------------------------------------+ - -Nosy List -''''''''' -A list of people who may be interested in an issue. - -It is acceptable to add someone to the nosy list if you think the issue should -be brought to their attention. Use the :ref:`experts` to know who wants to be -added to the nosy list for issues targeting specific areas. - -If you are logged in and have JavaScript enabled, you can use the ``[+]`` -button to add yourself to the nosy list (remember to click on -"Submit Changes" afterwards). Note that you are added to the nosy -automatically when you submit a message. - -The nosy list also has an autocomplete that lets you search from the lists of -developers and :ref:`experts`. The search is case-insensitive and -works for real names, modules, interest areas, etc., and only adds the -username(s) to the nosy once an entry is selected. - -Assigned To -''''''''''' -Who is expected to take the next step in resolving the issue. - -It is acceptable to assign an issue to someone if the issue cannot move -forward without their help, e.g., they need to make a technical decision to -allow the issue to move forward. Also consult the :ref:`experts` as certain -stdlib modules should always be assigned to a specific person. - -Note that in order to assign an issue to someone, that person **must** have -the :ref:`Developer role <devrole>` on the issue tracker. - -Dependencies -'''''''''''' -The issue requires the listed issue(s) to be resolved first before it can move -forward. - -Superseder -'''''''''' -The issue is a duplicate of the listed issue(s). - -Status -'''''' - -+---------------+------------------------------------------------------------+ -| Status | Description | -+===============+============================================================+ -| open | Issue is not resolved. | -+---------------+------------------------------------------------------------+ -| pending | The issue is blocked until someone (often the | -| | :abbr:`OP (original poster)`) provides some critical | -| | information; the issue will be closed after a set amount | -| | time if no reply comes in. | -| | | -| | Useful when someone opens an issue that lacks enough | -| | information to reproduce the bug reported. Requesting | -| | additional information and setting status to *pending* | -| | indicates that the issue should be closed if the necessary | -| | information is not provided in a timely manner (i.e. one | -| | month). | -+---------------+------------------------------------------------------------+ -| closed | The issue has been resolved (somehow). | -+---------------+------------------------------------------------------------+ - -Resolution -'''''''''' -Why the issue is in its current state. This is not usually used for issues -with the "open" status. - -+---------------+------------------------------------------------------------+ -| Resolution | Description | -+===============+============================================================+ -| open | Issue is not resolved. | -+---------------+------------------------------------------------------------+ -| duplicate | Duplicate of another issue; should have the *Superseder* | -| | field filled out. | -+---------------+------------------------------------------------------------+ -| fixed | A fix for the issue was committed. | -+---------------+------------------------------------------------------------+ -| later | Issue is to be worked on in a later release cycle. | -+---------------+------------------------------------------------------------+ -| not a bug | For some reason the issue is invalid (e.g. the perceived | -| | problem is not a bug in Python). | -+---------------+------------------------------------------------------------+ -| out of date | The issue has already been fixed, or the problem doesn't | -| | exist anymore for other reasons. | -+---------------+------------------------------------------------------------+ -| postponed | Issue will not be worked on at the moment but in a future | -| | minor release version. | -+---------------+------------------------------------------------------------+ -| rejected | Issue was rejected (especially for feature requests). | -+---------------+------------------------------------------------------------+ -| remind | The issue is acting as a reminder for someone. | -+---------------+------------------------------------------------------------+ -| wont fix | Issue will not be fixed, typically because it would cause | -| | a backwards-compatibility problem. | -+---------------+------------------------------------------------------------+ -| works for me | Bug cannot be reproduced. | -+---------------+------------------------------------------------------------+ - -Mercurial Repository -'''''''''''''''''''' -HTTP link to a Mercurial repository that contains a patch for the issue. -A :guilabel:`Create Patch` button will appear that computes a diff for the -head revision of the remote branch and attaches it to the issue. The button -supports only CPython_ patches. - -If you don't indicate a remote branch, ``default`` is used. You can -indicate a remote branch by adding ``#BRANCH`` to the end of the URL. - -Generating Special Links in a Comment -------------------------------------- -Using the following abbreviations in a comment will automatically generate -a link to relevant web pages. - -+-------------------------------------------------------------+-------------------------------------------------------+ -| Comment abbreviation | Description | -+=============================================================+=======================================================+ -| ``#<number>``, | Links to the tracker issue ``<number>``. | -| ``issue<number>``, or | | -| ``issue <number>`` | | -+-------------------------------------------------------------+-------------------------------------------------------+ -| ``msg<number>`` | Links to the tracker message ``<number>``. | -+-------------------------------------------------------------+-------------------------------------------------------+ -| ``PR <number>``, | Links to `GitHub pull requests`_. | -| ``PR<number>``, or | | -| ``pull request <number>`` | | -+-------------------------------------------------------------+-------------------------------------------------------+ -| a 10-, 11-, 12-, or 40-digit hex ``<number>`` | Indicates a Git or Mercurial changeset identifier and | -| | generates a link to changeset ``<number>`` on GitHub | -| | or https://hg.python.org/. The ``git`` and ``hg`` | -| | prefixes can also be used to disambiguate, and must | -| | precede the number without spaces. | -+-------------------------------------------------------------+-------------------------------------------------------+ -| ``r<number>``, | Indicates a legacy Subversion revision number, | -| ``rev<number>``, or | a reference to a changeset that was checked in prior | -| ``revision <number>`` | to 2011-03-05 when the official Python source code | -| | repositories were migrated from the | -| | :abbr:`svn (Subversion)` | -| | :abbr:`VCS (version control system)` to Mercurial. | -| | The issue tracker automatically translates the legacy | -| | svn revision ``<number>`` to its corresponding | -| | Mercurial changeset identifier. | -+-------------------------------------------------------------+-------------------------------------------------------+ -| ``Dir/file.ext`` or | Links to files in the | -| ``Dir/file.ext:NNN`` | `Python source code repositories`_, possibly linking | -| | to the line number specified after the ``:``. | -| | ``3.6/Dir/file.ext`` will generate a link with ``3.6``| -| | as branch. | -+-------------------------------------------------------------+-------------------------------------------------------+ -| ``PEP <number>`` or | Link to the :abbr:`PEP (Python Enhancement Proposal)` | -| ``PEP<number>`` | ``<number>``. | -+-------------------------------------------------------------+-------------------------------------------------------+ -| ``devguide``, | Links to the Devguide, this page, and this section | -| ``devguide/triaging``, or | respectively. | -| ``devguide/triaging#generating-special-links-in-a-comment`` | | -+-------------------------------------------------------------+-------------------------------------------------------+ - -Checklist for Triaging ----------------------- - -* Read the issue comment(s). -* Review and set classification fields - - Title: should be concise with specifics which are helpful to someone - scanning a list of issue titles. (Optional, if possible) Add a - prefix at the start of the title to indicate the module, e.g. IDLE, - doc, or async. - - Type - - Stage - - Components: multiple items may be set - - Versions: set if known, leave blank if unsure. Multiple items may be set. -* Review and set process fields - - Status - - Resolution - - Superseder - - Assigned To - - Nosy List - - Priority - - Keywords -* (Optional) Leave a brief comment about the proposed next action needed. If - there is a long message list, a summary can be very helpful. - - -.. _CPython: https://github.com/python/cpython/ -.. _Doc: https://github.com/python/cpython/tree/master/Doc/ -.. _Grammar: https://github.com/python/cpython/tree/master/Grammar/ -.. _Lib: https://github.com/python/cpython/tree/master/Lib/ -.. _Lib/lib2to3: https://github.com/python/cpython/tree/master/Lib/lib2to3/ -.. _Lib/ctypes: https://github.com/python/cpython/tree/master/Lib/ctypes/ -.. _Lib/distutils: https://github.com/python/cpython/tree/master/Lib/distutils/ -.. _Lib/doctest.py: https://github.com/python/cpython/tree/master/Lib/doctest.py -.. _Lib/idlelib: https://github.com/python/cpython/tree/master/Lib/idlelib/ -.. _Lib/io.py: https://github.com/python/cpython/tree/master/Lib/io.py -.. _Lib/re.py: https://github.com/python/cpython/tree/master/Lib/re.py -.. _Lib/test: https://github.com/python/cpython/tree/master/Lib/test/ -.. _Lib/test/regrtest.py: https://github.com/python/cpython/tree/master/Lib/test/regrtest.py -.. _Lib/test/support: https://github.com/python/cpython/tree/master/Lib/test/support/ -.. _Lib/tkinter: https://github.com/python/cpython/tree/master/Lib/tkinter/ -.. _Lib/unittest: https://github.com/python/cpython/tree/master/Lib/unittest/ -.. _Lib/xml: https://github.com/python/cpython/tree/master/Lib/xml/ -.. _Modules: https://github.com/python/cpython/tree/master/Modules/ -.. _Modules/_io: https://github.com/python/cpython/tree/master/Modules/_io/ -.. _Modules/_sre.c: https://github.com/python/cpython/tree/master/Modules/_sre.c -.. _Objects: https://github.com/python/cpython/tree/master/Objects/ -.. _Objects/unicodeobject.c: https://github.com/python/cpython/tree/master/Objects/unicodeobject.c -.. _Parser: https://github.com/python/cpython/tree/master/Parser/ -.. _Python: https://github.com/python/cpython/tree/master/Python/ -.. _Tools: https://github.com/python/cpython/tree/master/Tools/ -.. _Tools/demo: https://github.com/python/cpython/tree/master/Tools/demo/ -.. _Developer's guide: https://github.com/python/devguide/ -.. _GSoC: https://developers.google.com/open-source/gsoc/ -.. _issue tracker: https://bugs.python.org -.. _GitHub pull requests: https://github.com/python/cpython/pulls> -.. _Python source code repositories: https://github.com/python/cpython/ -.. _Reporting security issues in Python: https://www.python.org/news/security/ -.. _python-ideas: https://mail.python.org/mailman/listinfo/python-ideas -.. _release schedule: https://devguide.python.org/#status-of-python-branches -.. _PSF Code of Conduct: https://www.python.org/psf/codeofconduct/ diff --git a/versions.rst b/versions.rst new file mode 100644 index 0000000000..58d56b3e0a --- /dev/null +++ b/versions.rst @@ -0,0 +1,73 @@ +.. _versions: +.. _branchstatus: + +========================= +Status of Python versions +========================= + +The ``main`` branch is currently the future Python |main_version|, and is the only +branch that accepts new features. The latest release for each Python +version can be found on the `download page <https://www.python.org/downloads/>`__. + + +.. raw:: html + :file: _static/release-cycle.svg + +(See :ref:`below <full-chart>` for a chart with older versions. +Another useful visualization is `endoflife.date/python <https://endoflife.date/python>`__.) + + +Supported versions +================== + +Dates shown in *italic* are scheduled and can be adjusted. + +.. csv-table:: + :header-rows: 1 + :width: 100% + :file: include/branches.csv + + +Unsupported versions +==================== + +.. csv-table:: + :header-rows: 1 + :width: 100% + :file: include/end-of-life.csv + + +.. _full-chart: + +Full chart +========== + +.. raw:: html + :file: _static/release-cycle-all.svg + + +Status key +========== + +Python releases go through five phases, as described in :pep:`602`. Release +managers can adjust specific dates as needed. + +:feature: Before the first beta, the next full release can accept new features, + bug fixes, and security fixes. + +:prerelease: After the first beta, no new features can go in, but feature fixes + (including significant changes to new features), bug fixes, and security fixes + are accepted for the upcoming feature release. + +:bugfix: Once a version has been fully released, bug fixes and security fixes are + accepted. New binaries are built and released roughly every two months. This + phase is also called **maintenance** mode or **stable** release. + +:security: After two years (18 months for versions before 3.13), only security + fixes are accepted and no more binaries are released. New source-only versions + can be released as needed. + +:end-of-life: Five years after a release, support ends. The release cycle is + frozen; no further changes are allowed. + +See also the :ref:`devcycle` page for more information about branches and backporting.