diff --git a/.azure-pipelines/ci.yml b/.azure-pipelines/ci.yml
index 199547432be294..b5b2765e43844f 100644
--- a/.azure-pipelines/ci.yml
+++ b/.azure-pipelines/ci.yml
@@ -1,97 +1,16 @@
-variables:
- coverage: false
-
-trigger: ['main', '3.10', '3.9', '3.8', '3.7']
+trigger: ['main', '3.12', '3.11', '3.10', '3.9', '3.8', '3.7']
jobs:
- job: Prebuild
displayName: Pre-build checks
pool:
- vmImage: ubuntu-20.04
+ vmImage: ubuntu-22.04
steps:
- template: ./prebuild-checks.yml
-- job: Docs_PR
- displayName: Docs PR
- dependsOn: Prebuild
- condition: and(succeeded(), eq(dependencies.Prebuild.outputs['docs.run'], 'true'))
-
- pool:
- vmImage: ubuntu-20.04
-
- steps:
- - template: ./docs-steps.yml
- parameters:
- upload: true
-
-
-- job: macOS_CI_Tests
- displayName: macOS CI Tests
- dependsOn: Prebuild
- #condition: and(succeeded(), eq(dependencies.Prebuild.outputs['tests.run'], 'true'))
- # bpo-39837: macOS tests on Azure Pipelines are disabled
- condition: false
-
- variables:
- testRunTitle: '$(build.sourceBranchName)-macos'
- testRunPlatform: macos
-
- pool:
- vmImage: macos-10.15
-
- steps:
- - template: ./macos-steps.yml
-
-
-- job: Ubuntu_CI_Tests
- displayName: Ubuntu CI Tests
- dependsOn: Prebuild
- condition: and(succeeded(), eq(dependencies.Prebuild.outputs['tests.run'], 'true'))
-
- pool:
- vmImage: ubuntu-20.04
-
- variables:
- testRunTitle: '$(build.sourceBranchName)-linux'
- testRunPlatform: linux
- openssl_version: 1.1.1n
-
- steps:
- - template: ./posix-steps.yml
- parameters:
- dependencies: apt
-
-
-- job: Ubuntu_Coverage_CI_Tests
- displayName: Ubuntu CI Tests (coverage)
- dependsOn: Prebuild
- condition: |
- and(
- and(
- succeeded(),
- eq(variables['coverage'], 'true')
- ),
- eq(dependencies.Prebuild.outputs['tests.run'], 'true')
- )
-
- pool:
- vmImage: ubuntu-20.04
-
- variables:
- testRunTitle: '$(Build.SourceBranchName)-linux-coverage'
- testRunPlatform: linux-coverage
- openssl_version: 1.1.1n
-
- steps:
- - template: ./posix-steps.yml
- parameters:
- dependencies: apt
- coverage: true
-
-
- job: Windows_CI_Tests
displayName: Windows CI Tests
dependsOn: Prebuild
diff --git a/.azure-pipelines/docs-steps.yml b/.azure-pipelines/docs-steps.yml
deleted file mode 100644
index 647daff7a033a8..00000000000000
--- a/.azure-pipelines/docs-steps.yml
+++ /dev/null
@@ -1,47 +0,0 @@
-parameters:
- latex: false
- upload: false
-
-steps:
-- checkout: self
- clean: true
- fetchDepth: 5
-
-- task: UsePythonVersion@0
- displayName: 'Use Python 3.6 or later'
- inputs:
- versionSpec: '>=3.6'
-
-- script: python -m pip install -r requirements.txt
- workingDirectory: '$(build.sourcesDirectory)/Doc'
- displayName: 'Install build dependencies'
-
-- ${{ if ne(parameters.latex, 'true') }}:
- - script: make check html PYTHON=python
- workingDirectory: '$(build.sourcesDirectory)/Doc'
- displayName: 'Build documentation'
-
-- ${{ if eq(parameters.latex, 'true') }}:
- - script: sudo apt-get update && sudo apt-get install -qy --force-yes texlive-full
- displayName: 'Install LaTeX'
-
- - script: make dist PYTHON=python SPHINXBUILD='python -m sphinx' BLURB='python -m blurb'
- workingDirectory: '$(build.sourcesDirectory)/Doc'
- displayName: 'Build documentation'
-
-- ${{ if eq(parameters.upload, 'true') }}:
- - task: PublishBuildArtifacts@1
- displayName: 'Publish docs'
-
- inputs:
- PathToPublish: '$(build.sourcesDirectory)/Doc/build'
- ArtifactName: docs
- publishLocation: Container
-
- - ${{ if eq(parameters.latex, 'true') }}:
- - task: PublishBuildArtifacts@1
- displayName: 'Publish dist'
- inputs:
- PathToPublish: '$(build.sourcesDirectory)/Doc/dist'
- ArtifactName: docs_dist
- publishLocation: Container
diff --git a/.azure-pipelines/macos-steps.yml b/.azure-pipelines/macos-steps.yml
deleted file mode 100644
index fa38a0df8c87b8..00000000000000
--- a/.azure-pipelines/macos-steps.yml
+++ /dev/null
@@ -1,27 +0,0 @@
-steps:
-- checkout: self
- clean: true
- fetchDepth: 5
-
-- script: ./configure --with-pydebug --with-openssl=/usr/local/opt/openssl --prefix=/opt/python-azdev
- displayName: 'Configure CPython (debug)'
-
-- script: make -j4
- displayName: 'Build CPython'
-
-- script: make pythoninfo
- displayName: 'Display build info'
-
-- script: make buildbottest TESTOPTS="-j4 -uall,-cpu --junit-xml=$(build.binariesDirectory)/test-results.xml"
- displayName: 'Tests'
- continueOnError: true
- timeoutInMinutes: 30
-
-- task: PublishTestResults@2
- displayName: 'Publish Test Results'
- inputs:
- testResultsFiles: '$(build.binariesDirectory)/test-results.xml'
- mergeTestResults: true
- testRunTitle: $(testRunTitle)
- platform: $(testRunPlatform)
- condition: succeededOrFailed()
diff --git a/.azure-pipelines/posix-steps.yml b/.azure-pipelines/posix-steps.yml
index 29b43e0934472e..db44255e4422ff 100644
--- a/.azure-pipelines/posix-steps.yml
+++ b/.azure-pipelines/posix-steps.yml
@@ -1,10 +1,3 @@
-parameters:
- coverage: false
- sudo_dependencies: sudo
- dependencies: apt
- patchcheck: true
- xvfb: true
-
steps:
- checkout: self
clean: true
@@ -14,7 +7,7 @@ steps:
- script: sudo setfacl -Rb /home/vsts
displayName: 'Workaround ACL issue'
-- script: ${{ parameters.sudo_dependencies }} ./.azure-pipelines/posix-deps-${{ parameters.dependencies }}.sh $(openssl_version)
+- script: sudo ./.azure-pipelines/posix-deps-apt.sh $(openssl_version)
displayName: 'Install dependencies'
- script: ./configure --with-pydebug
@@ -23,61 +16,12 @@ steps:
- script: make -j4
displayName: 'Build CPython'
-- ${{ if eq(parameters.coverage, 'true') }}:
- - script: ./python -m venv venv && ./venv/bin/python -m pip install -U coverage
- displayName: 'Set up virtual environment'
-
- - script: ./venv/bin/python -m test.pythoninfo
- displayName: 'Display build info'
-
- - script: |
- $COMMAND -m coverage run --pylib -m test \
- --fail-env-changed \
- -uall,-cpu \
- --junit-xml=$(build.binariesDirectory)/test-results.xml \
- -x test_multiprocessing_fork \
- -x test_multiprocessing_forkserver \
- -x test_multiprocessing_spawn \
- -x test_concurrent_futures
- displayName: 'Tests with coverage'
- env:
- ${{ if eq(parameters.xvfb, 'true') }}:
- COMMAND: xvfb-run ./venv/bin/python
- ${{ if ne(parameters.xvfb, 'true') }}:
- COMMAND: ./venv/bin/python
-
- - script: ./venv/bin/python -m coverage xml
- displayName: 'Generate coverage.xml'
-
- - script: source ./venv/bin/activate && bash <(curl -s https://codecov.io/bash) -y .github/codecov.yml
- displayName: 'Publish code coverage results'
-
-
-- ${{ if ne(parameters.coverage, 'true') }}:
- - script: make pythoninfo
- displayName: 'Display build info'
-
- - script: $COMMAND buildbottest TESTOPTS="-j4 -uall,-cpu --junit-xml=$(build.binariesDirectory)/test-results.xml"
- displayName: 'Tests'
- env:
- ${{ if eq(parameters.xvfb, 'true') }}:
- COMMAND: xvfb-run make
- ${{ if ne(parameters.xvfb, 'true') }}:
- COMMAND: make
-
-- ${{ if eq(parameters.patchcheck, 'true') }}:
- - script: |
- git fetch origin
- ./python Tools/scripts/patchcheck.py --ci true
- displayName: 'Run patchcheck.py'
- condition: and(succeeded(), eq(variables['Build.Reason'], 'PullRequest'))
+- script: make pythoninfo
+ displayName: 'Display build info'
+- script: |
+ git fetch origin
+ ./python Tools/scripts/patchcheck.py --ci true
+ displayName: 'Run patchcheck.py'
+ condition: and(succeeded(), eq(variables['Build.Reason'], 'PullRequest'))
-- task: PublishTestResults@2
- displayName: 'Publish Test Results'
- inputs:
- testResultsFiles: '$(build.binariesDirectory)/test-results.xml'
- mergeTestResults: true
- testRunTitle: $(testRunTitle)
- platform: $(testRunPlatform)
- condition: succeededOrFailed()
diff --git a/.azure-pipelines/pr.yml b/.azure-pipelines/pr.yml
index b96a192005a42d..335a4b407cb83c 100644
--- a/.azure-pipelines/pr.yml
+++ b/.azure-pipelines/pr.yml
@@ -1,123 +1,28 @@
-variables:
- coverage: false
-
-pr: ['main', '3.10', '3.9', '3.8', '3.7']
+pr: ['main', '3.12', '3.11', '3.10', '3.9', '3.8', '3.7']
jobs:
- job: Prebuild
displayName: Pre-build checks
pool:
- vmImage: ubuntu-20.04
+ vmImage: ubuntu-22.04
steps:
- template: ./prebuild-checks.yml
-- job: Docs_PR
- displayName: Docs PR
- dependsOn: Prebuild
- condition: and(succeeded(), eq(dependencies.Prebuild.outputs['docs.run'], 'true'))
-
- pool:
- vmImage: ubuntu-20.04
-
- steps:
- - template: ./docs-steps.yml
-
-
-- job: macOS_PR_Tests
- displayName: macOS PR Tests
- dependsOn: Prebuild
- #condition: and(succeeded(), eq(dependencies.Prebuild.outputs['tests.run'], 'true'))
- # bpo-39837: macOS tests on Azure Pipelines are disabled
- condition: false
-
- variables:
- testRunTitle: '$(system.pullRequest.TargetBranch)-macos'
- testRunPlatform: macos
-
- pool:
- vmImage: macos-10.15
-
- steps:
- - template: ./macos-steps.yml
- parameters:
- targetBranch: $(System.PullRequest.TargetBranch)
-
-
-- job: Ubuntu_PR_Tests
- displayName: Ubuntu PR Tests
+- job: Ubuntu_Patchcheck
+ displayName: Ubuntu patchcheck
dependsOn: Prebuild
condition: and(succeeded(), eq(dependencies.Prebuild.outputs['tests.run'], 'true'))
pool:
- vmImage: ubuntu-20.04
+ vmImage: ubuntu-22.04
variables:
testRunTitle: '$(system.pullRequest.TargetBranch)-linux'
testRunPlatform: linux
- openssl_version: 1.1.1n
-
- steps:
- - template: ./posix-steps.yml
- parameters:
- dependencies: apt
-
-
-- job: Ubuntu_Coverage_PR_Tests
- displayName: Ubuntu PR Tests (coverage)
- dependsOn: Prebuild
- condition: |
- and(
- and(
- succeeded(),
- eq(variables['coverage'], 'true')
- ),
- eq(dependencies.Prebuild.outputs['tests.run'], 'true')
- )
-
- pool:
- vmImage: ubuntu-20.04
-
- variables:
- testRunTitle: '$(Build.SourceBranchName)-linux-coverage'
- testRunPlatform: linux-coverage
- openssl_version: 1.1.1n
+ openssl_version: 1.1.1u
steps:
- template: ./posix-steps.yml
- parameters:
- dependencies: apt
- coverage: true
-
-
-- job: Windows_PR_Tests
- displayName: Windows PR Tests
- dependsOn: Prebuild
- condition: and(succeeded(), eq(dependencies.Prebuild.outputs['tests.run'], 'true'))
-
- pool:
- vmImage: windows-2022
-
- strategy:
- matrix:
- win32:
- arch: win32
- buildOpt: '-p Win32'
- testRunTitle: '$(System.PullRequest.TargetBranch)-win32'
- testRunPlatform: win32
- win64:
- arch: amd64
- buildOpt: '-p x64'
- testRunTitle: '$(System.PullRequest.TargetBranch)-win64'
- testRunPlatform: win64
- winarm64:
- arch: arm64
- buildOpt: '-p arm64'
- maxParallel: 4
-
- steps:
- - template: ./windows-steps.yml
- parameters:
- targetBranch: $(System.PullRequest.TargetBranch)
diff --git a/.azure-pipelines/prebuild-checks.yml b/.azure-pipelines/prebuild-checks.yml
index 30ff642d1267a1..2c6460d2386735 100644
--- a/.azure-pipelines/prebuild-checks.yml
+++ b/.azure-pipelines/prebuild-checks.yml
@@ -11,18 +11,6 @@ steps:
displayName: Fetch comparison tree
condition: and(succeeded(), variables['System.PullRequest.TargetBranch'])
-- script: |
- if ! git diff --name-only $(diffTarget) | grep -qE '(\.rst$|^Doc|^Misc)'
- then
- echo "No docs were updated: docs.run=false"
- echo "##vso[task.setvariable variable=run;isOutput=true]false"
- else
- echo "Docs were updated: docs.run=true"
- echo "##vso[task.setvariable variable=run;isOutput=true]true"
- fi
- displayName: Detect documentation changes
- name: docs
-
- script: |
if ! git diff --name-only $(diffTarget) | grep -qvE '(\.rst$|^Doc|^Misc)'
then
diff --git a/.azure-pipelines/windows-layout-steps.yml b/.azure-pipelines/windows-layout-steps.yml
index e15729fac3443d..afd89781790494 100644
--- a/.azure-pipelines/windows-layout-steps.yml
+++ b/.azure-pipelines/windows-layout-steps.yml
@@ -12,7 +12,7 @@ steps:
displayName: Show layout info (${{ parameters.kind }})
- ${{ if eq(parameters.fulltest, 'true') }}:
- - script: .\python.exe -m test -q -uall -u-cpu -rwW --slowest --timeout=1200 -j0 --junit-xml="$(Build.BinariesDirectory)\test-results-${{ parameters.kind }}.xml" --tempdir "$(Build.BinariesDirectory)\tmp-${{ parameters.kind }}-$(arch)"
+ - script: .\python.exe -m test -q -uall -u-cpu -rwW --slowest --timeout=1200 -j0 --junit-xml="$(Build.BinariesDirectory)\test-results-${{ parameters.kind }}.xml" --tempdir "$(Build.BinariesDirectory)\tmp-${{ parameters.kind }}-$(arch)" -i test_launcher
workingDirectory: $(Build.BinariesDirectory)\layout-${{ parameters.kind }}-$(arch)
displayName: ${{ parameters.kind }} Tests
env:
diff --git a/.editorconfig b/.editorconfig
index 81445d2d79c739..0169eed951cd3f 100644
--- a/.editorconfig
+++ b/.editorconfig
@@ -8,5 +8,8 @@ indent_style = space
[*.{py,c,cpp,h}]
indent_size = 4
+[*.rst]
+indent_size = 3
+
[*.yml]
indent_size = 2
diff --git a/.gitattributes b/.gitattributes
index 6da587a4c6ea5a..1479ca074cda12 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -25,7 +25,7 @@ PC/classicAppCompat.* binary
[attr]noeol -text
Lib/test/cjkencodings/* noeol
-Lib/test/coding20731.py noeol
+Lib/test/tokenizedata/coding20731.py noeol
Lib/test/decimaltestdata/*.decTest noeol
Lib/test/test_email/data/*.txt noeol
Lib/test/test_importlib/data01/* noeol
diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
index 62ee6f89cda679..6c29ba321b923f 100644
--- a/.github/CODEOWNERS
+++ b/.github/CODEOWNERS
@@ -4,6 +4,13 @@
# It uses the same pattern rule for gitignore file
# https://git-scm.com/docs/gitignore#_pattern_format
+# GitHub
+.github/** @ezio-melotti @hugovk
+
+# pre-commit
+.pre-commit-config.yaml @hugovk @AlexWaygood
+.ruff.toml @hugovk @AlexWaygood
+
# asyncio
**/*asyncio* @1st1 @asvetlov
@@ -98,7 +105,7 @@ Lib/ast.py @isidentical
/Lib/unittest/test/testmock/* @cjw296
# SQLite 3
-**/*sqlite* @berkerpeksag
+**/*sqlite* @berkerpeksag @erlend-aasland
# subprocess
/Lib/subprocess.py @gpshead
@@ -130,7 +137,7 @@ Lib/ast.py @isidentical
**/*idlelib* @terryjreedy
-**/*typing* @gvanrossum @Fidget-Spinner @JelleZijlstra
+**/*typing* @gvanrossum @JelleZijlstra @AlexWaygood
**/*asyncore @giampaolo
**/*asynchat @giampaolo
diff --git a/.github/CONTRIBUTING.rst b/.github/CONTRIBUTING.rst
index 30a39a40494fde..f4affee76e1d44 100644
--- a/.github/CONTRIBUTING.rst
+++ b/.github/CONTRIBUTING.rst
@@ -6,19 +6,19 @@ Build Status
- main
- + `Stable buildbots `_
+ + `Stable buildbots `_
- 3.9
- + `Stable buildbots `_
+ + `Stable buildbots `_
- 3.8
- + `Stable buildbots `_
+ + `Stable buildbots `_
- 3.7
- + `Stable buildbots `_
+ + `Stable buildbots `_
Thank You
@@ -38,7 +38,7 @@ 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 `_.
+`Lifecycle of a Pull Request `_.
We utilize various bots and status checks to help with this, so do follow the
comments they leave and their "Details" links, respectively. The key points of
our workflow that are not covered by a bot or status check are:
diff --git a/.github/problem-matchers/sphinx.json b/.github/problem-matchers/sphinx.json
deleted file mode 100644
index 09848608a7b034..00000000000000
--- a/.github/problem-matchers/sphinx.json
+++ /dev/null
@@ -1,40 +0,0 @@
-{
- "problemMatcher": [
- {
- "owner": "sphinx-problem-matcher",
- "pattern": [
- {
- "regexp": "^(.*):(\\d+):\\s+(\\w*):\\s+(.*)$",
- "file": 1,
- "line": 2,
- "severity": 3,
- "message": 4
- }
- ]
- },
- {
- "owner": "sphinx-problem-matcher-loose",
- "pattern": [
- {
- "_comment": "A bit of a looser pattern, doesn't look for line numbers, just looks for file names relying on them to start with / and end with .rst",
- "regexp": "(\/.*\\.rst):\\s+(\\w*):\\s+(.*)$",
- "file": 1,
- "severity": 2,
- "message": 3
- }
- ]
- },
- {
- "owner": "sphinx-problem-matcher-loose-no-severity",
- "pattern": [
- {
- "_comment": "Looks for file names ending with .rst and line numbers but without severity",
- "regexp": "^(.*\\.rst):(\\d+):(.*)$",
- "file": 1,
- "line": 2,
- "message": 3
- }
- ]
- }
- ]
-}
\ No newline at end of file
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index b489335903772c..6143248a8b399d 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -8,33 +8,43 @@ on:
push:
branches:
- 'main'
+ - '3.11'
- '3.10'
- '3.9'
- '3.8'
- - '3.7'
pull_request:
branches:
- 'main'
+ - '3.11'
- '3.10'
- '3.9'
- '3.8'
- - '3.7'
+
+permissions:
+ contents: read
+
+concurrency:
+ group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}-reusable
+ cancel-in-progress: true
jobs:
check_source:
name: 'Check for source changes'
runs-on: ubuntu-latest
+ timeout-minutes: 10
outputs:
+ run-docs: ${{ steps.docs-changes.outputs.run-docs || false }}
run_tests: ${{ steps.check.outputs.run_tests }}
run_ssl_tests: ${{ steps.check.outputs.run_ssl_tests }}
+ config_hash: ${{ steps.config_hash.outputs.hash }}
steps:
- - uses: actions/checkout@v3
+ - uses: actions/checkout@v4
- name: Check for source changes
id: check
run: |
if [ -z "$GITHUB_BASE_REF" ]; then
- echo '::set-output name=run_tests::true'
- echo '::set-output name=run_ssl_tests::true'
+ echo "run_tests=true" >> $GITHUB_OUTPUT
+ echo "run_ssl_tests=true" >> $GITHUB_OUTPUT
else
git fetch origin $GITHUB_BASE_REF --depth=1
# git diff "origin/$GITHUB_BASE_REF..." (3 dots) may be more
@@ -50,24 +60,104 @@ jobs:
# into the PR branch anyway.
#
# https://github.com/python/core-workflow/issues/373
- git diff --name-only origin/$GITHUB_BASE_REF.. | grep -qvE '(\.rst$|^Doc|^Misc)' && echo '::set-output name=run_tests::true' || true
- git diff --name-only origin/$GITHUB_BASE_REF.. | grep -qE '(ssl|hashlib|hmac|^.github)' && echo '::set-output name=run_ssl_tests::true' || true
+ git diff --name-only origin/$GITHUB_BASE_REF.. | grep -qvE '(\.rst$|^Doc|^Misc|^\.pre-commit-config\.yaml$|\.ruff\.toml$)' && echo "run_tests=true" >> $GITHUB_OUTPUT || true
+ git diff --name-only origin/$GITHUB_BASE_REF.. | grep -qE '(ssl|hashlib|hmac|^.github)' && echo "run_ssl_tests=true" >> $GITHUB_OUTPUT || true
+ fi
+ - name: Compute hash for config cache key
+ id: config_hash
+ run: |
+ echo "hash=${{ hashFiles('configure', 'configure.ac', '.github/workflows/build.yml') }}" >> $GITHUB_OUTPUT
+ - name: Get a list of the changed documentation-related files
+ if: github.event_name == 'pull_request'
+ id: changed-docs-files
+ uses: Ana06/get-changed-files@v2.2.0
+ with:
+ filter: |
+ Doc/**
+ Misc/**
+ .github/workflows/reusable-docs.yml
+ format: csv # works for paths with spaces
+ - name: Check for docs changes
+ if: >-
+ github.event_name == 'pull_request'
+ && steps.changed-docs-files.outputs.added_modified_renamed != ''
+ id: docs-changes
+ run: |
+ echo "run-docs=true" >> "${GITHUB_OUTPUT}"
+
+ check-docs:
+ name: Docs
+ needs: check_source
+ if: fromJSON(needs.check_source.outputs.run-docs)
+ uses: ./.github/workflows/reusable-docs.yml
+
+ check_abi:
+ name: 'Check if the ABI has changed'
+ runs-on: ubuntu-20.04
+ needs: check_source
+ if: needs.check_source.outputs.run_tests == 'true'
+ steps:
+ - uses: actions/checkout@v4
+ - uses: actions/setup-python@v4
+ - name: Install dependencies
+ run: |
+ sudo ./.github/workflows/posix-deps-apt.sh
+ sudo apt-get install -yq abigail-tools
+ - name: Build CPython
+ env:
+ CFLAGS: -g3 -O0
+ run: |
+ # Build Python with the libpython dynamic library
+ ./configure --enable-shared
+ make -j4
+ - name: Check for changes in the ABI
+ id: check
+ run: |
+ if ! make check-abidump; then
+ echo "Generated ABI file is not up to date."
+ echo "Please add the release manager of this branch as a reviewer of this PR."
+ echo ""
+ echo "The up to date ABI file should be attached to this build as an artifact."
+ echo ""
+ echo "To learn more about this check: https://devguide.python.org/setup/#regenerate-the-abi-dump"
+ echo ""
+ exit 1
fi
+ - name: Generate updated ABI files
+ if: ${{ failure() && steps.check.conclusion == 'failure' }}
+ run: |
+ make regen-abidump
+ - uses: actions/upload-artifact@v3
+ name: Publish updated ABI files
+ if: ${{ failure() && steps.check.conclusion == 'failure' }}
+ with:
+ name: abi-data
+ path: ./Doc/data/*.abi
check_generated_files:
name: 'Check if generated files are up to date'
runs-on: ubuntu-latest
+ timeout-minutes: 60
needs: check_source
if: needs.check_source.outputs.run_tests == 'true'
steps:
- - uses: actions/checkout@v3
- - uses: actions/setup-python@v3
+ - uses: actions/checkout@v4
+ - uses: actions/setup-python@v4
+ with:
+ python-version: '3.x'
+ - name: Restore config.cache
+ uses: actions/cache@v3
+ with:
+ path: config.cache
+ key: ${{ github.job }}-${{ runner.os }}-${{ needs.check_source.outputs.config_hash }}-${{ env.pythonLocation }}
- name: Install Dependencies
run: sudo ./.github/workflows/posix-deps-apt.sh
- name: Add ccache to PATH
run: echo "PATH=/usr/lib/ccache:$PATH" >> $GITHUB_ENV
- name: Configure ccache action
- uses: hendrikmuhs/ccache-action@v1
+ uses: hendrikmuhs/ccache-action@v1.2
+ with:
+ save: false
- name: Check Autoconf version 2.69 and aclocal 1.16.3
run: |
grep "Generated by GNU Autoconf 2.69" configure
@@ -77,7 +167,7 @@ jobs:
- name: Configure CPython
run: |
# Build Python with the libpython dynamic library
- ./configure --with-pydebug --enable-shared
+ ./configure --config-cache --with-pydebug --enable-shared
- name: Regenerate autoconf files with container image
run: make regen-configure
- name: Build CPython
@@ -106,137 +196,55 @@ jobs:
- name: Check limited ABI symbols
run: make check-limited-abi
- build_win32:
- name: 'Windows (x86)'
- runs-on: windows-latest
+ build_windows:
+ name: 'Windows'
needs: check_source
if: needs.check_source.outputs.run_tests == 'true'
- env:
- IncludeUwp: 'true'
- steps:
- - uses: actions/checkout@v3
- - name: Build CPython
- run: .\PCbuild\build.bat -e -d -p Win32
- timeout-minutes: 30
- - name: Display build info
- run: .\python.bat -m test.pythoninfo
- - name: Tests
- run: .\PCbuild\rt.bat -p Win32 -d -q -uall -u-cpu -rwW --slowest --timeout=1200 -j0
-
- build_win_amd64:
- name: 'Windows (x64)'
- runs-on: windows-latest
- needs: check_source
- if: needs.check_source.outputs.run_tests == 'true'
- env:
- IncludeUwp: 'true'
- steps:
- - uses: actions/checkout@v3
- - name: Register MSVC problem matcher
- run: echo "::add-matcher::.github/problem-matchers/msvc.json"
- - name: Build CPython
- run: .\PCbuild\build.bat -e -d -p x64
- timeout-minutes: 30
- - name: Display build info
- run: .\python.bat -m test.pythoninfo
- - name: Tests
- run: .\PCbuild\rt.bat -p x64 -d -q -uall -u-cpu -rwW --slowest --timeout=1200 -j0
+ uses: ./.github/workflows/reusable-windows.yml
build_macos:
name: 'macOS'
- runs-on: macos-latest
needs: check_source
if: needs.check_source.outputs.run_tests == 'true'
- env:
- PYTHONSTRICTEXTENSIONBUILD: 1
- steps:
- - uses: actions/checkout@v3
- - name: Prepare homebrew environment variables
- run: |
- echo "LDFLAGS=-L$(brew --prefix tcl-tk)/lib" >> $GITHUB_ENV
- echo "PKG_CONFIG_PATH=$(brew --prefix openssl@1.1)/lib/pkgconfig:$(brew --prefix tcl-tk)/lib/pkgconfig" >> $GITHUB_ENV
- - name: Configure CPython
- run: ./configure --with-pydebug --prefix=/opt/python-dev
- - name: Build CPython
- run: make -j4
- - name: Display build info
- run: make pythoninfo
- - name: Tests
- run: make buildbottest TESTOPTS="-j4 -uall,-cpu"
+ uses: ./.github/workflows/reusable-macos.yml
+ with:
+ config_hash: ${{ needs.check_source.outputs.config_hash }}
build_ubuntu:
name: 'Ubuntu'
- runs-on: ubuntu-20.04
needs: check_source
if: needs.check_source.outputs.run_tests == 'true'
- env:
- OPENSSL_VER: 1.1.1n
- PYTHONSTRICTEXTENSIONBUILD: 1
- steps:
- - uses: actions/checkout@v3
- - name: Register gcc problem matcher
- run: echo "::add-matcher::.github/problem-matchers/gcc.json"
- - name: Install Dependencies
- run: sudo ./.github/workflows/posix-deps-apt.sh
- - name: Configure OpenSSL env vars
- run: |
- echo "MULTISSL_DIR=${GITHUB_WORKSPACE}/multissl" >> $GITHUB_ENV
- echo "OPENSSL_DIR=${GITHUB_WORKSPACE}/multissl/openssl/${OPENSSL_VER}" >> $GITHUB_ENV
- echo "LD_LIBRARY_PATH=${GITHUB_WORKSPACE}/multissl/openssl/${OPENSSL_VER}/lib" >> $GITHUB_ENV
- - name: 'Restore OpenSSL build'
- id: cache-openssl
- uses: actions/cache@v3
- with:
- path: ./multissl/openssl/${{ env.OPENSSL_VER }}
- key: ${{ runner.os }}-multissl-openssl-${{ env.OPENSSL_VER }}
- - name: Install OpenSSL
- if: steps.cache-openssl.outputs.cache-hit != 'true'
- run: python3 Tools/ssl/multissltests.py --steps=library --base-directory $MULTISSL_DIR --openssl $OPENSSL_VER --system Linux
- - name: Add ccache to PATH
- run: |
- echo "PATH=/usr/lib/ccache:$PATH" >> $GITHUB_ENV
- - name: Configure ccache action
- uses: hendrikmuhs/ccache-action@v1
- - name: Setup directory envs for out-of-tree builds
- run: |
- echo "CPYTHON_RO_SRCDIR=$(realpath -m ${GITHUB_WORKSPACE}/../cpython-ro-srcdir)" >> $GITHUB_ENV
- echo "CPYTHON_BUILDDIR=$(realpath -m ${GITHUB_WORKSPACE}/../cpython-builddir)" >> $GITHUB_ENV
- - name: Create directories for read-only out-of-tree builds
- run: mkdir -p $CPYTHON_RO_SRCDIR $CPYTHON_BUILDDIR
- - name: Bind mount sources read-only
- run: sudo mount --bind -o ro $GITHUB_WORKSPACE $CPYTHON_RO_SRCDIR
- - name: Configure CPython out-of-tree
- working-directory: ${{ env.CPYTHON_BUILDDIR }}
- run: ../cpython-ro-srcdir/configure --with-pydebug --with-openssl=$OPENSSL_DIR
- - name: Build CPython out-of-tree
- working-directory: ${{ env.CPYTHON_BUILDDIR }}
- run: make -j4
- - name: Display build info
- working-directory: ${{ env.CPYTHON_BUILDDIR }}
- run: make pythoninfo
- - name: Remount sources writable for tests
- # some tests write to srcdir, lack of pyc files slows down testing
- run: sudo mount $CPYTHON_RO_SRCDIR -oremount,rw
- - name: Tests
- working-directory: ${{ env.CPYTHON_BUILDDIR }}
- run: xvfb-run make buildbottest TESTOPTS="-j4 -uall,-cpu"
+ uses: ./.github/workflows/reusable-ubuntu.yml
+ with:
+ config_hash: ${{ needs.check_source.outputs.config_hash }}
+ options: |
+ ../cpython-ro-srcdir/configure \
+ --config-cache \
+ --with-pydebug \
+ --with-openssl=$OPENSSL_DIR
build_ubuntu_ssltests:
name: 'Ubuntu SSL tests with OpenSSL'
runs-on: ubuntu-20.04
+ timeout-minutes: 60
needs: check_source
if: needs.check_source.outputs.run_tests == 'true' && needs.check_source.outputs.run_ssl_tests == 'true'
strategy:
fail-fast: false
matrix:
- openssl_ver: [1.1.1n, 3.0.2]
+ openssl_ver: [1.1.1w, 3.0.13, 3.1.5, 3.2.1]
env:
OPENSSL_VER: ${{ matrix.openssl_ver }}
MULTISSL_DIR: ${{ github.workspace }}/multissl
OPENSSL_DIR: ${{ github.workspace }}/multissl/openssl/${{ matrix.openssl_ver }}
LD_LIBRARY_PATH: ${{ github.workspace }}/multissl/openssl/${{ matrix.openssl_ver }}/lib
steps:
- - uses: actions/checkout@v3
+ - uses: actions/checkout@v4
+ - name: Restore config.cache
+ uses: actions/cache@v3
+ with:
+ path: config.cache
+ key: ${{ github.job }}-${{ runner.os }}-${{ needs.check_source.outputs.config_hash }}
- name: Register gcc problem matcher
run: echo "::add-matcher::.github/problem-matchers/gcc.json"
- name: Install Dependencies
@@ -259,9 +267,11 @@ jobs:
run: |
echo "PATH=/usr/lib/ccache:$PATH" >> $GITHUB_ENV
- name: Configure ccache action
- uses: hendrikmuhs/ccache-action@v1
+ uses: hendrikmuhs/ccache-action@v1.2
+ with:
+ save: false
- name: Configure CPython
- run: ./configure --with-pydebug --with-openssl=$OPENSSL_DIR
+ run: ./configure --config-cache --with-pydebug --with-openssl=$OPENSSL_DIR
- name: Build CPython
run: make -j4
- name: Display build info
@@ -269,22 +279,31 @@ jobs:
- name: SSL tests
run: ./python Lib/test/ssltests.py
-
build_asan:
name: 'Address sanitizer'
runs-on: ubuntu-20.04
+ timeout-minutes: 60
needs: check_source
if: needs.check_source.outputs.run_tests == 'true'
env:
- OPENSSL_VER: 1.1.1n
+ OPENSSL_VER: 3.0.13
PYTHONSTRICTEXTENSIONBUILD: 1
ASAN_OPTIONS: detect_leaks=0:allocator_may_return_null=1:handle_segv=0
steps:
- - uses: actions/checkout@v3
+ - uses: actions/checkout@v4
+ - name: Restore config.cache
+ uses: actions/cache@v3
+ with:
+ path: config.cache
+ key: ${{ github.job }}-${{ runner.os }}-${{ needs.check_source.outputs.config_hash }}
- name: Register gcc problem matcher
run: echo "::add-matcher::.github/problem-matchers/gcc.json"
- name: Install Dependencies
run: sudo ./.github/workflows/posix-deps-apt.sh
+ - name: Set up GCC-10 for ASAN
+ uses: egor-tensin/setup-gcc@v1
+ with:
+ version: 10
- name: Configure OpenSSL env vars
run: |
echo "MULTISSL_DIR=${GITHUB_WORKSPACE}/multissl" >> $GITHUB_ENV
@@ -303,12 +322,60 @@ jobs:
run: |
echo "PATH=/usr/lib/ccache:$PATH" >> $GITHUB_ENV
- name: Configure ccache action
- uses: hendrikmuhs/ccache-action@v1
+ uses: hendrikmuhs/ccache-action@v1.2
+ with:
+ save: ${{ github.event_name == 'push' }}
+ max-size: "200M"
- name: Configure CPython
- run: ./configure --with-address-sanitizer --without-pymalloc
+ run: ./configure --config-cache --with-address-sanitizer --without-pymalloc
- name: Build CPython
run: make -j4
- name: Display build info
run: make pythoninfo
- name: Tests
run: xvfb-run make buildbottest TESTOPTS="-j4 -uall,-cpu"
+
+ all-required-green: # This job does nothing and is only used for the branch protection
+ name: All required checks pass
+ if: always()
+
+ needs:
+ - check_source # Transitive dependency, needed to access `run_tests` value
+ - check-docs
+ - check_generated_files
+ - build_macos
+ - build_ubuntu
+ - build_ubuntu_ssltests
+ - build_windows
+ - build_asan
+
+ runs-on: ubuntu-latest
+
+ steps:
+ - name: Check whether the needed jobs succeeded or failed
+ uses: re-actors/alls-green@05ac9388f0aebcb5727afa17fcccfecd6f8ec5fe
+ with:
+ allowed-failures: >-
+ build_macos,
+ build_ubuntu_ssltests,
+ allowed-skips: >-
+ ${{
+ !fromJSON(needs.check_source.outputs.run-docs)
+ && '
+ check-docs,
+ '
+ || ''
+ }}
+ ${{
+ needs.check_source.outputs.run_tests != 'true'
+ && '
+ check_generated_files,
+ build_macos,
+ build_ubuntu,
+ build_ubuntu_ssltests,
+ build_windows,
+ build_asan,
+ '
+ || ''
+ }}
+ jobs: ${{ toJSON(needs) }}
diff --git a/.github/workflows/build_msi.yml b/.github/workflows/build_msi.yml
index cba1e51ef27d3a..4c6e2678f716b5 100644
--- a/.github/workflows/build_msi.yml
+++ b/.github/workflows/build_msi.yml
@@ -5,6 +5,7 @@ on:
push:
branches:
- 'main'
+ - '3.11'
- '3.10'
- '3.9'
- '3.8'
@@ -14,6 +15,7 @@ on:
pull_request:
branches:
- 'main'
+ - '3.11'
- '3.10'
- '3.9'
- '3.8'
@@ -21,27 +23,37 @@ on:
paths:
- 'Tools/msi/**'
+permissions:
+ contents: read
+
+concurrency:
+ group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
+ cancel-in-progress: true
+
jobs:
build_win32:
name: 'Windows (x86) Installer'
runs-on: windows-latest
+ timeout-minutes: 60
steps:
- - uses: actions/checkout@v3
+ - uses: actions/checkout@v4
- name: Build CPython installer
run: .\Tools\msi\build.bat -x86
build_win_amd64:
name: 'Windows (x64) Installer'
runs-on: windows-latest
+ timeout-minutes: 60
steps:
- - uses: actions/checkout@v3
+ - uses: actions/checkout@v4
- name: Build CPython installer
run: .\Tools\msi\build.bat -x64
build_win_arm64:
name: 'Windows (ARM64) Installer'
runs-on: windows-latest
+ timeout-minutes: 60
steps:
- - uses: actions/checkout@v3
+ - uses: actions/checkout@v4
- name: Build CPython installer
run: .\Tools\msi\build.bat -arm64
diff --git a/.github/workflows/doc.yml b/.github/workflows/doc.yml
deleted file mode 100644
index 3ed66e74b89542..00000000000000
--- a/.github/workflows/doc.yml
+++ /dev/null
@@ -1,54 +0,0 @@
-name: Docs
-
-on:
- workflow_dispatch:
- #push:
- # branches:
- # - 'main'
- # - '3.10'
- # - '3.9'
- # - '3.8'
- # - '3.7'
- # paths:
- # - 'Doc/**'
- pull_request:
- branches:
- - 'main'
- - '3.10'
- - '3.9'
- - '3.8'
- - '3.7'
- paths:
- - 'Doc/**'
- - 'Misc/**'
-
-jobs:
- build_doc:
- name: 'Docs'
- runs-on: ubuntu-latest
- steps:
- - uses: actions/checkout@v3
- - name: Register Sphinx problem matcher
- run: echo "::add-matcher::.github/problem-matchers/sphinx.json"
- - name: 'Install Dependencies'
- run: sudo ./.github/workflows/posix-deps-apt.sh && sudo apt-get install wamerican
- - name: 'Configure CPython'
- run: ./configure --with-pydebug
- - name: 'Build CPython'
- run: make -j4
- - name: 'Install build dependencies'
- run: make -C Doc/ PYTHON=../python venv
- # Run "check doctest html" as 3 steps to get a more readable output
- # in the web UI
- - name: 'Check documentation'
- run: make -C Doc/ PYTHON=../python SPHINXOPTS="-q -W --keep-going -j4" check
- # Use "xvfb-run" since some doctest tests open GUI windows
- - name: 'Run documentation doctest'
- run: xvfb-run make -C Doc/ PYTHON=../python SPHINXOPTS="-q -W --keep-going -j4" doctest
- - name: 'Build HTML documentation'
- run: make -C Doc/ PYTHON=../python SPHINXOPTS="-q -W --keep-going -j4" html
- - name: 'Upload'
- uses: actions/upload-artifact@v3
- with:
- name: doc-html
- path: Doc/build/html
diff --git a/.github/workflows/documentation-links.yml b/.github/workflows/documentation-links.yml
new file mode 100644
index 00000000000000..43a7afec73884e
--- /dev/null
+++ b/.github/workflows/documentation-links.yml
@@ -0,0 +1,27 @@
+name: Read the Docs PR preview
+# Automatically edits a pull request's descriptions with a link
+# to the documentation's preview on Read the Docs.
+
+on:
+ pull_request_target:
+ types:
+ - opened
+ paths:
+ - 'Doc/**'
+ - '.github/workflows/doc.yml'
+
+permissions:
+ pull-requests: write
+
+concurrency:
+ group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
+ cancel-in-progress: true
+
+jobs:
+ documentation-links:
+ runs-on: ubuntu-latest
+ steps:
+ - uses: readthedocs/actions/preview@v1
+ with:
+ project-slug: "cpython-previews"
+ single-version: "true"
diff --git a/.github/workflows/lint.yml b/.github/workflows/lint.yml
new file mode 100644
index 00000000000000..89f65816b6969d
--- /dev/null
+++ b/.github/workflows/lint.yml
@@ -0,0 +1,26 @@
+name: Lint
+
+on: [push, pull_request, workflow_dispatch]
+
+permissions:
+ contents: read
+
+env:
+ FORCE_COLOR: 1
+ RUFF_FORMAT: github
+
+concurrency:
+ group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
+ cancel-in-progress: true
+
+jobs:
+ lint:
+ runs-on: ubuntu-latest
+ timeout-minutes: 10
+
+ steps:
+ - uses: actions/checkout@v4
+ - uses: actions/setup-python@v4
+ with:
+ python-version: "3.x"
+ - uses: pre-commit/action@v3.0.0
diff --git a/.github/workflows/new-bugs-announce-notifier.yml b/.github/workflows/new-bugs-announce-notifier.yml
index 8cd834419f00bf..d3b982455dd970 100644
--- a/.github/workflows/new-bugs-announce-notifier.yml
+++ b/.github/workflows/new-bugs-announce-notifier.yml
@@ -5,9 +5,13 @@ on:
types:
- opened
+permissions:
+ issues: read
+
jobs:
notify-new-bugs-announce:
runs-on: ubuntu-latest
+ timeout-minutes: 10
steps:
- uses: actions/setup-node@v3
with:
@@ -39,7 +43,7 @@ jobs:
assignee : issue.data.assignees.map(assignee => { return assignee.login }),
body : issue.data.body
};
-
+
const data = {
from: "CPython Issues ",
to: "new-bugs-announce@python.org",
diff --git a/.github/workflows/regen-abidump.sh b/.github/workflows/regen-abidump.sh
new file mode 100644
index 00000000000000..251bb3857ecfcb
--- /dev/null
+++ b/.github/workflows/regen-abidump.sh
@@ -0,0 +1,8 @@
+set -ex
+
+export DEBIAN_FRONTEND=noninteractive
+./.github/workflows/posix-deps-apt.sh
+apt-get install -yq abigail-tools python3
+export CFLAGS="-g3 -O0"
+./configure --enable-shared && make
+make regen-abidump
diff --git a/.github/workflows/require-pr-label.yml b/.github/workflows/require-pr-label.yml
new file mode 100644
index 00000000000000..ff5cbdf3eda749
--- /dev/null
+++ b/.github/workflows/require-pr-label.yml
@@ -0,0 +1,23 @@
+name: Check labels
+
+on:
+ pull_request:
+ types: [opened, reopened, labeled, unlabeled, synchronize]
+
+permissions:
+ issues: write
+ pull-requests: write
+
+jobs:
+ label:
+ name: DO-NOT-MERGE / unresolved review
+ if: github.repository_owner == 'python'
+ runs-on: ubuntu-latest
+ timeout-minutes: 10
+
+ steps:
+ - uses: mheap/github-action-required-labels@v5
+ with:
+ mode: exactly
+ count: 0
+ labels: "DO-NOT-MERGE, awaiting changes, awaiting change review"
diff --git a/.github/workflows/reusable-docs.yml b/.github/workflows/reusable-docs.yml
new file mode 100644
index 00000000000000..d0618516bedddf
--- /dev/null
+++ b/.github/workflows/reusable-docs.yml
@@ -0,0 +1,78 @@
+name: Docs
+
+on:
+ workflow_call:
+ workflow_dispatch:
+
+permissions:
+ contents: read
+
+concurrency:
+ group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
+ cancel-in-progress: true
+
+jobs:
+ build_doc:
+ name: 'Docs'
+ runs-on: ubuntu-latest
+ timeout-minutes: 60
+ steps:
+ - uses: actions/checkout@v4
+ - name: 'Set up Python'
+ uses: actions/setup-python@v4
+ with:
+ python-version: '3'
+ cache: 'pip'
+ cache-dependency-path: 'Doc/requirements.txt'
+ - name: 'Install build dependencies'
+ run: make -C Doc/ venv
+ - name: 'Build HTML documentation'
+ run: make -C Doc/ SPHINXOPTS="-q" SPHINXERRORHANDLING="-W --keep-going" html
+ - name: 'Upload'
+ uses: actions/upload-artifact@v3
+ with:
+ name: doc-html
+ path: Doc/build/html
+
+ # This build doesn't use problem matchers or check annotations
+ build_doc_oldest_supported_sphinx:
+ name: 'Docs (Oldest Sphinx)'
+ runs-on: ubuntu-latest
+ timeout-minutes: 60
+ steps:
+ - uses: actions/checkout@v4
+ - name: 'Set up Python'
+ uses: actions/setup-python@v4
+ with:
+ python-version: '3.11' # known to work with Sphinx 4.2
+ cache: 'pip'
+ cache-dependency-path: 'Doc/requirements-oldest-sphinx.txt'
+ - name: 'Install build dependencies'
+ run: make -C Doc/ venv REQUIREMENTS="requirements-oldest-sphinx.txt"
+ - name: 'Build HTML documentation'
+ run: make -C Doc/ SPHINXOPTS="-q" SPHINXERRORHANDLING="-W --keep-going" html
+
+ # Run "doctest" on HEAD as new syntax doesn't exist in the latest stable release
+ doctest:
+ name: 'Doctest'
+ runs-on: ubuntu-latest
+ timeout-minutes: 60
+ steps:
+ - uses: actions/checkout@v4
+ - uses: actions/cache@v3
+ with:
+ path: ~/.cache/pip
+ key: ubuntu-doc-${{ hashFiles('Doc/requirements.txt') }}
+ restore-keys: |
+ ubuntu-doc-
+ - name: 'Install Dependencies'
+ run: sudo ./.github/workflows/posix-deps-apt.sh && sudo apt-get install wamerican
+ - name: 'Configure CPython'
+ run: ./configure --with-pydebug
+ - name: 'Build CPython'
+ run: make -j4
+ - name: 'Install build dependencies'
+ run: make -C Doc/ PYTHON=../python venv
+ # Use "xvfb-run" since some doctest tests open GUI windows
+ - name: 'Run documentation doctest'
+ run: xvfb-run make -C Doc/ PYTHON=../python SPHINXOPTS="-q" SPHINXERRORHANDLING="-W --keep-going" doctest
diff --git a/.github/workflows/reusable-macos.yml b/.github/workflows/reusable-macos.yml
new file mode 100644
index 00000000000000..ac8fdb8677e2fa
--- /dev/null
+++ b/.github/workflows/reusable-macos.yml
@@ -0,0 +1,53 @@
+on:
+ workflow_call:
+ inputs:
+ config_hash:
+ required: true
+ type: string
+ free-threading:
+ required: false
+ type: boolean
+ default: false
+
+jobs:
+ build_macos:
+ name: 'build and test'
+ timeout-minutes: 60
+ env:
+ HOMEBREW_NO_ANALYTICS: 1
+ HOMEBREW_NO_AUTO_UPDATE: 1
+ HOMEBREW_NO_INSTALL_CLEANUP: 1
+ PYTHONSTRICTEXTENSIONBUILD: 1
+ strategy:
+ fail-fast: false
+ matrix:
+ os: [
+ "macos-14", # M1
+ "macos-13", # Intel
+ ]
+ runs-on: ${{ matrix.os }}
+ steps:
+ - uses: actions/checkout@v4
+ - name: Restore config.cache
+ uses: actions/cache@v3
+ with:
+ path: config.cache
+ key: ${{ github.job }}-${{ matrix.os }}-${{ inputs.config_hash }}
+ - name: Install Homebrew dependencies
+ run: brew install pkg-config openssl@3.0 xz gdbm tcl-tk
+ - name: Configure CPython
+ run: |
+ GDBM_CFLAGS="-I$(brew --prefix gdbm)/include" \
+ GDBM_LIBS="-L$(brew --prefix gdbm)/lib -lgdbm" \
+ ./configure \
+ --config-cache \
+ --with-pydebug \
+ ${{ inputs.free-threading && '--disable-gil' || '' }} \
+ --prefix=/opt/python-dev \
+ --with-openssl="$(brew --prefix openssl@3.0)"
+ - name: Build CPython
+ run: make -j4
+ - name: Display build info
+ run: make pythoninfo
+ - name: Tests
+ run: make buildbottest TESTOPTS="-j4 -uall,-cpu"
diff --git a/.github/workflows/reusable-ubuntu.yml b/.github/workflows/reusable-ubuntu.yml
new file mode 100644
index 00000000000000..de413b83b9e229
--- /dev/null
+++ b/.github/workflows/reusable-ubuntu.yml
@@ -0,0 +1,74 @@
+on:
+ workflow_call:
+ inputs:
+ config_hash:
+ required: true
+ type: string
+ options:
+ required: true
+ type: string
+
+jobs:
+ build_ubuntu_reusable:
+ name: 'build and test'
+ timeout-minutes: 60
+ runs-on: ubuntu-20.04
+ env:
+ OPENSSL_VER: 3.0.13
+ PYTHONSTRICTEXTENSIONBUILD: 1
+ steps:
+ - uses: actions/checkout@v4
+ - name: Register gcc problem matcher
+ run: echo "::add-matcher::.github/problem-matchers/gcc.json"
+ - name: Install dependencies
+ run: sudo ./.github/workflows/posix-deps-apt.sh
+ - name: Configure OpenSSL env vars
+ run: |
+ echo "MULTISSL_DIR=${GITHUB_WORKSPACE}/multissl" >> $GITHUB_ENV
+ echo "OPENSSL_DIR=${GITHUB_WORKSPACE}/multissl/openssl/${OPENSSL_VER}" >> $GITHUB_ENV
+ echo "LD_LIBRARY_PATH=${GITHUB_WORKSPACE}/multissl/openssl/${OPENSSL_VER}/lib" >> $GITHUB_ENV
+ - name: 'Restore OpenSSL build'
+ id: cache-openssl
+ uses: actions/cache@v3
+ with:
+ path: ./multissl/openssl/${{ env.OPENSSL_VER }}
+ key: ${{ runner.os }}-multissl-openssl-${{ env.OPENSSL_VER }}
+ - name: Install OpenSSL
+ if: steps.cache-openssl.outputs.cache-hit != 'true'
+ run: python3 Tools/ssl/multissltests.py --steps=library --base-directory $MULTISSL_DIR --openssl $OPENSSL_VER --system Linux
+ - name: Add ccache to PATH
+ run: |
+ echo "PATH=/usr/lib/ccache:$PATH" >> $GITHUB_ENV
+ - name: Configure ccache action
+ uses: hendrikmuhs/ccache-action@v1.2
+ with:
+ save: ${{ github.event_name == 'push' }}
+ max-size: "200M"
+ - name: Setup directory envs for out-of-tree builds
+ run: |
+ echo "CPYTHON_RO_SRCDIR=$(realpath -m ${GITHUB_WORKSPACE}/../cpython-ro-srcdir)" >> $GITHUB_ENV
+ echo "CPYTHON_BUILDDIR=$(realpath -m ${GITHUB_WORKSPACE}/../cpython-builddir)" >> $GITHUB_ENV
+ - name: Create directories for read-only out-of-tree builds
+ run: mkdir -p $CPYTHON_RO_SRCDIR $CPYTHON_BUILDDIR
+ - name: Bind mount sources read-only
+ run: sudo mount --bind -o ro $GITHUB_WORKSPACE $CPYTHON_RO_SRCDIR
+ - name: Restore config.cache
+ uses: actions/cache@v3
+ with:
+ path: ${{ env.CPYTHON_BUILDDIR }}/config.cache
+ key: ${{ github.job }}-${{ runner.os }}-${{ inputs.config_hash }}
+ - name: Configure CPython out-of-tree
+ working-directory: ${{ env.CPYTHON_BUILDDIR }}
+ run: ${{ inputs.options }}
+ - name: Build CPython out-of-tree
+ working-directory: ${{ env.CPYTHON_BUILDDIR }}
+ run: make -j4
+ - name: Display build info
+ working-directory: ${{ env.CPYTHON_BUILDDIR }}
+ run: make pythoninfo
+ - name: Remount sources writable for tests
+ # some tests write to srcdir, lack of pyc files slows down testing
+ run: sudo mount $CPYTHON_RO_SRCDIR -oremount,rw
+ - name: Tests
+ working-directory: ${{ env.CPYTHON_BUILDDIR }}
+ run: xvfb-run make buildbottest TESTOPTS="-j4 -uall,-cpu"
diff --git a/.github/workflows/reusable-windows.yml b/.github/workflows/reusable-windows.yml
new file mode 100644
index 00000000000000..41f2c2b0c2cd25
--- /dev/null
+++ b/.github/workflows/reusable-windows.yml
@@ -0,0 +1,53 @@
+on:
+ workflow_call:
+ inputs:
+ free-threading:
+ required: false
+ type: boolean
+ default: false
+
+jobs:
+ build_win32:
+ name: 'build and test (x86)'
+ runs-on: windows-latest
+ timeout-minutes: 60
+ env:
+ IncludeUwp: 'true'
+ steps:
+ - uses: actions/checkout@v4
+ - name: Build CPython
+ run: .\PCbuild\build.bat -e -d -p Win32 ${{ inputs.free-threading && '--disable-gil' || '' }}
+ - name: Display build info
+ run: .\python.bat -m test.pythoninfo
+ - name: Tests
+ run: .\PCbuild\rt.bat -p Win32 -d -q -uall -u-cpu -rwW --slowest --timeout=1200 -j0
+
+ build_win_amd64:
+ name: 'build and test (x64)'
+ runs-on: windows-latest
+ timeout-minutes: 60
+ env:
+ IncludeUwp: 'true'
+ steps:
+ - uses: actions/checkout@v4
+ - name: Register MSVC problem matcher
+ run: echo "::add-matcher::.github/problem-matchers/msvc.json"
+ - name: Build CPython
+ run: .\PCbuild\build.bat -e -d -p x64 ${{ inputs.free-threading && '--disable-gil' || '' }}
+ - name: Display build info
+ run: .\python.bat -m test.pythoninfo
+ - name: Tests
+ run: .\PCbuild\rt.bat -p x64 -d -q -uall -u-cpu -rwW --slowest --timeout=1200 -j0
+
+ build_win_arm64:
+ name: 'build (arm64)'
+ runs-on: windows-latest
+ timeout-minutes: 60
+ env:
+ IncludeUwp: 'true'
+ steps:
+ - uses: actions/checkout@v4
+ - name: Register MSVC problem matcher
+ run: echo "::add-matcher::.github/problem-matchers/msvc.json"
+ - name: Build CPython
+ run: .\PCbuild\build.bat -e -d -p arm64 ${{ inputs.free-threading && '--disable-gil' || '' }}
diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml
index f422707afb9e5c..81fb838728bd34 100644
--- a/.github/workflows/stale.yml
+++ b/.github/workflows/stale.yml
@@ -12,6 +12,7 @@ jobs:
if: github.repository_owner == 'python'
runs-on: ubuntu-latest
+ timeout-minutes: 10
steps:
- name: "Check PRs"
diff --git a/.github/workflows/verify-ensurepip-wheels.yml b/.github/workflows/verify-ensurepip-wheels.yml
new file mode 100644
index 00000000000000..e1f120db3f5ca4
--- /dev/null
+++ b/.github/workflows/verify-ensurepip-wheels.yml
@@ -0,0 +1,33 @@
+name: Verify bundled pip and setuptools
+
+on:
+ workflow_dispatch:
+ push:
+ paths:
+ - 'Lib/ensurepip/_bundled/**'
+ - '.github/workflows/verify-ensurepip-wheels.yml'
+ - 'Tools/scripts/verify_ensurepip_wheels.py'
+ pull_request:
+ paths:
+ - 'Lib/ensurepip/_bundled/**'
+ - '.github/workflows/verify-ensurepip-wheels.yml'
+ - 'Tools/scripts/verify_ensurepip_wheels.py'
+
+permissions:
+ contents: read
+
+concurrency:
+ group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
+ cancel-in-progress: true
+
+jobs:
+ verify:
+ runs-on: ubuntu-latest
+ timeout-minutes: 10
+ steps:
+ - uses: actions/checkout@v4
+ - uses: actions/setup-python@v4
+ with:
+ python-version: '3'
+ - name: Compare checksums of bundled pip and setuptools to ones published on PyPI
+ run: ./Tools/scripts/verify_ensurepip_wheels.py
diff --git a/.gitignore b/.gitignore
index b3b22f471c2765..d42e111666f1e9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -114,6 +114,7 @@ PCbuild/win32/
Tools/unicode/data/
/autom4te.cache
/build/
+/builddir/
/config.cache
/config.log
/config.status
diff --git a/.mailmap b/.mailmap
new file mode 100644
index 00000000000000..013c839ed6b7a4
--- /dev/null
+++ b/.mailmap
@@ -0,0 +1,3 @@
+# This file sets the canonical name for contributors to the repository.
+# Documentation: https://git-scm.com/docs/gitmailmap
+Amethyst Reese
diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
new file mode 100644
index 00000000000000..ad9593cc38a74f
--- /dev/null
+++ b/.pre-commit-config.yaml
@@ -0,0 +1,29 @@
+repos:
+ - repo: https://github.com/astral-sh/ruff-pre-commit
+ rev: v0.2.0
+ hooks:
+ - id: ruff
+ name: Run Ruff on Lib/test/
+ args: [--exit-non-zero-on-fix]
+ files: ^Lib/test/
+
+ - repo: https://github.com/pre-commit/pre-commit-hooks
+ rev: v4.5.0
+ hooks:
+ - id: check-toml
+ exclude: ^Lib/test/test_tomllib/
+ - id: check-yaml
+ - id: trailing-whitespace
+ types_or: [c, inc, python, rst]
+
+ - repo: https://github.com/sphinx-contrib/sphinx-lint
+ rev: v0.9.1
+ hooks:
+ - id: sphinx-lint
+ args: [--enable=default-role]
+ files: ^Doc/|^Misc/NEWS.d/
+
+ - repo: meta
+ hooks:
+ - id: check-hooks-apply
+ - id: check-useless-excludes
diff --git a/.readthedocs.yml b/.readthedocs.yml
new file mode 100644
index 00000000000000..898a9ae89dbb92
--- /dev/null
+++ b/.readthedocs.yml
@@ -0,0 +1,18 @@
+# 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-previews/
+
+version: 2
+
+sphinx:
+ configuration: Doc/conf.py
+
+build:
+ os: ubuntu-22.04
+ tools:
+ python: "3"
+
+ commands:
+ - make -C Doc venv html
+ - mkdir _readthedocs
+ - mv Doc/build/html _readthedocs/html
diff --git a/Doc/Makefile b/Doc/Makefile
index 3a3417bf99af3b..d1ffade8ccbff5 100644
--- a/Doc/Makefile
+++ b/Doc/Makefile
@@ -7,30 +7,33 @@
PYTHON = python3
VENVDIR = ./venv
SPHINXBUILD = PATH=$(VENVDIR)/bin:$$PATH sphinx-build
-SPHINXLINT = PATH=$(VENVDIR)/bin:$$PATH sphinx-lint
BLURB = PATH=$(VENVDIR)/bin:$$PATH blurb
+JOBS = auto
PAPER =
SOURCES =
DISTVERSION = $(shell $(PYTHON) tools/extensions/patchlevel.py)
+REQUIREMENTS = requirements.txt
SPHINXERRORHANDLING = -W
# Internal variables.
PAPEROPT_a4 = -D latex_elements.papersize=a4paper
PAPEROPT_letter = -D latex_elements.papersize=letterpaper
-ALLSPHINXOPTS = -b $(BUILDER) -d build/doctrees $(PAPEROPT_$(PAPER)) \
- $(SPHINXOPTS) $(SPHINXERRORHANDLING) . build/$(BUILDER) $(SOURCES)
-
-.PHONY: help build html htmlhelp latex text texinfo changes linkcheck \
- suspicious coverage doctest pydoc-topics htmlview clean dist check serve \
- autobuild-dev autobuild-stable venv
+ALLSPHINXOPTS = -b $(BUILDER) \
+ -d build/doctrees \
+ -j $(JOBS) \
+ $(PAPEROPT_$(PAPER)) \
+ $(SPHINXOPTS) $(SPHINXERRORHANDLING) \
+ . build/$(BUILDER) $(SOURCES)
+.PHONY: help
help:
@echo "Please use \`make ' where is one of"
@echo " clean to remove build files"
@echo " venv to create a venv with necessary tools"
@echo " html to make standalone HTML files"
@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 " htmlhelp to make HTML files and a HTML help project"
@echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
@echo " text to make plain text files"
@@ -45,6 +48,7 @@ help:
@echo " suspicious to check for suspicious markup in output text"
@echo " check to run a check for frequent markup errors"
+.PHONY: build
build:
-mkdir -p build
# Look first for a Misc/NEWS file (building from a source release tarball
@@ -71,38 +75,46 @@ build:
$(SPHINXBUILD) $(ALLSPHINXOPTS)
@echo
+.PHONY: html
html: BUILDER = html
html: build
@echo "Build finished. The HTML pages are in build/html."
+.PHONY: htmlhelp
htmlhelp: BUILDER = htmlhelp
htmlhelp: build
@echo "Build finished; now you can run HTML Help Workshop with the" \
"build/htmlhelp/pydoc.hhp project file."
+.PHONY: latex
latex: BUILDER = latex
latex: build
@echo "Build finished; the LaTeX files are in build/latex."
@echo "Run \`make all-pdf' or \`make all-ps' in that directory to" \
"run these through (pdf)latex."
+.PHONY: text
text: BUILDER = text
text: build
@echo "Build finished; the text files are in build/text."
+.PHONY: texinfo
texinfo: BUILDER = texinfo
texinfo: build
@echo "Build finished; the python.texi file is in build/texinfo."
@echo "Run \`make info' in that directory to run it through makeinfo."
+.PHONY: epub
epub: BUILDER = epub
epub: build
@echo "Build finished; the epub files are in build/epub."
+.PHONY: changes
changes: BUILDER = changes
changes: build
@echo "The overview file is in build/changes."
+.PHONY: linkcheck
linkcheck: BUILDER = linkcheck
linkcheck:
@$(MAKE) build BUILDER=$(BUILDER) || { \
@@ -110,6 +122,7 @@ linkcheck:
"or in build/$(BUILDER)/output.txt"; \
false; }
+.PHONY: suspicious
suspicious: BUILDER = suspicious
suspicious:
@$(MAKE) build BUILDER=$(BUILDER) || { \
@@ -122,10 +135,12 @@ suspicious:
@echo "⚠ make check"
@echo "⚠ instead."
+.PHONY: coverage
coverage: BUILDER = coverage
coverage: build
@echo "Coverage finished; see c.txt and python.txt in build/coverage"
+.PHONY: doctest
doctest: BUILDER = doctest
doctest:
@$(MAKE) build BUILDER=$(BUILDER) || { \
@@ -133,31 +148,42 @@ doctest:
"results in build/doctest/output.txt"; \
false; }
+.PHONY: pydoc-topics
pydoc-topics: BUILDER = pydoc-topics
pydoc-topics: build
@echo "Building finished; now run this:" \
"cp build/pydoc-topics/topics.py ../Lib/pydoc_data/topics.py"
+.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
+htmllive: SPHINXOPTS = --re-ignore="/venv/" --open-browser --delay 0
+htmllive: html
+
+.PHONY: clean
clean: clean-venv
-rm -rf build/*
+.PHONY: clean-venv
clean-venv:
rm -rf $(VENVDIR)
+.PHONY: venv
venv:
@if [ -d $(VENVDIR) ] ; then \
echo "venv already exists."; \
echo "To recreate it, remove it first with \`make clean-venv'."; \
else \
$(PYTHON) -m venv $(VENVDIR); \
- $(VENVDIR)/bin/python3 -m pip install -U pip setuptools; \
- $(VENVDIR)/bin/python3 -m pip install -r requirements.txt; \
+ $(VENVDIR)/bin/python3 -m pip install --upgrade pip; \
+ $(VENVDIR)/bin/python3 -m pip install -r $(REQUIREMENTS); \
echo "The venv has been created in the $(VENVDIR) directory"; \
fi
+.PHONY: dist
dist:
rm -rf dist
mkdir -p dist
@@ -212,10 +238,12 @@ dist:
rm -r dist/python-$(DISTVERSION)-docs-texinfo
rm dist/python-$(DISTVERSION)-docs-texinfo.tar
-check:
- $(SPHINXLINT) -i tools -i $(VENVDIR) -i README.rst
- $(SPHINXLINT) ../Misc/NEWS.d/next/
+.PHONY: check
+check: venv
+ $(VENVDIR)/bin/python3 -m pre_commit --version > /dev/null || $(VENVDIR)/bin/python3 -m pip install pre-commit
+ $(VENVDIR)/bin/python3 -m pre_commit run --all-files
+.PHONY: serve
serve:
@echo "The serve target was removed, use htmlview instead (see bpo-36329)"
@@ -227,15 +255,18 @@ serve:
# output files)
# for development releases: always build
+.PHONY: autobuild-dev
autobuild-dev:
make dist SPHINXOPTS='$(SPHINXOPTS) -Ea -A daily=1'
# for quick rebuilds (HTML only)
+.PHONY: autobuild-dev-html
autobuild-dev-html:
make html SPHINXOPTS='$(SPHINXOPTS) -Ea -A daily=1'
# for stable releases: only build if not in pre-release stage (alpha, beta)
# release candidate downloads are okay, since the stable tree can be in that stage
+.PHONY: autobuild-stable
autobuild-stable:
@case $(DISTVERSION) in *[ab]*) \
echo "Not building; $(DISTVERSION) is not a release version."; \
@@ -243,6 +274,7 @@ autobuild-stable:
esac
@make autobuild-dev
+.PHONY: autobuild-stable-html
autobuild-stable-html:
@case $(DISTVERSION) in *[ab]*) \
echo "Not building; $(DISTVERSION) is not a release version."; \
diff --git a/Doc/README.rst b/Doc/README.rst
index 4326086e9e3529..d67cad79916b38 100644
--- a/Doc/README.rst
+++ b/Doc/README.rst
@@ -40,7 +40,7 @@ If you'd like to create the virtual environment in a different location,
you can specify it using the ``VENVDIR`` variable.
You can also skip creating the virtual environment altogether, in which case
-the Makefile will look for instances of ``sphinxbuild`` and ``blurb``
+the Makefile will look for instances of ``sphinx-build`` and ``blurb``
installed on your process ``PATH`` (configurable with the ``SPHINXBUILD`` and
``BLURB`` variables).
diff --git a/Doc/_static/og-image.png b/Doc/_static/og-image.png
new file mode 100644
index 00000000000000..0e80751e740387
Binary files /dev/null and b/Doc/_static/og-image.png differ
diff --git a/Doc/about.rst b/Doc/about.rst
index f0b908487b2d09..5e6160ff2700ed 100644
--- a/Doc/about.rst
+++ b/Doc/about.rst
@@ -6,8 +6,8 @@ About these documents
These documents are generated from `reStructuredText`_ sources by `Sphinx`_, a
document processor specifically written for the Python documentation.
-.. _reStructuredText: http://docutils.sourceforge.net/rst.html
-.. _Sphinx: http://sphinx-doc.org/
+.. _reStructuredText: https://docutils.sourceforge.io/rst.html
+.. _Sphinx: https://www.sphinx-doc.org/
.. In the online version of these documents, you can submit comments and suggest
changes directly on the documentation pages.
@@ -21,7 +21,7 @@ Many thanks go to:
* Fred L. Drake, Jr., the creator of the original Python documentation toolset
and writer of much of the content;
-* the `Docutils `_ project for creating
+* the `Docutils `_ project for creating
reStructuredText and the Docutils suite;
* Fredrik Lundh for his Alternative Python Reference project from which Sphinx
got many good ideas.
diff --git a/Doc/bugs.rst b/Doc/bugs.rst
index 69d7c27410d56a..908987cf41ff6e 100644
--- a/Doc/bugs.rst
+++ b/Doc/bugs.rst
@@ -19,6 +19,9 @@ If you find a bug in this documentation or would like to propose an improvement,
please submit a bug report on the :ref:`tracker `. If you
have a suggestion on how to fix it, include that as well.
+You can also open a discussion item on our
+`Documentation Discourse forum `_.
+
If you're short on time, you can also email documentation bug reports to
docs@python.org (behavioral bugs can be sent to python-list@python.org).
'docs@' is a mailing list run by volunteers; your request will be noticed,
@@ -35,7 +38,7 @@ though it may take a while to be processed.
`Helping with Documentation `_
Comprehensive guide for individuals that are interested in contributing to Python documentation.
- `Documentation Translations `_
+ `Documentation Translations `_
A list of GitHub pages for documentation translation and their primary contacts.
@@ -67,7 +70,7 @@ Click on the "New issue" button in the top bar to report a new issue.
The submission form has two fields, "Title" and "Comment".
For the "Title" field, enter a *very* short description of the problem;
-less than ten words is good.
+fewer than ten words is good.
In the "Comment" field, describe the problem in detail, including what you
expected to happen and what did happen. Be sure to include whether any
diff --git a/Doc/c-api/allocation.rst b/Doc/c-api/allocation.rst
index 33b0c06a9ebc2e..b3609c233156b6 100644
--- a/Doc/c-api/allocation.rst
+++ b/Doc/c-api/allocation.rst
@@ -14,7 +14,7 @@ Allocating Objects on the Heap
.. c:function:: PyObject* PyObject_Init(PyObject *op, PyTypeObject *type)
- Initialize a newly-allocated object *op* with its type and initial
+ Initialize a newly allocated object *op* with its type and initial
reference. Returns the initialized object. If *type* indicates that the
object participates in the cyclic garbage detector, it is added to the
detector's set of observed objects. Other fields of the object are not
@@ -27,22 +27,26 @@ Allocating Objects on the Heap
length information for a variable-size object.
-.. c:function:: TYPE* PyObject_New(TYPE, PyTypeObject *type)
+.. c:macro:: PyObject_New(TYPE, typeobj)
- Allocate a new Python object using the C structure type *TYPE* and the
- Python type object *type*. Fields not defined by the Python object header
- are not initialized; the object's reference count will be one. The size of
- the memory allocation is determined from the :c:member:`~PyTypeObject.tp_basicsize` field of
- the type object.
+ Allocate a new Python object using the C structure type *TYPE*
+ and the Python type object *typeobj* (``PyTypeObject*``).
+ Fields not defined by the Python object header are not initialized.
+ The caller will own the only reference to the object
+ (i.e. its reference count will be one).
+ The size of the memory allocation is determined from the
+ :c:member:`~PyTypeObject.tp_basicsize` field of the type object.
-.. c:function:: TYPE* PyObject_NewVar(TYPE, PyTypeObject *type, Py_ssize_t size)
+.. c:macro:: PyObject_NewVar(TYPE, typeobj, size)
Allocate a new Python object using the C structure type *TYPE* and the
- Python type object *type*. Fields not defined by the Python object header
+ Python type object *typeobj* (``PyTypeObject*``).
+ Fields not defined by the Python object header
are not initialized. The allocated memory allows for the *TYPE* structure
- plus *size* fields of the size given by the :c:member:`~PyTypeObject.tp_itemsize` field of
- *type*. This is useful for implementing objects like tuples, which are
+ plus *size* (``Py_ssize_t``) fields of the size
+ given by the :c:member:`~PyTypeObject.tp_itemsize` field of
+ *typeobj*. This is useful for implementing objects like tuples, which are
able to determine their size at construction time. Embedding the array of
fields into the same allocation decreases the number of allocations,
improving the memory management efficiency.
@@ -50,8 +54,8 @@ Allocating Objects on the Heap
.. c:function:: void PyObject_Del(void *op)
- Releases memory allocated to an object using :c:func:`PyObject_New` or
- :c:func:`PyObject_NewVar`. This is normally called from the
+ Releases memory allocated to an object using :c:macro:`PyObject_New` or
+ :c:macro:`PyObject_NewVar`. This is normally called from the
:c:member:`~PyTypeObject.tp_dealloc` handler specified in the object's type. The fields of
the object should not be accessed after this call as the memory is no
longer a valid Python object.
diff --git a/Doc/c-api/apiabiversion.rst b/Doc/c-api/apiabiversion.rst
index 85b6e2f373877f..f6c8284daeacb0 100644
--- a/Doc/c-api/apiabiversion.rst
+++ b/Doc/c-api/apiabiversion.rst
@@ -58,7 +58,9 @@ See :ref:`stable` for a discussion of API and ABI stability across versions.
Thus ``3.4.1a2`` is hexversion ``0x030401a2`` and ``3.10.0`` is
hexversion ``0x030a00f0``.
- This version is also available via the symbol :data:`Py_Version`.
+ Use this for numeric comparisons, e.g. ``#if PY_VERSION_HEX >= ...``.
+
+ This version is also available via the symbol :c:var:`Py_Version`.
.. c:var:: const unsigned long Py_Version
diff --git a/Doc/c-api/arg.rst b/Doc/c-api/arg.rst
index 1d93b35dc1c884..08d6cf788e299e 100644
--- a/Doc/c-api/arg.rst
+++ b/Doc/c-api/arg.rst
@@ -34,24 +34,39 @@ These formats allow accessing an object as a contiguous chunk of memory.
You don't have to provide raw storage for the returned unicode or bytes
area.
-In general, when a format sets a pointer to a buffer, the buffer is
-managed by the corresponding Python object, and the buffer shares
-the lifetime of this object. You won't have to release any memory yourself.
-The only exceptions are ``es``, ``es#``, ``et`` and ``et#``.
-
-However, when a :c:type:`Py_buffer` structure gets filled, the underlying
-buffer is locked so that the caller can subsequently use the buffer even
-inside a :c:type:`Py_BEGIN_ALLOW_THREADS` block without the risk of mutable data
-being resized or destroyed. As a result, **you have to call**
-:c:func:`PyBuffer_Release` after you have finished processing the data (or
-in any early abort case).
-
Unless otherwise stated, buffers are not NUL-terminated.
-Some formats require a read-only :term:`bytes-like object`, and set a
-pointer instead of a buffer structure. They work by checking that
-the object's :c:member:`PyBufferProcs.bf_releasebuffer` field is ``NULL``,
-which disallows mutable objects such as :class:`bytearray`.
+There are three ways strings and buffers can be converted to C:
+
+* Formats such as ``y*`` and ``s*`` fill a :c:type:`Py_buffer` structure.
+ This locks the underlying buffer so that the caller can subsequently use
+ the buffer even inside a :c:type:`Py_BEGIN_ALLOW_THREADS`
+ block without the risk of mutable data being resized or destroyed.
+ As a result, **you have to call** :c:func:`PyBuffer_Release` after you have
+ finished processing the data (or in any early abort case).
+
+* The ``es``, ``es#``, ``et`` and ``et#`` formats allocate the result buffer.
+ **You have to call** :c:func:`PyMem_Free` after you have finished
+ processing the data (or in any early abort case).
+
+* .. _c-arg-borrowed-buffer:
+
+ Other formats take a :class:`str` or a read-only :term:`bytes-like object`,
+ such as :class:`bytes`, and provide a ``const char *`` pointer to
+ its buffer.
+ In this case the buffer is "borrowed": it is managed by the corresponding
+ Python object, and shares the lifetime of this object.
+ You won't have to release any memory yourself.
+
+ To ensure that the underlying buffer may be safely borrowed, the object's
+ :c:member:`PyBufferProcs.bf_releasebuffer` field must be ``NULL``.
+ This disallows common mutable objects such as :class:`bytearray`,
+ but also some read-only objects such as :class:`memoryview` of
+ :class:`bytes`.
+
+ Besides this ``bf_releasebuffer`` requirement, there is no check to verify
+ whether the input object is immutable (e.g. whether it would honor a request
+ for a writable buffer, or whether another thread can mutate the data).
.. note::
@@ -89,7 +104,7 @@ which disallows mutable objects such as :class:`bytearray`.
Unicode objects are converted to C strings using ``'utf-8'`` encoding.
``s#`` (:class:`str`, read-only :term:`bytes-like object`) [const char \*, :c:type:`Py_ssize_t`]
- Like ``s*``, except that it doesn't accept mutable objects.
+ Like ``s*``, except that it provides a :ref:`borrowed buffer `.
The result is stored into two C variables,
the first one a pointer to a C string, the second one its length.
The string may contain embedded null bytes. Unicode objects are converted
@@ -108,8 +123,9 @@ which disallows mutable objects such as :class:`bytearray`.
pointer is set to ``NULL``.
``y`` (read-only :term:`bytes-like object`) [const char \*]
- This format converts a bytes-like object to a C pointer to a character
- string; it does not accept Unicode objects. The bytes buffer must not
+ This format converts a bytes-like object to a C pointer to a
+ :ref:`borrowed ` character string;
+ it does not accept Unicode objects. The bytes buffer must not
contain embedded null bytes; if it does, a :exc:`ValueError`
exception is raised.
@@ -129,12 +145,12 @@ which disallows mutable objects such as :class:`bytearray`.
``S`` (:class:`bytes`) [PyBytesObject \*]
Requires that the Python object is a :class:`bytes` object, without
attempting any conversion. Raises :exc:`TypeError` if the object is not
- a bytes object. The C variable may also be declared as :c:type:`PyObject*`.
+ a bytes object. The C variable may also be declared as :c:expr:`PyObject*`.
``Y`` (:class:`bytearray`) [PyByteArrayObject \*]
Requires that the Python object is a :class:`bytearray` object, without
attempting any conversion. Raises :exc:`TypeError` if the object is not
- a :class:`bytearray` object. The C variable may also be declared as :c:type:`PyObject*`.
+ a :class:`bytearray` object. The C variable may also be declared as :c:expr:`PyObject*`.
``u`` (:class:`str`) [const Py_UNICODE \*]
Convert a Python Unicode object to a C pointer to a NUL-terminated buffer of
@@ -181,7 +197,7 @@ which disallows mutable objects such as :class:`bytearray`.
``U`` (:class:`str`) [PyObject \*]
Requires that the Python object is a Unicode object, without attempting
any conversion. Raises :exc:`TypeError` if the object is not a Unicode
- object. The C variable may also be declared as :c:type:`PyObject*`.
+ object. The C variable may also be declared as :c:expr:`PyObject*`.
``w*`` (read-write :term:`bytes-like object`) [Py_buffer]
This format accepts any object which implements the read-write buffer
@@ -194,10 +210,10 @@ which disallows mutable objects such as :class:`bytearray`.
It only works for encoded data without embedded NUL bytes.
This format requires two arguments. The first is only used as input, and
- must be a :c:type:`const char*` which points to the name of an encoding as a
+ must be a :c:expr:`const char*` which points to the name of an encoding as a
NUL-terminated string, or ``NULL``, in which case ``'utf-8'`` encoding is used.
An exception is raised if the named encoding is not known to Python. The
- second argument must be a :c:type:`char**`; the value of the pointer it
+ second argument must be a :c:expr:`char**`; the value of the pointer it
references will be set to a buffer with the contents of the argument text.
The text will be encoded in the encoding specified by the first argument.
@@ -217,10 +233,10 @@ which disallows mutable objects such as :class:`bytearray`.
characters.
It requires three arguments. The first is only used as input, and must be a
- :c:type:`const char*` which points to the name of an encoding as a
+ :c:expr:`const char*` which points to the name of an encoding as a
NUL-terminated string, or ``NULL``, in which case ``'utf-8'`` encoding is used.
An exception is raised if the named encoding is not known to Python. The
- second argument must be a :c:type:`char**`; the value of the pointer it
+ second argument must be a :c:expr:`char**`; the value of the pointer it
references will be set to a buffer with the contents of the argument text.
The text will be encoded in the encoding specified by the first argument.
The third argument must be a pointer to an integer; the referenced integer
@@ -252,59 +268,59 @@ Numbers
``b`` (:class:`int`) [unsigned char]
Convert a nonnegative Python integer to an unsigned tiny int, stored in a C
- :c:type:`unsigned char`.
+ :c:expr:`unsigned char`.
``B`` (:class:`int`) [unsigned char]
Convert a Python integer to a tiny int without overflow checking, stored in a C
- :c:type:`unsigned char`.
+ :c:expr:`unsigned char`.
``h`` (:class:`int`) [short int]
- Convert a Python integer to a C :c:type:`short int`.
+ Convert a Python integer to a C :c:expr:`short int`.
``H`` (:class:`int`) [unsigned short int]
- Convert a Python integer to a C :c:type:`unsigned short int`, without overflow
+ Convert a Python integer to a C :c:expr:`unsigned short int`, without overflow
checking.
``i`` (:class:`int`) [int]
- Convert a Python integer to a plain C :c:type:`int`.
+ Convert a Python integer to a plain C :c:expr:`int`.
``I`` (:class:`int`) [unsigned int]
- Convert a Python integer to a C :c:type:`unsigned int`, without overflow
+ Convert a Python integer to a C :c:expr:`unsigned int`, without overflow
checking.
``l`` (:class:`int`) [long int]
- Convert a Python integer to a C :c:type:`long int`.
+ Convert a Python integer to a C :c:expr:`long int`.
``k`` (:class:`int`) [unsigned long]
- Convert a Python integer to a C :c:type:`unsigned long` without
+ Convert a Python integer to a C :c:expr:`unsigned long` without
overflow checking.
``L`` (:class:`int`) [long long]
- Convert a Python integer to a C :c:type:`long long`.
+ Convert a Python integer to a C :c:expr:`long long`.
``K`` (:class:`int`) [unsigned long long]
- Convert a Python integer to a C :c:type:`unsigned long long`
+ Convert a Python integer to a C :c:expr:`unsigned long long`
without overflow checking.
-``n`` (:class:`int`) [Py_ssize_t]
+``n`` (:class:`int`) [:c:type:`Py_ssize_t`]
Convert a Python integer to a C :c:type:`Py_ssize_t`.
``c`` (:class:`bytes` or :class:`bytearray` of length 1) [char]
Convert a Python byte, represented as a :class:`bytes` or
- :class:`bytearray` object of length 1, to a C :c:type:`char`.
+ :class:`bytearray` object of length 1, to a C :c:expr:`char`.
.. versionchanged:: 3.3
Allow :class:`bytearray` objects.
``C`` (:class:`str` of length 1) [int]
Convert a Python character, represented as a :class:`str` object of
- length 1, to a C :c:type:`int`.
+ length 1, to a C :c:expr:`int`.
``f`` (:class:`float`) [float]
- Convert a Python floating point number to a C :c:type:`float`.
+ Convert a Python floating point number to a C :c:expr:`float`.
``d`` (:class:`float`) [double]
- Convert a Python floating point number to a C :c:type:`double`.
+ Convert a Python floating point number to a C :c:expr:`double`.
``D`` (:class:`complex`) [Py_complex]
Convert a Python complex number to a C :c:type:`Py_complex` structure.
@@ -314,13 +330,15 @@ Other objects
``O`` (object) [PyObject \*]
Store a Python object (without any conversion) in a C object pointer. The C
- program thus receives the actual object that was passed. The object's reference
- count is not increased. The pointer stored is not ``NULL``.
+ program thus receives the actual object that was passed. A new
+ :term:`strong reference` to the object is not created
+ (i.e. its reference count is not increased).
+ The pointer stored is not ``NULL``.
``O!`` (object) [*typeobject*, PyObject \*]
Store a Python object in a C object pointer. This is similar to ``O``, but
takes two C arguments: the first is the address of a Python type object, the
- second is the address of the C variable (of type :c:type:`PyObject*`) into which
+ second is the address of the C variable (of type :c:expr:`PyObject*`) into which
the object pointer is stored. If the Python object does not have the required
type, :exc:`TypeError` is raised.
@@ -329,13 +347,13 @@ Other objects
``O&`` (object) [*converter*, *anything*]
Convert a Python object to a C variable through a *converter* function. This
takes two arguments: the first is a function, the second is the address of a C
- variable (of arbitrary type), converted to :c:type:`void *`. The *converter*
+ variable (of arbitrary type), converted to :c:expr:`void *`. The *converter*
function in turn is called as follows::
status = converter(object, address);
where *object* is the Python object to be converted and *address* is the
- :c:type:`void*` argument that was passed to the :c:func:`PyArg_Parse\*` function.
+ :c:expr:`void*` argument that was passed to the ``PyArg_Parse*`` function.
The returned *status* should be ``1`` for a successful conversion and ``0`` if
the conversion has failed. When the conversion fails, the *converter* function
should raise an exception and leave the content of *address* unmodified.
@@ -364,7 +382,7 @@ Other objects
*items*. Format units for sequences may be nested.
It is possible to pass "long" integers (integers whose value exceeds the
-platform's :const:`LONG_MAX`) however no proper range checking is done --- the
+platform's :c:macro:`LONG_MAX`) however no proper range checking is done --- the
most significant bits are silently truncated when the receiving field is too
small to receive the value (actually, the semantics are inherited from downcasts
in C --- your mileage may vary).
@@ -399,7 +417,8 @@ inside nested parentheses. They are:
mutually exclude each other.
Note that any Python object references which are provided to the caller are
-*borrowed* references; do not decrement their reference count!
+*borrowed* references; do not release them
+(i.e. do not decrement their reference count)!
Additional arguments passed to these functions must be addresses of variables
whose type is determined by the format string; these are used to store values
@@ -409,9 +428,9 @@ what is specified for the corresponding format unit in that case.
For the conversion to succeed, the *arg* object must match the format
and the format must be exhausted. On success, the
-:c:func:`PyArg_Parse\*` functions return true, otherwise they return
+``PyArg_Parse*`` functions return true, otherwise they return
false and raise an appropriate exception. When the
-:c:func:`PyArg_Parse\*` functions fail due to conversion failure in one
+``PyArg_Parse*`` functions fail due to conversion failure in one
of the format units, the variables at the addresses corresponding to that
and the following format units are left untouched.
@@ -476,12 +495,12 @@ API Functions
A simpler form of parameter retrieval which does not use a format string to
specify the types of the arguments. Functions which use this method to retrieve
- their parameters should be declared as :const:`METH_VARARGS` in function or
+ their parameters should be declared as :c:macro:`METH_VARARGS` in function or
method tables. The tuple containing the actual parameters should be passed as
*args*; it must actually be a tuple. The length of the tuple must be at least
*min* and no more than *max*; *min* and *max* may be equal. Additional
arguments must be passed to the function, each of which should be a pointer to a
- :c:type:`PyObject*` variable; these will be filled in with the values from
+ :c:expr:`PyObject*` variable; these will be filled in with the values from
*args*; they will contain :term:`borrowed references `.
The variables which correspond
to optional parameters not given by *args* will not be filled in; these should
@@ -490,7 +509,7 @@ API Functions
will be set if there was a failure.
This is an example of the use of this function, taken from the sources for the
- :mod:`_weakref` helper module for weak references::
+ :mod:`!_weakref` helper module for weak references::
static PyObject *
weakref_ref(PyObject *self, PyObject *args)
@@ -518,7 +537,7 @@ Building values
.. c:function:: PyObject* Py_BuildValue(const char *format, ...)
Create a new value based on a format string similar to those accepted by the
- :c:func:`PyArg_Parse\*` family of functions and a sequence of values. Returns
+ ``PyArg_Parse*`` family of functions and a sequence of values. Returns
the value or ``NULL`` in the case of an error; an exception will be raised if
``NULL`` is returned.
@@ -584,58 +603,60 @@ Building values
Same as ``s#``.
``i`` (:class:`int`) [int]
- Convert a plain C :c:type:`int` to a Python integer object.
+ Convert a plain C :c:expr:`int` to a Python integer object.
``b`` (:class:`int`) [char]
- Convert a plain C :c:type:`char` to a Python integer object.
+ Convert a plain C :c:expr:`char` to a Python integer object.
``h`` (:class:`int`) [short int]
- Convert a plain C :c:type:`short int` to a Python integer object.
+ Convert a plain C :c:expr:`short int` to a Python integer object.
``l`` (:class:`int`) [long int]
- Convert a C :c:type:`long int` to a Python integer object.
+ Convert a C :c:expr:`long int` to a Python integer object.
``B`` (:class:`int`) [unsigned char]
- Convert a C :c:type:`unsigned char` to a Python integer object.
+ Convert a C :c:expr:`unsigned char` to a Python integer object.
``H`` (:class:`int`) [unsigned short int]
- Convert a C :c:type:`unsigned short int` to a Python integer object.
+ Convert a C :c:expr:`unsigned short int` to a Python integer object.
``I`` (:class:`int`) [unsigned int]
- Convert a C :c:type:`unsigned int` to a Python integer object.
+ Convert a C :c:expr:`unsigned int` to a Python integer object.
``k`` (:class:`int`) [unsigned long]
- Convert a C :c:type:`unsigned long` to a Python integer object.
+ Convert a C :c:expr:`unsigned long` to a Python integer object.
``L`` (:class:`int`) [long long]
- Convert a C :c:type:`long long` to a Python integer object.
+ Convert a C :c:expr:`long long` to a Python integer object.
``K`` (:class:`int`) [unsigned long long]
- Convert a C :c:type:`unsigned long long` to a Python integer object.
+ Convert a C :c:expr:`unsigned long long` to a Python integer object.
- ``n`` (:class:`int`) [Py_ssize_t]
+ ``n`` (:class:`int`) [:c:type:`Py_ssize_t`]
Convert a C :c:type:`Py_ssize_t` to a Python integer.
``c`` (:class:`bytes` of length 1) [char]
- Convert a C :c:type:`int` representing a byte to a Python :class:`bytes` object of
+ Convert a C :c:expr:`int` representing a byte to a Python :class:`bytes` object of
length 1.
``C`` (:class:`str` of length 1) [int]
- Convert a C :c:type:`int` representing a character to Python :class:`str`
+ Convert a C :c:expr:`int` representing a character to Python :class:`str`
object of length 1.
``d`` (:class:`float`) [double]
- Convert a C :c:type:`double` to a Python floating point number.
+ Convert a C :c:expr:`double` to a Python floating point number.
``f`` (:class:`float`) [float]
- Convert a C :c:type:`float` to a Python floating point number.
+ Convert a C :c:expr:`float` to a Python floating point number.
``D`` (:class:`complex`) [Py_complex \*]
Convert a C :c:type:`Py_complex` structure to a Python complex number.
``O`` (object) [PyObject \*]
- Pass a Python object untouched (except for its reference count, which is
- incremented by one). If the object passed in is a ``NULL`` pointer, it is assumed
+ Pass a Python object untouched but create a new
+ :term:`strong reference` to it
+ (i.e. its reference count is incremented by one).
+ If the object passed in is a ``NULL`` pointer, it is assumed
that this was caused because the call producing the argument found an error and
set an exception. Therefore, :c:func:`Py_BuildValue` will return ``NULL`` but won't
raise an exception. If no exception has been raised yet, :exc:`SystemError` is
@@ -645,13 +666,13 @@ Building values
Same as ``O``.
``N`` (object) [PyObject \*]
- Same as ``O``, except it doesn't increment the reference count on the object.
+ Same as ``O``, except it doesn't create a new :term:`strong reference`.
Useful when the object is created by a call to an object constructor in the
argument list.
``O&`` (object) [*converter*, *anything*]
Convert *anything* to a Python object through a *converter* function. The
- function is called with *anything* (which should be compatible with :c:type:`void*`)
+ function is called with *anything* (which should be compatible with :c:expr:`void*`)
as its argument and should return a "new" Python object, or ``NULL`` if an
error occurred.
diff --git a/Doc/c-api/bool.rst b/Doc/c-api/bool.rst
index c197d447e9618c..b15ee156c52c21 100644
--- a/Doc/c-api/bool.rst
+++ b/Doc/c-api/bool.rst
@@ -11,6 +11,12 @@ creation and deletion functions don't apply to booleans. The following macros
are available, however.
+.. c:var:: PyTypeObject PyBool_Type
+
+ This instance of :c:type:`PyTypeObject` represents the Python boolean type; it
+ is the same object as :class:`bool` in the Python layer.
+
+
.. c:function:: int PyBool_Check(PyObject *o)
Return true if *o* is of type :c:data:`PyBool_Type`. This function always
diff --git a/Doc/c-api/buffer.rst b/Doc/c-api/buffer.rst
index 05e131d06b909d..1e1cabdf242bd1 100644
--- a/Doc/c-api/buffer.rst
+++ b/Doc/c-api/buffer.rst
@@ -29,7 +29,7 @@ without intermediate copying.
Python provides such a facility at the C level in the form of the :ref:`buffer
protocol `. This protocol has two sides:
-.. index:: single: PyBufferProcs
+.. index:: single: PyBufferProcs (C type)
- on the producer side, a type can export a "buffer interface" which allows
objects of that type to expose information about their underlying buffer.
@@ -44,7 +44,7 @@ the elements exposed by an :class:`array.array` can be multi-byte values.
An example consumer of the buffer interface is the :meth:`~io.BufferedIOBase.write`
method of file objects: any object that can export a series of bytes through
-the buffer interface can be written to a file. While :meth:`write` only
+the buffer interface can be written to a file. While :meth:`!write` only
needs read-only access to the internal contents of the object passed to it,
other methods such as :meth:`~io.BufferedIOBase.readinto` need write access
to the contents of their argument. The buffer interface allows objects to
@@ -99,10 +99,12 @@ a buffer, see :c:func:`PyObject_GetBuffer`.
For :term:`contiguous` arrays, the value points to the beginning of
the memory block.
- .. c:member:: void *obj
+ .. c:member:: PyObject *obj
A new reference to the exporting object. The reference is owned by
- the consumer and automatically decremented and set to ``NULL`` by
+ the consumer and automatically released
+ (i.e. reference count decremented)
+ and set to ``NULL`` by
:c:func:`PyBuffer_Release`. The field is the equivalent of the return
value of any standard C-API function.
@@ -159,10 +161,7 @@ a buffer, see :c:func:`PyObject_GetBuffer`.
If it is ``0``, :c:member:`~Py_buffer.buf` points to a single item representing
a scalar. In this case, :c:member:`~Py_buffer.shape`, :c:member:`~Py_buffer.strides`
and :c:member:`~Py_buffer.suboffsets` MUST be ``NULL``.
-
- The macro :c:macro:`PyBUF_MAX_NDIM` limits the maximum number of dimensions
- to 64. Exporters MUST respect this limit, consumers of multi-dimensional
- buffers SHOULD be able to handle up to :c:macro:`PyBUF_MAX_NDIM` dimensions.
+ The maximum number of dimensions is given by :c:macro:`PyBUF_MAX_NDIM`.
.. c:member:: Py_ssize_t *shape
@@ -215,6 +214,17 @@ a buffer, see :c:func:`PyObject_GetBuffer`.
freed when the buffer is released. The consumer MUST NOT alter this
value.
+
+Constants:
+
+.. c:macro:: PyBUF_MAX_NDIM
+
+ The maximum number of dimensions the memory represents.
+ Exporters MUST respect this limit, consumers of multi-dimensional
+ buffers SHOULD be able to handle up to :c:macro:`!PyBUF_MAX_NDIM` dimensions.
+ Currently set to 64.
+
+
.. _buffer-request-types:
Buffer request types
@@ -225,7 +235,7 @@ object via :c:func:`PyObject_GetBuffer`. Since the complexity of the logical
structure of the memory can vary drastically, the consumer uses the *flags*
argument to specify the exact buffer type it can handle.
-All :c:data:`Py_buffer` fields are unambiguously defined by the request
+All :c:type:`Py_buffer` fields are unambiguously defined by the request
type.
request-independent fields
@@ -438,7 +448,7 @@ Buffer-related functions
Send a request to *exporter* to fill in *view* as specified by *flags*.
If the exporter cannot provide a buffer of the exact type, it MUST raise
- :c:data:`PyExc_BufferError`, set ``view->obj`` to ``NULL`` and
+ :exc:`BufferError`, set ``view->obj`` to ``NULL`` and
return ``-1``.
On success, fill in *view*, set ``view->obj`` to a new reference
@@ -454,7 +464,8 @@ Buffer-related functions
.. c:function:: void PyBuffer_Release(Py_buffer *view)
- Release the buffer *view* and decrement the reference count for
+ Release the buffer *view* and release the :term:`strong reference`
+ (i.e. decrement the reference count) to the view's supporting object,
``view->obj``. This function MUST be called when the buffer
is no longer being used, otherwise reference leaks may occur.
@@ -464,7 +475,7 @@ Buffer-related functions
.. c:function:: Py_ssize_t PyBuffer_SizeFromFormat(const char *format)
- Return the implied :c:data:`~Py_buffer.itemsize` from :c:data:`~Py_buffer.format`.
+ Return the implied :c:member:`~Py_buffer.itemsize` from :c:member:`~Py_buffer.format`.
On error, raise an exception and return -1.
.. versionadded:: 3.9
@@ -499,7 +510,7 @@ Buffer-related functions
This function fails if *len* != *src->len*.
-.. c:function:: int PyObject_CopyData(Py_buffer *dest, Py_buffer *src)
+.. c:function:: int PyObject_CopyData(PyObject *dest, PyObject *src)
Copy data from *src* to *dest* buffer. Can convert between C-style and
or Fortran-style buffers.
@@ -524,7 +535,7 @@ Buffer-related functions
and :c:macro:`PyBUF_WRITABLE` is set in *flags*.
On success, set ``view->obj`` to a new reference to *exporter* and
- return 0. Otherwise, raise :c:data:`PyExc_BufferError`, set
+ return 0. Otherwise, raise :exc:`BufferError`, set
``view->obj`` to ``NULL`` and return ``-1``;
If this function is used as part of a :ref:`getbufferproc `,
diff --git a/Doc/c-api/bytearray.rst b/Doc/c-api/bytearray.rst
index 4bf3cfe100cd01..456f7d89bca03c 100644
--- a/Doc/c-api/bytearray.rst
+++ b/Doc/c-api/bytearray.rst
@@ -5,7 +5,7 @@
Byte Array Objects
------------------
-.. index:: object: bytearray
+.. index:: pair: object; bytearray
.. c:type:: PyByteArrayObject
diff --git a/Doc/c-api/bytes.rst b/Doc/c-api/bytes.rst
index d47f0422e61004..d96809c99adb51 100644
--- a/Doc/c-api/bytes.rst
+++ b/Doc/c-api/bytes.rst
@@ -8,7 +8,7 @@ Bytes Objects
These functions raise :exc:`TypeError` when expecting a bytes parameter and
called with a non-bytes parameter.
-.. index:: object: bytes
+.. index:: pair: object; bytes
.. c:type:: PyBytesObject
@@ -67,39 +67,39 @@ called with a non-bytes parameter.
+-------------------+---------------+--------------------------------+
| Format Characters | Type | Comment |
+===================+===============+================================+
- | :attr:`%%` | *n/a* | The literal % character. |
+ | ``%%`` | *n/a* | The literal % character. |
+-------------------+---------------+--------------------------------+
- | :attr:`%c` | int | A single byte, |
+ | ``%c`` | int | A single byte, |
| | | represented as a C int. |
+-------------------+---------------+--------------------------------+
- | :attr:`%d` | int | Equivalent to |
+ | ``%d`` | int | Equivalent to |
| | | ``printf("%d")``. [1]_ |
+-------------------+---------------+--------------------------------+
- | :attr:`%u` | unsigned int | Equivalent to |
+ | ``%u`` | unsigned int | Equivalent to |
| | | ``printf("%u")``. [1]_ |
+-------------------+---------------+--------------------------------+
- | :attr:`%ld` | long | Equivalent to |
+ | ``%ld`` | long | Equivalent to |
| | | ``printf("%ld")``. [1]_ |
+-------------------+---------------+--------------------------------+
- | :attr:`%lu` | unsigned long | Equivalent to |
+ | ``%lu`` | unsigned long | Equivalent to |
| | | ``printf("%lu")``. [1]_ |
+-------------------+---------------+--------------------------------+
- | :attr:`%zd` | Py_ssize_t | Equivalent to |
- | | | ``printf("%zd")``. [1]_ |
+ | ``%zd`` | :c:type:`\ | Equivalent to |
+ | | Py_ssize_t` | ``printf("%zd")``. [1]_ |
+-------------------+---------------+--------------------------------+
- | :attr:`%zu` | size_t | Equivalent to |
+ | ``%zu`` | size_t | Equivalent to |
| | | ``printf("%zu")``. [1]_ |
+-------------------+---------------+--------------------------------+
- | :attr:`%i` | int | Equivalent to |
+ | ``%i`` | int | Equivalent to |
| | | ``printf("%i")``. [1]_ |
+-------------------+---------------+--------------------------------+
- | :attr:`%x` | int | Equivalent to |
+ | ``%x`` | int | Equivalent to |
| | | ``printf("%x")``. [1]_ |
+-------------------+---------------+--------------------------------+
- | :attr:`%s` | const char\* | A null-terminated C character |
+ | ``%s`` | const char\* | A null-terminated C character |
| | | array. |
+-------------------+---------------+--------------------------------+
- | :attr:`%p` | const void\* | The hex representation of a C |
+ | ``%p`` | const void\* | The hex representation of a C |
| | | pointer. Mostly equivalent to |
| | | ``printf("%p")`` except that |
| | | it is guaranteed to start with |
@@ -158,6 +158,7 @@ called with a non-bytes parameter.
Return the null-terminated contents of the object *obj*
through the output variables *buffer* and *length*.
+ Returns ``0`` on success.
If *length* is ``NULL``, the bytes object
may not contain embedded null bytes;
@@ -187,8 +188,8 @@ called with a non-bytes parameter.
.. c:function:: void PyBytes_ConcatAndDel(PyObject **bytes, PyObject *newpart)
Create a new bytes object in *\*bytes* containing the contents of *newpart*
- appended to *bytes*. This version decrements the reference count of
- *newpart*.
+ appended to *bytes*. This version releases the :term:`strong reference`
+ to *newpart* (i.e. decrements its reference count).
.. c:function:: int _PyBytes_Resize(PyObject **bytes, Py_ssize_t newsize)
diff --git a/Doc/c-api/call.rst b/Doc/c-api/call.rst
index cdf72bc1f4714a..df17c2207e94fd 100644
--- a/Doc/c-api/call.rst
+++ b/Doc/c-api/call.rst
@@ -63,7 +63,7 @@ the arguments to an args tuple and kwargs dict anyway, then there is no point
in implementing vectorcall.
Classes can implement the vectorcall protocol by enabling the
-:const:`Py_TPFLAGS_HAVE_VECTORCALL` flag and setting
+:c:macro:`Py_TPFLAGS_HAVE_VECTORCALL` flag and setting
:c:member:`~PyTypeObject.tp_vectorcall_offset` to the offset inside the
object structure where a *vectorcallfunc* appears.
This is a pointer to a function with the following signature:
@@ -75,7 +75,7 @@ This is a pointer to a function with the following signature:
values of the keyword arguments.
This can be *NULL* if there are no arguments.
- *nargsf* is the number of positional arguments plus possibly the
- :const:`PY_VECTORCALL_ARGUMENTS_OFFSET` flag.
+ :c:macro:`PY_VECTORCALL_ARGUMENTS_OFFSET` flag.
To get the actual number of positional arguments from *nargsf*,
use :c:func:`PyVectorcall_NARGS`.
- *kwnames* is a tuple containing the names of the keyword arguments;
@@ -95,10 +95,12 @@ This is a pointer to a function with the following signature:
``args[0]`` may be changed.
Whenever they can do so cheaply (without additional allocation), callers
- are encouraged to use :const:`PY_VECTORCALL_ARGUMENTS_OFFSET`.
+ are encouraged to use :c:macro:`PY_VECTORCALL_ARGUMENTS_OFFSET`.
Doing so will allow callables such as bound methods to make their onward
calls (which include a prepended *self* argument) very efficiently.
+ .. versionadded:: 3.8
+
To call an object that implements vectorcall, use a :ref:`call API `
function as with any other callable.
:c:func:`PyObject_Vectorcall` will usually be most efficient.
@@ -144,8 +146,6 @@ Vectorcall Support API
However, the function ``PyVectorcall_NARGS`` should be used to allow
for future extensions.
- This function is not part of the :ref:`limited API `.
-
.. versionadded:: 3.8
.. c:function:: vectorcallfunc PyVectorcall_Function(PyObject *op)
@@ -158,9 +158,7 @@ Vectorcall Support API
This is mostly useful to check whether or not *op* supports vectorcall,
which can be done by checking ``PyVectorcall_Function(op) != NULL``.
- This function is not part of the :ref:`limited API `.
-
- .. versionadded:: 3.8
+ .. versionadded:: 3.9
.. c:function:: PyObject* PyVectorcall_Call(PyObject *callable, PyObject *tuple, PyObject *dict)
@@ -169,11 +167,9 @@ Vectorcall Support API
This is a specialized function, intended to be put in the
:c:member:`~PyTypeObject.tp_call` slot or be used in an implementation of ``tp_call``.
- It does not check the :const:`Py_TPFLAGS_HAVE_VECTORCALL` flag
+ It does not check the :c:macro:`Py_TPFLAGS_HAVE_VECTORCALL` flag
and it does not fall back to ``tp_call``.
- This function is not part of the :ref:`limited API `.
-
.. versionadded:: 3.8
@@ -256,8 +252,6 @@ please see individual documentation for details.
Return the result of the call on success, or raise an exception and return
*NULL* on failure.
- This function is not part of the :ref:`limited API `.
-
.. versionadded:: 3.9
@@ -283,7 +277,7 @@ please see individual documentation for details.
This is the equivalent of the Python expression: ``callable(*args)``.
- Note that if you only pass :c:type:`PyObject *` args,
+ Note that if you only pass :c:expr:`PyObject *` args,
:c:func:`PyObject_CallFunctionObjArgs` is a faster alternative.
.. versionchanged:: 3.4
@@ -304,7 +298,7 @@ please see individual documentation for details.
This is the equivalent of the Python expression:
``obj.name(arg1, arg2, ...)``.
- Note that if you only pass :c:type:`PyObject *` args,
+ Note that if you only pass :c:expr:`PyObject *` args,
:c:func:`PyObject_CallMethodObjArgs` is a faster alternative.
.. versionchanged:: 3.4
@@ -314,7 +308,7 @@ please see individual documentation for details.
.. c:function:: PyObject* PyObject_CallFunctionObjArgs(PyObject *callable, ...)
Call a callable Python object *callable*, with a variable number of
- :c:type:`PyObject *` arguments. The arguments are provided as a variable number
+ :c:expr:`PyObject *` arguments. The arguments are provided as a variable number
of parameters followed by *NULL*.
Return the result of the call on success, or raise an exception and return
@@ -328,7 +322,7 @@ please see individual documentation for details.
Call a method of the Python object *obj*, where the name of the method is given as a
Python string object in *name*. It is called with a variable number of
- :c:type:`PyObject *` arguments. The arguments are provided as a variable number
+ :c:expr:`PyObject *` arguments. The arguments are provided as a variable number
of parameters followed by *NULL*.
Return the result of the call on success, or raise an exception and return
@@ -343,8 +337,6 @@ please see individual documentation for details.
Return the result of the call on success, or raise an exception and return
*NULL* on failure.
- This function is not part of the :ref:`limited API `.
-
.. versionadded:: 3.9
@@ -357,8 +349,6 @@ please see individual documentation for details.
Return the result of the call on success, or raise an exception and return
*NULL* on failure.
- This function is not part of the :ref:`limited API `.
-
.. versionadded:: 3.9
@@ -372,8 +362,6 @@ please see individual documentation for details.
Return the result of the call on success, or raise an exception and return
*NULL* on failure.
- This function is not part of the :ref:`limited API `.
-
.. versionadded:: 3.9
.. c:function:: PyObject* PyObject_VectorcallDict(PyObject *callable, PyObject *const *args, size_t nargsf, PyObject *kwdict)
@@ -388,8 +376,6 @@ please see individual documentation for details.
already has a dictionary ready to use for the keyword arguments,
but not a tuple for the positional arguments.
- This function is not part of the :ref:`limited API `.
-
.. versionadded:: 3.9
.. c:function:: PyObject* PyObject_VectorcallMethod(PyObject *name, PyObject *const *args, size_t nargsf, PyObject *kwnames)
@@ -399,19 +385,17 @@ please see individual documentation for details.
*args[0]*, and the *args* array starting at *args[1]* represents the arguments
of the call. There must be at least one positional argument.
*nargsf* is the number of positional arguments including *args[0]*,
- plus :const:`PY_VECTORCALL_ARGUMENTS_OFFSET` if the value of ``args[0]`` may
+ plus :c:macro:`PY_VECTORCALL_ARGUMENTS_OFFSET` if the value of ``args[0]`` may
temporarily be changed. Keyword arguments can be passed just like in
:c:func:`PyObject_Vectorcall`.
- If the object has the :const:`Py_TPFLAGS_METHOD_DESCRIPTOR` feature,
+ If the object has the :c:macro:`Py_TPFLAGS_METHOD_DESCRIPTOR` feature,
this will call the unbound method object with the full
*args* vector as arguments.
Return the result of the call on success, or raise an exception and return
*NULL* on failure.
- This function is not part of the :ref:`limited API `.
-
.. versionadded:: 3.9
diff --git a/Doc/c-api/capsule.rst b/Doc/c-api/capsule.rst
index 2c4cfc48f9a27a..cdb8aa33e9fd32 100644
--- a/Doc/c-api/capsule.rst
+++ b/Doc/c-api/capsule.rst
@@ -5,7 +5,7 @@
Capsules
--------
-.. index:: object: Capsule
+.. index:: pair: object; Capsule
Refer to :ref:`using-capsules` for more information on using these objects.
@@ -15,7 +15,7 @@ Refer to :ref:`using-capsules` for more information on using these objects.
.. c:type:: PyCapsule
This subtype of :c:type:`PyObject` represents an opaque value, useful for C
- extension modules who need to pass an opaque value (as a :c:type:`void*`
+ extension modules who need to pass an opaque value (as a :c:expr:`void*`
pointer) through Python code to other C code. It is often used to make a C
function pointer defined in one module available to other modules, so the
regular import mechanism can be used to access C APIs defined in dynamically
@@ -64,7 +64,7 @@ Refer to :ref:`using-capsules` for more information on using these objects.
The *name* parameter must compare exactly to the name stored in the capsule.
If the name stored in the capsule is ``NULL``, the *name* passed in must also
- be ``NULL``. Python uses the C function :c:func:`strcmp` to compare capsule
+ be ``NULL``. Python uses the C function :c:func:`!strcmp` to compare capsule
names.
@@ -121,7 +121,7 @@ Refer to :ref:`using-capsules` for more information on using these objects.
compared.)
In other words, if :c:func:`PyCapsule_IsValid` returns a true value, calls to
- any of the accessors (any function starting with :c:func:`PyCapsule_Get`) are
+ any of the accessors (any function starting with ``PyCapsule_Get``) are
guaranteed to succeed.
Return a nonzero value if the object is valid and matches the name passed in.
diff --git a/Doc/c-api/cell.rst b/Doc/c-api/cell.rst
index ac4ef5adc5cc20..f8cd0344fdd1c0 100644
--- a/Doc/c-api/cell.rst
+++ b/Doc/c-api/cell.rst
@@ -25,7 +25,7 @@ Cell objects are not likely to be useful elsewhere.
The type object corresponding to cell objects.
-.. c:function:: int PyCell_Check(ob)
+.. c:function:: int PyCell_Check(PyObject *ob)
Return true if *ob* is a cell object; *ob* must not be ``NULL``. This
function always succeeds.
diff --git a/Doc/c-api/code.rst b/Doc/c-api/code.rst
index 7915b81b463773..3f30710025a3b3 100644
--- a/Doc/c-api/code.rst
+++ b/Doc/c-api/code.rst
@@ -1,9 +1,9 @@
.. highlight:: c
-.. _codeobjects:
-
.. index:: object; code, code object
+.. _codeobjects:
+
Code Objects
------------
@@ -22,18 +22,19 @@ bound into a function.
.. c:var:: PyTypeObject PyCode_Type
This is an instance of :c:type:`PyTypeObject` representing the Python
- :class:`code` type.
+ :ref:`code object `.
.. c:function:: int PyCode_Check(PyObject *co)
- Return true if *co* is a :class:`code` object. This function always succeeds.
+ Return true if *co* is a :ref:`code object `.
+ This function always succeeds.
.. c:function:: int PyCode_GetNumFree(PyCodeObject *co)
Return the number of free variables in *co*.
-.. c:function:: PyCodeObject* PyCode_New(int argcount, int kwonlyargcount, int nlocals, int stacksize, int flags, PyObject *code, PyObject *consts, PyObject *names, PyObject *varnames, PyObject *freevars, PyObject *cellvars, PyObject *filename, PyObject *name, int firstlineno, PyObject *linetable, PyObject *exceptiontable)
+.. c:function:: PyCodeObject* PyCode_New(int argcount, int kwonlyargcount, int nlocals, int stacksize, int flags, PyObject *code, PyObject *consts, PyObject *names, PyObject *varnames, PyObject *freevars, PyObject *cellvars, PyObject *filename, PyObject *name, PyObject *qualname, int firstlineno, PyObject *linetable, PyObject *exceptiontable)
Return a new code object. If you need a dummy code object to create a frame,
use :c:func:`PyCode_NewEmpty` instead. Calling :c:func:`PyCode_New` directly
@@ -43,9 +44,9 @@ bound into a function.
execution or VM crashes. Use this function only with extreme care.
.. versionchanged:: 3.11
- Added ``exceptiontable`` parameter.
+ Added ``qualname`` and ``exceptiontable`` parameters.
-.. c:function:: PyCodeObject* PyCode_NewWithPosOnlyArgs(int argcount, int posonlyargcount, int kwonlyargcount, int nlocals, int stacksize, int flags, PyObject *code, PyObject *consts, PyObject *names, PyObject *varnames, PyObject *freevars, PyObject *cellvars, PyObject *filename, PyObject *name, int firstlineno, PyObject *linetable, PyObject *exceptiontable)
+.. c:function:: PyCodeObject* PyCode_NewWithPosOnlyArgs(int argcount, int posonlyargcount, int kwonlyargcount, int nlocals, int stacksize, int flags, PyObject *code, PyObject *consts, PyObject *names, PyObject *varnames, PyObject *freevars, PyObject *cellvars, PyObject *filename, PyObject *name, PyObject *qualname, int firstlineno, PyObject *linetable, PyObject *exceptiontable)
Similar to :c:func:`PyCode_New`, but with an extra "posonlyargcount" for positional-only arguments.
The same caveats that apply to ``PyCode_New`` also apply to this function.
@@ -53,7 +54,7 @@ bound into a function.
.. versionadded:: 3.8
.. versionchanged:: 3.11
- Added ``exceptiontable`` parameter.
+ Added ``qualname`` and ``exceptiontable`` parameters.
.. c:function:: PyCodeObject* PyCode_NewEmpty(const char *filename, const char *funcname, int firstlineno)
@@ -77,6 +78,8 @@ bound into a function.
Returns ``1`` if the function succeeds and 0 otherwise.
+ .. versionadded:: 3.11
+
.. c:function:: PyObject* PyCode_GetCode(PyCodeObject *co)
Equivalent to the Python code ``getattr(co, 'co_code')``.
@@ -90,3 +93,28 @@ bound into a function.
.. versionadded:: 3.11
+.. c:function:: PyObject* PyCode_GetVarnames(PyCodeObject *co)
+
+ Equivalent to the Python code ``getattr(co, 'co_varnames')``.
+ Returns a new reference to a :c:type:`PyTupleObject` containing the names of
+ the local variables. On error, ``NULL`` is returned and an exception
+ is raised.
+
+ .. versionadded:: 3.11
+
+.. c:function:: PyObject* PyCode_GetCellvars(PyCodeObject *co)
+
+ Equivalent to the Python code ``getattr(co, 'co_cellvars')``.
+ Returns a new reference to a :c:type:`PyTupleObject` containing the names of
+ the local variables that are referenced by nested functions. On error, ``NULL``
+ is returned and an exception is raised.
+
+ .. versionadded:: 3.11
+
+.. c:function:: PyObject* PyCode_GetFreevars(PyCodeObject *co)
+
+ Equivalent to the Python code ``getattr(co, 'co_freevars')``.
+ Returns a new reference to a :c:type:`PyTupleObject` containing the names of
+ the free variables. On error, ``NULL`` is returned and an exception is raised.
+
+ .. versionadded:: 3.11
diff --git a/Doc/c-api/codec.rst b/Doc/c-api/codec.rst
index 235c77c945cc5b..8ae5c4fecd6248 100644
--- a/Doc/c-api/codec.rst
+++ b/Doc/c-api/codec.rst
@@ -7,7 +7,7 @@ Codec registry and support functions
Register a new codec search function.
- As side effect, this tries to load the :mod:`encodings` package, if not yet
+ As side effect, this tries to load the :mod:`!encodings` package, if not yet
done, to make sure that it is always first in the list of search functions.
.. c:function:: int PyCodec_Unregister(PyObject *search_function)
diff --git a/Doc/c-api/complex.rst b/Doc/c-api/complex.rst
index c25894681bca35..e3fd001c599c80 100644
--- a/Doc/c-api/complex.rst
+++ b/Doc/c-api/complex.rst
@@ -5,7 +5,7 @@
Complex Number Objects
----------------------
-.. index:: object: complex number
+.. index:: pair: object; complex number
Python's complex number objects are implemented as two distinct types when
viewed from the C API: one is the Python object exposed to Python programs, and
@@ -64,7 +64,7 @@ pointers. This is consistent throughout the API.
representation.
If *divisor* is null, this method returns zero and sets
- :c:data:`errno` to :c:data:`EDOM`.
+ :c:data:`errno` to :c:macro:`!EDOM`.
.. c:function:: Py_complex _Py_c_pow(Py_complex num, Py_complex exp)
@@ -73,7 +73,7 @@ pointers. This is consistent throughout the API.
representation.
If *num* is null and *exp* is not a positive real number,
- this method returns zero and sets :c:data:`errno` to :c:data:`EDOM`.
+ this method returns zero and sets :c:data:`errno` to :c:macro:`!EDOM`.
Complex Numbers as Python Objects
@@ -115,24 +115,24 @@ Complex Numbers as Python Objects
.. c:function:: double PyComplex_RealAsDouble(PyObject *op)
- Return the real part of *op* as a C :c:type:`double`.
+ Return the real part of *op* as a C :c:expr:`double`.
.. c:function:: double PyComplex_ImagAsDouble(PyObject *op)
- Return the imaginary part of *op* as a C :c:type:`double`.
+ Return the imaginary part of *op* as a C :c:expr:`double`.
.. c:function:: Py_complex PyComplex_AsCComplex(PyObject *op)
Return the :c:type:`Py_complex` value of the complex number *op*.
- If *op* is not a Python complex number object but has a :meth:`__complex__`
+ If *op* is not a Python complex number object but has a :meth:`~object.__complex__`
method, this method will first be called to convert *op* to a Python complex
- number object. If ``__complex__()`` is not defined then it falls back to
- :meth:`__float__`. If ``__float__()`` is not defined then it falls back
- to :meth:`__index__`. Upon failure, this method returns ``-1.0`` as a real
+ number object. If :meth:`!__complex__` is not defined then it falls back to
+ :meth:`~object.__float__`. If :meth:`!__float__` is not defined then it falls back
+ to :meth:`~object.__index__`. Upon failure, this method returns ``-1.0`` as a real
value.
.. versionchanged:: 3.8
- Use :meth:`__index__` if available.
+ Use :meth:`~object.__index__` if available.
diff --git a/Doc/c-api/concrete.rst b/Doc/c-api/concrete.rst
index 8d3124a12fa9d2..880f7b15ce68e8 100644
--- a/Doc/c-api/concrete.rst
+++ b/Doc/c-api/concrete.rst
@@ -40,7 +40,7 @@ This section describes Python type objects and the singleton object ``None``.
Numeric Objects
===============
-.. index:: object: numeric
+.. index:: pair: object; numeric
.. toctree::
@@ -55,7 +55,7 @@ Numeric Objects
Sequence Objects
================
-.. index:: object: sequence
+.. index:: pair: object; sequence
Generic operations on sequence objects were discussed in the previous chapter;
this section deals with the specific kinds of sequence objects that are
@@ -77,7 +77,7 @@ intrinsic to the Python language.
Container Objects
=================
-.. index:: object: mapping
+.. index:: pair: object; mapping
.. toctree::
diff --git a/Doc/c-api/conversion.rst b/Doc/c-api/conversion.rst
index 7b4cc1cacdd4ab..4aaf3905e81c8a 100644
--- a/Doc/c-api/conversion.rst
+++ b/Doc/c-api/conversion.rst
@@ -28,7 +28,8 @@ not.
The wrappers ensure that ``str[size-1]`` is always ``'\0'`` upon return. They
never write more than *size* bytes (including the trailing ``'\0'``) into str.
Both functions require that ``str != NULL``, ``size > 0``, ``format != NULL``
-and ``size < INT_MAX``.
+and ``size < INT_MAX``. Note that this means there is no equivalent to the C99
+``n = snprintf(NULL, 0, ...)`` which would determine the necessary buffer size.
The return value (*rv*) for these functions should be interpreted as follows:
@@ -47,9 +48,45 @@ The return value (*rv*) for these functions should be interpreted as follows:
The following functions provide locale-independent string to number conversions.
+.. c:function:: unsigned long PyOS_strtoul(const char *str, char **ptr, int base)
+
+ Convert the initial part of the string in ``str`` to an :c:expr:`unsigned
+ long` value according to the given ``base``, which must be between ``2`` and
+ ``36`` inclusive, or be the special value ``0``.
+
+ Leading white space and case of characters are ignored. If ``base`` is zero
+ it looks for a leading ``0b``, ``0o`` or ``0x`` to tell which base. If
+ these are absent it defaults to ``10``. Base must be 0 or between 2 and 36
+ (inclusive). If ``ptr`` is non-``NULL`` it will contain a pointer to the
+ end of the scan.
+
+ If the converted value falls out of range of corresponding return type,
+ range error occurs (:c:data:`errno` is set to :c:macro:`!ERANGE`) and
+ :c:macro:`!ULONG_MAX` is returned. If no conversion can be performed, ``0``
+ is returned.
+
+ See also the Unix man page :manpage:`strtoul(3)`.
+
+ .. versionadded:: 3.2
+
+
+.. c:function:: long PyOS_strtol(const char *str, char **ptr, int base)
+
+ Convert the initial part of the string in ``str`` to an :c:expr:`long` value
+ according to the given ``base``, which must be between ``2`` and ``36``
+ inclusive, or be the special value ``0``.
+
+ Same as :c:func:`PyOS_strtoul`, but return a :c:expr:`long` value instead
+ and :c:macro:`LONG_MAX` on overflows.
+
+ See also the Unix man page :manpage:`strtol(3)`.
+
+ .. versionadded:: 3.2
+
+
.. c:function:: double PyOS_string_to_double(const char *s, char **endptr, PyObject *overflow_exception)
- Convert a string ``s`` to a :c:type:`double`, raising a Python
+ Convert a string ``s`` to a :c:expr:`double`, raising a Python
exception on failure. The set of accepted strings corresponds to
the set of strings accepted by Python's :func:`float` constructor,
except that ``s`` must not have leading or trailing whitespace.
@@ -83,7 +120,7 @@ The following functions provide locale-independent string to number conversions.
.. c:function:: char* PyOS_double_to_string(double val, char format_code, int precision, int flags, int *ptype)
- Convert a :c:type:`double` *val* to a string using supplied
+ Convert a :c:expr:`double` *val* to a string using supplied
*format_code*, *precision*, and *flags*.
*format_code* must be one of ``'e'``, ``'E'``, ``'f'``, ``'F'``,
@@ -118,10 +155,10 @@ The following functions provide locale-independent string to number conversions.
.. c:function:: int PyOS_stricmp(const char *s1, const char *s2)
Case insensitive comparison of strings. The function works almost
- identically to :c:func:`strcmp` except that it ignores the case.
+ identically to :c:func:`!strcmp` except that it ignores the case.
.. c:function:: int PyOS_strnicmp(const char *s1, const char *s2, Py_ssize_t size)
Case insensitive comparison of strings. The function works almost
- identically to :c:func:`strncmp` except that it ignores the case.
+ identically to :c:func:`!strncmp` except that it ignores the case.
diff --git a/Doc/c-api/datetime.rst b/Doc/c-api/datetime.rst
index 4c4e4bcfa63335..97522da773477e 100644
--- a/Doc/c-api/datetime.rst
+++ b/Doc/c-api/datetime.rst
@@ -8,11 +8,54 @@ DateTime Objects
Various date and time objects are supplied by the :mod:`datetime` module.
Before using any of these functions, the header file :file:`datetime.h` must be
included in your source (note that this is not included by :file:`Python.h`),
-and the macro :c:macro:`PyDateTime_IMPORT` must be invoked, usually as part of
+and the macro :c:macro:`!PyDateTime_IMPORT` must be invoked, usually as part of
the module initialisation function. The macro puts a pointer to a C structure
-into a static variable, :c:data:`PyDateTimeAPI`, that is used by the following
+into a static variable, :c:data:`!PyDateTimeAPI`, that is used by the following
macros.
+.. c:type:: PyDateTime_Date
+
+ This subtype of :c:type:`PyObject` represents a Python date object.
+
+.. c:type:: PyDateTime_DateTime
+
+ This subtype of :c:type:`PyObject` represents a Python datetime object.
+
+.. c:type:: PyDateTime_Time
+
+ This subtype of :c:type:`PyObject` represents a Python time object.
+
+.. c:type:: PyDateTime_Delta
+
+ This subtype of :c:type:`PyObject` represents the difference between two datetime values.
+
+.. c:var:: PyTypeObject PyDateTime_DateType
+
+ This instance of :c:type:`PyTypeObject` represents the Python date type;
+ it is the same object as :class:`datetime.date` in the Python layer.
+
+.. c:var:: PyTypeObject PyDateTime_DateTimeType
+
+ This instance of :c:type:`PyTypeObject` represents the Python datetime type;
+ it is the same object as :class:`datetime.datetime` in the Python layer.
+
+.. c:var:: PyTypeObject PyDateTime_TimeType
+
+ This instance of :c:type:`PyTypeObject` represents the Python time type;
+ it is the same object as :class:`datetime.time` in the Python layer.
+
+.. c:var:: PyTypeObject PyDateTime_DeltaType
+
+ This instance of :c:type:`PyTypeObject` represents Python type for
+ the difference between two datetime values;
+ it is the same object as :class:`datetime.timedelta` in the Python layer.
+
+.. c:var:: PyTypeObject PyDateTime_TZInfoType
+
+ This instance of :c:type:`PyTypeObject` represents the Python time zone info type;
+ it is the same object as :class:`datetime.tzinfo` in the Python layer.
+
+
Macro for access to the UTC singleton:
.. c:var:: PyObject* PyDateTime_TimeZone_UTC
@@ -28,7 +71,7 @@ Type-check macros:
.. c:function:: int PyDate_Check(PyObject *ob)
Return true if *ob* is of type :c:data:`PyDateTime_DateType` or a subtype of
- :c:data:`PyDateTime_DateType`. *ob* must not be ``NULL``. This function always
+ :c:data:`!PyDateTime_DateType`. *ob* must not be ``NULL``. This function always
succeeds.
@@ -41,7 +84,7 @@ Type-check macros:
.. c:function:: int PyDateTime_Check(PyObject *ob)
Return true if *ob* is of type :c:data:`PyDateTime_DateTimeType` or a subtype of
- :c:data:`PyDateTime_DateTimeType`. *ob* must not be ``NULL``. This function always
+ :c:data:`!PyDateTime_DateTimeType`. *ob* must not be ``NULL``. This function always
succeeds.
@@ -54,7 +97,7 @@ Type-check macros:
.. c:function:: int PyTime_Check(PyObject *ob)
Return true if *ob* is of type :c:data:`PyDateTime_TimeType` or a subtype of
- :c:data:`PyDateTime_TimeType`. *ob* must not be ``NULL``. This function always
+ :c:data:`!PyDateTime_TimeType`. *ob* must not be ``NULL``. This function always
succeeds.
@@ -67,7 +110,7 @@ Type-check macros:
.. c:function:: int PyDelta_Check(PyObject *ob)
Return true if *ob* is of type :c:data:`PyDateTime_DeltaType` or a subtype of
- :c:data:`PyDateTime_DeltaType`. *ob* must not be ``NULL``. This function always
+ :c:data:`!PyDateTime_DeltaType`. *ob* must not be ``NULL``. This function always
succeeds.
@@ -80,7 +123,7 @@ Type-check macros:
.. c:function:: int PyTZInfo_Check(PyObject *ob)
Return true if *ob* is of type :c:data:`PyDateTime_TZInfoType` or a subtype of
- :c:data:`PyDateTime_TZInfoType`. *ob* must not be ``NULL``. This function always
+ :c:data:`!PyDateTime_TZInfoType`. *ob* must not be ``NULL``. This function always
succeeds.
@@ -132,14 +175,16 @@ Macros to create objects:
resulting number of microseconds and seconds lie in the ranges documented for
:class:`datetime.timedelta` objects.
-.. c:function:: PyObject* PyTimeZone_FromOffset(PyDateTime_DeltaType* offset)
+
+.. c:function:: PyObject* PyTimeZone_FromOffset(PyObject *offset)
Return a :class:`datetime.timezone` object with an unnamed fixed offset
represented by the *offset* argument.
.. versionadded:: 3.7
-.. c:function:: PyObject* PyTimeZone_FromOffsetAndName(PyDateTime_DeltaType* offset, PyUnicode* name)
+
+.. c:function:: PyObject* PyTimeZone_FromOffsetAndName(PyObject *offset, PyObject *name)
Return a :class:`datetime.timezone` object with a fixed offset represented
by the *offset* argument and with tzname *name*.
@@ -148,8 +193,8 @@ Macros to create objects:
Macros to extract fields from date objects. The argument must be an instance of
-:c:data:`PyDateTime_Date`, including subclasses (such as
-:c:data:`PyDateTime_DateTime`). The argument must not be ``NULL``, and the type is
+:c:type:`PyDateTime_Date`, including subclasses (such as
+:c:type:`PyDateTime_DateTime`). The argument must not be ``NULL``, and the type is
not checked:
.. c:function:: int PyDateTime_GET_YEAR(PyDateTime_Date *o)
@@ -168,7 +213,7 @@ not checked:
Macros to extract fields from datetime objects. The argument must be an
-instance of :c:data:`PyDateTime_DateTime`, including subclasses. The argument
+instance of :c:type:`PyDateTime_DateTime`, including subclasses. The argument
must not be ``NULL``, and the type is not checked:
.. c:function:: int PyDateTime_DATE_GET_HOUR(PyDateTime_DateTime *o)
@@ -190,14 +235,23 @@ must not be ``NULL``, and the type is not checked:
Return the microsecond, as an int from 0 through 999999.
+
+.. c:function:: int PyDateTime_DATE_GET_FOLD(PyDateTime_DateTime *o)
+
+ Return the fold, as an int from 0 through 1.
+
+ .. versionadded:: 3.6
+
+
.. c:function:: PyObject* PyDateTime_DATE_GET_TZINFO(PyDateTime_DateTime *o)
Return the tzinfo (which may be ``None``).
.. versionadded:: 3.10
+
Macros to extract fields from time objects. The argument must be an instance of
-:c:data:`PyDateTime_Time`, including subclasses. The argument must not be ``NULL``,
+:c:type:`PyDateTime_Time`, including subclasses. The argument must not be ``NULL``,
and the type is not checked:
.. c:function:: int PyDateTime_TIME_GET_HOUR(PyDateTime_Time *o)
@@ -219,6 +273,14 @@ and the type is not checked:
Return the microsecond, as an int from 0 through 999999.
+
+.. c:function:: int PyDateTime_TIME_GET_FOLD(PyDateTime_Time *o)
+
+ Return the fold, as an int from 0 through 1.
+
+ .. versionadded:: 3.6
+
+
.. c:function:: PyObject* PyDateTime_TIME_GET_TZINFO(PyDateTime_Time *o)
Return the tzinfo (which may be ``None``).
@@ -227,7 +289,7 @@ and the type is not checked:
Macros to extract fields from time delta objects. The argument must be an
-instance of :c:data:`PyDateTime_Delta`, including subclasses. The argument must
+instance of :c:type:`PyDateTime_Delta`, including subclasses. The argument must
not be ``NULL``, and the type is not checked:
.. c:function:: int PyDateTime_DELTA_GET_DAYS(PyDateTime_Delta *o)
diff --git a/Doc/c-api/dict.rst b/Doc/c-api/dict.rst
index d257c9b5f763d1..1575aa50eff5d6 100644
--- a/Doc/c-api/dict.rst
+++ b/Doc/c-api/dict.rst
@@ -5,7 +5,7 @@
Dictionary Objects
------------------
-.. index:: object: dictionary
+.. index:: pair: object; dictionary
.. c:type:: PyDictObject
@@ -70,17 +70,14 @@ Dictionary Objects
.. c:function:: int PyDict_SetItemString(PyObject *p, const char *key, PyObject *val)
- .. index:: single: PyUnicode_FromString()
-
- Insert *val* into the dictionary *p* using *key* as a key. *key* should
- be a :c:type:`const char*`. The key object is created using
- ``PyUnicode_FromString(key)``. Return ``0`` on success or ``-1`` on
- failure. This function *does not* steal a reference to *val*.
+ This is the same as :c:func:`PyDict_SetItem`, but *key* is
+ specified as a :c:expr:`const char*` UTF-8 encoded bytes string,
+ rather than a :c:expr:`PyObject*`.
.. c:function:: int PyDict_DelItem(PyObject *p, PyObject *key)
- Remove the entry in dictionary *p* with key *key*. *key* must be hashable;
+ Remove the entry in dictionary *p* with key *key*. *key* must be :term:`hashable`;
if it isn't, :exc:`TypeError` is raised.
If *key* is not in the dictionary, :exc:`KeyError` is raised.
Return ``0`` on success or ``-1`` on failure.
@@ -88,9 +85,9 @@ Dictionary Objects
.. c:function:: int PyDict_DelItemString(PyObject *p, const char *key)
- Remove the entry in dictionary *p* which has a key specified by the string *key*.
- If *key* is not in the dictionary, :exc:`KeyError` is raised.
- Return ``0`` on success or ``-1`` on failure.
+ This is the same as :c:func:`PyDict_DelItem`, but *key* is
+ specified as a :c:expr:`const char*` UTF-8 encoded bytes string,
+ rather than a :c:expr:`PyObject*`.
.. c:function:: PyObject* PyDict_GetItem(PyObject *p, PyObject *key)
@@ -98,9 +95,11 @@ Dictionary Objects
Return the object from dictionary *p* which has a key *key*. Return ``NULL``
if the key *key* is not present, but *without* setting an exception.
- Note that exceptions which occur while calling :meth:`__hash__` and
- :meth:`__eq__` methods will get suppressed.
- To get error reporting use :c:func:`PyDict_GetItemWithError()` instead.
+ .. note::
+
+ Exceptions that occur while this calls :meth:`~object.__hash__` and
+ :meth:`~object.__eq__` methods are silently ignored.
+ Prefer the :c:func:`PyDict_GetItemWithError` function instead.
.. versionchanged:: 3.10
Calling this API without :term:`GIL` held had been allowed for historical
@@ -118,12 +117,16 @@ Dictionary Objects
.. c:function:: PyObject* PyDict_GetItemString(PyObject *p, const char *key)
This is the same as :c:func:`PyDict_GetItem`, but *key* is specified as a
- :c:type:`const char*`, rather than a :c:type:`PyObject*`.
+ :c:expr:`const char*` UTF-8 encoded bytes string, rather than a
+ :c:expr:`PyObject*`.
+
+ .. note::
- Note that exceptions which occur while calling :meth:`__hash__` and
- :meth:`__eq__` methods and creating a temporary string object
- will get suppressed.
- To get error reporting use :c:func:`PyDict_GetItemWithError()` instead.
+ Exceptions that occur while this calls :meth:`~object.__hash__` and
+ :meth:`~object.__eq__` methods or while creating the temporary :class:`str`
+ object are silently ignored.
+ Prefer using the :c:func:`PyDict_GetItemWithError` function with your own
+ :c:func:`PyUnicode_FromString` *key* instead.
.. c:function:: PyObject* PyDict_SetDefault(PyObject *p, PyObject *key, PyObject *defaultobj)
@@ -154,7 +157,7 @@ Dictionary Objects
.. c:function:: Py_ssize_t PyDict_Size(PyObject *p)
- .. index:: builtin: len
+ .. index:: pair: built-in function; len
Return the number of items in the dictionary. This is equivalent to
``len(p)`` on a dictionary.
@@ -167,7 +170,7 @@ Dictionary Objects
prior to the first call to this function to start the iteration; the
function returns true for each pair in the dictionary, and false once all
pairs have been reported. The parameters *pkey* and *pvalue* should either
- point to :c:type:`PyObject*` variables that will be filled in with each key
+ point to :c:expr:`PyObject*` variables that will be filled in with each key
and value, respectively, or may be ``NULL``. Any references returned through
them are borrowed. *ppos* should not be altered during iteration. Its
value represents offsets within the internal dictionary structure, and
diff --git a/Doc/c-api/exceptions.rst b/Doc/c-api/exceptions.rst
index 7bfeca5958cc42..9abf443f025e56 100644
--- a/Doc/c-api/exceptions.rst
+++ b/Doc/c-api/exceptions.rst
@@ -14,7 +14,7 @@ there is a global indicator (per thread) of the last error that occurred. Most
C API functions don't clear this on success, but will set it to indicate the
cause of the error on failure. Most C API functions also return an error
indicator, usually ``NULL`` if they are supposed to return a pointer, or ``-1``
-if they return an integer (exception: the :c:func:`PyArg_\*` functions
+if they return an integer (exception: the ``PyArg_*`` functions
return ``1`` for success and ``0`` for failure).
Concretely, the error indicator consists of three object pointers: the
@@ -78,7 +78,7 @@ Printing and clearing
This utility function prints a warning message to ``sys.stderr`` when an
exception has been set but it is impossible for the interpreter to actually
raise the exception. It is used, for example, when an exception occurs in an
- :meth:`__del__` method.
+ :meth:`~object.__del__` method.
The function is called with a single argument *obj* that identifies the context
in which the unraisable exception occurred. If possible,
@@ -99,7 +99,8 @@ For convenience, some of these functions will always return a
This is the most common way to set the error indicator. The first argument
specifies the exception type; it is normally one of the standard exceptions,
- e.g. :c:data:`PyExc_RuntimeError`. You need not increment its reference count.
+ e.g. :c:data:`PyExc_RuntimeError`. You need not create a new
+ :term:`strong reference` to it (e.g. with :c:func:`Py_INCREF`).
The second argument is an error message; it is decoded from ``'utf-8'``.
@@ -147,14 +148,14 @@ For convenience, some of these functions will always return a
.. c:function:: PyObject* PyErr_SetFromErrno(PyObject *type)
- .. index:: single: strerror()
+ .. index:: single: strerror (C function)
This is a convenience function to raise an exception when a C library function
has returned an error and set the C variable :c:data:`errno`. It constructs a
tuple object whose first item is the integer :c:data:`errno` value and whose
- second item is the corresponding error message (gotten from :c:func:`strerror`),
+ second item is the corresponding error message (gotten from :c:func:`!strerror`),
and then calls ``PyErr_SetObject(type, object)``. On Unix, when the
- :c:data:`errno` value is :const:`EINTR`, indicating an interrupted system call,
+ :c:data:`errno` value is :c:macro:`!EINTR`, indicating an interrupted system call,
this calls :c:func:`PyErr_CheckSignals`, and if that set the error indicator,
leaves it set to that. The function always returns ``NULL``, so a wrapper
function around a system call can write ``return PyErr_SetFromErrno(type);``
@@ -166,7 +167,7 @@ For convenience, some of these functions will always return a
Similar to :c:func:`PyErr_SetFromErrno`, with the additional behavior that if
*filenameObject* is not ``NULL``, it is passed to the constructor of *type* as
a third parameter. In the case of :exc:`OSError` exception,
- this is used to define the :attr:`filename` attribute of the
+ this is used to define the :attr:`!filename` attribute of the
exception instance.
@@ -189,12 +190,12 @@ For convenience, some of these functions will always return a
.. c:function:: PyObject* PyErr_SetFromWindowsErr(int ierr)
This is a convenience function to raise :exc:`WindowsError`. If called with
- *ierr* of :c:data:`0`, the error code returned by a call to :c:func:`GetLastError`
- is used instead. It calls the Win32 function :c:func:`FormatMessage` to retrieve
- the Windows description of error code given by *ierr* or :c:func:`GetLastError`,
+ *ierr* of ``0``, the error code returned by a call to :c:func:`!GetLastError`
+ is used instead. It calls the Win32 function :c:func:`!FormatMessage` to retrieve
+ the Windows description of error code given by *ierr* or :c:func:`!GetLastError`,
then it constructs a tuple object whose first item is the *ierr* value and whose
second item is the corresponding error message (gotten from
- :c:func:`FormatMessage`), and then calls ``PyErr_SetObject(PyExc_WindowsError,
+ :c:func:`!FormatMessage`), and then calls ``PyErr_SetObject(PyExc_WindowsError,
object)``. This function always returns ``NULL``.
.. availability:: Windows.
@@ -210,17 +211,21 @@ For convenience, some of these functions will always return a
.. c:function:: PyObject* PyErr_SetFromWindowsErrWithFilename(int ierr, const char *filename)
- Similar to :c:func:`PyErr_SetFromWindowsErrWithFilenameObject`, but the
- filename is given as a C string. *filename* is decoded from the filesystem
- encoding (:func:`os.fsdecode`).
+ Similar to :c:func:`PyErr_SetFromWindowsErr`, with the additional behavior
+ that if *filename* is not ``NULL``, it is decoded from the filesystem
+ encoding (:func:`os.fsdecode`) and passed to the constructor of
+ :exc:`OSError` as a third parameter to be used to define the
+ :attr:`!filename` attribute of the exception instance.
.. availability:: Windows.
.. c:function:: PyObject* PyErr_SetExcFromWindowsErrWithFilenameObject(PyObject *type, int ierr, PyObject *filename)
- Similar to :c:func:`PyErr_SetFromWindowsErrWithFilenameObject`, with an
- additional parameter specifying the exception type to be raised.
+ Similar to :c:func:`PyErr_SetExcFromWindowsErr`, with the additional behavior
+ that if *filename* is not ``NULL``, it is passed to the constructor of
+ :exc:`OSError` as a third parameter to be used to define the
+ :attr:`!filename` attribute of the exception instance.
.. availability:: Windows.
@@ -359,7 +364,7 @@ an error value).
.. c:function:: int PyErr_ResourceWarning(PyObject *source, Py_ssize_t stack_level, const char *format, ...)
Function similar to :c:func:`PyErr_WarnFormat`, but *category* is
- :exc:`ResourceWarning` and it passes *source* to :func:`warnings.WarningMessage`.
+ :exc:`ResourceWarning` and it passes *source* to :class:`!warnings.WarningMessage`.
.. versionadded:: 3.6
@@ -370,7 +375,7 @@ Querying the error indicator
.. c:function:: PyObject* PyErr_Occurred()
Test whether the error indicator is set. If set, return the exception *type*
- (the first argument to the last call to one of the :c:func:`PyErr_Set\*`
+ (the first argument to the last call to one of the ``PyErr_Set*``
functions or to :c:func:`PyErr_Restore`). If not set, return ``NULL``. You do not
own a reference to the return value, so you do not need to :c:func:`Py_DECREF`
it.
@@ -451,7 +456,8 @@ Querying the error indicator
.. note::
- This function *does not* implicitly set the ``__traceback__``
+ This function *does not* implicitly set the
+ :attr:`~BaseException.__traceback__`
attribute on the exception value. If setting the traceback
appropriately is desired, the following additional snippet is needed::
@@ -543,8 +549,8 @@ Signal Handling
.. c:function:: int PyErr_CheckSignals()
.. index::
- module: signal
- single: SIGINT
+ pair: module; signal
+ single: SIGINT (C macro)
single: KeyboardInterrupt (built-in exception)
This function interacts with Python's signal handling.
@@ -567,18 +573,18 @@ Signal Handling
be interruptible by user requests (such as by pressing Ctrl-C).
.. note::
- The default Python signal handler for :const:`SIGINT` raises the
+ The default Python signal handler for :c:macro:`!SIGINT` raises the
:exc:`KeyboardInterrupt` exception.
.. c:function:: void PyErr_SetInterrupt()
.. index::
- module: signal
- single: SIGINT
+ pair: module; signal
+ single: SIGINT (C macro)
single: KeyboardInterrupt (built-in exception)
- Simulate the effect of a :const:`SIGINT` signal arriving.
+ Simulate the effect of a :c:macro:`!SIGINT` signal arriving.
This is equivalent to ``PyErr_SetInterruptEx(SIGINT)``.
.. note::
@@ -589,7 +595,7 @@ Signal Handling
.. c:function:: int PyErr_SetInterruptEx(int signum)
.. index::
- module: signal
+ pair: module; signal
single: KeyboardInterrupt (built-in exception)
Simulate the effect of a signal arriving. The next time
@@ -602,7 +608,7 @@ Signal Handling
to interrupt an operation).
If the given signal isn't handled by Python (it was set to
- :data:`signal.SIG_DFL` or :data:`signal.SIG_IGN`), it will be ignored.
+ :py:const:`signal.SIG_DFL` or :py:const:`signal.SIG_IGN`), it will be ignored.
If *signum* is outside of the allowed range of signal numbers, ``-1``
is returned. Otherwise, ``0`` is returned. The error indicator is
@@ -641,7 +647,7 @@ Exception Classes
This creates a class object derived from :exc:`Exception` (accessible in C as
:c:data:`PyExc_Exception`).
- The :attr:`__module__` attribute of the new class is set to the first part (up
+ The :attr:`!__module__` attribute of the new class is set to the first part (up
to the last dot) of the *name* argument, and the class name is set to the last
part (after the last dot). The *base* argument can be used to specify alternate
base classes; it can either be only one class or a tuple of classes. The *dict*
@@ -663,7 +669,8 @@ Exception Objects
.. c:function:: PyObject* PyException_GetTraceback(PyObject *ex)
Return the traceback associated with the exception as a new reference, as
- accessible from Python through :attr:`__traceback__`. If there is no
+ accessible from Python through the :attr:`~BaseException.__traceback__`
+ attribute. If there is no
traceback associated, this returns ``NULL``.
@@ -677,8 +684,8 @@ Exception Objects
Return the context (another exception instance during whose handling *ex* was
raised) associated with the exception as a new reference, as accessible from
- Python through :attr:`__context__`. If there is no context associated, this
- returns ``NULL``.
+ Python through the :attr:`~BaseException.__context__` attribute.
+ If there is no context associated, this returns ``NULL``.
.. c:function:: void PyException_SetContext(PyObject *ex, PyObject *ctx)
@@ -690,18 +697,20 @@ Exception Objects
.. c:function:: PyObject* PyException_GetCause(PyObject *ex)
- Return the cause (either an exception instance, or :const:`None`,
+ Return the cause (either an exception instance, or ``None``,
set by ``raise ... from ...``) associated with the exception as a new
- reference, as accessible from Python through :attr:`__cause__`.
+ reference, as accessible from Python through the
+ :attr:`~BaseException.__cause__` attribute.
.. c:function:: void PyException_SetCause(PyObject *ex, PyObject *cause)
Set the cause associated with the exception to *cause*. Use ``NULL`` to clear
it. There is no type check to make sure that *cause* is either an exception
- instance or :const:`None`. This steals a reference to *cause*.
+ instance or ``None``. This steals a reference to *cause*.
- :attr:`__suppress_context__` is implicitly set to ``True`` by this function.
+ The :attr:`~BaseException.__suppress_context__` attribute is implicitly set
+ to ``True`` by this function.
.. _unicodeexceptions:
@@ -788,8 +797,8 @@ because the :ref:`call protocol ` takes care of recursion handling.
Marks a point where a recursive C-level call is about to be performed.
- If :const:`USE_STACKCHECK` is defined, this function checks if the OS
- stack overflowed using :c:func:`PyOS_CheckStack`. In this is the case, it
+ If :c:macro:`!USE_STACKCHECK` is defined, this function checks if the OS
+ stack overflowed using :c:func:`PyOS_CheckStack`. If this is the case, it
sets a :exc:`MemoryError` and returns a nonzero value.
The function then checks if the recursion limit is reached. If this is the
@@ -801,7 +810,7 @@ because the :ref:`call protocol ` takes care of recursion handling.
depth limit.
.. versionchanged:: 3.9
- This function is now also available in the limited API.
+ This function is now also available in the :ref:`limited API `.
.. c:function:: void Py_LeaveRecursiveCall(void)
@@ -809,7 +818,7 @@ because the :ref:`call protocol ` takes care of recursion handling.
*successful* invocation of :c:func:`Py_EnterRecursiveCall`.
.. versionchanged:: 3.9
- This function is now also available in the limited API.
+ This function is now also available in the :ref:`limited API `.
Properly implementing :c:member:`~PyTypeObject.tp_repr` for container types requires
special recursion handling. In addition to protecting the stack,
@@ -848,72 +857,72 @@ Standard Exceptions
All standard Python exceptions are available as global variables whose names are
``PyExc_`` followed by the Python exception name. These have the type
-:c:type:`PyObject*`; they are all class objects. For completeness, here are all
+:c:expr:`PyObject*`; they are all class objects. For completeness, here are all
the variables:
.. index::
- single: PyExc_BaseException
- single: PyExc_Exception
- single: PyExc_ArithmeticError
- single: PyExc_AssertionError
- single: PyExc_AttributeError
- single: PyExc_BlockingIOError
- single: PyExc_BrokenPipeError
- single: PyExc_BufferError
- single: PyExc_ChildProcessError
- single: PyExc_ConnectionAbortedError
- single: PyExc_ConnectionError
- single: PyExc_ConnectionRefusedError
- single: PyExc_ConnectionResetError
- single: PyExc_EOFError
- single: PyExc_FileExistsError
- single: PyExc_FileNotFoundError
- single: PyExc_FloatingPointError
- single: PyExc_GeneratorExit
- single: PyExc_ImportError
- single: PyExc_IndentationError
- single: PyExc_IndexError
- single: PyExc_InterruptedError
- single: PyExc_IsADirectoryError
- single: PyExc_KeyError
- single: PyExc_KeyboardInterrupt
- single: PyExc_LookupError
- single: PyExc_MemoryError
- single: PyExc_ModuleNotFoundError
- single: PyExc_NameError
- single: PyExc_NotADirectoryError
- single: PyExc_NotImplementedError
- single: PyExc_OSError
- single: PyExc_OverflowError
- single: PyExc_PermissionError
- single: PyExc_ProcessLookupError
- single: PyExc_RecursionError
- single: PyExc_ReferenceError
- single: PyExc_RuntimeError
- single: PyExc_StopAsyncIteration
- single: PyExc_StopIteration
- single: PyExc_SyntaxError
- single: PyExc_SystemError
- single: PyExc_SystemExit
- single: PyExc_TabError
- single: PyExc_TimeoutError
- single: PyExc_TypeError
- single: PyExc_UnboundLocalError
- single: PyExc_UnicodeDecodeError
- single: PyExc_UnicodeEncodeError
- single: PyExc_UnicodeError
- single: PyExc_UnicodeTranslateError
- single: PyExc_ValueError
- single: PyExc_ZeroDivisionError
+ single: PyExc_BaseException (C var)
+ single: PyExc_Exception (C var)
+ single: PyExc_ArithmeticError (C var)
+ single: PyExc_AssertionError (C var)
+ single: PyExc_AttributeError (C var)
+ single: PyExc_BlockingIOError (C var)
+ single: PyExc_BrokenPipeError (C var)
+ single: PyExc_BufferError (C var)
+ single: PyExc_ChildProcessError (C var)
+ single: PyExc_ConnectionAbortedError (C var)
+ single: PyExc_ConnectionError (C var)
+ single: PyExc_ConnectionRefusedError (C var)
+ single: PyExc_ConnectionResetError (C var)
+ single: PyExc_EOFError (C var)
+ single: PyExc_FileExistsError (C var)
+ single: PyExc_FileNotFoundError (C var)
+ single: PyExc_FloatingPointError (C var)
+ single: PyExc_GeneratorExit (C var)
+ single: PyExc_ImportError (C var)
+ single: PyExc_IndentationError (C var)
+ single: PyExc_IndexError (C var)
+ single: PyExc_InterruptedError (C var)
+ single: PyExc_IsADirectoryError (C var)
+ single: PyExc_KeyError (C var)
+ single: PyExc_KeyboardInterrupt (C var)
+ single: PyExc_LookupError (C var)
+ single: PyExc_MemoryError (C var)
+ single: PyExc_ModuleNotFoundError (C var)
+ single: PyExc_NameError (C var)
+ single: PyExc_NotADirectoryError (C var)
+ single: PyExc_NotImplementedError (C var)
+ single: PyExc_OSError (C var)
+ single: PyExc_OverflowError (C var)
+ single: PyExc_PermissionError (C var)
+ single: PyExc_ProcessLookupError (C var)
+ single: PyExc_RecursionError (C var)
+ single: PyExc_ReferenceError (C var)
+ single: PyExc_RuntimeError (C var)
+ single: PyExc_StopAsyncIteration (C var)
+ single: PyExc_StopIteration (C var)
+ single: PyExc_SyntaxError (C var)
+ single: PyExc_SystemError (C var)
+ single: PyExc_SystemExit (C var)
+ single: PyExc_TabError (C var)
+ single: PyExc_TimeoutError (C var)
+ single: PyExc_TypeError (C var)
+ single: PyExc_UnboundLocalError (C var)
+ single: PyExc_UnicodeDecodeError (C var)
+ single: PyExc_UnicodeEncodeError (C var)
+ single: PyExc_UnicodeError (C var)
+ single: PyExc_UnicodeTranslateError (C var)
+ single: PyExc_ValueError (C var)
+ single: PyExc_ZeroDivisionError (C var)
+-----------------------------------------+---------------------------------+----------+
| C Name | Python Name | Notes |
+=========================================+=================================+==========+
-| :c:data:`PyExc_BaseException` | :exc:`BaseException` | \(1) |
+| :c:data:`PyExc_BaseException` | :exc:`BaseException` | [1]_ |
+-----------------------------------------+---------------------------------+----------+
-| :c:data:`PyExc_Exception` | :exc:`Exception` | \(1) |
+| :c:data:`PyExc_Exception` | :exc:`Exception` | [1]_ |
+-----------------------------------------+---------------------------------+----------+
-| :c:data:`PyExc_ArithmeticError` | :exc:`ArithmeticError` | \(1) |
+| :c:data:`PyExc_ArithmeticError` | :exc:`ArithmeticError` | [1]_ |
+-----------------------------------------+---------------------------------+----------+
| :c:data:`PyExc_AssertionError` | :exc:`AssertionError` | |
+-----------------------------------------+---------------------------------+----------+
@@ -959,7 +968,7 @@ the variables:
+-----------------------------------------+---------------------------------+----------+
| :c:data:`PyExc_KeyboardInterrupt` | :exc:`KeyboardInterrupt` | |
+-----------------------------------------+---------------------------------+----------+
-| :c:data:`PyExc_LookupError` | :exc:`LookupError` | \(1) |
+| :c:data:`PyExc_LookupError` | :exc:`LookupError` | [1]_ |
+-----------------------------------------+---------------------------------+----------+
| :c:data:`PyExc_MemoryError` | :exc:`MemoryError` | |
+-----------------------------------------+---------------------------------+----------+
@@ -971,7 +980,7 @@ the variables:
+-----------------------------------------+---------------------------------+----------+
| :c:data:`PyExc_NotImplementedError` | :exc:`NotImplementedError` | |
+-----------------------------------------+---------------------------------+----------+
-| :c:data:`PyExc_OSError` | :exc:`OSError` | \(1) |
+| :c:data:`PyExc_OSError` | :exc:`OSError` | [1]_ |
+-----------------------------------------+---------------------------------+----------+
| :c:data:`PyExc_OverflowError` | :exc:`OverflowError` | |
+-----------------------------------------+---------------------------------+----------+
@@ -981,7 +990,7 @@ the variables:
+-----------------------------------------+---------------------------------+----------+
| :c:data:`PyExc_RecursionError` | :exc:`RecursionError` | |
+-----------------------------------------+---------------------------------+----------+
-| :c:data:`PyExc_ReferenceError` | :exc:`ReferenceError` | \(2) |
+| :c:data:`PyExc_ReferenceError` | :exc:`ReferenceError` | |
+-----------------------------------------+---------------------------------+----------+
| :c:data:`PyExc_RuntimeError` | :exc:`RuntimeError` | |
+-----------------------------------------+---------------------------------+----------+
@@ -1035,18 +1044,18 @@ the variables:
These are compatibility aliases to :c:data:`PyExc_OSError`:
.. index::
- single: PyExc_EnvironmentError
- single: PyExc_IOError
- single: PyExc_WindowsError
+ single: PyExc_EnvironmentError (C var)
+ single: PyExc_IOError (C var)
+ single: PyExc_WindowsError (C var)
+-------------------------------------+----------+
| C Name | Notes |
+=====================================+==========+
-| :c:data:`PyExc_EnvironmentError` | |
+| :c:data:`!PyExc_EnvironmentError` | |
+-------------------------------------+----------+
-| :c:data:`PyExc_IOError` | |
+| :c:data:`!PyExc_IOError` | |
+-------------------------------------+----------+
-| :c:data:`PyExc_WindowsError` | \(3) |
+| :c:data:`!PyExc_WindowsError` | [2]_ |
+-------------------------------------+----------+
.. versionchanged:: 3.3
@@ -1054,10 +1063,10 @@ These are compatibility aliases to :c:data:`PyExc_OSError`:
Notes:
-(1)
+.. [1]
This is a base class for other standard exceptions.
-(2)
+.. [2]
Only defined on Windows; protect code that uses this by testing that the
preprocessor macro ``MS_WINDOWS`` is defined.
@@ -1068,26 +1077,26 @@ Standard Warning Categories
All standard Python warning categories are available as global variables whose
names are ``PyExc_`` followed by the Python exception name. These have the type
-:c:type:`PyObject*`; they are all class objects. For completeness, here are all
+:c:expr:`PyObject*`; they are all class objects. For completeness, here are all
the variables:
.. index::
- single: PyExc_Warning
- single: PyExc_BytesWarning
- single: PyExc_DeprecationWarning
- single: PyExc_FutureWarning
- single: PyExc_ImportWarning
- single: PyExc_PendingDeprecationWarning
- single: PyExc_ResourceWarning
- single: PyExc_RuntimeWarning
- single: PyExc_SyntaxWarning
- single: PyExc_UnicodeWarning
- single: PyExc_UserWarning
+ single: PyExc_Warning (C var)
+ single: PyExc_BytesWarning (C var)
+ single: PyExc_DeprecationWarning (C var)
+ single: PyExc_FutureWarning (C var)
+ single: PyExc_ImportWarning (C var)
+ single: PyExc_PendingDeprecationWarning (C var)
+ single: PyExc_ResourceWarning (C var)
+ single: PyExc_RuntimeWarning (C var)
+ single: PyExc_SyntaxWarning (C var)
+ single: PyExc_UnicodeWarning (C var)
+ single: PyExc_UserWarning (C var)
+------------------------------------------+---------------------------------+----------+
| C Name | Python Name | Notes |
+==========================================+=================================+==========+
-| :c:data:`PyExc_Warning` | :exc:`Warning` | \(1) |
+| :c:data:`PyExc_Warning` | :exc:`Warning` | [3]_ |
+------------------------------------------+---------------------------------+----------+
| :c:data:`PyExc_BytesWarning` | :exc:`BytesWarning` | |
+------------------------------------------+---------------------------------+----------+
@@ -1115,5 +1124,5 @@ the variables:
Notes:
-(1)
+.. [3]
This is a base class for other standard warning categories.
diff --git a/Doc/c-api/file.rst b/Doc/c-api/file.rst
index ed3735aa83608a..e9019a0d500f7e 100644
--- a/Doc/c-api/file.rst
+++ b/Doc/c-api/file.rst
@@ -5,10 +5,10 @@
File Objects
------------
-.. index:: object: file
+.. index:: pair: object; file
These APIs are a minimal emulation of the Python 2 C API for built-in file
-objects, which used to rely on the buffered I/O (:c:type:`FILE*`) support
+objects, which used to rely on the buffered I/O (:c:expr:`FILE*`) support
from the C standard library. In Python 3, files and streams use the new
:mod:`io` module, which defines several layers over the low-level unbuffered
I/O of the operating system. The functions described below are
@@ -38,7 +38,7 @@ the :mod:`io` APIs instead.
.. c:function:: int PyObject_AsFileDescriptor(PyObject *p)
- Return the file descriptor associated with *p* as an :c:type:`int`. If the
+ Return the file descriptor associated with *p* as an :c:expr:`int`. If the
object is an integer, its value is returned. If not, the
object's :meth:`~io.IOBase.fileno` method is called if it exists; the
method must return an integer, which is returned as the file descriptor
@@ -65,8 +65,14 @@ the :mod:`io` APIs instead.
Overrides the normal behavior of :func:`io.open_code` to pass its parameter
through the provided handler.
- The handler is a function of type :c:type:`PyObject *(\*)(PyObject *path,
- void *userData)`, where *path* is guaranteed to be :c:type:`PyUnicodeObject`.
+ The *handler* is a function of type:
+
+ .. c:namespace:: NULL
+ .. c:type:: PyObject * (*Py_OpenCodeHookFunction)(PyObject *, void *)
+
+ Equivalent of :c:expr:`PyObject *(\*)(PyObject *path,
+ void *userData)`, where *path* is guaranteed to be
+ :c:type:`PyUnicodeObject`.
The *userData* pointer is passed into the hook function. Since hook
functions may be called from different runtimes, this pointer should not
@@ -90,10 +96,10 @@ the :mod:`io` APIs instead.
.. c:function:: int PyFile_WriteObject(PyObject *obj, PyObject *p, int flags)
- .. index:: single: Py_PRINT_RAW
+ .. index:: single: Py_PRINT_RAW (C macro)
Write object *obj* to file object *p*. The only supported flag for *flags* is
- :const:`Py_PRINT_RAW`; if given, the :func:`str` of the object is written
+ :c:macro:`Py_PRINT_RAW`; if given, the :func:`str` of the object is written
instead of the :func:`repr`. Return ``0`` on success or ``-1`` on failure; the
appropriate exception will be set.
diff --git a/Doc/c-api/float.rst b/Doc/c-api/float.rst
index b306caf74b7c81..4f6ac0d8175c6b 100644
--- a/Doc/c-api/float.rst
+++ b/Doc/c-api/float.rst
@@ -3,9 +3,9 @@
.. _floatobjects:
Floating Point Objects
-----------------------
+======================
-.. index:: object: floating point
+.. index:: pair: object; floating point
.. c:type:: PyFloatObject
@@ -44,20 +44,20 @@ Floating Point Objects
.. c:function:: double PyFloat_AsDouble(PyObject *pyfloat)
- Return a C :c:type:`double` representation of the contents of *pyfloat*. If
- *pyfloat* is not a Python floating point object but has a :meth:`__float__`
+ Return a C :c:expr:`double` representation of the contents of *pyfloat*. If
+ *pyfloat* is not a Python floating point object but has a :meth:`~object.__float__`
method, this method will first be called to convert *pyfloat* into a float.
- If ``__float__()`` is not defined then it falls back to :meth:`__index__`.
+ If :meth:`!__float__` is not defined then it falls back to :meth:`~object.__index__`.
This method returns ``-1.0`` upon failure, so one should call
:c:func:`PyErr_Occurred` to check for errors.
.. versionchanged:: 3.8
- Use :meth:`__index__` if available.
+ Use :meth:`~object.__index__` if available.
.. c:function:: double PyFloat_AS_DOUBLE(PyObject *pyfloat)
- Return a C :c:type:`double` representation of the contents of *pyfloat*, but
+ Return a C :c:expr:`double` representation of the contents of *pyfloat*, but
without error checking.
@@ -70,21 +70,21 @@ Floating Point Objects
.. c:function:: double PyFloat_GetMax()
- Return the maximum representable finite float *DBL_MAX* as C :c:type:`double`.
+ Return the maximum representable finite float *DBL_MAX* as C :c:expr:`double`.
.. c:function:: double PyFloat_GetMin()
- Return the minimum normalized positive float *DBL_MIN* as C :c:type:`double`.
+ Return the minimum normalized positive float *DBL_MIN* as C :c:expr:`double`.
Pack and Unpack functions
-=========================
+-------------------------
The pack and unpack functions provide an efficient platform-independent way to
store floating-point values as byte strings. The Pack routines produce a bytes
-string from a C :c:type:`double`, and the Unpack routines produce a C
-:c:type:`double` from such a bytes string. The suffix (2, 4 or 8) specifies the
+string from a C :c:expr:`double`, and the Unpack routines produce a C
+:c:expr:`double` from such a bytes string. The suffix (2, 4 or 8) specifies the
number of bytes in the bytes string.
On platforms that appear to use IEEE 754 formats these functions work by
@@ -104,12 +104,12 @@ happens in such cases is partly accidental (alas).
.. versionadded:: 3.11
Pack functions
---------------
+^^^^^^^^^^^^^^
The pack routines write 2, 4 or 8 bytes, starting at *p*. *le* is an
-:c:type:`int` argument, non-zero if you want the bytes string in little-endian
+:c:expr:`int` argument, non-zero if you want the bytes string in little-endian
format (exponent last, at ``p+1``, ``p+3``, or ``p+6`` ``p+7``), zero if you
-want big-endian format (exponent first, at *p*). The :c:data:`PY_BIG_ENDIAN`
+want big-endian format (exponent first, at *p*). The :c:macro:`PY_BIG_ENDIAN`
constant can be used to use the native endian: it is equal to ``1`` on big
endian processor, or ``0`` on little endian processor.
@@ -135,12 +135,12 @@ There are two problems on non-IEEE platforms:
Unpack functions
-----------------
+^^^^^^^^^^^^^^^^
The unpack routines read 2, 4 or 8 bytes, starting at *p*. *le* is an
-:c:type:`int` argument, non-zero if the bytes string is in little-endian format
+:c:expr:`int` argument, non-zero if the bytes string is in little-endian format
(exponent last, at ``p+1``, ``p+3`` or ``p+6`` and ``p+7``), zero if big-endian
-(exponent first, at *p*). The :c:data:`PY_BIG_ENDIAN` constant can be used to
+(exponent first, at *p*). The :c:macro:`PY_BIG_ENDIAN` constant can be used to
use the native endian: it is equal to ``1`` on big endian processor, or ``0``
on little endian processor.
diff --git a/Doc/c-api/frame.rst b/Doc/c-api/frame.rst
index 46ce700abf1474..91526275d07c58 100644
--- a/Doc/c-api/frame.rst
+++ b/Doc/c-api/frame.rst
@@ -19,6 +19,24 @@ can be used to get a frame object.
See also :ref:`Reflection `.
+.. c:var:: PyTypeObject PyFrame_Type
+
+ The type of frame objects.
+ It is the same object as :py:class:`types.FrameType` in the Python layer.
+
+ .. versionchanged:: 3.11
+
+ Previously, this type was only available after including
+ ````.
+
+.. c:function:: int PyFrame_Check(PyObject *obj)
+
+ Return non-zero if *obj* is a frame object.
+
+ .. versionchanged:: 3.11
+
+ Previously, this function was only available after including
+ ````.
.. c:function:: PyFrameObject* PyFrame_GetBack(PyFrameObject *frame)
@@ -32,7 +50,7 @@ See also :ref:`Reflection `.
.. c:function:: PyObject* PyFrame_GetBuiltins(PyFrameObject *frame)
- Get the *frame*'s ``f_builtins`` attribute.
+ Get the *frame*'s :attr:`~frame.f_builtins` attribute.
Return a :term:`strong reference`. The result cannot be ``NULL``.
@@ -63,7 +81,7 @@ See also :ref:`Reflection `.
.. c:function:: PyObject* PyFrame_GetGlobals(PyFrameObject *frame)
- Get the *frame*'s ``f_globals`` attribute.
+ Get the *frame*'s :attr:`~frame.f_globals` attribute.
Return a :term:`strong reference`. The result cannot be ``NULL``.
@@ -72,7 +90,7 @@ See also :ref:`Reflection `.
.. c:function:: int PyFrame_GetLasti(PyFrameObject *frame)
- Get the *frame*'s ``f_lasti`` attribute.
+ Get the *frame*'s :attr:`~frame.f_lasti` attribute.
Returns -1 if ``frame.f_lasti`` is ``None``.
@@ -81,7 +99,7 @@ See also :ref:`Reflection `.
.. c:function:: PyObject* PyFrame_GetLocals(PyFrameObject *frame)
- Get the *frame*'s ``f_locals`` attribute (:class:`dict`).
+ Get the *frame*'s :attr:`~frame.f_locals` attribute (:class:`dict`).
Return a :term:`strong reference`.
diff --git a/Doc/c-api/function.rst b/Doc/c-api/function.rst
index 56c18396d3221d..805c84607bd839 100644
--- a/Doc/c-api/function.rst
+++ b/Doc/c-api/function.rst
@@ -5,7 +5,7 @@
Function Objects
----------------
-.. index:: object: function
+.. index:: pair: object; function
There are a few functions specific to Python functions.
@@ -34,18 +34,20 @@ There are a few functions specific to Python functions.
Return a new function object associated with the code object *code*. *globals*
must be a dictionary with the global variables accessible to the function.
- The function's docstring and name are retrieved from the code object. *__module__*
+ The function's docstring and name are retrieved from the code object.
+ :attr:`~function.__module__`
is retrieved from *globals*. The argument defaults, annotations and closure are
- set to ``NULL``. *__qualname__* is set to the same value as the code object's
- ``co_qualname`` field.
+ set to ``NULL``. :attr:`~function.__qualname__` is set to the same value as
+ the code object's :attr:`~codeobject.co_qualname` field.
.. c:function:: PyObject* PyFunction_NewWithQualName(PyObject *code, PyObject *globals, PyObject *qualname)
As :c:func:`PyFunction_New`, but also allows setting the function object's
- ``__qualname__`` attribute. *qualname* should be a unicode object or ``NULL``;
- if ``NULL``, the ``__qualname__`` attribute is set to the same value as the
- code object's ``co_qualname`` field.
+ :attr:`~function.__qualname__` attribute.
+ *qualname* should be a unicode object or ``NULL``;
+ if ``NULL``, the :attr:`!__qualname__` attribute is set to the same value as
+ the code object's :attr:`~codeobject.co_qualname` field.
.. versionadded:: 3.3
@@ -62,11 +64,12 @@ There are a few functions specific to Python functions.
.. c:function:: PyObject* PyFunction_GetModule(PyObject *op)
- Return a :term:`borrowed reference` to the *__module__* attribute of the
- function object *op*. It can be *NULL*.
+ Return a :term:`borrowed reference` to the :attr:`~function.__module__`
+ attribute of the :ref:`function object ` *op*.
+ It can be *NULL*.
- This is normally a string containing the module name, but can be set to any
- other object by Python code.
+ This is normally a :class:`string ` containing the module name,
+ but can be set to any other object by Python code.
.. c:function:: PyObject* PyFunction_GetDefaults(PyObject *op)
diff --git a/Doc/c-api/gcsupport.rst b/Doc/c-api/gcsupport.rst
index 8c90d1e8991c10..6bdbb008f8e74a 100644
--- a/Doc/c-api/gcsupport.rst
+++ b/Doc/c-api/gcsupport.rst
@@ -13,22 +13,20 @@ or strings), do not need to provide any explicit support for garbage
collection.
To create a container type, the :c:member:`~PyTypeObject.tp_flags` field of the type object must
-include the :const:`Py_TPFLAGS_HAVE_GC` and provide an implementation of the
+include the :c:macro:`Py_TPFLAGS_HAVE_GC` and provide an implementation of the
:c:member:`~PyTypeObject.tp_traverse` handler. If instances of the type are mutable, a
:c:member:`~PyTypeObject.tp_clear` implementation must also be provided.
-.. data:: Py_TPFLAGS_HAVE_GC
- :noindex:
-
+:c:macro:`Py_TPFLAGS_HAVE_GC`
Objects with a type with this flag set must conform with the rules
documented here. For convenience these objects will be referred to as
container objects.
Constructors for container types must conform to two rules:
-#. The memory for the object must be allocated using :c:func:`PyObject_GC_New`
- or :c:func:`PyObject_GC_NewVar`.
+#. The memory for the object must be allocated using :c:macro:`PyObject_GC_New`
+ or :c:macro:`PyObject_GC_NewVar`.
#. Once all the fields which may contain references to other containers are
initialized, it must call :c:func:`PyObject_GC_Track`.
@@ -52,23 +50,23 @@ rules:
:c:member:`~PyTypeObject.tp_flags`, :c:member:`~PyTypeObject.tp_traverse`
and :c:member:`~PyTypeObject.tp_clear` fields if the type inherits from a
class that implements the garbage collector protocol and the child class
- does *not* include the :const:`Py_TPFLAGS_HAVE_GC` flag.
+ does *not* include the :c:macro:`Py_TPFLAGS_HAVE_GC` flag.
-.. c:function:: TYPE* PyObject_GC_New(TYPE, PyTypeObject *type)
+.. c:macro:: PyObject_GC_New(TYPE, typeobj)
- Analogous to :c:func:`PyObject_New` but for container objects with the
- :const:`Py_TPFLAGS_HAVE_GC` flag set.
+ Analogous to :c:macro:`PyObject_New` but for container objects with the
+ :c:macro:`Py_TPFLAGS_HAVE_GC` flag set.
-.. c:function:: TYPE* PyObject_GC_NewVar(TYPE, PyTypeObject *type, Py_ssize_t size)
+.. c:macro:: PyObject_GC_NewVar(TYPE, typeobj, size)
- Analogous to :c:func:`PyObject_NewVar` but for container objects with the
- :const:`Py_TPFLAGS_HAVE_GC` flag set.
+ Analogous to :c:macro:`PyObject_NewVar` but for container objects with the
+ :c:macro:`Py_TPFLAGS_HAVE_GC` flag set.
.. c:function:: TYPE* PyObject_GC_Resize(TYPE, PyVarObject *op, Py_ssize_t newsize)
- Resize an object allocated by :c:func:`PyObject_NewVar`. Returns the
+ Resize an object allocated by :c:macro:`PyObject_NewVar`. Returns the
resized object or ``NULL`` on failure. *op* must not be tracked by the collector yet.
@@ -111,8 +109,8 @@ rules:
.. c:function:: void PyObject_GC_Del(void *op)
- Releases memory allocated to an object using :c:func:`PyObject_GC_New` or
- :c:func:`PyObject_GC_NewVar`.
+ Releases memory allocated to an object using :c:macro:`PyObject_GC_New` or
+ :c:macro:`PyObject_GC_NewVar`.
.. c:function:: void PyObject_GC_UnTrack(void *op)
@@ -126,7 +124,7 @@ rules:
.. versionchanged:: 3.8
- The :c:func:`_PyObject_GC_TRACK` and :c:func:`_PyObject_GC_UNTRACK` macros
+ The :c:func:`!_PyObject_GC_TRACK` and :c:func:`!_PyObject_GC_UNTRACK` macros
have been removed from the public C API.
The :c:member:`~PyTypeObject.tp_traverse` handler accepts a function parameter of this type:
diff --git a/Doc/c-api/import.rst b/Doc/c-api/import.rst
index 5e2333a74ce648..61c523285e6be1 100644
--- a/Doc/c-api/import.rst
+++ b/Doc/c-api/import.rst
@@ -13,20 +13,8 @@ Importing Modules
single: __all__ (package variable)
single: modules (in module sys)
- This is a simplified interface to :c:func:`PyImport_ImportModuleEx` below,
- leaving the *globals* and *locals* arguments set to ``NULL`` and *level* set
- to 0. When the *name*
- argument contains a dot (when it specifies a submodule of a package), the
- *fromlist* argument is set to the list ``['*']`` so that the return value is the
- named module rather than the top-level package containing it as would otherwise
- be the case. (Unfortunately, this has an additional side effect when *name* in
- fact specifies a subpackage instead of a submodule: the submodules specified in
- the package's ``__all__`` variable are loaded.) Return a new reference to the
- imported module, or ``NULL`` with an exception set on failure. A failing
- import of a module doesn't leave the module in :data:`sys.modules`.
-
- This function always uses absolute imports.
-
+ This is a wrapper around :c:func:`PyImport_Import()` which takes a
+ :c:expr:`const char *` as an argument instead of a :c:expr:`PyObject *`.
.. c:function:: PyObject* PyImport_ImportModuleNoBlock(const char *name)
@@ -41,7 +29,7 @@ Importing Modules
.. c:function:: PyObject* PyImport_ImportModuleEx(const char *name, PyObject *globals, PyObject *locals, PyObject *fromlist)
- .. index:: builtin: __import__
+ .. index:: pair: built-in function; __import__
Import a module. This is best described by referring to the built-in Python
function :func:`__import__`.
@@ -120,25 +108,25 @@ Importing Modules
.. c:function:: PyObject* PyImport_ExecCodeModule(const char *name, PyObject *co)
- .. index:: builtin: compile
+ .. index:: pair: built-in function; compile
Given a module name (possibly of the form ``package.module``) and a code object
read from a Python bytecode file or obtained from the built-in function
:func:`compile`, load the module. Return a new reference to the module object,
or ``NULL`` with an exception set if an error occurred. *name*
- is removed from :attr:`sys.modules` in error cases, even if *name* was already
- in :attr:`sys.modules` on entry to :c:func:`PyImport_ExecCodeModule`. Leaving
- incompletely initialized modules in :attr:`sys.modules` is dangerous, as imports of
+ is removed from :data:`sys.modules` in error cases, even if *name* was already
+ in :data:`sys.modules` on entry to :c:func:`PyImport_ExecCodeModule`. Leaving
+ incompletely initialized modules in :data:`sys.modules` is dangerous, as imports of
such modules have no way to know that the module object is an unknown (and
probably damaged with respect to the module author's intents) state.
The module's :attr:`__spec__` and :attr:`__loader__` will be set, if
not set already, with the appropriate values. The spec's loader will
be set to the module's ``__loader__`` (if set) and to an instance of
- :class:`SourceFileLoader` otherwise.
+ :class:`~importlib.machinery.SourceFileLoader` otherwise.
The module's :attr:`__file__` attribute will be set to the code object's
- :c:member:`co_filename`. If applicable, :attr:`__cached__` will also
+ :attr:`~codeobject.co_filename`. If applicable, :attr:`__cached__` will also
be set.
This function will reload the module if it was already imported. See
@@ -214,7 +202,7 @@ Importing Modules
.. c:function:: PyObject* PyImport_GetImporter(PyObject *path)
- Return a finder object for a :data:`sys.path`/:attr:`pkg.__path__` item
+ Return a finder object for a :data:`sys.path`/:attr:`!pkg.__path__` item
*path*, possibly by fetching it from the :data:`sys.path_importer_cache`
dict. If it wasn't yet cached, traverse :data:`sys.path_hooks` until a hook
is found that can handle the path item. Return ``None`` if no hook could;
@@ -243,7 +231,7 @@ Importing Modules
UTF-8 encoded string instead of a Unicode object.
-.. c:type:: struct _frozen
+.. c:struct:: _frozen
.. index:: single: freeze utility
@@ -265,7 +253,7 @@ Importing Modules
.. c:var:: const struct _frozen* PyImport_FrozenModules
- This pointer is initialized to point to an array of :c:type:`struct _frozen`
+ This pointer is initialized to point to an array of :c:struct:`_frozen`
records, terminated by one whose members are all ``NULL`` or zero. When a frozen
module is imported, it is searched in this table. Third-party code could play
tricks with this to provide a dynamically created collection of frozen modules.
@@ -281,25 +269,27 @@ Importing Modules
:c:func:`Py_Initialize`.
-.. c:type:: struct _inittab
+.. c:struct:: _inittab
- Structure describing a single entry in the list of built-in modules. Each of
- these structures gives the name and initialization function for a module built
- into the interpreter. The name is an ASCII encoded string. Programs which
+ Structure describing a single entry in the list of built-in modules.
+ Programs which
embed Python may use an array of these structures in conjunction with
:c:func:`PyImport_ExtendInittab` to provide additional built-in modules.
- The structure is defined in :file:`Include/import.h` as::
+ The structure consists of two members:
- struct _inittab {
- const char *name; /* ASCII encoded string */
- PyObject* (*initfunc)(void);
- };
+ .. c:member:: const char *name
+
+ The module name, as an ASCII encoded string.
+
+ .. c: member:: PyObject* (*initfunc)(void)
+
+ Initialization function for a module built into the interpreter.
.. c:function:: int PyImport_ExtendInittab(struct _inittab *newtab)
Add a collection of modules to the table of built-in modules. The *newtab*
- array must end with a sentinel entry which contains ``NULL`` for the :attr:`name`
+ array must end with a sentinel entry which contains ``NULL`` for the :c:member:`~_inittab.name`
field; failure to provide the sentinel value can result in a memory fault.
Returns ``0`` on success or ``-1`` if insufficient memory could be allocated to
extend the internal table. In the event of failure, no modules are added to the
diff --git a/Doc/c-api/init.rst b/Doc/c-api/init.rst
index d4954958f855f5..86e6ec3f3cbfce 100644
--- a/Doc/c-api/init.rst
+++ b/Doc/c-api/init.rst
@@ -25,7 +25,7 @@ The following functions can be safely called before Python is initialized:
* :c:func:`PyImport_AppendInittab`
* :c:func:`PyImport_ExtendInittab`
- * :c:func:`PyInitFrozenExtensions`
+ * :c:func:`!PyInitFrozenExtensions`
* :c:func:`PyMem_SetAllocator`
* :c:func:`PyMem_SetupDebugHooks`
* :c:func:`PyObject_SetArenaAllocator`
@@ -122,7 +122,7 @@ to 1 and ``-bb`` sets :c:data:`Py_BytesWarningFlag` to 2.
.. c:var:: int Py_IgnoreEnvironmentFlag
- Ignore all :envvar:`PYTHON*` environment variables, e.g.
+ Ignore all :envvar:`!PYTHON*` environment variables, e.g.
:envvar:`PYTHONPATH` and :envvar:`PYTHONHOME`, that might be set.
Set by the :option:`-E` and :option:`-I` options.
@@ -165,7 +165,7 @@ to 1 and ``-bb`` sets :c:data:`Py_BytesWarningFlag` to 2.
.. c:var:: int Py_LegacyWindowsStdioFlag
If the flag is non-zero, use :class:`io.FileIO` instead of
- :class:`WindowsConsoleIO` for :mod:`sys` standard streams.
+ :class:`!io._WindowsConsoleIO` for :mod:`sys` standard streams.
Set to ``1`` if the :envvar:`PYTHONLEGACYWINDOWSSTDIO` environment
variable is set to a non-empty string.
@@ -233,13 +233,13 @@ Initializing and finalizing the interpreter
single: PyEval_InitThreads()
single: modules (in module sys)
single: path (in module sys)
- module: builtins
- module: __main__
- module: sys
+ pair: module; builtins
+ pair: module; __main__
+ pair: module; sys
triple: module; search; path
- single: PySys_SetArgv()
- single: PySys_SetArgvEx()
- single: Py_FinalizeEx()
+ single: PySys_SetArgv (C function)
+ single: PySys_SetArgvEx (C function)
+ single: Py_FinalizeEx (C function)
Initialize the Python interpreter. In an application embedding Python,
this should be called before using any other Python/C API functions; see
@@ -292,7 +292,7 @@ Initializing and finalizing the interpreter
the application.
**Bugs and caveats:** The destruction of modules and objects in modules is done
- in random order; this may cause destructors (:meth:`__del__` methods) to fail
+ in random order; this may cause destructors (:meth:`~object.__del__` methods) to fail
when they depend on other objects (even functions) or modules. Dynamically
loaded extension modules loaded by Python are not unloaded. Small amounts of
memory allocated by the Python interpreter may not be freed (if you find a leak,
@@ -376,12 +376,12 @@ Process-wide parameters
interpreter will change the contents of this storage.
Use :c:func:`Py_DecodeLocale` to decode a bytes string to get a
- :c:type:`wchar_*` string.
+ :c:expr:`wchar_*` string.
.. deprecated:: 3.11
-.. c:function:: wchar* Py_GetProgramName()
+.. c:function:: wchar_t* Py_GetProgramName()
.. index:: single: Py_SetProgramName()
@@ -404,7 +404,7 @@ Process-wide parameters
program name is ``'/usr/local/bin/python'``, the prefix is ``'/usr/local'``. The
returned string points into static storage; the caller should not modify its
value. This corresponds to the :makevar:`prefix` variable in the top-level
- :file:`Makefile` and the ``--prefix`` argument to the :program:`configure`
+ :file:`Makefile` and the :option:`--prefix` argument to the :program:`configure`
script at build time. The value is available to Python code as ``sys.prefix``.
It is only useful on Unix. See also the next function.
@@ -527,7 +527,7 @@ Process-wide parameters
if required after calling :c:func:`Py_Initialize`.
Use :c:func:`Py_DecodeLocale` to decode a bytes string to get a
- :c:type:`wchar_*` string.
+ :c:expr:`wchar_*` string.
The path argument is copied internally, so the caller may free it after the
call completes.
@@ -642,7 +642,7 @@ Process-wide parameters
directory (``"."``).
Use :c:func:`Py_DecodeLocale` to decode a bytes string to get a
- :c:type:`wchar_*` string.
+ :c:expr:`wchar_*` string.
See also :c:member:`PyConfig.orig_argv` and :c:member:`PyConfig.argv`
members of the :ref:`Python Initialization Configuration `.
@@ -678,7 +678,7 @@ Process-wide parameters
:option:`-I`.
Use :c:func:`Py_DecodeLocale` to decode a bytes string to get a
- :c:type:`wchar_*` string.
+ :c:expr:`wchar_*` string.
See also :c:member:`PyConfig.orig_argv` and :c:member:`PyConfig.argv`
members of the :ref:`Python Initialization Configuration `.
@@ -704,12 +704,12 @@ Process-wide parameters
this storage.
Use :c:func:`Py_DecodeLocale` to decode a bytes string to get a
- :c:type:`wchar_*` string.
+ :c:expr:`wchar_*` string.
.. deprecated:: 3.11
-.. c:function:: w_char* Py_GetPythonHome()
+.. c:function:: wchar_t* Py_GetPythonHome()
Return the default "home", that is, the value set by a previous call to
:c:func:`Py_SetPythonHome`, or the value of the :envvar:`PYTHONHOME`
@@ -740,7 +740,7 @@ operations could cause problems in a multi-threaded program: for example, when
two threads simultaneously increment the reference count of the same object, the
reference count could end up being incremented only once instead of twice.
-.. index:: single: setswitchinterval() (in module sys)
+.. index:: single: setswitchinterval (in module sys)
Therefore, the rule exists that only the thread that has acquired the
:term:`GIL` may operate on Python objects or call Python/C API functions.
@@ -750,8 +750,7 @@ released around potentially blocking I/O operations like reading or writing
a file, so that other Python threads can run in the meantime.
.. index::
- single: PyThreadState
- single: PyThreadState
+ single: PyThreadState (C type)
The Python interpreter keeps some thread-specific bookkeeping information
inside a data structure called :c:type:`PyThreadState`. There's also one
@@ -777,8 +776,8 @@ This is so common that a pair of macros exists to simplify it::
Py_END_ALLOW_THREADS
.. index::
- single: Py_BEGIN_ALLOW_THREADS
- single: Py_END_ALLOW_THREADS
+ single: Py_BEGIN_ALLOW_THREADS (C macro)
+ single: Py_END_ALLOW_THREADS (C macro)
The :c:macro:`Py_BEGIN_ALLOW_THREADS` macro opens a new block and declares a
hidden local variable; the :c:macro:`Py_END_ALLOW_THREADS` macro closes the
@@ -793,8 +792,8 @@ The block above expands to the following code::
PyEval_RestoreThread(_save);
.. index::
- single: PyEval_RestoreThread()
- single: PyEval_SaveThread()
+ single: PyEval_RestoreThread (C function)
+ single: PyEval_SaveThread (C function)
Here is how these functions work: the global interpreter lock is used to protect the pointer to the
current thread state. When releasing the lock and saving the thread state,
@@ -847,11 +846,11 @@ from a C thread is::
/* Release the thread. No Python API allowed beyond this point. */
PyGILState_Release(gstate);
-Note that the :c:func:`PyGILState_\*` functions assume there is only one global
+Note that the ``PyGILState_*`` functions assume there is only one global
interpreter (created automatically by :c:func:`Py_Initialize`). Python
supports the creation of additional interpreters (using
:c:func:`Py_NewInterpreter`), but mixing multiple interpreters and the
-:c:func:`PyGILState_\*` API is unsupported.
+``PyGILState_*`` API is unsupported.
.. _fork-and-threads:
@@ -872,7 +871,7 @@ the fork, and releasing them afterwards. In addition, it resets any
:ref:`lock-objects` in the child. When extending or embedding Python, there
is no way to inform Python of additional (non-Python) locks that need to be
acquired before or reset after a fork. OS facilities such as
-:c:func:`pthread_atfork` would need to be used to accomplish the same thing.
+:c:func:`!pthread_atfork` would need to be used to accomplish the same thing.
Additionally, when extending or embedding Python, calling :c:func:`fork`
directly rather than through :func:`os.fork` (and returning to or calling
into Python) may result in a deadlock by one of Python's internal locks
@@ -914,8 +913,11 @@ code, or when embedding the Python interpreter:
.. c:type:: PyThreadState
This data structure represents the state of a single thread. The only public
- data member is :attr:`interp` (:c:type:`PyInterpreterState *`), which points to
- this thread's interpreter state.
+ data member is:
+
+ .. c:member:: PyInterpreterState *interp
+
+ This thread's interpreter state.
.. c:function:: void PyEval_InitThreads()
@@ -940,9 +942,9 @@ code, or when embedding the Python interpreter:
.. versionchanged:: 3.2
This function cannot be called before :c:func:`Py_Initialize()` anymore.
- .. deprecated-removed:: 3.9 3.11
+ .. deprecated:: 3.9
- .. index:: module: _thread
+ .. index:: pair: module; _thread
.. c:function:: int PyEval_ThreadsInitialized()
@@ -954,7 +956,7 @@ code, or when embedding the Python interpreter:
.. versionchanged:: 3.7
The :term:`GIL` is now initialized by :c:func:`Py_Initialize()`.
- .. deprecated-removed:: 3.9 3.11
+ .. deprecated:: 3.9
.. c:function:: PyThreadState* PyEval_SaveThread()
@@ -975,7 +977,7 @@ code, or when embedding the Python interpreter:
.. note::
Calling this function from a thread when the runtime is finalizing
will terminate the thread, even if the thread was not created by Python.
- You can use :c:func:`_Py_IsFinalizing` or :func:`sys.is_finalizing` to
+ You can use :c:func:`!_Py_IsFinalizing` or :func:`sys.is_finalizing` to
check if the interpreter is in process of being finalized before calling
this function to avoid unwanted termination.
@@ -1021,7 +1023,7 @@ with sub-interpreters:
.. note::
Calling this function from a thread when the runtime is finalizing
will terminate the thread, even if the thread was not created by Python.
- You can use :c:func:`_Py_IsFinalizing` or :func:`sys.is_finalizing` to
+ You can use :c:func:`!_Py_IsFinalizing` or :func:`sys.is_finalizing` to
check if the interpreter is in process of being finalized before calling
this function to avoid unwanted termination.
@@ -1287,12 +1289,12 @@ All of the following functions must be called after :c:func:`Py_Initialize`.
function does not steal any references to *exc*. To prevent naive misuse, you
must write your own C extension to call this. Must be called with the GIL held.
Returns the number of thread states modified; this is normally one, but will be
- zero if the thread id isn't found. If *exc* is :const:`NULL`, the pending
+ zero if the thread id isn't found. If *exc* is ``NULL``, the pending
exception (if any) for the thread is cleared. This raises no exceptions.
.. versionchanged:: 3.7
- The type of the *id* parameter changed from :c:type:`long` to
- :c:type:`unsigned long`.
+ The type of the *id* parameter changed from :c:expr:`long` to
+ :c:expr:`unsigned long`.
.. c:function:: void PyEval_AcquireThread(PyThreadState *tstate)
@@ -1303,7 +1305,7 @@ All of the following functions must be called after :c:func:`Py_Initialize`.
.. note::
Calling this function from a thread when the runtime is finalizing
will terminate the thread, even if the thread was not created by Python.
- You can use :c:func:`_Py_IsFinalizing` or :func:`sys.is_finalizing` to
+ You can use :c:func:`!_Py_IsFinalizing` or :func:`sys.is_finalizing` to
check if the interpreter is in process of being finalized before calling
this function to avoid unwanted termination.
@@ -1385,9 +1387,9 @@ function. You can create and destroy them using the following functions:
.. c:function:: PyThreadState* Py_NewInterpreter()
.. index::
- module: builtins
- module: __main__
- module: sys
+ pair: module; builtins
+ pair: module; __main__
+ pair: module; sys
single: stdout (in module sys)
single: stderr (in module sys)
single: stdin (in module sys)
@@ -1414,8 +1416,8 @@ function. You can create and destroy them using the following functions:
entry.)
.. index::
- single: Py_FinalizeEx()
- single: Py_Initialize()
+ single: Py_FinalizeEx (C function)
+ single: Py_Initialize (C function)
Extension modules are shared between (sub-)interpreters as follows:
@@ -1443,12 +1445,12 @@ function. You can create and destroy them using the following functions:
As with multi-phase initialization, this means that only C-level static
and global variables are shared between these modules.
- .. index:: single: close() (in module os)
+ .. index:: single: close (in module os)
.. c:function:: void Py_EndInterpreter(PyThreadState *tstate)
- .. index:: single: Py_FinalizeEx()
+ .. index:: single: Py_FinalizeEx (C function)
Destroy the (sub-)interpreter represented by the given thread state. The given
thread state must be the current thread state. See the discussion of thread
@@ -1478,7 +1480,7 @@ operations executed by such objects may affect the wrong (sub-)interpreter's
dictionary of loaded modules. It is equally important to avoid sharing
objects from which the above are reachable.
-Also note that combining this functionality with :c:func:`PyGILState_\*` APIs
+Also note that combining this functionality with ``PyGILState_*`` APIs
is delicate, because these APIs assume a bijection between Python thread states
and OS-level threads, an assumption broken by the presence of sub-interpreters.
It is highly recommended that you don't switch sub-interpreters between a pair
@@ -1498,8 +1500,6 @@ pointer and a void pointer argument.
.. c:function:: int Py_AddPendingCall(int (*func)(void *), void *arg)
- .. index:: single: Py_AddPendingCall()
-
Schedule a function to be called from the main interpreter thread. On
success, ``0`` is returned and *func* is queued for being called in the
main thread. On failure, ``-1`` is returned without setting any exception.
@@ -1566,32 +1566,32 @@ Python-level trace functions in previous versions.
The type of the trace function registered using :c:func:`PyEval_SetProfile` and
:c:func:`PyEval_SetTrace`. The first parameter is the object passed to the
registration function as *obj*, *frame* is the frame object to which the event
- pertains, *what* is one of the constants :const:`PyTrace_CALL`,
- :const:`PyTrace_EXCEPTION`, :const:`PyTrace_LINE`, :const:`PyTrace_RETURN`,
- :const:`PyTrace_C_CALL`, :const:`PyTrace_C_EXCEPTION`, :const:`PyTrace_C_RETURN`,
- or :const:`PyTrace_OPCODE`, and *arg* depends on the value of *what*:
-
- +------------------------------+----------------------------------------+
- | Value of *what* | Meaning of *arg* |
- +==============================+========================================+
- | :const:`PyTrace_CALL` | Always :c:data:`Py_None`. |
- +------------------------------+----------------------------------------+
- | :const:`PyTrace_EXCEPTION` | Exception information as returned by |
- | | :func:`sys.exc_info`. |
- +------------------------------+----------------------------------------+
- | :const:`PyTrace_LINE` | Always :c:data:`Py_None`. |
- +------------------------------+----------------------------------------+
- | :const:`PyTrace_RETURN` | Value being returned to the caller, |
- | | or ``NULL`` if caused by an exception. |
- +------------------------------+----------------------------------------+
- | :const:`PyTrace_C_CALL` | Function object being called. |
- +------------------------------+----------------------------------------+
- | :const:`PyTrace_C_EXCEPTION` | Function object being called. |
- +------------------------------+----------------------------------------+
- | :const:`PyTrace_C_RETURN` | Function object being called. |
- +------------------------------+----------------------------------------+
- | :const:`PyTrace_OPCODE` | Always :c:data:`Py_None`. |
- +------------------------------+----------------------------------------+
+ pertains, *what* is one of the constants :c:data:`PyTrace_CALL`,
+ :c:data:`PyTrace_EXCEPTION`, :c:data:`PyTrace_LINE`, :c:data:`PyTrace_RETURN`,
+ :c:data:`PyTrace_C_CALL`, :c:data:`PyTrace_C_EXCEPTION`, :c:data:`PyTrace_C_RETURN`,
+ or :c:data:`PyTrace_OPCODE`, and *arg* depends on the value of *what*:
+
+ +-------------------------------+----------------------------------------+
+ | Value of *what* | Meaning of *arg* |
+ +===============================+========================================+
+ | :c:data:`PyTrace_CALL` | Always :c:data:`Py_None`. |
+ +-------------------------------+----------------------------------------+
+ | :c:data:`PyTrace_EXCEPTION` | Exception information as returned by |
+ | | :func:`sys.exc_info`. |
+ +-------------------------------+----------------------------------------+
+ | :c:data:`PyTrace_LINE` | Always :c:data:`Py_None`. |
+ +-------------------------------+----------------------------------------+
+ | :c:data:`PyTrace_RETURN` | Value being returned to the caller, |
+ | | or ``NULL`` if caused by an exception. |
+ +-------------------------------+----------------------------------------+
+ | :c:data:`PyTrace_C_CALL` | Function object being called. |
+ +-------------------------------+----------------------------------------+
+ | :c:data:`PyTrace_C_EXCEPTION` | Function object being called. |
+ +-------------------------------+----------------------------------------+
+ | :c:data:`PyTrace_C_RETURN` | Function object being called. |
+ +-------------------------------+----------------------------------------+
+ | :c:data:`PyTrace_OPCODE` | Always :c:data:`Py_None`. |
+ +-------------------------------+----------------------------------------+
.. c:var:: int PyTrace_CALL
@@ -1617,7 +1617,8 @@ Python-level trace functions in previous versions.
The value passed as the *what* parameter to a :c:type:`Py_tracefunc` function
(but not a profiling function) when a line-number event is being reported.
- It may be disabled for a frame by setting :attr:`f_trace_lines` to *0* on that frame.
+ It may be disabled for a frame by setting :attr:`~frame.f_trace_lines` to
+ *0* on that frame.
.. c:var:: int PyTrace_RETURN
@@ -1649,7 +1650,7 @@ Python-level trace functions in previous versions.
The value for the *what* parameter to :c:type:`Py_tracefunc` functions (but not
profiling functions) when a new opcode is about to be executed. This event is
not emitted by default: it must be explicitly requested by setting
- :attr:`f_trace_opcodes` to *1* on the frame.
+ :attr:`~frame.f_trace_opcodes` to *1* on the frame.
.. c:function:: void PyEval_SetProfile(Py_tracefunc func, PyObject *obj)
@@ -1658,8 +1659,8 @@ Python-level trace functions in previous versions.
function as its first parameter, and may be any Python object, or ``NULL``. If
the profile function needs to maintain state, using a different value for *obj*
for each thread provides a convenient and thread-safe place to store it. The
- profile function is called for all monitored events except :const:`PyTrace_LINE`
- :const:`PyTrace_OPCODE` and :const:`PyTrace_EXCEPTION`.
+ profile function is called for all monitored events except :c:data:`PyTrace_LINE`
+ :c:data:`PyTrace_OPCODE` and :c:data:`PyTrace_EXCEPTION`.
See also the :func:`sys.setprofile` function.
@@ -1672,8 +1673,8 @@ Python-level trace functions in previous versions.
:c:func:`PyEval_SetProfile`, except the tracing function does receive line-number
events and per-opcode events, but does not receive any event related to C function
objects being called. Any trace function registered using :c:func:`PyEval_SetTrace`
- will not receive :const:`PyTrace_C_CALL`, :const:`PyTrace_C_EXCEPTION` or
- :const:`PyTrace_C_RETURN` as a value for the *what* parameter.
+ will not receive :c:data:`PyTrace_C_CALL`, :c:data:`PyTrace_C_EXCEPTION` or
+ :c:data:`PyTrace_C_RETURN` as a value for the *what* parameter.
See also the :func:`sys.settrace` function.
@@ -1730,7 +1731,7 @@ The Python interpreter provides low-level support for thread-local storage
(TLS) which wraps the underlying native TLS implementation to support the
Python-level thread local storage API (:class:`threading.local`). The
CPython C level APIs are similar to those offered by pthreads and Windows:
-use a thread key and functions to associate a :c:type:`void*` value per
+use a thread key and functions to associate a :c:expr:`void*` value per
thread.
The GIL does *not* need to be held when calling these functions; they supply
@@ -1741,8 +1742,8 @@ you need to include :file:`pythread.h` to use thread-local storage.
.. note::
None of these API functions handle memory management on behalf of the
- :c:type:`void*` values. You need to allocate and deallocate them yourself.
- If the :c:type:`void*` values happen to be :c:type:`PyObject*`, these
+ :c:expr:`void*` values. You need to allocate and deallocate them yourself.
+ If the :c:expr:`void*` values happen to be :c:expr:`PyObject*`, these
functions don't do refcount operations on them either.
.. _thread-specific-storage-api:
@@ -1752,7 +1753,7 @@ Thread Specific Storage (TSS) API
TSS API is introduced to supersede the use of the existing TLS API within the
CPython interpreter. This API uses a new type :c:type:`Py_tss_t` instead of
-:c:type:`int` to represent thread keys.
+:c:expr:`int` to represent thread keys.
.. versionadded:: 3.7
@@ -1796,11 +1797,11 @@ is not possible due to its implementation being opaque at build time.
Free the given *key* allocated by :c:func:`PyThread_tss_alloc`, after
first calling :c:func:`PyThread_tss_delete` to ensure any associated
thread locals have been unassigned. This is a no-op if the *key*
- argument is `NULL`.
+ argument is ``NULL``.
.. note::
A freed key becomes a dangling pointer. You should reset the key to
- `NULL`.
+ ``NULL``.
Methods
@@ -1838,14 +1839,14 @@ undefined if the given :c:type:`Py_tss_t` has not been initialized by
.. c:function:: int PyThread_tss_set(Py_tss_t *key, void *value)
- Return a zero value to indicate successfully associating a :c:type:`void*`
+ Return a zero value to indicate successfully associating a :c:expr:`void*`
value with a TSS key in the current thread. Each thread has a distinct
- mapping of the key to a :c:type:`void*` value.
+ mapping of the key to a :c:expr:`void*` value.
.. c:function:: void* PyThread_tss_get(Py_tss_t *key)
- Return the :c:type:`void*` value associated with a TSS key in the current
+ Return the :c:expr:`void*` value associated with a TSS key in the current
thread. This returns ``NULL`` if no value is associated with the key in the
current thread.
diff --git a/Doc/c-api/init_config.rst b/Doc/c-api/init_config.rst
index 728df2100336e7..ad1cd3f4f06681 100644
--- a/Doc/c-api/init_config.rst
+++ b/Doc/c-api/init_config.rst
@@ -82,6 +82,8 @@ PyWideStringList
If *length* is non-zero, *items* must be non-``NULL`` and all strings must be
non-``NULL``.
+ .. c:namespace:: NULL
+
Methods:
.. c:function:: PyStatus PyWideStringList_Append(PyWideStringList *list, const wchar_t *item)
@@ -97,10 +99,12 @@ PyWideStringList
If *index* is greater than or equal to *list* length, append *item* to
*list*.
- *index* must be greater than or equal to 0.
+ *index* must be greater than or equal to ``0``.
Python must be preinitialized to call this function.
+ .. c:namespace:: PyWideStringList
+
Structure fields:
.. c:member:: Py_ssize_t length
@@ -135,6 +139,8 @@ PyStatus
Name of the function which created an error, can be ``NULL``.
+ .. c:namespace:: NULL
+
Functions to create a status:
.. c:function:: PyStatus PyStatus_Ok(void)
@@ -210,6 +216,8 @@ PyPreConfig
Structure used to preinitialize Python.
+ .. c:namespace:: NULL
+
Function to initialize a preconfiguration:
.. c:function:: void PyPreConfig_InitPythonConfig(PyPreConfig *preconfig)
@@ -222,6 +230,8 @@ PyPreConfig
Initialize the preconfiguration with :ref:`Isolated Configuration
`.
+ .. c:namespace:: PyPreConfig
+
Structure fields:
.. c:member:: int allocator
@@ -254,10 +264,10 @@ PyPreConfig
.. c:member:: int configure_locale
- Set the LC_CTYPE locale to the user preferred locale?
+ Set the LC_CTYPE locale to the user preferred locale.
- If equals to 0, set :c:member:`~PyPreConfig.coerce_c_locale` and
- :c:member:`~PyPreConfig.coerce_c_locale_warn` members to 0.
+ If equals to ``0``, set :c:member:`~PyPreConfig.coerce_c_locale` and
+ :c:member:`~PyPreConfig.coerce_c_locale_warn` members to ``0``.
See the :term:`locale encoding`.
@@ -265,9 +275,9 @@ PyPreConfig
.. c:member:: int coerce_c_locale
- If equals to 2, coerce the C locale.
+ If equals to ``2``, coerce the C locale.
- If equals to 1, read the LC_CTYPE locale to decide if it should be
+ If equals to ``1``, read the LC_CTYPE locale to decide if it should be
coerced.
See the :term:`locale encoding`.
@@ -282,8 +292,8 @@ PyPreConfig
.. c:member:: int dev_mode
- If non-zero, enables the :ref:`Python Development Mode `:
- see :c:member:`PyConfig.dev_mode`.
+ :ref:`Python Development Mode `: see
+ :c:member:`PyConfig.dev_mode`.
Default: ``-1`` in Python mode, ``0`` in isolated mode.
@@ -329,8 +339,10 @@ PyPreConfig
If non-zero, enable the :ref:`Python UTF-8 Mode `.
- Set by the :option:`-X utf8 <-X>` command line option and the
- :envvar:`PYTHONUTF8` environment variable.
+ Set to ``0`` or ``1`` by the :option:`-X utf8 <-X>` command line option
+ and the :envvar:`PYTHONUTF8` environment variable.
+
+ Also set to ``1`` if the ``LC_CTYPE`` locale is ``C`` or ``POSIX``.
Default: ``-1`` in Python config and ``0`` in isolated config.
@@ -427,6 +439,8 @@ PyConfig
When done, the :c:func:`PyConfig_Clear` function must be used to release the
configuration memory.
+ .. c:namespace:: NULL
+
Structure methods:
.. c:function:: void PyConfig_InitPythonConfig(PyConfig *config)
@@ -520,11 +534,13 @@ PyConfig
Moreover, if :c:func:`PyConfig_SetArgv` or :c:func:`PyConfig_SetBytesArgv`
is used, this method must be called before other methods, since the
preinitialization configuration depends on command line arguments (if
- :c:member:`parse_argv` is non-zero).
+ :c:member:`~PyConfig.parse_argv` is non-zero).
The caller of these methods is responsible to handle exceptions (error or
exit) using ``PyStatus_Exception()`` and ``Py_ExitStatusException()``.
+ .. c:namespace:: PyConfig
+
Structure fields:
.. c:member:: PyWideStringList argv
@@ -555,7 +571,7 @@ PyConfig
* Otherwise (``python -c code`` and ``python``), prepend an empty string,
which means the current working directory.
- Set to 1 by the :option:`-P` command line option and the
+ Set to ``1`` by the :option:`-P` command line option and the
:envvar:`PYTHONSAFEPATH` environment variable.
Default: ``0`` in Python config, ``1`` in isolated config.
@@ -592,10 +608,10 @@ PyConfig
.. c:member:: int buffered_stdio
- If equals to 0 and :c:member:`~PyConfig.configure_c_stdio` is non-zero,
+ If equals to ``0`` and :c:member:`~PyConfig.configure_c_stdio` is non-zero,
disable buffering on the C streams stdout and stderr.
- Set to 0 by the :option:`-u` command line option and the
+ Set to ``0`` by the :option:`-u` command line option and the
:envvar:`PYTHONUNBUFFERED` environment variable.
stdin is always opened in buffered mode.
@@ -604,11 +620,11 @@ PyConfig
.. c:member:: int bytes_warning
- If equals to 1, issue a warning when comparing :class:`bytes` or
+ If equals to ``1``, issue a warning when comparing :class:`bytes` or
:class:`bytearray` with :class:`str`, or comparing :class:`bytes` with
:class:`int`.
- If equal or greater to 2, raise a :exc:`BytesWarning` exception in these
+ If equal or greater to ``2``, raise a :exc:`BytesWarning` exception in these
cases.
Incremented by the :option:`-b` command line option.
@@ -671,6 +687,9 @@ PyConfig
If non-zero, enable the :ref:`Python Development Mode `.
+ Set to ``1`` by the :option:`-X dev <-X>` option and the
+ :envvar:`PYTHONDEVMODE` environment variable.
+
Default: ``-1`` in Python mode, ``0`` in isolated mode.
.. c:member:: int dump_refs
@@ -730,9 +749,8 @@ PyConfig
* ``"utf-8"`` if :c:member:`PyPreConfig.utf8_mode` is non-zero.
* ``"ascii"`` if Python detects that ``nl_langinfo(CODESET)`` announces
- the ASCII encoding (or Roman8 encoding on HP-UX), whereas the
- ``mbstowcs()`` function decodes from a different encoding (usually
- Latin1).
+ the ASCII encoding, whereas the ``mbstowcs()`` function
+ decodes from a different encoding (usually Latin1).
* ``"utf-8"`` if ``nl_langinfo(CODESET)`` returns an empty string.
* Otherwise, use the :term:`locale encoding`:
``nl_langinfo(CODESET)`` result.
@@ -800,7 +818,7 @@ PyConfig
Enter interactive mode after executing a script or a command.
- If greater than 0, enable inspect: when a script is passed as first
+ If greater than ``0``, enable inspect: when a script is passed as first
argument or the -c option is used, enter interactive mode after executing
the script or the command, even when :data:`sys.stdin` does not appear to
be a terminal.
@@ -818,7 +836,7 @@ PyConfig
.. c:member:: int interactive
- If greater than 0, enable the interactive mode (REPL).
+ If greater than ``0``, enable the interactive mode (REPL).
Incremented by the :option:`-i` command line option.
@@ -826,17 +844,19 @@ PyConfig
.. c:member:: int isolated
- If greater than 0, enable isolated mode:
+ If greater than ``0``, enable isolated mode:
- * Set :c:member:`~PyConfig.safe_path` to 1:
+ * Set :c:member:`~PyConfig.safe_path` to ``1``:
don't prepend a potentially unsafe path to :data:`sys.path` at Python
startup.
- * Set :c:member:`~PyConfig.use_environment` to 0.
- * Set :c:member:`~PyConfig.user_site_directory` to 0: don't add the user
+ * Set :c:member:`~PyConfig.use_environment` to ``0``.
+ * Set :c:member:`~PyConfig.user_site_directory` to ``0``: don't add the user
site directory to :data:`sys.path`.
* Python REPL doesn't import :mod:`readline` nor enable default readline
configuration on interactive prompts.
+ Set to ``1`` by the :option:`-I` command line option.
+
Default: ``0`` in Python mode, ``1`` in isolated mode.
See also :c:member:`PyPreConfig.isolated`.
@@ -844,7 +864,7 @@ PyConfig
.. c:member:: int legacy_windows_stdio
If non-zero, use :class:`io.FileIO` instead of
- :class:`io.WindowsConsoleIO` for :data:`sys.stdin`, :data:`sys.stdout`
+ :class:`!io._WindowsConsoleIO` for :data:`sys.stdin`, :data:`sys.stdout`
and :data:`sys.stderr`.
Set to ``1`` if the :envvar:`PYTHONLEGACYWINDOWSSTDIO` environment
@@ -893,7 +913,7 @@ PyConfig
.. c:member:: wchar_t* pythonpath_env
Module search paths (:data:`sys.path`) as a string separated by ``DELIM``
- (:data:`os.path.pathsep`).
+ (:data:`os.pathsep`).
Set by the :envvar:`PYTHONPATH` environment variable.
@@ -906,7 +926,7 @@ PyConfig
Module search paths: :data:`sys.path`.
- If :c:member:`~PyConfig.module_search_paths_set` is equal to 0,
+ If :c:member:`~PyConfig.module_search_paths_set` is equal to ``0``,
:c:func:`Py_InitializeFromConfig` will replace
:c:member:`~PyConfig.module_search_paths` and sets
:c:member:`~PyConfig.module_search_paths_set` to ``1``.
@@ -970,7 +990,7 @@ PyConfig
.. c:member:: int parser_debug
- Parser debug mode. If greater than 0, turn on parser debugging output (for expert only, depending
+ Parser debug mode. If greater than ``0``, turn on parser debugging output (for expert only, depending
on compilation options).
Incremented by the :option:`-d` command line option. Set to the
@@ -981,7 +1001,7 @@ PyConfig
.. c:member:: int pathconfig_warnings
If non-zero, calculation of path configuration is allowed to log
- warnings into ``stderr``. If equals to 0, suppress these warnings.
+ warnings into ``stderr``. If equals to ``0``, suppress these warnings.
Default: ``1`` in Python mode, ``0`` in isolated mode.
@@ -1031,7 +1051,7 @@ PyConfig
.. c:member:: int quiet
- Quiet mode. If greater than 0, don't display the copyright and version at
+ Quiet mode. If greater than ``0``, don't display the copyright and version at
Python startup in interactive mode.
Incremented by the :option:`-q` command line option.
@@ -1071,7 +1091,7 @@ PyConfig
Show total reference count at exit?
- Set to 1 by :option:`-X showrefcount <-X>` command line option.
+ Set to ``1`` by :option:`-X showrefcount <-X>` command line option.
Need a :ref:`debug build of Python ` (the ``Py_REF_DEBUG``
macro must be defined).
@@ -1090,7 +1110,7 @@ PyConfig
Set to ``0`` by the :option:`-S` command line option.
- :data:`sys.flags.no_site` is set to the inverted value of
+ :data:`sys.flags.no_site ` is set to the inverted value of
:c:member:`~PyConfig.site_import`.
Default: ``1``.
@@ -1150,6 +1170,8 @@ PyConfig
If equals to zero, ignore the :ref:`environment variables
`.
+ Set to ``0`` by the :option:`-E` environment variable.
+
Default: ``1`` in Python config and ``0`` in isolated config.
.. c:member:: int user_site_directory
@@ -1164,11 +1186,11 @@ PyConfig
.. c:member:: int verbose
- Verbose mode. If greater than 0, print a message each time a module is
+ Verbose mode. If greater than ``0``, print a message each time a module is
imported, showing the place (filename or built-in module) from which
it is loaded.
- If greater or equal to 2, print a message for each file that is checked
+ If greater or equal to ``2``, print a message for each file that is checked
for when searching for a module. Also provides information on module
cleanup at exit.
@@ -1199,7 +1221,7 @@ PyConfig
.. c:member:: int write_bytecode
- If equal to 0, Python won't try to write ``.pyc`` files on the import of
+ If equal to ``0``, Python won't try to write ``.pyc`` files on the import of
source modules.
Set to ``0`` by the :option:`-B` command line option and the
@@ -1280,7 +1302,11 @@ Example setting the program name::
}
More complete example modifying the default configuration, read the
-configuration, and then override some parameters::
+configuration, and then override some parameters. Note that since
+3.11, many parameters are not calculated until initialization, and
+so values cannot be read from the configuration structure. Any values
+set before initialize is called will be left unchanged by
+initialization::
PyStatus init_python(const char *program_name)
{
@@ -1305,7 +1331,15 @@ configuration, and then override some parameters::
goto done;
}
- /* Append our custom search path to sys.path */
+ /* Specify sys.path explicitly */
+ /* If you want to modify the default set of paths, finish
+ initialization first and then use PySys_GetObject("path") */
+ config.module_search_paths_set = 1;
+ status = PyWideStringList_Append(&config.module_search_paths,
+ L"/path/to/stdlib");
+ if (PyStatus_Exception(status)) {
+ goto done;
+ }
status = PyWideStringList_Append(&config.module_search_paths,
L"/path/to/more/modules");
if (PyStatus_Exception(status)) {
@@ -1400,18 +1434,18 @@ Python Path Configuration
If at least one "output field" is not set, Python calculates the path
configuration to fill unset fields. If
-:c:member:`~PyConfig.module_search_paths_set` is equal to 0,
+:c:member:`~PyConfig.module_search_paths_set` is equal to ``0``,
:c:member:`~PyConfig.module_search_paths` is overridden and
-:c:member:`~PyConfig.module_search_paths_set` is set to 1.
+:c:member:`~PyConfig.module_search_paths_set` is set to ``1``.
It is possible to completely ignore the function calculating the default
path configuration by setting explicitly all path configuration output
fields listed above. A string is considered as set even if it is non-empty.
``module_search_paths`` is considered as set if
-``module_search_paths_set`` is set to 1. In this case, path
-configuration input fields are ignored as well.
+``module_search_paths_set`` is set to ``1``. In this case,
+``module_search_paths`` will be used without modification.
-Set :c:member:`~PyConfig.pathconfig_warnings` to 0 to suppress warnings when
+Set :c:member:`~PyConfig.pathconfig_warnings` to ``0`` to suppress warnings when
calculating the path configuration (Unix only, Windows does not log any warning).
If :c:member:`~PyConfig.base_prefix` or :c:member:`~PyConfig.base_exec_prefix`
@@ -1445,10 +1479,10 @@ The following configuration files are used by the path configuration:
If a ``._pth`` file is present:
-* Set :c:member:`~PyConfig.isolated` to 1.
-* Set :c:member:`~PyConfig.use_environment` to 0.
-* Set :c:member:`~PyConfig.site_import` to 0.
-* Set :c:member:`~PyConfig.safe_path` to 1.
+* Set :c:member:`~PyConfig.isolated` to ``1``.
+* Set :c:member:`~PyConfig.use_environment` to ``0``.
+* Set :c:member:`~PyConfig.site_import` to ``0``.
+* Set :c:member:`~PyConfig.safe_path` to ``1``.
The ``__PYVENV_LAUNCHER__`` environment variable is used to set
:c:member:`PyConfig.base_executable`
@@ -1511,7 +1545,7 @@ initialization, the core feature of :pep:`432`:
Private provisional API:
-* :c:member:`PyConfig._init_main`: if set to 0,
+* :c:member:`PyConfig._init_main`: if set to ``0``,
:c:func:`Py_InitializeFromConfig` stops at the "Core" initialization phase.
* :c:member:`PyConfig._isolated_interpreter`: if non-zero,
disallow threads, subprocesses and fork.
diff --git a/Doc/c-api/intro.rst b/Doc/c-api/intro.rst
index 9efac0b83d024d..a4b89218c76ae8 100644
--- a/Doc/c-api/intro.rst
+++ b/Doc/c-api/intro.rst
@@ -78,19 +78,19 @@ used by extension writers. Structure member names do not have a reserved prefix.
The header files are typically installed with Python. On Unix, these are
located in the directories :file:`{prefix}/include/pythonversion/` and
-:file:`{exec_prefix}/include/pythonversion/`, where :envvar:`prefix` and
-:envvar:`exec_prefix` are defined by the corresponding parameters to Python's
+:file:`{exec_prefix}/include/pythonversion/`, where :option:`prefix <--prefix>` and
+:option:`exec_prefix <--exec-prefix>` are defined by the corresponding parameters to Python's
:program:`configure` script and *version* is
``'%d.%d' % sys.version_info[:2]``. On Windows, the headers are installed
-in :file:`{prefix}/include`, where :envvar:`prefix` is the installation
+in :file:`{prefix}/include`, where ``prefix`` is the installation
directory specified to the installer.
To include the headers, place both directories (if different) on your compiler's
search path for includes. Do *not* place the parent directories on the search
path and then use ``#include ``; this will break on
multi-platform builds since the platform independent headers under
-:envvar:`prefix` include the platform specific headers from
-:envvar:`exec_prefix`.
+:option:`prefix <--prefix>` include the platform specific headers from
+:option:`exec_prefix <--exec-prefix>`.
C++ users should note that although the API is defined entirely using C, the
header files properly declare the entry points to be ``extern "C"``. As a result,
@@ -105,6 +105,30 @@ defined closer to where they are useful (e.g. :c:macro:`Py_RETURN_NONE`).
Others of a more general utility are defined here. This is not necessarily a
complete listing.
+.. c:macro:: PyMODINIT_FUNC
+
+ Declare an extension module ``PyInit`` initialization function. The function
+ return type is :c:expr:`PyObject*`. The macro declares any special linkage
+ declarations required by the platform, and for C++ declares the function as
+ ``extern "C"``.
+
+ The initialization function must be named :samp:`PyInit_{name}`, where
+ *name* is the name of the module, and should be the only non-\ ``static``
+ item defined in the module file. Example::
+
+ static struct PyModuleDef spam_module = {
+ PyModuleDef_HEAD_INIT,
+ .m_name = "spam",
+ ...
+ };
+
+ PyMODINIT_FUNC
+ PyInit_spam(void)
+ {
+ return PyModule_Create(&spam_module);
+ }
+
+
.. c:macro:: Py_ABS(x)
Return the absolute value of ``x``.
@@ -124,7 +148,7 @@ complete listing.
worse performances (due to increased code size for example). The compiler is
usually smarter than the developer for the cost/benefit analysis.
- If Python is :ref:`built in debug mode ` (if the ``Py_DEBUG``
+ If Python is :ref:`built in debug mode ` (if the :c:macro:`Py_DEBUG`
macro is defined), the :c:macro:`Py_ALWAYS_INLINE` macro does nothing.
It must be specified before the function return type. Usage::
@@ -261,16 +285,16 @@ complete listing.
Objects, Types and Reference Counts
===================================
-.. index:: object: type
+.. index:: pair: object; type
Most Python/C API functions have one or more arguments as well as a return value
-of type :c:type:`PyObject*`. This type is a pointer to an opaque data type
+of type :c:expr:`PyObject*`. This type is a pointer to an opaque data type
representing an arbitrary Python object. Since all Python object types are
treated the same way by the Python language in most situations (e.g.,
assignments, scope rules, and argument passing), it is only fitting that they
should be represented by a single C type. Almost all Python objects live on the
heap: you never declare an automatic or static variable of type
-:c:type:`PyObject`, only pointer variables of type :c:type:`PyObject*` can be
+:c:type:`PyObject`, only pointer variables of type :c:expr:`PyObject*` can be
declared. The sole exception are the type objects; since these must never be
deallocated, they are typically static :c:type:`PyTypeObject` objects.
@@ -287,52 +311,58 @@ true if (and only if) the object pointed to by *a* is a Python list.
Reference Counts
----------------
-The reference count is important because today's computers have a finite (and
-often severely limited) memory size; it counts how many different places there
-are that have a reference to an object. Such a place could be another object,
-or a global (or static) C variable, or a local variable in some C function.
-When an object's reference count becomes zero, the object is deallocated. If
-it contains references to other objects, their reference count is decremented.
-Those other objects may be deallocated in turn, if this decrement makes their
-reference count become zero, and so on. (There's an obvious problem with
-objects that reference each other here; for now, the solution is "don't do
-that.")
+The reference count is important because today's computers have a finite
+(and often severely limited) memory size; it counts how many different
+places there are that have a :term:`strong reference` to an object.
+Such a place could be another object, or a global (or static) C variable,
+or a local variable in some C function.
+When the last :term:`strong reference` to an object is released
+(i.e. its reference count becomes zero), the object is deallocated.
+If it contains references to other objects, those references are released.
+Those other objects may be deallocated in turn, if there are no more
+references to them, and so on. (There's an obvious problem with
+objects that reference each other here; for now, the solution
+is "don't do that.")
.. index::
- single: Py_INCREF()
- single: Py_DECREF()
-
-Reference counts are always manipulated explicitly. The normal way is to use
-the macro :c:func:`Py_INCREF` to increment an object's reference count by one,
-and :c:func:`Py_DECREF` to decrement it by one. The :c:func:`Py_DECREF` macro
+ single: Py_INCREF (C function)
+ single: Py_DECREF (C function)
+
+Reference counts are always manipulated explicitly. The normal way is
+to use the macro :c:func:`Py_INCREF` to take a new reference to an
+object (i.e. increment its reference count by one),
+and :c:func:`Py_DECREF` to release that reference (i.e. decrement the
+reference count by one). The :c:func:`Py_DECREF` macro
is considerably more complex than the incref one, since it must check whether
the reference count becomes zero and then cause the object's deallocator to be
-called. The deallocator is a function pointer contained in the object's type
-structure. The type-specific deallocator takes care of decrementing the
-reference counts for other objects contained in the object if this is a compound
+called. The deallocator is a function pointer contained in the object's type
+structure. The type-specific deallocator takes care of releasing references
+for other objects contained in the object if this is a compound
object type, such as a list, as well as performing any additional finalization
that's needed. There's no chance that the reference count can overflow; at
least as many bits are used to hold the reference count as there are distinct
memory locations in virtual memory (assuming ``sizeof(Py_ssize_t) >= sizeof(void*)``).
Thus, the reference count increment is a simple operation.
-It is not necessary to increment an object's reference count for every local
-variable that contains a pointer to an object. In theory, the object's
+It is not necessary to hold a :term:`strong reference` (i.e. increment
+the reference count) for every local variable that contains a pointer
+to an object. In theory, the object's
reference count goes up by one when the variable is made to point to it and it
goes down by one when the variable goes out of scope. However, these two
cancel each other out, so at the end the reference count hasn't changed. The
only real reason to use the reference count is to prevent the object from being
deallocated as long as our variable is pointing to it. If we know that there
is at least one other reference to the object that lives at least as long as
-our variable, there is no need to increment the reference count temporarily.
+our variable, there is no need to take a new :term:`strong reference`
+(i.e. increment the reference count) temporarily.
An important situation where this arises is in objects that are passed as
arguments to C functions in an extension module that are called from Python;
the call mechanism guarantees to hold a reference to every argument for the
duration of the call.
However, a common pitfall is to extract an object from a list and hold on to it
-for a while without incrementing its reference count. Some other operation might
-conceivably remove the object from the list, decrementing its reference count
+for a while without taking a new reference. Some other operation might
+conceivably remove the object from the list, releasing that reference,
and possibly deallocating it. The real danger is that innocent-looking
operations may invoke arbitrary Python code which could do this; there is a code
path which allows control to flow back to the user from a :c:func:`Py_DECREF`, so
@@ -340,7 +370,8 @@ almost any operation is potentially dangerous.
A safe approach is to always use the generic operations (functions whose name
begins with ``PyObject_``, ``PyNumber_``, ``PySequence_`` or ``PyMapping_``).
-These operations always increment the reference count of the object they return.
+These operations always create a new :term:`strong reference`
+(i.e. increment the reference count) of the object they return.
This leaves the caller with the responsibility to call :c:func:`Py_DECREF` when
they are done with the result; this soon becomes second nature.
@@ -356,7 +387,7 @@ to objects (objects are not owned: they are always shared). "Owning a
reference" means being responsible for calling Py_DECREF on it when the
reference is no longer needed. Ownership can also be transferred, meaning that
the code that receives ownership of the reference then becomes responsible for
-eventually decref'ing it by calling :c:func:`Py_DECREF` or :c:func:`Py_XDECREF`
+eventually releasing it by calling :c:func:`Py_DECREF` or :c:func:`Py_XDECREF`
when it's no longer needed---or passing on this responsibility (usually to its
caller). When a function passes ownership of a reference on to its caller, the
caller is said to receive a *new* reference. When no ownership is transferred,
@@ -370,8 +401,8 @@ function, that function assumes that it now owns that reference, and you are not
responsible for it any longer.
.. index::
- single: PyList_SetItem()
- single: PyTuple_SetItem()
+ single: PyList_SetItem (C function)
+ single: PyTuple_SetItem (C function)
Few functions steal references; the two notable exceptions are
:c:func:`PyList_SetItem` and :c:func:`PyTuple_SetItem`, which steal a reference
@@ -414,9 +445,9 @@ For example, the above two blocks of code could be replaced by the following
It is much more common to use :c:func:`PyObject_SetItem` and friends with items
whose references you are only borrowing, like arguments that were passed in to
-the function you are writing. In that case, their behaviour regarding reference
-counts is much saner, since you don't have to increment a reference count so you
-can give a reference away ("have it be stolen"). For example, this function
+the function you are writing. In that case, their behaviour regarding references
+is much saner, since you don't have to take a new reference just so you
+can give that reference away ("have it be stolen"). For example, this function
sets all items of a list (actually, any mutable sequence) to a given item::
int
@@ -460,8 +491,8 @@ using :c:func:`PySequence_GetItem` (which happens to take exactly the same
arguments), you do own a reference to the returned object.
.. index::
- single: PyList_GetItem()
- single: PySequence_GetItem()
+ single: PyList_GetItem (C function)
+ single: PySequence_GetItem (C function)
Here is an example of how you could write a function that computes the sum of
the items in a list of integers; once using :c:func:`PyList_GetItem`, and once
@@ -530,13 +561,20 @@ Types
-----
There are few other data types that play a significant role in the Python/C
-API; most are simple C types such as :c:type:`int`, :c:type:`long`,
-:c:type:`double` and :c:type:`char*`. A few structure types are used to
+API; most are simple C types such as :c:expr:`int`, :c:expr:`long`,
+:c:expr:`double` and :c:expr:`char*`. A few structure types are used to
describe static tables used to list the functions exported by a module or the
data attributes of a new object type, and another is used to describe the value
of a complex number. These will be discussed together with the functions that
use them.
+.. c:type:: Py_ssize_t
+
+ A signed integral type such that ``sizeof(Py_ssize_t) == sizeof(size_t)``.
+ C99 doesn't define such a thing directly (size_t is an unsigned integral type).
+ See :pep:`353` for details. ``PY_SSIZE_T_MAX`` is the largest positive value
+ of type :c:type:`Py_ssize_t`.
+
.. _api-exceptions:
@@ -549,7 +587,7 @@ caller, then to the caller's caller, and so on, until they reach the top-level
interpreter, where they are reported to the user accompanied by a stack
traceback.
-.. index:: single: PyErr_Occurred()
+.. index:: single: PyErr_Occurred (C function)
For C programmers, however, error checking always has to be explicit. All
functions in the Python/C API can raise exceptions, unless an explicit claim is
@@ -563,8 +601,8 @@ ambiguous return value, and require explicit testing for errors with
:c:func:`PyErr_Occurred`. These exceptions are always explicitly documented.
.. index::
- single: PyErr_SetString()
- single: PyErr_Clear()
+ single: PyErr_SetString (C function)
+ single: PyErr_Clear (C function)
Exception state is maintained in per-thread storage (this is equivalent to
using global storage in an unthreaded application). A thread can be in one of
@@ -586,7 +624,7 @@ an exception is being passed on between C functions until it reaches the Python
bytecode interpreter's main loop, which takes care of transferring it to
``sys.exc_info()`` and friends.
-.. index:: single: exc_info() (in module sys)
+.. index:: single: exc_info (in module sys)
Note that starting with Python 1.5, the preferred, thread-safe way to access the
exception state from Python code is to call the function :func:`sys.exc_info`,
@@ -609,7 +647,7 @@ and lose important information about the exact cause of the error.
.. index:: single: sum_sequence()
A simple example of detecting exceptions and passing them on is shown in the
-:c:func:`sum_sequence` example above. It so happens that this example doesn't
+:c:func:`!sum_sequence` example above. It so happens that this example doesn't
need to clean up any owned references when it detects an error. The following
example function shows some error cleanup. First, to remind you why you like
Python, we show the equivalent Python code::
@@ -671,9 +709,9 @@ Here is the corresponding C code, in all its glory::
.. index:: single: incr_item()
.. index::
- single: PyErr_ExceptionMatches()
- single: PyErr_Clear()
- single: Py_XDECREF()
+ single: PyErr_ExceptionMatches (C function)
+ single: PyErr_Clear (C function)
+ single: Py_XDECREF (C function)
This example represents an endorsed use of the ``goto`` statement in C!
It illustrates the use of :c:func:`PyErr_ExceptionMatches` and
@@ -697,10 +735,10 @@ the finalization, of the Python interpreter. Most functionality of the
interpreter can only be used after the interpreter has been initialized.
.. index::
- single: Py_Initialize()
- module: builtins
- module: __main__
- module: sys
+ single: Py_Initialize (C function)
+ pair: module; builtins
+ pair: module; __main__
+ pair: module; sys
triple: module; search; path
single: path (in module sys)
@@ -732,11 +770,11 @@ environment variable :envvar:`PYTHONHOME`, or insert additional directories in
front of the standard path by setting :envvar:`PYTHONPATH`.
.. index::
- single: Py_SetProgramName()
- single: Py_GetPath()
- single: Py_GetPrefix()
- single: Py_GetExecPrefix()
- single: Py_GetProgramFullPath()
+ single: Py_SetProgramName (C function)
+ single: Py_GetPath (C function)
+ single: Py_GetPrefix (C function)
+ single: Py_GetExecPrefix (C function)
+ single: Py_GetProgramFullPath (C function)
The embedding application can steer the search by calling
``Py_SetProgramName(file)`` *before* calling :c:func:`Py_Initialize`. Note that
@@ -746,7 +784,7 @@ control has to provide its own implementation of :c:func:`Py_GetPath`,
:c:func:`Py_GetPrefix`, :c:func:`Py_GetExecPrefix`, and
:c:func:`Py_GetProgramFullPath` (all defined in :file:`Modules/getpath.c`).
-.. index:: single: Py_IsInitialized()
+.. index:: single: Py_IsInitialized (C function)
Sometimes, it is desirable to "uninitialize" Python. For instance, the
application may want to start over (make another call to
@@ -772,14 +810,16 @@ A full list of the various types of debugging builds is in the file
:file:`Misc/SpecialBuilds.txt` in the Python source distribution. Builds are
available that support tracing of reference counts, debugging the memory
allocator, or low-level profiling of the main interpreter loop. Only the most
-frequently-used builds will be described in the remainder of this section.
+frequently used builds will be described in the remainder of this section.
+
+.. c:macro:: Py_DEBUG
-Compiling the interpreter with the :c:macro:`Py_DEBUG` macro defined produces
+Compiling the interpreter with the :c:macro:`!Py_DEBUG` macro defined produces
what is generally meant by :ref:`a debug build of Python `.
-:c:macro:`Py_DEBUG` is enabled in the Unix build by adding
+:c:macro:`!Py_DEBUG` is enabled in the Unix build by adding
:option:`--with-pydebug` to the :file:`./configure` command.
It is also implied by the presence of the
-not-Python-specific :c:macro:`_DEBUG` macro. When :c:macro:`Py_DEBUG` is enabled
+not-Python-specific :c:macro:`!_DEBUG` macro. When :c:macro:`!Py_DEBUG` is enabled
in the Unix build, compiler optimization is disabled.
In addition to the reference count debugging described below, extra checks are
@@ -794,4 +834,3 @@ after every statement run by the interpreter.)
Please refer to :file:`Misc/SpecialBuilds.txt` in the Python source distribution
for more detailed information.
-
diff --git a/Doc/c-api/iterator.rst b/Doc/c-api/iterator.rst
index 3fcf099134d4dd..6b7ba8c9979163 100644
--- a/Doc/c-api/iterator.rst
+++ b/Doc/c-api/iterator.rst
@@ -6,7 +6,7 @@ Iterator Objects
----------------
Python provides two general-purpose iterator objects. The first, a sequence
-iterator, works with an arbitrary sequence supporting the :meth:`__getitem__`
+iterator, works with an arbitrary sequence supporting the :meth:`~object.__getitem__`
method. The second works with a callable object and a sentinel value, calling
the callable for each item in the sequence, and ending the iteration when the
sentinel value is returned.
@@ -19,7 +19,7 @@ sentinel value is returned.
types.
-.. c:function:: int PySeqIter_Check(op)
+.. c:function:: int PySeqIter_Check(PyObject *op)
Return true if the type of *op* is :c:data:`PySeqIter_Type`. This function
always succeeds.
@@ -38,7 +38,7 @@ sentinel value is returned.
two-argument form of the :func:`iter` built-in function.
-.. c:function:: int PyCallIter_Check(op)
+.. c:function:: int PyCallIter_Check(PyObject *op)
Return true if the type of *op* is :c:data:`PyCallIter_Type`. This
function always succeeds.
diff --git a/Doc/c-api/list.rst b/Doc/c-api/list.rst
index f9e65354a259f4..dbf35611eccd3e 100644
--- a/Doc/c-api/list.rst
+++ b/Doc/c-api/list.rst
@@ -5,7 +5,7 @@
List Objects
------------
-.. index:: object: list
+.. index:: pair: object; list
.. c:type:: PyListObject
@@ -45,7 +45,7 @@ List Objects
.. c:function:: Py_ssize_t PyList_Size(PyObject *list)
- .. index:: builtin: len
+ .. index:: pair: built-in function; len
Return the length of the list object in *list*; this is equivalent to
``len(list)`` on a list object.
@@ -138,7 +138,7 @@ List Objects
.. c:function:: PyObject* PyList_AsTuple(PyObject *list)
- .. index:: builtin: tuple
+ .. index:: pair: built-in function; tuple
Return a new tuple object containing the contents of *list*; equivalent to
``tuple(list)``.
diff --git a/Doc/c-api/long.rst b/Doc/c-api/long.rst
index 620344e71373b2..6138e08304b1b2 100644
--- a/Doc/c-api/long.rst
+++ b/Doc/c-api/long.rst
@@ -5,8 +5,8 @@
Integer Objects
---------------
-.. index:: object: long integer
- object: integer
+.. index:: pair: object; long integer
+ pair: object; integer
All integers are implemented as "long" integer objects of arbitrary size.
@@ -47,7 +47,7 @@ distinguished from a number. Use :c:func:`PyErr_Occurred` to disambiguate.
.. c:function:: PyObject* PyLong_FromUnsignedLong(unsigned long v)
- Return a new :c:type:`PyLongObject` object from a C :c:type:`unsigned long`, or
+ Return a new :c:type:`PyLongObject` object from a C :c:expr:`unsigned long`, or
``NULL`` on failure.
@@ -65,13 +65,13 @@ distinguished from a number. Use :c:func:`PyErr_Occurred` to disambiguate.
.. c:function:: PyObject* PyLong_FromLongLong(long long v)
- Return a new :c:type:`PyLongObject` object from a C :c:type:`long long`, or ``NULL``
+ Return a new :c:type:`PyLongObject` object from a C :c:expr:`long long`, or ``NULL``
on failure.
.. c:function:: PyObject* PyLong_FromUnsignedLongLong(unsigned long long v)
- Return a new :c:type:`PyLongObject` object from a C :c:type:`unsigned long long`,
+ Return a new :c:type:`PyLongObject` object from a C :c:expr:`unsigned long long`,
or ``NULL`` on failure.
@@ -93,6 +93,10 @@ distinguished from a number. Use :c:func:`PyErr_Occurred` to disambiguate.
underscores after a base specifier and between digits are ignored. If there
are no digits, :exc:`ValueError` will be raised.
+ .. seealso:: Python methods :meth:`int.to_bytes` and :meth:`int.from_bytes`
+ to convert a :c:type:`PyLongObject` to/from an array of bytes in base
+ ``256``. You can call those from C using :c:func:`PyObject_CallMethod`.
+
.. c:function:: PyObject* PyLong_FromUnicodeObject(PyObject *u, int base)
@@ -112,43 +116,43 @@ distinguished from a number. Use :c:func:`PyErr_Occurred` to disambiguate.
.. c:function:: long PyLong_AsLong(PyObject *obj)
.. index::
- single: LONG_MAX
+ single: LONG_MAX (C macro)
single: OverflowError (built-in exception)
- Return a C :c:type:`long` representation of *obj*. If *obj* is not an
- instance of :c:type:`PyLongObject`, first call its :meth:`__index__` method
+ Return a C :c:expr:`long` representation of *obj*. If *obj* is not an
+ instance of :c:type:`PyLongObject`, first call its :meth:`~object.__index__` method
(if present) to convert it to a :c:type:`PyLongObject`.
Raise :exc:`OverflowError` if the value of *obj* is out of range for a
- :c:type:`long`.
+ :c:expr:`long`.
Returns ``-1`` on error. Use :c:func:`PyErr_Occurred` to disambiguate.
.. versionchanged:: 3.8
- Use :meth:`__index__` if available.
+ Use :meth:`~object.__index__` if available.
.. versionchanged:: 3.10
- This function will no longer use :meth:`__int__`.
+ This function will no longer use :meth:`~object.__int__`.
.. c:function:: long PyLong_AsLongAndOverflow(PyObject *obj, int *overflow)
- Return a C :c:type:`long` representation of *obj*. If *obj* is not an
- instance of :c:type:`PyLongObject`, first call its :meth:`__index__`
+ Return a C :c:expr:`long` representation of *obj*. If *obj* is not an
+ instance of :c:type:`PyLongObject`, first call its :meth:`~object.__index__`
method (if present) to convert it to a :c:type:`PyLongObject`.
- If the value of *obj* is greater than :const:`LONG_MAX` or less than
- :const:`LONG_MIN`, set *\*overflow* to ``1`` or ``-1``, respectively, and
+ If the value of *obj* is greater than :c:macro:`LONG_MAX` or less than
+ :c:macro:`LONG_MIN`, set *\*overflow* to ``1`` or ``-1``, respectively, and
return ``-1``; otherwise, set *\*overflow* to ``0``. If any other exception
occurs set *\*overflow* to ``0`` and return ``-1`` as usual.
Returns ``-1`` on error. Use :c:func:`PyErr_Occurred` to disambiguate.
.. versionchanged:: 3.8
- Use :meth:`__index__` if available.
+ Use :meth:`~object.__index__` if available.
.. versionchanged:: 3.10
- This function will no longer use :meth:`__int__`.
+ This function will no longer use :meth:`~object.__int__`.
.. c:function:: long long PyLong_AsLongLong(PyObject *obj)
@@ -156,30 +160,30 @@ distinguished from a number. Use :c:func:`PyErr_Occurred` to disambiguate.
.. index::
single: OverflowError (built-in exception)
- Return a C :c:type:`long long` representation of *obj*. If *obj* is not an
- instance of :c:type:`PyLongObject`, first call its :meth:`__index__` method
+ Return a C :c:expr:`long long` representation of *obj*. If *obj* is not an
+ instance of :c:type:`PyLongObject`, first call its :meth:`~object.__index__` method
(if present) to convert it to a :c:type:`PyLongObject`.
Raise :exc:`OverflowError` if the value of *obj* is out of range for a
- :c:type:`long long`.
+ :c:expr:`long long`.
Returns ``-1`` on error. Use :c:func:`PyErr_Occurred` to disambiguate.
.. versionchanged:: 3.8
- Use :meth:`__index__` if available.
+ Use :meth:`~object.__index__` if available.
.. versionchanged:: 3.10
- This function will no longer use :meth:`__int__`.
+ This function will no longer use :meth:`~object.__int__`.
.. c:function:: long long PyLong_AsLongLongAndOverflow(PyObject *obj, int *overflow)
- Return a C :c:type:`long long` representation of *obj*. If *obj* is not an
- instance of :c:type:`PyLongObject`, first call its :meth:`__index__` method
+ Return a C :c:expr:`long long` representation of *obj*. If *obj* is not an
+ instance of :c:type:`PyLongObject`, first call its :meth:`~object.__index__` method
(if present) to convert it to a :c:type:`PyLongObject`.
- If the value of *obj* is greater than :const:`LLONG_MAX` or less than
- :const:`LLONG_MIN`, set *\*overflow* to ``1`` or ``-1``, respectively,
+ If the value of *obj* is greater than :c:macro:`LLONG_MAX` or less than
+ :c:macro:`LLONG_MIN`, set *\*overflow* to ``1`` or ``-1``, respectively,
and return ``-1``; otherwise, set *\*overflow* to ``0``. If any other
exception occurs set *\*overflow* to ``0`` and return ``-1`` as usual.
@@ -188,16 +192,16 @@ distinguished from a number. Use :c:func:`PyErr_Occurred` to disambiguate.
.. versionadded:: 3.2
.. versionchanged:: 3.8
- Use :meth:`__index__` if available.
+ Use :meth:`~object.__index__` if available.
.. versionchanged:: 3.10
- This function will no longer use :meth:`__int__`.
+ This function will no longer use :meth:`~object.__int__`.
.. c:function:: Py_ssize_t PyLong_AsSsize_t(PyObject *pylong)
.. index::
- single: PY_SSIZE_T_MAX
+ single: PY_SSIZE_T_MAX (C macro)
single: OverflowError (built-in exception)
Return a C :c:type:`Py_ssize_t` representation of *pylong*. *pylong* must
@@ -212,14 +216,14 @@ distinguished from a number. Use :c:func:`PyErr_Occurred` to disambiguate.
.. c:function:: unsigned long PyLong_AsUnsignedLong(PyObject *pylong)
.. index::
- single: ULONG_MAX
+ single: ULONG_MAX (C macro)
single: OverflowError (built-in exception)
- Return a C :c:type:`unsigned long` representation of *pylong*. *pylong*
+ Return a C :c:expr:`unsigned long` representation of *pylong*. *pylong*
must be an instance of :c:type:`PyLongObject`.
Raise :exc:`OverflowError` if the value of *pylong* is out of range for a
- :c:type:`unsigned long`.
+ :c:expr:`unsigned long`.
Returns ``(unsigned long)-1`` on error.
Use :c:func:`PyErr_Occurred` to disambiguate.
@@ -228,7 +232,7 @@ distinguished from a number. Use :c:func:`PyErr_Occurred` to disambiguate.
.. c:function:: size_t PyLong_AsSize_t(PyObject *pylong)
.. index::
- single: SIZE_MAX
+ single: SIZE_MAX (C macro)
single: OverflowError (built-in exception)
Return a C :c:type:`size_t` representation of *pylong*. *pylong* must be
@@ -246,11 +250,11 @@ distinguished from a number. Use :c:func:`PyErr_Occurred` to disambiguate.
.. index::
single: OverflowError (built-in exception)
- Return a C :c:type:`unsigned long long` representation of *pylong*. *pylong*
+ Return a C :c:expr:`unsigned long long` representation of *pylong*. *pylong*
must be an instance of :c:type:`PyLongObject`.
Raise :exc:`OverflowError` if the value of *pylong* is out of range for an
- :c:type:`unsigned long long`.
+ :c:expr:`unsigned long long`.
Returns ``(unsigned long long)-1`` on error.
Use :c:func:`PyErr_Occurred` to disambiguate.
@@ -261,59 +265,59 @@ distinguished from a number. Use :c:func:`PyErr_Occurred` to disambiguate.
.. c:function:: unsigned long PyLong_AsUnsignedLongMask(PyObject *obj)
- Return a C :c:type:`unsigned long` representation of *obj*. If *obj* is not
- an instance of :c:type:`PyLongObject`, first call its :meth:`__index__`
+ Return a C :c:expr:`unsigned long` representation of *obj*. If *obj* is not
+ an instance of :c:type:`PyLongObject`, first call its :meth:`~object.__index__`
method (if present) to convert it to a :c:type:`PyLongObject`.
- If the value of *obj* is out of range for an :c:type:`unsigned long`,
+ If the value of *obj* is out of range for an :c:expr:`unsigned long`,
return the reduction of that value modulo ``ULONG_MAX + 1``.
Returns ``(unsigned long)-1`` on error. Use :c:func:`PyErr_Occurred` to
disambiguate.
.. versionchanged:: 3.8
- Use :meth:`__index__` if available.
+ Use :meth:`~object.__index__` if available.
.. versionchanged:: 3.10
- This function will no longer use :meth:`__int__`.
+ This function will no longer use :meth:`~object.__int__`.
.. c:function:: unsigned long long PyLong_AsUnsignedLongLongMask(PyObject *obj)
- Return a C :c:type:`unsigned long long` representation of *obj*. If *obj*
+ Return a C :c:expr:`unsigned long long` representation of *obj*. If *obj*
is not an instance of :c:type:`PyLongObject`, first call its
- :meth:`__index__` method (if present) to convert it to a
+ :meth:`~object.__index__` method (if present) to convert it to a
:c:type:`PyLongObject`.
- If the value of *obj* is out of range for an :c:type:`unsigned long long`,
+ If the value of *obj* is out of range for an :c:expr:`unsigned long long`,
return the reduction of that value modulo ``ULLONG_MAX + 1``.
Returns ``(unsigned long long)-1`` on error. Use :c:func:`PyErr_Occurred`
to disambiguate.
.. versionchanged:: 3.8
- Use :meth:`__index__` if available.
+ Use :meth:`~object.__index__` if available.
.. versionchanged:: 3.10
- This function will no longer use :meth:`__int__`.
+ This function will no longer use :meth:`~object.__int__`.
.. c:function:: double PyLong_AsDouble(PyObject *pylong)
- Return a C :c:type:`double` representation of *pylong*. *pylong* must be
+ Return a C :c:expr:`double` representation of *pylong*. *pylong* must be
an instance of :c:type:`PyLongObject`.
Raise :exc:`OverflowError` if the value of *pylong* is out of range for a
- :c:type:`double`.
+ :c:expr:`double`.
Returns ``-1.0`` on error. Use :c:func:`PyErr_Occurred` to disambiguate.
.. c:function:: void* PyLong_AsVoidPtr(PyObject *pylong)
- Convert a Python integer *pylong* to a C :c:type:`void` pointer.
+ Convert a Python integer *pylong* to a C :c:expr:`void` pointer.
If *pylong* cannot be converted, an :exc:`OverflowError` will be raised. This
- is only assured to produce a usable :c:type:`void` pointer for values created
+ is only assured to produce a usable :c:expr:`void` pointer for values created
with :c:func:`PyLong_FromVoidPtr`.
Returns ``NULL`` on error. Use :c:func:`PyErr_Occurred` to disambiguate.
diff --git a/Doc/c-api/mapping.rst b/Doc/c-api/mapping.rst
index 3c9d282c6d0ab0..0c42b9177bb56d 100644
--- a/Doc/c-api/mapping.rst
+++ b/Doc/c-api/mapping.rst
@@ -13,14 +13,14 @@ See also :c:func:`PyObject_GetItem`, :c:func:`PyObject_SetItem` and
Return ``1`` if the object provides the mapping protocol or supports slicing,
and ``0`` otherwise. Note that it returns ``1`` for Python classes with
- a :meth:`__getitem__` method, since in general it is impossible to
+ a :meth:`~object.__getitem__` method, since in general it is impossible to
determine what type of keys the class supports. This function always succeeds.
.. c:function:: Py_ssize_t PyMapping_Size(PyObject *o)
Py_ssize_t PyMapping_Length(PyObject *o)
- .. index:: builtin: len
+ .. index:: pair: built-in function; len
Returns the number of keys in object *o* on success, and ``-1`` on failure.
This is equivalent to the Python expression ``len(o)``.
@@ -28,30 +28,28 @@ See also :c:func:`PyObject_GetItem`, :c:func:`PyObject_SetItem` and
.. c:function:: PyObject* PyMapping_GetItemString(PyObject *o, const char *key)
- Return element of *o* corresponding to the string *key* or ``NULL`` on failure.
- This is the equivalent of the Python expression ``o[key]``.
- See also :c:func:`PyObject_GetItem`.
+ This is the same as :c:func:`PyObject_GetItem`, but *key* is
+ specified as a :c:expr:`const char*` UTF-8 encoded bytes string,
+ rather than a :c:expr:`PyObject*`.
.. c:function:: int PyMapping_SetItemString(PyObject *o, const char *key, PyObject *v)
- Map the string *key* to the value *v* in object *o*. Returns ``-1`` on
- failure. This is the equivalent of the Python statement ``o[key] = v``.
- See also :c:func:`PyObject_SetItem`. This function *does not* steal a
- reference to *v*.
+ This is the same as :c:func:`PyObject_SetItem`, but *key* is
+ specified as a :c:expr:`const char*` UTF-8 encoded bytes string,
+ rather than a :c:expr:`PyObject*`.
.. c:function:: int PyMapping_DelItem(PyObject *o, PyObject *key)
- Remove the mapping for the object *key* from the object *o*. Return ``-1``
- on failure. This is equivalent to the Python statement ``del o[key]``.
This is an alias of :c:func:`PyObject_DelItem`.
.. c:function:: int PyMapping_DelItemString(PyObject *o, const char *key)
- Remove the mapping for the string *key* from the object *o*. Return ``-1``
- on failure. This is equivalent to the Python statement ``del o[key]``.
+ This is the same as :c:func:`PyObject_DelItem`, but *key* is
+ specified as a :c:expr:`const char*` UTF-8 encoded bytes string,
+ rather than a :c:expr:`PyObject*`.
.. c:function:: int PyMapping_HasKey(PyObject *o, PyObject *key)
@@ -60,20 +58,25 @@ See also :c:func:`PyObject_GetItem`, :c:func:`PyObject_SetItem` and
This is equivalent to the Python expression ``key in o``.
This function always succeeds.
- Note that exceptions which occur while calling the :meth:`__getitem__`
- method will get suppressed.
- To get error reporting use :c:func:`PyObject_GetItem()` instead.
+ .. note::
+
+ Exceptions which occur when this calls :meth:`~object.__getitem__`
+ method are silently ignored.
+ For proper error handling, use :c:func:`PyObject_GetItem()` instead.
.. c:function:: int PyMapping_HasKeyString(PyObject *o, const char *key)
- Return ``1`` if the mapping object has the key *key* and ``0`` otherwise.
- This is equivalent to the Python expression ``key in o``.
- This function always succeeds.
+ This is the same as :c:func:`PyMapping_HasKey`, but *key* is
+ specified as a :c:expr:`const char*` UTF-8 encoded bytes string,
+ rather than a :c:expr:`PyObject*`.
+
+ .. note::
- Note that exceptions which occur while calling the :meth:`__getitem__`
- method and creating a temporary string object will get suppressed.
- To get error reporting use :c:func:`PyMapping_GetItemString()` instead.
+ Exceptions that occur when this calls :meth:`~object.__getitem__`
+ method or while creating the temporary :class:`str`
+ object are silently ignored.
+ For proper error handling, use :c:func:`PyMapping_GetItemString` instead.
.. c:function:: PyObject* PyMapping_Keys(PyObject *o)
diff --git a/Doc/c-api/marshal.rst b/Doc/c-api/marshal.rst
index 7bb0dad2b6b6d5..489f1580a414b2 100644
--- a/Doc/c-api/marshal.rst
+++ b/Doc/c-api/marshal.rst
@@ -21,16 +21,20 @@ unmarshalling. Version 2 uses a binary format for floating point numbers.
.. c:function:: void PyMarshal_WriteLongToFile(long value, FILE *file, int version)
- Marshal a :c:type:`long` integer, *value*, to *file*. This will only write
+ Marshal a :c:expr:`long` integer, *value*, to *file*. This will only write
the least-significant 32 bits of *value*; regardless of the size of the
- native :c:type:`long` type. *version* indicates the file format.
+ native :c:expr:`long` type. *version* indicates the file format.
+ This function can fail, in which case it sets the error indicator.
+ Use :c:func:`PyErr_Occurred` to check for that.
.. c:function:: void PyMarshal_WriteObjectToFile(PyObject *value, FILE *file, int version)
Marshal a Python object, *value*, to *file*.
*version* indicates the file format.
+ This function can fail, in which case it sets the error indicator.
+ Use :c:func:`PyErr_Occurred` to check for that.
.. c:function:: PyObject* PyMarshal_WriteObjectToString(PyObject *value, int version)
@@ -43,9 +47,9 @@ The following functions allow marshalled values to be read back in.
.. c:function:: long PyMarshal_ReadLongFromFile(FILE *file)
- Return a C :c:type:`long` from the data stream in a :c:type:`FILE*` opened
+ Return a C :c:expr:`long` from the data stream in a :c:expr:`FILE*` opened
for reading. Only a 32-bit value can be read in using this function,
- regardless of the native size of :c:type:`long`.
+ regardless of the native size of :c:expr:`long`.
On error, sets the appropriate exception (:exc:`EOFError`) and returns
``-1``.
@@ -53,9 +57,9 @@ The following functions allow marshalled values to be read back in.
.. c:function:: int PyMarshal_ReadShortFromFile(FILE *file)
- Return a C :c:type:`short` from the data stream in a :c:type:`FILE*` opened
+ Return a C :c:expr:`short` from the data stream in a :c:expr:`FILE*` opened
for reading. Only a 16-bit value can be read in using this function,
- regardless of the native size of :c:type:`short`.
+ regardless of the native size of :c:expr:`short`.
On error, sets the appropriate exception (:exc:`EOFError`) and returns
``-1``.
@@ -63,7 +67,7 @@ The following functions allow marshalled values to be read back in.
.. c:function:: PyObject* PyMarshal_ReadObjectFromFile(FILE *file)
- Return a Python object from the data stream in a :c:type:`FILE*` opened for
+ Return a Python object from the data stream in a :c:expr:`FILE*` opened for
reading.
On error, sets the appropriate exception (:exc:`EOFError`, :exc:`ValueError`
@@ -72,7 +76,7 @@ The following functions allow marshalled values to be read back in.
.. c:function:: PyObject* PyMarshal_ReadLastObjectFromFile(FILE *file)
- Return a Python object from the data stream in a :c:type:`FILE*` opened for
+ Return a Python object from the data stream in a :c:expr:`FILE*` opened for
reading. Unlike :c:func:`PyMarshal_ReadObjectFromFile`, this function
assumes that no further objects will be read from the file, allowing it to
aggressively load file data into memory so that the de-serialization can
diff --git a/Doc/c-api/memory.rst b/Doc/c-api/memory.rst
index 987dea40dd674e..81c5b0b48b839d 100644
--- a/Doc/c-api/memory.rst
+++ b/Doc/c-api/memory.rst
@@ -41,10 +41,10 @@ buffers is performed on demand by the Python memory manager through the Python/C
API functions listed in this document.
.. index::
- single: malloc()
- single: calloc()
- single: realloc()
- single: free()
+ single: malloc (C function)
+ single: calloc (C function)
+ single: realloc (C function)
+ single: free (C function)
To avoid memory corruption, extension writers should never try to operate on
Python objects with the functions exported by the C library: :c:func:`malloc`,
@@ -75,7 +75,7 @@ memory manager. For example, this is required when the interpreter is extended
with new object types written in C. Another reason for using the Python heap is
the desire to *inform* the Python memory manager about the memory needs of the
extension module. Even when the requested memory is used exclusively for
-internal, highly-specific purposes, delegating all memory requests to the Python
+internal, highly specific purposes, delegating all memory requests to the Python
memory manager causes the interpreter to have a more accurate image of its
memory footprint as a whole. Consequently, under certain circumstances, the
Python memory manager may or may not trigger appropriate actions, like garbage
@@ -95,6 +95,8 @@ for the I/O buffer escapes completely the Python memory manager.
Allocator Domains
=================
+.. _allocator-domains:
+
All allocating functions belong to one of three different "domains" (see also
:c:type:`PyMemAllocatorDomain`). These domains represent different allocation
strategies and are optimized for different purposes. The specific details on
@@ -134,14 +136,14 @@ need to be held.
The :ref:`default raw memory allocator ` uses
the following functions: :c:func:`malloc`, :c:func:`calloc`, :c:func:`realloc`
-and :c:func:`free`; call ``malloc(1)`` (or ``calloc(1, 1)``) when requesting
+and :c:func:`!free`; call ``malloc(1)`` (or ``calloc(1, 1)``) when requesting
zero bytes.
.. versionadded:: 3.4
.. c:function:: void* PyMem_RawMalloc(size_t n)
- Allocates *n* bytes and returns a pointer of type :c:type:`void*` to the
+ Allocates *n* bytes and returns a pointer of type :c:expr:`void*` to the
allocated memory, or ``NULL`` if the request fails.
Requesting zero bytes returns a distinct non-``NULL`` pointer if possible, as
@@ -152,7 +154,7 @@ zero bytes.
.. c:function:: void* PyMem_RawCalloc(size_t nelem, size_t elsize)
Allocates *nelem* elements each whose size in bytes is *elsize* and returns
- a pointer of type :c:type:`void*` to the allocated memory, or ``NULL`` if the
+ a pointer of type :c:expr:`void*` to the allocated memory, or ``NULL`` if the
request fails. The memory is initialized to zeros.
Requesting zero elements or elements of size zero bytes returns a distinct
@@ -212,7 +214,7 @@ The :ref:`default memory allocator ` uses the
.. c:function:: void* PyMem_Malloc(size_t n)
- Allocates *n* bytes and returns a pointer of type :c:type:`void*` to the
+ Allocates *n* bytes and returns a pointer of type :c:expr:`void*` to the
allocated memory, or ``NULL`` if the request fails.
Requesting zero bytes returns a distinct non-``NULL`` pointer if possible, as
@@ -223,7 +225,7 @@ The :ref:`default memory allocator ` uses the
.. c:function:: void* PyMem_Calloc(size_t nelem, size_t elsize)
Allocates *nelem* elements each whose size in bytes is *elsize* and returns
- a pointer of type :c:type:`void*` to the allocated memory, or ``NULL`` if the
+ a pointer of type :c:expr:`void*` to the allocated memory, or ``NULL`` if the
request fails. The memory is initialized to zeros.
Requesting zero elements or elements of size zero bytes returns a distinct
@@ -262,17 +264,17 @@ The following type-oriented macros are provided for convenience. Note that
*TYPE* refers to any C type.
-.. c:function:: TYPE* PyMem_New(TYPE, size_t n)
+.. c:macro:: PyMem_New(TYPE, n)
Same as :c:func:`PyMem_Malloc`, but allocates ``(n * sizeof(TYPE))`` bytes of
- memory. Returns a pointer cast to :c:type:`TYPE*`. The memory will not have
+ memory. Returns a pointer cast to ``TYPE*``. The memory will not have
been initialized in any way.
-.. c:function:: TYPE* PyMem_Resize(void *p, TYPE, size_t n)
+.. c:macro:: PyMem_Resize(p, TYPE, n)
Same as :c:func:`PyMem_Realloc`, but the memory block is resized to ``(n *
- sizeof(TYPE))`` bytes. Returns a pointer cast to :c:type:`TYPE*`. On return,
+ sizeof(TYPE))`` bytes. Returns a pointer cast to ``TYPE*``. On return,
*p* will be a pointer to the new memory area, or ``NULL`` in the event of
failure.
@@ -320,7 +322,7 @@ The :ref:`default object allocator ` uses the
.. c:function:: void* PyObject_Malloc(size_t n)
- Allocates *n* bytes and returns a pointer of type :c:type:`void*` to the
+ Allocates *n* bytes and returns a pointer of type :c:expr:`void*` to the
allocated memory, or ``NULL`` if the request fails.
Requesting zero bytes returns a distinct non-``NULL`` pointer if possible, as
@@ -331,7 +333,7 @@ The :ref:`default object allocator ` uses the
.. c:function:: void* PyObject_Calloc(size_t nelem, size_t elsize)
Allocates *nelem* elements each whose size in bytes is *elsize* and returns
- a pointer of type :c:type:`void*` to the allocated memory, or ``NULL`` if the
+ a pointer of type :c:expr:`void*` to the allocated memory, or ``NULL`` if the
request fails. The memory is initialized to zeros.
Requesting zero elements or elements of size zero bytes returns a distinct
@@ -421,7 +423,7 @@ Customize Memory Allocators
+----------------------------------------------------------+---------------------------------------+
.. versionchanged:: 3.5
- The :c:type:`PyMemAllocator` structure was renamed to
+ The :c:type:`!PyMemAllocator` structure was renamed to
:c:type:`PyMemAllocatorEx` and a new ``calloc`` field was added.
@@ -429,6 +431,8 @@ Customize Memory Allocators
Enum used to identify an allocator domain. Domains:
+ .. c:namespace:: NULL
+
.. c:macro:: PYMEM_DOMAIN_RAW
Functions:
@@ -468,7 +472,7 @@ Customize Memory Allocators
The new allocator must return a distinct non-``NULL`` pointer when requesting
zero bytes.
- For the :c:data:`PYMEM_DOMAIN_RAW` domain, the allocator must be
+ For the :c:macro:`PYMEM_DOMAIN_RAW` domain, the allocator must be
thread-safe: the :term:`GIL ` is not held when the
allocator is called.
@@ -479,6 +483,25 @@ Customize Memory Allocators
See also :c:member:`PyPreConfig.allocator` and :ref:`Preinitialize Python
with PyPreConfig `.
+ .. warning::
+
+ :c:func:`PyMem_SetAllocator` does have the following contract:
+
+ * It can be called after :c:func:`Py_PreInitialize` and before
+ :c:func:`Py_InitializeFromConfig` to install a custom memory
+ allocator. There are no restrictions over the installed allocator
+ other than the ones imposed by the domain (for instance, the Raw
+ Domain allows the allocator to be called without the GIL held). See
+ :ref:`the section on allocator domains ` for more
+ information.
+
+ * If called after Python has finish initializing (after
+ :c:func:`Py_InitializeFromConfig` has been called) the allocator
+ **must** wrap the existing allocator. Substituting the current
+ allocator for some other arbitrary one is **not supported**.
+
+
+
.. c:function:: void PyMem_SetupDebugHooks(void)
Setup :ref:`debug hooks in the Python memory allocators `
@@ -515,8 +538,8 @@ Runtime checks:
- Detect write before the start of the buffer (buffer underflow).
- Detect write after the end of the buffer (buffer overflow).
- Check that the :term:`GIL ` is held when
- allocator functions of :c:data:`PYMEM_DOMAIN_OBJ` (ex:
- :c:func:`PyObject_Malloc`) and :c:data:`PYMEM_DOMAIN_MEM` (ex:
+ allocator functions of :c:macro:`PYMEM_DOMAIN_OBJ` (ex:
+ :c:func:`PyObject_Malloc`) and :c:macro:`PYMEM_DOMAIN_MEM` (ex:
:c:func:`PyMem_Malloc`) domains are called.
On error, the debug hooks use the :mod:`tracemalloc` module to get the
@@ -536,9 +559,9 @@ that the treatment of negative indices differs from a Python slice):
``p[-S]``
API identifier (ASCII character):
- * ``'r'`` for :c:data:`PYMEM_DOMAIN_RAW`.
- * ``'m'`` for :c:data:`PYMEM_DOMAIN_MEM`.
- * ``'o'`` for :c:data:`PYMEM_DOMAIN_OBJ`.
+ * ``'r'`` for :c:macro:`PYMEM_DOMAIN_RAW`.
+ * ``'m'`` for :c:macro:`PYMEM_DOMAIN_MEM`.
+ * ``'o'`` for :c:macro:`PYMEM_DOMAIN_OBJ`.
``p[-S+1:0]``
Copies of PYMEM_FORBIDDENBYTE. Used to catch under- writes and reads.
@@ -560,7 +583,7 @@ that the treatment of negative indices differs from a Python slice):
default).
A serial number, incremented by 1 on each call to a malloc-like or
- realloc-like function. Big-endian ``size_t``. If "bad memory" is detected
+ realloc-like function. Big-endian :c:type:`size_t`. If "bad memory" is detected
later, the serial number gives an excellent way to set a breakpoint on the
next run, to capture the instant at which this block was passed out. The
static function bumpserialno() in obmalloc.c is the only place the serial
@@ -580,7 +603,7 @@ PYMEM_CLEANBYTE (meaning uninitialized memory is getting used).
compiled in release mode. On error, the debug hooks now use
:mod:`tracemalloc` to get the traceback where a memory block was allocated.
The debug hooks now also check if the GIL is held when functions of
- :c:data:`PYMEM_DOMAIN_OBJ` and :c:data:`PYMEM_DOMAIN_MEM` domains are
+ :c:macro:`PYMEM_DOMAIN_OBJ` and :c:macro:`PYMEM_DOMAIN_MEM` domains are
called.
.. versionchanged:: 3.8
@@ -597,17 +620,18 @@ The pymalloc allocator
Python has a *pymalloc* allocator optimized for small objects (smaller or equal
to 512 bytes) with a short lifetime. It uses memory mappings called "arenas"
-with a fixed size of 256 KiB. It falls back to :c:func:`PyMem_RawMalloc` and
+with a fixed size of either 256 KiB on 32-bit platforms or 1 MiB on 64-bit
+platforms. It falls back to :c:func:`PyMem_RawMalloc` and
:c:func:`PyMem_RawRealloc` for allocations larger than 512 bytes.
*pymalloc* is the :ref:`default allocator ` of the
-:c:data:`PYMEM_DOMAIN_MEM` (ex: :c:func:`PyMem_Malloc`) and
-:c:data:`PYMEM_DOMAIN_OBJ` (ex: :c:func:`PyObject_Malloc`) domains.
+:c:macro:`PYMEM_DOMAIN_MEM` (ex: :c:func:`PyMem_Malloc`) and
+:c:macro:`PYMEM_DOMAIN_OBJ` (ex: :c:func:`PyObject_Malloc`) domains.
The arena allocator uses the following functions:
-* :c:func:`VirtualAlloc` and :c:func:`VirtualFree` on Windows,
-* :c:func:`mmap` and :c:func:`munmap` if available,
+* :c:func:`!VirtualAlloc` and :c:func:`!VirtualFree` on Windows,
+* :c:func:`!mmap` and :c:func:`!munmap` if available,
* :c:func:`malloc` and :c:func:`free` otherwise.
This allocator is disabled if Python is configured with the
@@ -711,8 +735,8 @@ allocators operating on different heaps. ::
free(buf1); /* Fatal -- should be PyMem_Del() */
In addition to the functions aimed at handling raw memory blocks from the Python
-heap, objects in Python are allocated and released with :c:func:`PyObject_New`,
-:c:func:`PyObject_NewVar` and :c:func:`PyObject_Del`.
+heap, objects in Python are allocated and released with :c:macro:`PyObject_New`,
+:c:macro:`PyObject_NewVar` and :c:func:`PyObject_Del`.
These will be explained in the next chapter on defining and implementing new
object types in C.
diff --git a/Doc/c-api/memoryview.rst b/Doc/c-api/memoryview.rst
index 4d94b3f545f327..f6038032805259 100644
--- a/Doc/c-api/memoryview.rst
+++ b/Doc/c-api/memoryview.rst
@@ -3,7 +3,7 @@
.. _memoryview-objects:
.. index::
- object: memoryview
+ pair: object; memoryview
MemoryView objects
------------------
@@ -20,6 +20,17 @@ any other object.
read/write, otherwise it may be either read-only or read/write at the
discretion of the exporter.
+
+.. c:macro:: PyBUF_READ
+
+ Flag to request a readonly buffer.
+
+
+.. c:macro:: PyBUF_WRITE
+
+ Flag to request a writable buffer.
+
+
.. c:function:: PyObject *PyMemoryView_FromMemory(char *mem, Py_ssize_t size, int flags)
Create a memoryview object using *mem* as the underlying buffer.
@@ -41,6 +52,8 @@ any other object.
original memory. Otherwise, a copy is made and the memoryview points to a
new bytes object.
+ *buffertype* can be one of :c:macro:`PyBUF_READ` or :c:macro:`PyBUF_WRITE`.
+
.. c:function:: int PyMemoryView_Check(PyObject *obj)
@@ -55,7 +68,7 @@ any other object.
*mview* **must** be a memoryview instance; this macro doesn't check its type,
you must do it yourself or you will risk crashes.
-.. c:function:: Py_buffer *PyMemoryView_GET_BASE(PyObject *mview)
+.. c:function:: PyObject *PyMemoryView_GET_BASE(PyObject *mview)
Return either a pointer to the exporting object that the memoryview is based
on or ``NULL`` if the memoryview has been created by one of the functions
diff --git a/Doc/c-api/method.rst b/Doc/c-api/method.rst
index 6e7e1e21aa93f2..0d75ab8e1af111 100644
--- a/Doc/c-api/method.rst
+++ b/Doc/c-api/method.rst
@@ -5,10 +5,10 @@
Instance Method Objects
-----------------------
-.. index:: object: instancemethod
+.. index:: pair: object; instancemethod
-An instance method is a wrapper for a :c:data:`PyCFunction` and the new way
-to bind a :c:data:`PyCFunction` to a class object. It replaces the former call
+An instance method is a wrapper for a :c:type:`PyCFunction` and the new way
+to bind a :c:type:`PyCFunction` to a class object. It replaces the former call
``PyMethod_New(func, NULL, class)``.
@@ -47,7 +47,7 @@ to bind a :c:data:`PyCFunction` to a class object. It replaces the former call
Method Objects
--------------
-.. index:: object: method
+.. index:: pair: object; method
Methods are bound function objects. Methods are always bound to an instance of
a user-defined class. Unbound methods (methods bound to a class object) are
diff --git a/Doc/c-api/module.rst b/Doc/c-api/module.rst
index 94c8d9f981713f..71a079a8e67f4f 100644
--- a/Doc/c-api/module.rst
+++ b/Doc/c-api/module.rst
@@ -5,7 +5,7 @@
Module Objects
--------------
-.. index:: object: module
+.. index:: pair: object; module
.. c:var:: PyTypeObject PyModule_Type
@@ -64,8 +64,8 @@ Module Objects
If *module* is not a module object (or a subtype of a module object),
:exc:`SystemError` is raised and ``NULL`` is returned.
- It is recommended extensions use other :c:func:`PyModule_\*` and
- :c:func:`PyObject_\*` functions rather than directly manipulate a module's
+ It is recommended extensions use other ``PyModule_*`` and
+ ``PyObject_*`` functions rather than directly manipulate a module's
:attr:`~object.__dict__`.
@@ -119,7 +119,7 @@ Module Objects
encoded to 'utf-8'.
.. deprecated:: 3.2
- :c:func:`PyModule_GetFilename` raises :c:type:`UnicodeEncodeError` on
+ :c:func:`PyModule_GetFilename` raises :exc:`UnicodeEncodeError` on
unencodable filenames, use :c:func:`PyModule_GetFilenameObject` instead.
@@ -145,7 +145,7 @@ or request "multi-phase initialization" by returning the definition struct itsel
.. c:member:: PyModuleDef_Base m_base
- Always initialize this member to :const:`PyModuleDef_HEAD_INIT`.
+ Always initialize this member to :c:macro:`PyModuleDef_HEAD_INIT`.
.. c:member:: const char *m_name
@@ -164,7 +164,7 @@ or request "multi-phase initialization" by returning the definition struct itsel
This memory area is allocated based on *m_size* on module creation,
and freed when the module object is deallocated, after the
- :c:member:`m_free` function has been called, if present.
+ :c:member:`~PyModuleDef.m_free` function has been called, if present.
Setting ``m_size`` to ``-1`` means that the module does not support
sub-interpreters, because it has global state.
@@ -202,7 +202,7 @@ or request "multi-phase initialization" by returning the definition struct itsel
This function is not called if the module state was requested but is not
allocated yet. This is the case immediately after the module is created
and before the module is executed (:c:data:`Py_mod_exec` function). More
- precisely, this function is not called if :c:member:`m_size` is greater
+ precisely, this function is not called if :c:member:`~PyModuleDef.m_size` is greater
than 0 and the module state (as returned by :c:func:`PyModule_GetState`)
is ``NULL``.
@@ -217,7 +217,7 @@ or request "multi-phase initialization" by returning the definition struct itsel
This function is not called if the module state was requested but is not
allocated yet. This is the case immediately after the module is created
and before the module is executed (:c:data:`Py_mod_exec` function). More
- precisely, this function is not called if :c:member:`m_size` is greater
+ precisely, this function is not called if :c:member:`~PyModuleDef.m_size` is greater
than 0 and the module state (as returned by :c:func:`PyModule_GetState`)
is ``NULL``.
@@ -238,7 +238,7 @@ or request "multi-phase initialization" by returning the definition struct itsel
This function is not called if the module state was requested but is not
allocated yet. This is the case immediately after the module is created
and before the module is executed (:c:data:`Py_mod_exec` function). More
- precisely, this function is not called if :c:member:`m_size` is greater
+ precisely, this function is not called if :c:member:`~PyModuleDef.m_size` is greater
than 0 and the module state (as returned by :c:func:`PyModule_GetState`)
is ``NULL``.
@@ -256,7 +256,7 @@ of the following two module creation functions:
Create a new module object, given the definition in *def*. This behaves
like :c:func:`PyModule_Create2` with *module_api_version* set to
- :const:`PYTHON_API_VERSION`.
+ :c:macro:`PYTHON_API_VERSION`.
.. c:function:: PyObject* PyModule_Create2(PyModuleDef *def, int module_api_version)
@@ -282,7 +282,7 @@ An alternate way to specify extensions is to request "multi-phase initialization
Extension modules created this way behave more like Python modules: the
initialization is split between the *creation phase*, when the module object
is created, and the *execution phase*, when it is populated.
-The distinction is similar to the :py:meth:`__new__` and :py:meth:`__init__` methods
+The distinction is similar to the :py:meth:`!__new__` and :py:meth:`!__init__` methods
of classes.
Unlike modules created using single-phase initialization, these modules are not
@@ -293,7 +293,7 @@ By default, multiple modules created from the same definition should be
independent: changes to one should not affect the others.
This means that all state should be specific to the module object (using e.g.
using :c:func:`PyModule_GetState`), or its contents (such as the module's
-:attr:`__dict__` or individual classes created with :c:func:`PyType_FromSpec`).
+:attr:`~object.__dict__` or individual classes created with :c:func:`PyType_FromSpec`).
All modules created using multi-phase initialization are expected to support
:ref:`sub-interpreters `. Making sure multiple modules
@@ -338,6 +338,7 @@ The available slot types are:
The *value* pointer of this slot must point to a function of the signature:
.. c:function:: PyObject* create_module(PyObject *spec, PyModuleDef *def)
+ :noindex:
The function receives a :py:class:`~importlib.machinery.ModuleSpec`
instance, as defined in :PEP:`451`, and the module definition.
@@ -372,6 +373,7 @@ The available slot types are:
The signature of the function is:
.. c:function:: int exec_module(PyObject* module)
+ :noindex:
If multiple ``Py_mod_exec`` slots are specified, they are processed in the
order they appear in the *m_slots* array.
@@ -388,15 +390,15 @@ objects dynamically. Note that both ``PyModule_FromDefAndSpec`` and
.. c:function:: PyObject * PyModule_FromDefAndSpec(PyModuleDef *def, PyObject *spec)
- Create a new module object, given the definition in *module* and the
+ Create a new module object, given the definition in *def* and the
ModuleSpec *spec*. This behaves like :c:func:`PyModule_FromDefAndSpec2`
- with *module_api_version* set to :const:`PYTHON_API_VERSION`.
+ with *module_api_version* set to :c:macro:`PYTHON_API_VERSION`.
.. versionadded:: 3.5
.. c:function:: PyObject * PyModule_FromDefAndSpec2(PyModuleDef *def, PyObject *spec, int module_api_version)
- Create a new module object, given the definition in *module* and the
+ Create a new module object, given the definition in *def* and the
ModuleSpec *spec*, assuming the API version *module_api_version*.
If that version does not match the version of the running interpreter,
a :exc:`RuntimeWarning` is emitted.
@@ -498,7 +500,7 @@ state:
.. note::
Unlike other functions that steal references, ``PyModule_AddObject()``
- only decrements the reference count of *value* **on success**.
+ only releases the reference to *value* **on success**.
This means that its return value must be checked, and calling code must
:c:func:`Py_DECREF` *value* manually on error.
@@ -555,7 +557,7 @@ state:
``NULL``-terminated. Return ``-1`` on error, ``0`` on success.
-.. c:function:: int PyModule_AddIntMacro(PyObject *module, macro)
+.. c:macro:: PyModule_AddIntMacro(module, macro)
Add an int constant to *module*. The name and the value are taken from
*macro*. For example ``PyModule_AddIntMacro(module, AF_INET)`` adds the int
@@ -563,7 +565,7 @@ state:
Return ``-1`` on error, ``0`` on success.
-.. c:function:: int PyModule_AddStringMacro(PyObject *module, macro)
+.. c:macro:: PyModule_AddStringMacro(module, macro)
Add a string constant to *module*.
diff --git a/Doc/c-api/none.rst b/Doc/c-api/none.rst
index 26d2b7aab201ba..e238fd1c2d8dc6 100644
--- a/Doc/c-api/none.rst
+++ b/Doc/c-api/none.rst
@@ -5,11 +5,11 @@
The ``None`` Object
-------------------
-.. index:: object: None
+.. index:: pair: object; None
Note that the :c:type:`PyTypeObject` for ``None`` is not directly exposed in the
Python/C API. Since ``None`` is a singleton, testing for object identity (using
-``==`` in C) is sufficient. There is no :c:func:`PyNone_Check` function for the
+``==`` in C) is sufficient. There is no :c:func:`!PyNone_Check` function for the
same reason.
diff --git a/Doc/c-api/number.rst b/Doc/c-api/number.rst
index 11c9c67d36a678..13d3c5af956905 100644
--- a/Doc/c-api/number.rst
+++ b/Doc/c-api/number.rst
@@ -64,7 +64,7 @@ Number Protocol
.. c:function:: PyObject* PyNumber_Divmod(PyObject *o1, PyObject *o2)
- .. index:: builtin: divmod
+ .. index:: pair: built-in function; divmod
See the built-in function :func:`divmod`. Returns ``NULL`` on failure. This is
the equivalent of the Python expression ``divmod(o1, o2)``.
@@ -72,7 +72,7 @@ Number Protocol
.. c:function:: PyObject* PyNumber_Power(PyObject *o1, PyObject *o2, PyObject *o3)
- .. index:: builtin: pow
+ .. index:: pair: built-in function; pow
See the built-in function :func:`pow`. Returns ``NULL`` on failure. This is the
equivalent of the Python expression ``pow(o1, o2, o3)``, where *o3* is optional.
@@ -94,7 +94,7 @@ Number Protocol
.. c:function:: PyObject* PyNumber_Absolute(PyObject *o)
- .. index:: builtin: abs
+ .. index:: pair: built-in function; abs
Returns the absolute value of *o*, or ``NULL`` on failure. This is the equivalent
of the Python expression ``abs(o)``.
@@ -192,7 +192,7 @@ Number Protocol
.. c:function:: PyObject* PyNumber_InPlacePower(PyObject *o1, PyObject *o2, PyObject *o3)
- .. index:: builtin: pow
+ .. index:: pair: built-in function; pow
See the built-in function :func:`pow`. Returns ``NULL`` on failure. The operation
is done *in-place* when *o1* supports it. This is the equivalent of the Python
@@ -238,7 +238,7 @@ Number Protocol
.. c:function:: PyObject* PyNumber_Long(PyObject *o)
- .. index:: builtin: int
+ .. index:: pair: built-in function; int
Returns the *o* converted to an integer object on success, or ``NULL`` on
failure. This is the equivalent of the Python expression ``int(o)``.
@@ -246,7 +246,7 @@ Number Protocol
.. c:function:: PyObject* PyNumber_Float(PyObject *o)
- .. index:: builtin: float
+ .. index:: pair: built-in function; float
Returns the *o* converted to a float object on success, or ``NULL`` on failure.
This is the equivalent of the Python expression ``float(o)``.
@@ -273,11 +273,11 @@ Number Protocol
.. c:function:: Py_ssize_t PyNumber_AsSsize_t(PyObject *o, PyObject *exc)
- Returns *o* converted to a Py_ssize_t value if *o* can be interpreted as an
+ Returns *o* converted to a :c:type:`Py_ssize_t` value if *o* can be interpreted as an
integer. If the call fails, an exception is raised and ``-1`` is returned.
If *o* can be converted to a Python int but the attempt to
- convert to a Py_ssize_t value would raise an :exc:`OverflowError`, then the
+ convert to a :c:type:`Py_ssize_t` value would raise an :exc:`OverflowError`, then the
*exc* argument is the type of exception that will be raised (usually
:exc:`IndexError` or :exc:`OverflowError`). If *exc* is ``NULL``, then the
exception is cleared and the value is clipped to ``PY_SSIZE_T_MIN`` for a negative
diff --git a/Doc/c-api/object.rst b/Doc/c-api/object.rst
index 9dcfd769c64a05..e3a0aaad9a6598 100644
--- a/Doc/c-api/object.rst
+++ b/Doc/c-api/object.rst
@@ -15,15 +15,23 @@ Object Protocol
.. c:macro:: Py_RETURN_NOTIMPLEMENTED
Properly handle returning :c:data:`Py_NotImplemented` from within a C
- function (that is, increment the reference count of NotImplemented and
- return it).
+ function (that is, create a new :term:`strong reference`
+ to NotImplemented and return it).
+
+
+.. c:macro:: Py_PRINT_RAW
+
+ Flag to be used with multiple functions that print the object (like
+ :c:func:`PyObject_Print` and :c:func:`PyFile_WriteObject`).
+ If passed, these function would use the :func:`str` of the object
+ instead of the :func:`repr`.
.. c:function:: int PyObject_Print(PyObject *o, FILE *fp, int flags)
Print an object *o*, on file *fp*. Returns ``-1`` on error. The flags argument
is used to enable certain printing options. The only option currently supported
- is :const:`Py_PRINT_RAW`; if given, the :func:`str` of the object is written
+ is :c:macro:`Py_PRINT_RAW`; if given, the :func:`str` of the object is written
instead of the :func:`repr`.
@@ -33,21 +41,25 @@ Object Protocol
is equivalent to the Python expression ``hasattr(o, attr_name)``. This function
always succeeds.
- Note that exceptions which occur while calling :meth:`__getattr__` and
- :meth:`__getattribute__` methods will get suppressed.
- To get error reporting use :c:func:`PyObject_GetAttr()` instead.
+ .. note::
+
+ Exceptions that occur when this calls :meth:`~object.__getattr__` and
+ :meth:`~object.__getattribute__` methods are silently ignored.
+ For proper error handling, use :c:func:`PyObject_GetAttr` instead.
.. c:function:: int PyObject_HasAttrString(PyObject *o, const char *attr_name)
- Returns ``1`` if *o* has the attribute *attr_name*, and ``0`` otherwise. This
- is equivalent to the Python expression ``hasattr(o, attr_name)``. This function
- always succeeds.
+ This is the same as :c:func:`PyObject_HasAttr`, but *attr_name* is
+ specified as a :c:expr:`const char*` UTF-8 encoded bytes string,
+ rather than a :c:expr:`PyObject*`.
+
+ .. note::
- Note that exceptions which occur while calling :meth:`__getattr__` and
- :meth:`__getattribute__` methods and creating a temporary string object
- will get suppressed.
- To get error reporting use :c:func:`PyObject_GetAttrString()` instead.
+ Exceptions that occur when this calls :meth:`~object.__getattr__` and
+ :meth:`~object.__getattribute__` methods or while creating the temporary
+ :class:`str` object are silently ignored.
+ For proper error handling, use :c:func:`PyObject_GetAttrString` instead.
.. c:function:: PyObject* PyObject_GetAttr(PyObject *o, PyObject *attr_name)
@@ -59,9 +71,9 @@ Object Protocol
.. c:function:: PyObject* PyObject_GetAttrString(PyObject *o, const char *attr_name)
- Retrieve an attribute named *attr_name* from object *o*. Returns the attribute
- value on success, or ``NULL`` on failure. This is the equivalent of the Python
- expression ``o.attr_name``.
+ This is the same as :c:func:`PyObject_GetAttr`, but *attr_name* is
+ specified as a :c:expr:`const char*` UTF-8 encoded bytes string,
+ rather than a :c:expr:`PyObject*`.
.. c:function:: PyObject* PyObject_GenericGetAttr(PyObject *o, PyObject *name)
@@ -88,10 +100,9 @@ Object Protocol
.. c:function:: int PyObject_SetAttrString(PyObject *o, const char *attr_name, PyObject *v)
- Set the value of the attribute named *attr_name*, for object *o*, to the value
- *v*. Raise an exception and return ``-1`` on failure;
- return ``0`` on success. This is the equivalent of the Python statement
- ``o.attr_name = v``.
+ This is the same as :c:func:`PyObject_SetAttr`, but *attr_name* is
+ specified as a :c:expr:`const char*` UTF-8 encoded bytes string,
+ rather than a :c:expr:`PyObject*`.
If *v* is ``NULL``, the attribute is deleted, but this feature is
deprecated in favour of using :c:func:`PyObject_DelAttrString`.
@@ -117,8 +128,9 @@ Object Protocol
.. c:function:: int PyObject_DelAttrString(PyObject *o, const char *attr_name)
- Delete attribute named *attr_name*, for object *o*. Returns ``-1`` on failure.
- This is the equivalent of the Python statement ``del o.attr_name``.
+ This is the same as :c:func:`PyObject_DelAttr`, but *attr_name* is
+ specified as a :c:expr:`const char*` UTF-8 encoded bytes string,
+ rather than a :c:expr:`PyObject*`.
.. c:function:: PyObject* PyObject_GenericGetDict(PyObject *o, void *context)
@@ -126,6 +138,14 @@ Object Protocol
A generic implementation for the getter of a ``__dict__`` descriptor. It
creates the dictionary if necessary.
+ This function may also be called to get the :py:attr:`~object.__dict__`
+ of the object *o*. Pass ``NULL`` for *context* when calling it.
+ Since this function may need to allocate memory for the
+ dictionary, it may be more efficient to call :c:func:`PyObject_GetAttr`
+ when accessing an attribute on the object.
+
+ On failure, returns ``NULL`` with an exception set.
+
.. versionadded:: 3.3
@@ -137,11 +157,21 @@ Object Protocol
.. versionadded:: 3.3
+.. c:function:: PyObject** _PyObject_GetDictPtr(PyObject *obj)
+
+ Return a pointer to :py:attr:`~object.__dict__` of the object *obj*.
+ If there is no ``__dict__``, return ``NULL`` without setting an exception.
+
+ This function may need to allocate memory for the
+ dictionary, so it may be more efficient to call :c:func:`PyObject_GetAttr`
+ when accessing an attribute on the object.
+
+
.. c:function:: PyObject* PyObject_RichCompare(PyObject *o1, PyObject *o2, int opid)
Compare the values of *o1* and *o2* using the operation specified by *opid*,
- which must be one of :const:`Py_LT`, :const:`Py_LE`, :const:`Py_EQ`,
- :const:`Py_NE`, :const:`Py_GT`, or :const:`Py_GE`, corresponding to ``<``,
+ which must be one of :c:macro:`Py_LT`, :c:macro:`Py_LE`, :c:macro:`Py_EQ`,
+ :c:macro:`Py_NE`, :c:macro:`Py_GT`, or :c:macro:`Py_GE`, corresponding to ``<``,
``<=``, ``==``, ``!=``, ``>``, or ``>=`` respectively. This is the equivalent of
the Python expression ``o1 op o2``, where ``op`` is the operator corresponding
to *opid*. Returns the value of the comparison on success, or ``NULL`` on failure.
@@ -150,20 +180,25 @@ Object Protocol
.. c:function:: int PyObject_RichCompareBool(PyObject *o1, PyObject *o2, int opid)
Compare the values of *o1* and *o2* using the operation specified by *opid*,
- which must be one of :const:`Py_LT`, :const:`Py_LE`, :const:`Py_EQ`,
- :const:`Py_NE`, :const:`Py_GT`, or :const:`Py_GE`, corresponding to ``<``,
- ``<=``, ``==``, ``!=``, ``>``, or ``>=`` respectively. Returns ``-1`` on error,
- ``0`` if the result is false, ``1`` otherwise. This is the equivalent of the
- Python expression ``o1 op o2``, where ``op`` is the operator corresponding to
- *opid*.
+ like :c:func:`PyObject_RichCompare`, but returns ``-1`` on error, ``0`` if
+ the result is false, ``1`` otherwise.
.. note::
If *o1* and *o2* are the same object, :c:func:`PyObject_RichCompareBool`
- will always return ``1`` for :const:`Py_EQ` and ``0`` for :const:`Py_NE`.
+ will always return ``1`` for :c:macro:`Py_EQ` and ``0`` for :c:macro:`Py_NE`.
+
+.. c:function:: PyObject* PyObject_Format(PyObject *obj, PyObject *format_spec)
+
+ Format *obj* using *format_spec*. This is equivalent to the Python
+ expression ``format(obj, format_spec)``.
+
+ *format_spec* may be ``NULL``. In this case the call is equivalent
+ to ``format(obj)``.
+ Returns the formatted string on success, ``NULL`` on failure.
.. c:function:: PyObject* PyObject_Repr(PyObject *o)
- .. index:: builtin: repr
+ .. index:: pair: built-in function; repr
Compute a string representation of object *o*. Returns the string
representation on success, ``NULL`` on failure. This is the equivalent of the
@@ -175,7 +210,7 @@ Object Protocol
.. c:function:: PyObject* PyObject_ASCII(PyObject *o)
- .. index:: builtin: ascii
+ .. index:: pair: built-in function; ascii
As :c:func:`PyObject_Repr`, compute a string representation of object *o*, but
escape the non-ASCII characters in the string returned by
@@ -200,7 +235,7 @@ Object Protocol
.. c:function:: PyObject* PyObject_Bytes(PyObject *o)
- .. index:: builtin: bytes
+ .. index:: pair: built-in function; bytes
Compute a bytes representation of object *o*. ``NULL`` is returned on
failure and a bytes object on success. This is equivalent to the Python
@@ -225,7 +260,7 @@ Object Protocol
Normally only class objects, i.e. instances of :class:`type` or a derived
class, are considered classes. However, objects can override this by having
- a :attr:`__bases__` attribute (which must be a tuple of base classes).
+ a :attr:`~class.__bases__` attribute (which must be a tuple of base classes).
.. c:function:: int PyObject_IsInstance(PyObject *inst, PyObject *cls)
@@ -242,28 +277,28 @@ Object Protocol
is an instance of *cls* if its class is a subclass of *cls*.
An instance *inst* can override what is considered its class by having a
- :attr:`__class__` attribute.
+ :attr:`~instance.__class__` attribute.
An object *cls* can override if it is considered a class, and what its base
- classes are, by having a :attr:`__bases__` attribute (which must be a tuple
+ classes are, by having a :attr:`~class.__bases__` attribute (which must be a tuple
of base classes).
.. c:function:: Py_hash_t PyObject_Hash(PyObject *o)
- .. index:: builtin: hash
+ .. index:: pair: built-in function; hash
Compute and return the hash value of an object *o*. On failure, return ``-1``.
This is the equivalent of the Python expression ``hash(o)``.
.. versionchanged:: 3.2
The return type is now Py_hash_t. This is a signed integer the same size
- as Py_ssize_t.
+ as :c:type:`Py_ssize_t`.
.. c:function:: Py_hash_t PyObject_HashNotImplemented(PyObject *o)
- Set a :exc:`TypeError` indicating that ``type(o)`` is not hashable and return ``-1``.
+ Set a :exc:`TypeError` indicating that ``type(o)`` is not :term:`hashable` and return ``-1``.
This function receives special treatment when stored in a ``tp_hash`` slot,
allowing a type to explicitly indicate to the interpreter that it is not
hashable.
@@ -285,15 +320,16 @@ Object Protocol
.. c:function:: PyObject* PyObject_Type(PyObject *o)
- .. index:: builtin: type
+ .. index:: pair: built-in function; type
When *o* is non-``NULL``, returns a type object corresponding to the object type
of object *o*. On failure, raises :exc:`SystemError` and returns ``NULL``. This
- is equivalent to the Python expression ``type(o)``. This function increments the
- reference count of the return value. There's really no reason to use this
+ is equivalent to the Python expression ``type(o)``.
+ This function creates a new :term:`strong reference` to the return value.
+ There's really no reason to use this
function instead of the :c:func:`Py_TYPE()` function, which returns a
- pointer of type :c:type:`PyTypeObject*`, except when the incremented reference
- count is needed.
+ pointer of type :c:expr:`PyTypeObject*`, except when a new
+ :term:`strong reference` is needed.
.. c:function:: int PyObject_TypeCheck(PyObject *o, PyTypeObject *type)
@@ -305,7 +341,7 @@ Object Protocol
.. c:function:: Py_ssize_t PyObject_Size(PyObject *o)
Py_ssize_t PyObject_Length(PyObject *o)
- .. index:: builtin: len
+ .. index:: pair: built-in function; len
Return the length of object *o*. If the object *o* provides either the sequence
and mapping protocols, the sequence length is returned. On error, ``-1`` is
diff --git a/Doc/c-api/refcounting.rst b/Doc/c-api/refcounting.rst
index 391907c8c2976a..e1782ab27f4f66 100644
--- a/Doc/c-api/refcounting.rst
+++ b/Doc/c-api/refcounting.rst
@@ -13,31 +13,36 @@ objects.
.. c:function:: void Py_INCREF(PyObject *o)
- Increment the reference count for object *o*.
+ Indicate taking a new :term:`strong reference` to object *o*,
+ indicating it is in use and should not be destroyed.
This function is usually used to convert a :term:`borrowed reference` to a
:term:`strong reference` in-place. The :c:func:`Py_NewRef` function can be
used to create a new :term:`strong reference`.
+ When done using the object, release it by calling :c:func:`Py_DECREF`.
+
The object must not be ``NULL``; if you aren't sure that it isn't
``NULL``, use :c:func:`Py_XINCREF`.
+ Do not expect this function to actually modify *o* in any way.
+
.. c:function:: void Py_XINCREF(PyObject *o)
- Increment the reference count for object *o*. The object may be ``NULL``, in
- which case the macro has no effect.
+ Similar to :c:func:`Py_INCREF`, but the object *o* can be ``NULL``,
+ in which case this has no effect.
See also :c:func:`Py_XNewRef`.
.. c:function:: PyObject* Py_NewRef(PyObject *o)
- Create a new :term:`strong reference` to an object: increment the reference
- count of the object *o* and return the object *o*.
+ Create a new :term:`strong reference` to an object:
+ call :c:func:`Py_INCREF` on *o* and return the object *o*.
When the :term:`strong reference` is no longer needed, :c:func:`Py_DECREF`
- should be called on it to decrement the object reference count.
+ should be called on it to release the reference.
The object *o* must not be ``NULL``; use :c:func:`Py_XNewRef` if *o* can be
``NULL``.
@@ -67,9 +72,12 @@ objects.
.. c:function:: void Py_DECREF(PyObject *o)
- Decrement the reference count for object *o*.
+ Release a :term:`strong reference` to object *o*, indicating the
+ reference is no longer used.
- If the reference count reaches zero, the object's type's deallocation
+ Once the last :term:`strong reference` is released
+ (i.e. the object's reference count reaches 0),
+ the object's type's deallocation
function (which must not be ``NULL``) is invoked.
This function is usually used to delete a :term:`strong reference` before
@@ -78,10 +86,12 @@ objects.
The object must not be ``NULL``; if you aren't sure that it isn't ``NULL``,
use :c:func:`Py_XDECREF`.
+ Do not expect this function to actually modify *o* in any way.
+
.. warning::
The deallocation function can cause arbitrary Python code to be invoked (e.g.
- when a class instance with a :meth:`__del__` method is deallocated). While
+ when a class instance with a :meth:`~object.__del__` method is deallocated). While
exceptions in such code are not propagated, the executed code has free access to
all Python global variables. This means that any object that is reachable from
a global variable should be in a consistent state before :c:func:`Py_DECREF` is
@@ -92,28 +102,37 @@ objects.
.. c:function:: void Py_XDECREF(PyObject *o)
- Decrement the reference count for object *o*. The object may be ``NULL``, in
- which case the macro has no effect; otherwise the effect is the same as for
- :c:func:`Py_DECREF`, and the same warning applies.
+ Similar to :c:func:`Py_DECREF`, but the object *o* can be ``NULL``,
+ in which case this has no effect.
+ The same warning from :c:func:`Py_DECREF` applies here as well.
.. c:function:: void Py_CLEAR(PyObject *o)
- Decrement the reference count for object *o*. The object may be ``NULL``, in
+ Release a :term:`strong reference` for object *o*.
+ The object may be ``NULL``, in
which case the macro has no effect; otherwise the effect is the same as for
:c:func:`Py_DECREF`, except that the argument is also set to ``NULL``. The warning
for :c:func:`Py_DECREF` does not apply with respect to the object passed because
the macro carefully uses a temporary variable and sets the argument to ``NULL``
- before decrementing its reference count.
+ before releasing the reference.
+
+ It is a good idea to use this macro whenever releasing a reference
+ to an object that might be traversed during garbage collection.
+
+.. c:function:: void Py_IncRef(PyObject *o)
+
+ Indicate taking a new :term:`strong reference` to object *o*.
+ A function version of :c:func:`Py_XINCREF`.
+ It can be used for runtime dynamic embedding of Python.
+
- It is a good idea to use this macro whenever decrementing the reference
- count of an object that might be traversed during garbage collection.
+.. c:function:: void Py_DecRef(PyObject *o)
+ Release a :term:`strong reference` to object *o*.
+ A function version of :c:func:`Py_XDECREF`.
+ It can be used for runtime dynamic embedding of Python.
-The following functions are for runtime dynamic embedding of Python:
-``Py_IncRef(PyObject *o)``, ``Py_DecRef(PyObject *o)``. They are
-simply exported function versions of :c:func:`Py_XINCREF` and
-:c:func:`Py_XDECREF`, respectively.
The following functions or macros are only for use within the interpreter core:
:c:func:`_Py_Dealloc`, :c:func:`_Py_ForgetReference`, :c:func:`_Py_NewReference`,
diff --git a/Doc/c-api/sequence.rst b/Doc/c-api/sequence.rst
index c78d273f9f149f..ce28839f5ba739 100644
--- a/Doc/c-api/sequence.rst
+++ b/Doc/c-api/sequence.rst
@@ -9,7 +9,7 @@ Sequence Protocol
.. c:function:: int PySequence_Check(PyObject *o)
Return ``1`` if the object provides the sequence protocol, and ``0`` otherwise.
- Note that it returns ``1`` for Python classes with a :meth:`__getitem__`
+ Note that it returns ``1`` for Python classes with a :meth:`~object.__getitem__`
method, unless they are :class:`dict` subclasses, since in general it
is impossible to determine what type of keys the class supports. This
function always succeeds.
@@ -18,7 +18,7 @@ Sequence Protocol
.. c:function:: Py_ssize_t PySequence_Size(PyObject *o)
Py_ssize_t PySequence_Length(PyObject *o)
- .. index:: builtin: len
+ .. index:: pair: built-in function; len
Returns the number of objects in sequence *o* on success, and ``-1`` on
failure. This is equivalent to the Python expression ``len(o)``.
@@ -120,7 +120,7 @@ Sequence Protocol
.. c:function:: PyObject* PySequence_Tuple(PyObject *o)
- .. index:: builtin: tuple
+ .. index:: pair: built-in function; tuple
Return a tuple object with the same contents as the sequence or iterable *o*,
or ``NULL`` on failure. If *o* is a tuple, a new reference will be returned,
diff --git a/Doc/c-api/set.rst b/Doc/c-api/set.rst
index f0d905bae8ae44..cba823aa027bd6 100644
--- a/Doc/c-api/set.rst
+++ b/Doc/c-api/set.rst
@@ -9,8 +9,8 @@ Set Objects
.. index::
- object: set
- object: frozenset
+ pair: object; set
+ pair: object; frozenset
This section details the public API for :class:`set` and :class:`frozenset`
objects. Any functionality not listed below is best accessed using either
@@ -107,10 +107,10 @@ or :class:`frozenset` or instances of their subtypes.
.. c:function:: Py_ssize_t PySet_Size(PyObject *anyset)
- .. index:: builtin: len
+ .. index:: pair: built-in function; len
Return the length of a :class:`set` or :class:`frozenset` object. Equivalent to
- ``len(anyset)``. Raises a :exc:`PyExc_SystemError` if *anyset* is not a
+ ``len(anyset)``. Raises a :exc:`SystemError` if *anyset* is not a
:class:`set`, :class:`frozenset`, or an instance of a subtype.
@@ -122,9 +122,9 @@ or :class:`frozenset` or instances of their subtypes.
.. c:function:: int PySet_Contains(PyObject *anyset, PyObject *key)
Return ``1`` if found, ``0`` if not found, and ``-1`` if an error is encountered. Unlike
- the Python :meth:`__contains__` method, this function does not automatically
+ the Python :meth:`~object.__contains__` method, this function does not automatically
convert unhashable sets into temporary frozensets. Raise a :exc:`TypeError` if
- the *key* is unhashable. Raise :exc:`PyExc_SystemError` if *anyset* is not a
+ the *key* is unhashable. Raise :exc:`SystemError` if *anyset* is not a
:class:`set`, :class:`frozenset`, or an instance of a subtype.
@@ -147,9 +147,9 @@ subtypes but not for instances of :class:`frozenset` or its subtypes.
Return ``1`` if found and removed, ``0`` if not found (no action taken), and ``-1`` if an
error is encountered. Does not raise :exc:`KeyError` for missing keys. Raise a
- :exc:`TypeError` if the *key* is unhashable. Unlike the Python :meth:`~set.discard`
+ :exc:`TypeError` if the *key* is unhashable. Unlike the Python :meth:`~frozenset.discard`
method, this function does not automatically convert unhashable sets into
- temporary frozensets. Raise :exc:`PyExc_SystemError` if *set* is not an
+ temporary frozensets. Raise :exc:`SystemError` if *set* is not an
instance of :class:`set` or its subtype.
@@ -163,4 +163,6 @@ subtypes but not for instances of :class:`frozenset` or its subtypes.
.. c:function:: int PySet_Clear(PyObject *set)
- Empty an existing set of all elements.
+ Empty an existing set of all elements. Return ``0`` on
+ success. Return ``-1`` and raise :exc:`SystemError` if *set* is not an instance of
+ :class:`set` or its subtype.
diff --git a/Doc/c-api/slice.rst b/Doc/c-api/slice.rst
index 8271d9acfb645e..af4c540068cbf4 100644
--- a/Doc/c-api/slice.rst
+++ b/Doc/c-api/slice.rst
@@ -34,7 +34,7 @@ Slice Objects
*length* as errors.
Returns ``0`` on success and ``-1`` on error with no exception set (unless one of
- the indices was not :const:`None` and failed to be converted to an integer,
+ the indices was not ``None`` and failed to be converted to an integer,
in which case ``-1`` is returned with an exception set).
You probably do not want to use this function.
@@ -113,7 +113,7 @@ Slice Objects
Ellipsis Object
----------------
+^^^^^^^^^^^^^^^
.. c:var:: PyObject *Py_Ellipsis
diff --git a/Doc/c-api/stable.rst b/Doc/c-api/stable.rst
index 4ae20e93e36785..9a035b5445d908 100644
--- a/Doc/c-api/stable.rst
+++ b/Doc/c-api/stable.rst
@@ -16,7 +16,7 @@ CPython's Application Binary Interface (ABI) is forward- and
backwards-compatible across a minor release (if these are compiled the same
way; see :ref:`stable-abi-platform` below).
So, code compiled for Python 3.10.0 will work on 3.10.8 and vice versa,
-but will need to be compiled separately for 3.9.x and 3.10.x.
+but will need to be compiled separately for 3.9.x and 3.11.x.
Names prefixed by an underscore, such as ``_Py_InternalState``,
are private API that can change without notice even in patch releases.
@@ -25,26 +25,26 @@ are private API that can change without notice even in patch releases.
Stable Application Binary Interface
===================================
+For simplicity, this document talks about *extensions*, but the Limited API
+and Stable ABI work the same way for all uses of the API – for example,
+embedding Python.
+
+.. _limited-c-api:
+
+Limited C API
+-------------
+
Python 3.2 introduced the *Limited API*, a subset of Python's C API.
Extensions that only use the Limited API can be
compiled once and work with multiple versions of Python.
-Contents of the Limited API are :ref:`listed below `.
-
-To enable this, Python provides a *Stable ABI*: a set of symbols that will
-remain compatible across Python 3.x versions. The Stable ABI contains symbols
-exposed in the Limited API, but also other ones – for example, functions
-necessary to support older versions of the Limited API.
-
-(For simplicity, this document talks about *extensions*, but the Limited API
-and Stable ABI work the same way for all uses of the API – for example,
-embedding Python.)
+Contents of the Limited API are :ref:`listed below `.
.. c:macro:: Py_LIMITED_API
Define this macro before including ``Python.h`` to opt in to only use
the Limited API, and to select the Limited API version.
- Define ``Py_LIMITED_API`` to the value of :c:data:`PY_VERSION_HEX`
+ Define ``Py_LIMITED_API`` to the value of :c:macro:`PY_VERSION_HEX`
corresponding to the lowest Python version your extension supports.
The extension will work without recompilation with all Python 3 releases
from the specified one onward, and can use Limited API introduced up to that
@@ -57,6 +57,19 @@ embedding Python.)
You can also define ``Py_LIMITED_API`` to ``3``. This works the same as
``0x03020000`` (Python 3.2, the version that introduced Limited API).
+
+.. _stable-abi:
+
+Stable ABI
+----------
+
+To enable this, Python provides a *Stable ABI*: a set of symbols that will
+remain compatible across Python 3.x versions.
+
+The Stable ABI contains symbols exposed in the :ref:`Limited API
+`, but also other ones – for example, functions necessary to
+support older versions of the Limited API.
+
On Windows, extensions that use the Stable ABI should be linked against
``python3.dll`` rather than a version-specific library such as
``python39.dll``.
@@ -101,9 +114,9 @@ Limited API Caveats
-------------------
Note that compiling with ``Py_LIMITED_API`` is *not* a complete guarantee that
-code conforms to the Limited API or the Stable ABI. ``Py_LIMITED_API`` only
-covers definitions, but an API also includes other issues, such as expected
-semantics.
+code conforms to the :ref:`Limited API ` or the :ref:`Stable ABI
+`. ``Py_LIMITED_API`` only covers definitions, but an API also
+includes other issues, such as expected semantics.
One issue that ``Py_LIMITED_API`` does not guard against is calling a function
with arguments that are invalid in a lower Python version.
@@ -136,9 +149,9 @@ Platform Considerations
=======================
ABI stability depends not only on Python, but also on the compiler used,
-lower-level libraries and compiler options. For the purposes of the Stable ABI,
-these details define a “platform”. They usually depend on the OS
-type and processor architecture
+lower-level libraries and compiler options. For the purposes of
+the :ref:`Stable ABI `, these details define a “platform”. They
+usually depend on the OS type and processor architecture
It is the responsibility of each particular distributor of Python
to ensure that all Python versions on a particular platform are built
@@ -147,12 +160,12 @@ This is the case with Windows and macOS releases from ``python.org`` and many
third-party distributors.
-.. _stable-abi-list:
+.. _limited-api-list:
Contents of Limited API
=======================
-Currently, the Limited API includes the following items:
+Currently, the :ref:`Limited API ` includes the following items:
.. limited-api-list::
diff --git a/Doc/c-api/structures.rst b/Doc/c-api/structures.rst
index ff5ecf24072c1a..1d313545fc57be 100644
--- a/Doc/c-api/structures.rst
+++ b/Doc/c-api/structures.rst
@@ -27,14 +27,14 @@ the definition of all other Python objects.
object. In a normal "release" build, it contains only the object's
reference count and a pointer to the corresponding type object.
Nothing is actually declared to be a :c:type:`PyObject`, but every pointer
- to a Python object can be cast to a :c:type:`PyObject*`. Access to the
+ to a Python object can be cast to a :c:expr:`PyObject*`. Access to the
members must be done by using the macros :c:macro:`Py_REFCNT` and
:c:macro:`Py_TYPE`.
.. c:type:: PyVarObject
- This is an extension of :c:type:`PyObject` that adds the :attr:`ob_size`
+ This is an extension of :c:type:`PyObject` that adds the :c:member:`~PyVarObject.ob_size`
field. This is only used for objects that have some notion of *length*.
This type does not often appear in the Python/C API.
Access to the members must be done by using the macros
@@ -103,7 +103,7 @@ the definition of all other Python objects.
.. versionchanged:: 3.11
:c:func:`Py_TYPE()` is changed to an inline static function.
- The parameter type is no longer :c:type:`const PyObject*`.
+ The parameter type is no longer :c:expr:`const PyObject*`.
.. c:function:: int Py_IS_TYPE(PyObject *o, PyTypeObject *type)
@@ -128,7 +128,7 @@ the definition of all other Python objects.
Use the :c:func:`Py_SET_REFCNT()` function to set an object reference count.
.. versionchanged:: 3.11
- The parameter type is no longer :c:type:`const PyObject*`.
+ The parameter type is no longer :c:expr:`const PyObject*`.
.. versionchanged:: 3.10
:c:func:`Py_REFCNT()` is changed to the inline static function.
@@ -149,7 +149,7 @@ the definition of all other Python objects.
.. versionchanged:: 3.11
:c:func:`Py_SIZE()` is changed to an inline static function.
- The parameter type is no longer :c:type:`const PyVarObject*`.
+ The parameter type is no longer :c:expr:`const PyVarObject*`.
.. c:function:: void Py_SET_SIZE(PyVarObject *o, Py_ssize_t size)
@@ -171,7 +171,7 @@ the definition of all other Python objects.
.. c:macro:: PyVarObject_HEAD_INIT(type, size)
This is a macro which expands to initialization values for a new
- :c:type:`PyVarObject` type, including the :attr:`ob_size` field.
+ :c:type:`PyVarObject` type, including the :c:member:`~PyVarObject.ob_size` field.
This macro expands to::
_PyObject_EXTRA_INIT
@@ -184,7 +184,7 @@ Implementing functions and methods
.. c:type:: PyCFunction
Type of the functions used to implement most Python callables in C.
- Functions of this type take two :c:type:`PyObject*` parameters and return
+ Functions of this type take two :c:expr:`PyObject*` parameters and return
one such value. If the return value is ``NULL``, an exception shall have
been set. If not ``NULL``, the return value is interpreted as the return
value of the function as exposed in Python. The function must return a new
@@ -198,7 +198,7 @@ Implementing functions and methods
.. c:type:: PyCFunctionWithKeywords
Type of the functions used to implement Python callables in C
- with signature :const:`METH_VARARGS | METH_KEYWORDS`.
+ with signature :ref:`METH_VARARGS | METH_KEYWORDS `.
The function signature is::
PyObject *PyCFunctionWithKeywords(PyObject *self,
@@ -209,7 +209,7 @@ Implementing functions and methods
.. c:type:: _PyCFunctionFast
Type of the functions used to implement Python callables in C
- with signature :const:`METH_FASTCALL`.
+ with signature :c:macro:`METH_FASTCALL`.
The function signature is::
PyObject *_PyCFunctionFast(PyObject *self,
@@ -219,7 +219,7 @@ Implementing functions and methods
.. c:type:: _PyCFunctionFastWithKeywords
Type of the functions used to implement Python callables in C
- with signature :const:`METH_FASTCALL | METH_KEYWORDS`.
+ with signature :ref:`METH_FASTCALL | METH_KEYWORDS `.
The function signature is::
PyObject *_PyCFunctionFastWithKeywords(PyObject *self,
@@ -230,7 +230,7 @@ Implementing functions and methods
.. c:type:: PyCMethod
Type of the functions used to implement Python callables in C
- with signature :const:`METH_METHOD | METH_FASTCALL | METH_KEYWORDS`.
+ with signature :ref:`METH_METHOD | METH_FASTCALL | METH_KEYWORDS `.
The function signature is::
PyObject *PyCMethod(PyObject *self,
@@ -247,46 +247,58 @@ Implementing functions and methods
Structure used to describe a method of an extension type. This structure has
four fields:
- +------------------+---------------+-------------------------------+
- | Field | C Type | Meaning |
- +==================+===============+===============================+
- | :attr:`ml_name` | const char \* | name of the method |
- +------------------+---------------+-------------------------------+
- | :attr:`ml_meth` | PyCFunction | pointer to the C |
- | | | implementation |
- +------------------+---------------+-------------------------------+
- | :attr:`ml_flags` | int | flag bits indicating how the |
- | | | call should be constructed |
- +------------------+---------------+-------------------------------+
- | :attr:`ml_doc` | const char \* | points to the contents of the |
- | | | docstring |
- +------------------+---------------+-------------------------------+
+ .. c:member:: const char *ml_name
+
+ Name of the method.
-The :attr:`ml_meth` is a C function pointer. The functions may be of different
-types, but they always return :c:type:`PyObject*`. If the function is not of
+ .. c:member:: PyCFunction ml_meth
+
+ Pointer to the C implementation.
+
+ .. c:member:: int ml_flags
+
+ Flags bits indicating how the call should be constructed.
+
+ .. c:member:: const char *ml_doc
+
+ Points to the contents of the docstring.
+
+The :c:member:`~PyMethodDef.ml_meth` is a C function pointer.
+The functions may be of different
+types, but they always return :c:expr:`PyObject*`. If the function is not of
the :c:type:`PyCFunction`, the compiler will require a cast in the method table.
Even though :c:type:`PyCFunction` defines the first parameter as
-:c:type:`PyObject*`, it is common that the method implementation uses the
+:c:expr:`PyObject*`, it is common that the method implementation uses the
specific C type of the *self* object.
-The :attr:`ml_flags` field is a bitfield which can include the following flags.
+The :c:member:`~PyMethodDef.ml_flags` field is a bitfield which can include
+the following flags.
The individual flags indicate either a calling convention or a binding
convention.
There are these calling conventions:
-.. data:: METH_VARARGS
+.. c:macro:: METH_VARARGS
This is the typical calling convention, where the methods have the type
- :c:type:`PyCFunction`. The function expects two :c:type:`PyObject*` values.
+ :c:type:`PyCFunction`. The function expects two :c:expr:`PyObject*` values.
The first one is the *self* object for methods; for module functions, it is
the module object. The second parameter (often called *args*) is a tuple
object representing all arguments. This parameter is typically processed
using :c:func:`PyArg_ParseTuple` or :c:func:`PyArg_UnpackTuple`.
-.. data:: METH_VARARGS | METH_KEYWORDS
+.. c:macro:: METH_KEYWORDS
+
+ Can only be used in certain combinations with other flags:
+ :ref:`METH_VARARGS | METH_KEYWORDS `,
+ :ref:`METH_FASTCALL | METH_KEYWORDS ` and
+ :ref:`METH_METHOD | METH_FASTCALL | METH_KEYWORDS `.
+
+
+.. _METH_VARARGS-METH_KEYWORDS:
+:c:expr:`METH_VARARGS | METH_KEYWORDS`
Methods with these flags must be of type :c:type:`PyCFunctionWithKeywords`.
The function expects three parameters: *self*, *args*, *kwargs* where
*kwargs* is a dictionary of all the keyword arguments or possibly ``NULL``
@@ -294,42 +306,49 @@ There are these calling conventions:
using :c:func:`PyArg_ParseTupleAndKeywords`.
-.. data:: METH_FASTCALL
+.. c:macro:: METH_FASTCALL
Fast calling convention supporting only positional arguments.
The methods have the type :c:type:`_PyCFunctionFast`.
The first parameter is *self*, the second parameter is a C array
- of :c:type:`PyObject*` values indicating the arguments and the third
+ of :c:expr:`PyObject*` values indicating the arguments and the third
parameter is the number of arguments (the length of the array).
.. versionadded:: 3.7
.. versionchanged:: 3.10
- ``METH_FASTCALL`` is now part of the stable ABI.
+ ``METH_FASTCALL`` is now part of the :ref:`stable ABI `.
-.. data:: METH_FASTCALL | METH_KEYWORDS
+.. _METH_FASTCALL-METH_KEYWORDS:
- Extension of :const:`METH_FASTCALL` supporting also keyword arguments,
+:c:expr:`METH_FASTCALL | METH_KEYWORDS`
+ Extension of :c:macro:`METH_FASTCALL` supporting also keyword arguments,
with methods of type :c:type:`_PyCFunctionFastWithKeywords`.
Keyword arguments are passed the same way as in the
:ref:`vectorcall protocol `:
- there is an additional fourth :c:type:`PyObject*` parameter
+ there is an additional fourth :c:expr:`PyObject*` parameter
which is a tuple representing the names of the keyword arguments
(which are guaranteed to be strings)
or possibly ``NULL`` if there are no keywords. The values of the keyword
arguments are stored in the *args* array, after the positional arguments.
- This is not part of the :ref:`limited API `.
-
.. versionadded:: 3.7
-.. data:: METH_METHOD | METH_FASTCALL | METH_KEYWORDS
+.. c:macro:: METH_METHOD
+
+ Can only be used in the combination with other flags:
+ :ref:`METH_METHOD | METH_FASTCALL | METH_KEYWORDS `.
+
- Extension of :const:`METH_FASTCALL | METH_KEYWORDS` supporting the *defining
- class*, that is, the class that contains the method in question.
+.. _METH_METHOD-METH_FASTCALL-METH_KEYWORDS:
+
+:c:expr:`METH_METHOD | METH_FASTCALL | METH_KEYWORDS`
+ Extension of :ref:`METH_FASTCALL | METH_KEYWORDS `
+ supporting the *defining class*, that is,
+ the class that contains the method in question.
The defining class might be a superclass of ``Py_TYPE(self)``.
The method needs to be of type :c:type:`PyCMethod`, the same as for
@@ -339,10 +358,10 @@ There are these calling conventions:
.. versionadded:: 3.9
-.. data:: METH_NOARGS
+.. c:macro:: METH_NOARGS
Methods without parameters don't need to check whether arguments are given if
- they are listed with the :const:`METH_NOARGS` flag. They need to be of type
+ they are listed with the :c:macro:`METH_NOARGS` flag. They need to be of type
:c:type:`PyCFunction`. The first parameter is typically named *self* and will
hold a reference to the module or object instance. In all cases the second
parameter will be ``NULL``.
@@ -351,12 +370,12 @@ There are these calling conventions:
:c:macro:`Py_UNUSED` can be used to prevent a compiler warning.
-.. data:: METH_O
+.. c:macro:: METH_O
- Methods with a single object argument can be listed with the :const:`METH_O`
+ Methods with a single object argument can be listed with the :c:macro:`METH_O`
flag, instead of invoking :c:func:`PyArg_ParseTuple` with a ``"O"`` argument.
They have the type :c:type:`PyCFunction`, with the *self* parameter, and a
- :c:type:`PyObject*` parameter representing the single argument.
+ :c:expr:`PyObject*` parameter representing the single argument.
These two constants are not used to indicate the calling convention but the
@@ -365,9 +384,9 @@ defined for modules. At most one of these flags may be set for any given
method.
-.. data:: METH_CLASS
+.. c:macro:: METH_CLASS
- .. index:: builtin: classmethod
+ .. index:: pair: built-in function; classmethod
The method will be passed the type object as the first parameter rather
than an instance of the type. This is used to create *class methods*,
@@ -375,9 +394,9 @@ method.
function.
-.. data:: METH_STATIC
+.. c:macro:: METH_STATIC
- .. index:: builtin: staticmethod
+ .. index:: pair: built-in function; staticmethod
The method will be passed ``NULL`` as the first parameter rather than an
instance of the type. This is used to create *static methods*, similar to
@@ -387,18 +406,52 @@ One other constant controls whether a method is loaded in place of another
definition with the same method name.
-.. data:: METH_COEXIST
+.. c:macro:: METH_COEXIST
The method will be loaded in place of existing definitions. Without
*METH_COEXIST*, the default is to skip repeated definitions. Since slot
wrappers are loaded before the method table, the existence of a
*sq_contains* slot, for example, would generate a wrapped method named
- :meth:`__contains__` and preclude the loading of a corresponding
+ :meth:`~object.__contains__` and preclude the loading of a corresponding
PyCFunction with the same name. With the flag defined, the PyCFunction
will be loaded in place of the wrapper object and will co-exist with the
slot. This is helpful because calls to PyCFunctions are optimized more
than wrapper object calls.
+.. c:function:: PyObject * PyCMethod_New(PyMethodDef *ml, PyObject *self, PyObject *module, PyTypeObject *cls)
+
+ Turn *ml* into a Python :term:`callable` object.
+ The caller must ensure that *ml* outlives the :term:`callable`.
+ Typically, *ml* is defined as a static variable.
+
+ The *self* parameter will be passed as the *self* argument
+ to the C function in ``ml->ml_meth`` when invoked.
+ *self* can be ``NULL``.
+
+ The :term:`callable` object's ``__module__`` attribute
+ can be set from the given *module* argument.
+ *module* should be a Python string,
+ which will be used as name of the module the function is defined in.
+ If unavailable, it can be set to :const:`None` or ``NULL``.
+
+ .. seealso:: :attr:`function.__module__`
+
+ The *cls* parameter will be passed as the *defining_class*
+ argument to the C function.
+ Must be set if :c:macro:`METH_METHOD` is set on ``ml->ml_flags``.
+
+ .. versionadded:: 3.9
+
+
+.. c:function:: PyObject * PyCFunction_NewEx(PyMethodDef *ml, PyObject *self, PyObject *module)
+
+ Equivalent to ``PyCMethod_New(ml, self, module, NULL)``.
+
+
+.. c:function:: PyObject * PyCFunction_New(PyMethodDef *ml, PyObject *self)
+
+ Equivalent to ``PyCMethod_New(ml, self, NULL, NULL)``.
+
Accessing attributes of extension types
---------------------------------------
@@ -522,7 +575,7 @@ Accessing attributes of extension types
| | | getter and setter |
+-------------+------------------+-----------------------------------+
- The ``get`` function takes one :c:type:`PyObject*` parameter (the
+ The ``get`` function takes one :c:expr:`PyObject*` parameter (the
instance) and a function pointer (the associated ``closure``)::
typedef PyObject *(*getter)(PyObject *, void *);
@@ -530,7 +583,7 @@ Accessing attributes of extension types
It should return a new reference on success or ``NULL`` with a set exception
on failure.
- ``set`` functions take two :c:type:`PyObject*` parameters (the instance and
+ ``set`` functions take two :c:expr:`PyObject*` parameters (the instance and
the value to be set) and a function pointer (the associated ``closure``)::
typedef int (*setter)(PyObject *, PyObject *, void *);
diff --git a/Doc/c-api/sys.rst b/Doc/c-api/sys.rst
index 5e8d993100f632..ee27e56731f9ca 100644
--- a/Doc/c-api/sys.rst
+++ b/Doc/c-api/sys.rst
@@ -5,11 +5,13 @@
Operating System Utilities
==========================
+
.. c:function:: PyObject* PyOS_FSPath(PyObject *path)
Return the file system representation for *path*. If the object is a
- :class:`str` or :class:`bytes` object, then its reference count is
- incremented. If the object implements the :class:`os.PathLike` interface,
+ :class:`str` or :class:`bytes` object, then a new
+ :term:`strong reference` is returned.
+ If the object implements the :class:`os.PathLike` interface,
then :meth:`~os.PathLike.__fspath__` is returned as long as it is a
:class:`str` or :class:`bytes` object. Otherwise :exc:`TypeError` is raised
and ``NULL`` is returned.
@@ -94,27 +96,30 @@ Operating System Utilities
.. c:function:: int PyOS_CheckStack()
+ .. index:: single: USE_STACKCHECK (C macro)
+
Return true when the interpreter runs out of stack space. This is a reliable
- check, but is only available when :const:`USE_STACKCHECK` is defined (currently
+ check, but is only available when :c:macro:`!USE_STACKCHECK` is defined (currently
on certain versions of Windows using the Microsoft Visual C++ compiler).
- :const:`USE_STACKCHECK` will be defined automatically; you should never
+ :c:macro:`!USE_STACKCHECK` will be defined automatically; you should never
change the definition in your own code.
+.. c:type:: void (*PyOS_sighandler_t)(int)
+
+
.. c:function:: PyOS_sighandler_t PyOS_getsig(int i)
Return the current signal handler for signal *i*. This is a thin wrapper around
- either :c:func:`sigaction` or :c:func:`signal`. Do not call those functions
- directly! :c:type:`PyOS_sighandler_t` is a typedef alias for :c:type:`void
- (\*)(int)`.
+ either :c:func:`!sigaction` or :c:func:`!signal`. Do not call those functions
+ directly!
.. c:function:: PyOS_sighandler_t PyOS_setsig(int i, PyOS_sighandler_t h)
Set the signal handler for signal *i* to be *h*; return the old signal handler.
- This is a thin wrapper around either :c:func:`sigaction` or :c:func:`signal`. Do
- not call those functions directly! :c:type:`PyOS_sighandler_t` is a typedef
- alias for :c:type:`void (\*)(int)`.
+ This is a thin wrapper around either :c:func:`!sigaction` or :c:func:`!signal`. Do
+ not call those functions directly!
.. c:function:: wchar_t* Py_DecodeLocale(const char* arg, size_t *size)
@@ -348,7 +353,7 @@ accessible to C code. They all work with the current interpreter thread's
leaks.)
Note that ``#`` format characters should always be treated as
- ``Py_ssize_t``, regardless of whether ``PY_SSIZE_T_CLEAN`` was defined.
+ :c:type:`Py_ssize_t`, regardless of whether ``PY_SSIZE_T_CLEAN`` was defined.
:func:`sys.audit` performs the same function from Python code.
@@ -356,7 +361,7 @@ accessible to C code. They all work with the current interpreter thread's
.. versionchanged:: 3.8.2
- Require ``Py_ssize_t`` for ``#`` format characters. Previously, an
+ Require :c:type:`Py_ssize_t` for ``#`` format characters. Previously, an
unavoidable deprecation warning was raised.
@@ -377,10 +382,8 @@ accessible to C code. They all work with the current interpreter thread's
silently abort the operation by raising an error subclassed from
:class:`Exception` (other errors will not be silenced).
- The hook function is of type :c:type:`int (*)(const char *event, PyObject
- *args, void *userData)`, where *args* is guaranteed to be a
- :c:type:`PyTupleObject`. The hook function is always called with the GIL
- held by the Python interpreter that raised the event.
+ The hook function is always called with the GIL held by the Python
+ interpreter that raised the event.
See :pep:`578` for a detailed description of auditing. Functions in the
runtime and standard library that raise events are listed in the
@@ -389,12 +392,21 @@ accessible to C code. They all work with the current interpreter thread's
.. audit-event:: sys.addaudithook "" c.PySys_AddAuditHook
- If the interpreter is initialized, this function raises a auditing event
+ If the interpreter is initialized, this function raises an auditing event
``sys.addaudithook`` with no arguments. If any existing hooks raise an
exception derived from :class:`Exception`, the new hook will not be
added and the exception is cleared. As a result, callers cannot assume
that their hook has been added unless they control all existing hooks.
+ .. c:namespace:: NULL
+ .. c:type:: int (*Py_AuditHookFunction) (const char *event, PyObject *args, void *userData)
+
+ The type of the hook function.
+ *event* is the C string event argument passed to :c:func:`PySys_Audit` or
+ :c:func:`PySys_AuditTuple`.
+ *args* is guaranteed to be a :c:type:`PyTupleObject`.
+ *userData* is the argument passed to PySys_AddAuditHook().
+
.. versionadded:: 3.8
@@ -406,13 +418,13 @@ Process Control
.. c:function:: void Py_FatalError(const char *message)
- .. index:: single: abort()
+ .. index:: single: abort (C function)
Print a fatal error message and kill the process. No cleanup is performed.
This function should only be invoked when a condition is detected that would
make it dangerous to continue using the Python interpreter; e.g., when the
object administration appears to be corrupted. On Unix, the standard C library
- function :c:func:`abort` is called which will attempt to produce a :file:`core`
+ function :c:func:`!abort` is called which will attempt to produce a :file:`core`
file.
The ``Py_FatalError()`` function is replaced with a macro which logs
@@ -426,8 +438,8 @@ Process Control
.. c:function:: void Py_Exit(int status)
.. index::
- single: Py_FinalizeEx()
- single: exit()
+ single: Py_FinalizeEx (C function)
+ single: exit (C function)
Exit the current process. This calls :c:func:`Py_FinalizeEx` and then calls the
standard C library function ``exit(status)``. If :c:func:`Py_FinalizeEx`
@@ -440,7 +452,7 @@ Process Control
.. c:function:: int Py_AtExit(void (*func) ())
.. index::
- single: Py_FinalizeEx()
+ single: Py_FinalizeEx (C function)
single: cleanup functions
Register a cleanup function to be called by :c:func:`Py_FinalizeEx`. The cleanup
diff --git a/Doc/c-api/tuple.rst b/Doc/c-api/tuple.rst
index 9b85522600d4e7..d298aaf3ab5484 100644
--- a/Doc/c-api/tuple.rst
+++ b/Doc/c-api/tuple.rst
@@ -5,7 +5,7 @@
Tuple Objects
-------------
-.. index:: object: tuple
+.. index:: pair: object; tuple
.. c:type:: PyTupleObject
@@ -111,6 +111,8 @@ Tuple Objects
raises :exc:`MemoryError` or :exc:`SystemError`.
+.. _struct-sequence-objects:
+
Struct Sequence Objects
-----------------------
@@ -142,39 +144,39 @@ type.
Contains the meta information of a struct sequence type to create.
- +-------------------+------------------------------+--------------------------------------+
- | Field | C Type | Meaning |
- +===================+==============================+======================================+
- | ``name`` | ``const char *`` | name of the struct sequence type |
- +-------------------+------------------------------+--------------------------------------+
- | ``doc`` | ``const char *`` | pointer to docstring for the type |
- | | | or ``NULL`` to omit |
- +-------------------+------------------------------+--------------------------------------+
- | ``fields`` | ``PyStructSequence_Field *`` | pointer to ``NULL``-terminated array |
- | | | with field names of the new type |
- +-------------------+------------------------------+--------------------------------------+
- | ``n_in_sequence`` | ``int`` | number of fields visible to the |
- | | | Python side (if used as tuple) |
- +-------------------+------------------------------+--------------------------------------+
+ .. c:member:: const char *name
+
+ Name of the struct sequence type.
+
+ .. c:member:: const char *doc
+
+ Pointer to docstring for the type or ``NULL`` to omit.
+
+ .. c:member:: PyStructSequence_Field *fields
+
+ Pointer to ``NULL``-terminated array with field names of the new type.
+
+ .. c:member:: int n_in_sequence
+
+ Number of fields visible to the Python side (if used as tuple).
.. c:type:: PyStructSequence_Field
Describes a field of a struct sequence. As a struct sequence is modeled as a
- tuple, all fields are typed as :c:type:`PyObject*`. The index in the
- :attr:`fields` array of the :c:type:`PyStructSequence_Desc` determines which
+ tuple, all fields are typed as :c:expr:`PyObject*`. The index in the
+ :c:member:`~PyStructSequence_Desc.fields` array of
+ the :c:type:`PyStructSequence_Desc` determines which
field of the struct sequence is described.
- +-----------+------------------+-----------------------------------------+
- | Field | C Type | Meaning |
- +===========+==================+=========================================+
- | ``name`` | ``const char *`` | name for the field or ``NULL`` to end |
- | | | the list of named fields, set to |
- | | | :c:data:`PyStructSequence_UnnamedField` |
- | | | to leave unnamed |
- +-----------+------------------+-----------------------------------------+
- | ``doc`` | ``const char *`` | field docstring or ``NULL`` to omit |
- +-----------+------------------+-----------------------------------------+
+ .. c:member:: const char *name
+
+ Name for the field or ``NULL`` to end the list of named fields,
+ set to :c:data:`PyStructSequence_UnnamedField` to leave unnamed.
+
+ .. c:member:: const char *doc
+
+ Field docstring or ``NULL`` to omit.
.. c:var:: const char * const PyStructSequence_UnnamedField
diff --git a/Doc/c-api/type.rst b/Doc/c-api/type.rst
index d740e4eb0897e5..a7ca19677134d0 100644
--- a/Doc/c-api/type.rst
+++ b/Doc/c-api/type.rst
@@ -5,7 +5,7 @@
Type Objects
------------
-.. index:: object: type
+.. index:: pair: object; type
.. c:type:: PyTypeObject
@@ -40,9 +40,9 @@ Type Objects
.. c:function:: unsigned long PyType_GetFlags(PyTypeObject* type)
Return the :c:member:`~PyTypeObject.tp_flags` member of *type*. This function is primarily
- meant for use with `Py_LIMITED_API`; the individual flag bits are
+ meant for use with ``Py_LIMITED_API``; the individual flag bits are
guaranteed to be stable across Python releases, but access to
- :c:member:`~PyTypeObject.tp_flags` itself is not part of the limited API.
+ :c:member:`~PyTypeObject.tp_flags` itself is not part of the :ref:`limited API `.
.. versionadded:: 3.2
@@ -66,7 +66,7 @@ Type Objects
.. c:function:: int PyType_IS_GC(PyTypeObject *o)
Return true if the type object includes support for the cycle detector; this
- tests the type flag :const:`Py_TPFLAGS_HAVE_GC`.
+ tests the type flag :c:macro:`Py_TPFLAGS_HAVE_GC`.
.. c:function:: int PyType_IsSubtype(PyTypeObject *a, PyTypeObject *b)
@@ -99,10 +99,10 @@ Type Objects
.. note::
If some of the base classes implements the GC protocol and the provided
- type does not include the :const:`Py_TPFLAGS_HAVE_GC` in its flags, then
+ type does not include the :c:macro:`Py_TPFLAGS_HAVE_GC` in its flags, then
the GC protocol will be automatically implemented from its parents. On
the contrary, if the type being created does include
- :const:`Py_TPFLAGS_HAVE_GC` in its flags then it **must** implement the
+ :c:macro:`Py_TPFLAGS_HAVE_GC` in its flags then it **must** implement the
GC protocol itself by at least implementing the
:c:member:`~PyTypeObject.tp_traverse` handle.
@@ -149,7 +149,7 @@ Type Objects
``Py_TYPE(self)`` may be a *subclass* of the intended class, and subclasses
are not necessarily defined in the same module as their superclass.
See :c:type:`PyCMethod` to get the class that defines the method.
- See :c:func:`PyType_GetModuleByDef` for cases when ``PyCMethod`` cannot
+ See :c:func:`PyType_GetModuleByDef` for cases when :c:type:`!PyCMethod` cannot
be used.
.. versionadded:: 3.9
@@ -193,7 +193,7 @@ The following functions and structs are used to create
.. c:function:: PyObject* PyType_FromModuleAndSpec(PyObject *module, PyType_Spec *spec, PyObject *bases)
Creates and returns a :ref:`heap type ` from the *spec*
- (:const:`Py_TPFLAGS_HEAPTYPE`).
+ (:c:macro:`Py_TPFLAGS_HEAPTYPE`).
The *bases* argument can be used to specify base classes; it can either
be only one class or a tuple of classes.
@@ -292,7 +292,7 @@ The following functions and structs are used to create
Setting :c:data:`Py_tp_bases` or :c:data:`Py_tp_base` may be
problematic on some platforms.
To avoid issues, use the *bases* argument of
- :py:func:`PyType_FromSpecWithBases` instead.
+ :c:func:`PyType_FromSpecWithBases` instead.
.. versionchanged:: 3.9
@@ -301,7 +301,7 @@ The following functions and structs are used to create
.. versionchanged:: 3.11
:c:member:`~PyBufferProcs.bf_getbuffer` and
:c:member:`~PyBufferProcs.bf_releasebuffer` are now available
- under the limited API.
+ under the :ref:`limited API `.
.. c:member:: void *PyType_Slot.pfunc
diff --git a/Doc/c-api/typehints.rst b/Doc/c-api/typehints.rst
index 8b0b9b651e80e6..98fe68737deb81 100644
--- a/Doc/c-api/typehints.rst
+++ b/Doc/c-api/typehints.rst
@@ -15,8 +15,8 @@ two types exist -- :ref:`GenericAlias ` and
Equivalent to calling the Python class
:class:`types.GenericAlias`. The *origin* and *args* arguments set the
``GenericAlias``\ 's ``__origin__`` and ``__args__`` attributes respectively.
- *origin* should be a :c:type:`PyTypeObject*`, and *args* can be a
- :c:type:`PyTupleObject*` or any ``PyObject*``. If *args* passed is
+ *origin* should be a :c:expr:`PyTypeObject*`, and *args* can be a
+ :c:expr:`PyTupleObject*` or any ``PyObject*``. If *args* passed is
not a tuple, a 1-tuple is automatically constructed and ``__args__`` is set
to ``(args,)``.
Minimal checking is done for the arguments, so the function will succeed even
@@ -35,7 +35,7 @@ two types exist -- :ref:`GenericAlias ` and
...
}
- .. seealso:: The data model method :meth:`__class_getitem__`.
+ .. seealso:: The data model method :meth:`~object.__class_getitem__`.
.. versionadded:: 3.9
diff --git a/Doc/c-api/typeobj.rst b/Doc/c-api/typeobj.rst
index ed434d8fd44fb2..df43eafc377d01 100644
--- a/Doc/c-api/typeobj.rst
+++ b/Doc/c-api/typeobj.rst
@@ -7,8 +7,8 @@ Type Objects
Perhaps one of the most important structures of the Python object system is the
structure that defines a new type: the :c:type:`PyTypeObject` structure. Type
-objects can be handled using any of the :c:func:`PyObject_\*` or
-:c:func:`PyType_\*` functions, but do not offer much that's interesting to most
+objects can be handled using any of the ``PyObject_*`` or
+``PyType_*`` functions, but do not offer much that's interesting to most
Python applications. These objects are fundamental to how objects behave, so
they are very important to the interpreter itself and to any extension module
that implements new types.
@@ -43,13 +43,13 @@ Quick Reference
+================================================+===================================+===================+===+===+===+===+
| :c:member:`~PyTypeObject.tp_name` | const char * | __name__ | X | X | | |
+------------------------------------------------+-----------------------------------+-------------------+---+---+---+---+
- | :c:member:`~PyTypeObject.tp_basicsize` | Py_ssize_t | | X | X | | X |
+ | :c:member:`~PyTypeObject.tp_basicsize` | :c:type:`Py_ssize_t` | | X | X | | X |
+------------------------------------------------+-----------------------------------+-------------------+---+---+---+---+
- | :c:member:`~PyTypeObject.tp_itemsize` | Py_ssize_t | | | X | | X |
+ | :c:member:`~PyTypeObject.tp_itemsize` | :c:type:`Py_ssize_t` | | | X | | X |
+------------------------------------------------+-----------------------------------+-------------------+---+---+---+---+
| :c:member:`~PyTypeObject.tp_dealloc` | :c:type:`destructor` | | X | X | | X |
+------------------------------------------------+-----------------------------------+-------------------+---+---+---+---+
- | :c:member:`~PyTypeObject.tp_vectorcall_offset` | Py_ssize_t | | | X | | X |
+ | :c:member:`~PyTypeObject.tp_vectorcall_offset` | :c:type:`Py_ssize_t` | | | X | | X |
+------------------------------------------------+-----------------------------------+-------------------+---+---+---+---+
| (:c:member:`~PyTypeObject.tp_getattr`) | :c:type:`getattrfunc` | __getattribute__, | | | | G |
| | | __getattr__ | | | | |
@@ -96,7 +96,7 @@ Quick Reference
| | | __gt__, | | | | |
| | | __ge__ | | | | |
+------------------------------------------------+-----------------------------------+-------------------+---+---+---+---+
- | :c:member:`~PyTypeObject.tp_weaklistoffset` | Py_ssize_t | | | X | | ? |
+ | :c:member:`~PyTypeObject.tp_weaklistoffset` | :c:type:`Py_ssize_t` | | | X | | ? |
+------------------------------------------------+-----------------------------------+-------------------+---+---+---+---+
| :c:member:`~PyTypeObject.tp_iter` | :c:type:`getiterfunc` | __iter__ | | | | X |
+------------------------------------------------+-----------------------------------+-------------------+---+---+---+---+
@@ -117,7 +117,7 @@ Quick Reference
| :c:member:`~PyTypeObject.tp_descr_set` | :c:type:`descrsetfunc` | __set__, | | | | X |
| | | __delete__ | | | | |
+------------------------------------------------+-----------------------------------+-------------------+---+---+---+---+
- | :c:member:`~PyTypeObject.tp_dictoffset` | Py_ssize_t | | | X | | ? |
+ | :c:member:`~PyTypeObject.tp_dictoffset` | :c:type:`Py_ssize_t` | | | X | | ? |
+------------------------------------------------+-----------------------------------+-------------------+---+---+---+---+
| :c:member:`~PyTypeObject.tp_init` | :c:type:`initproc` | __init__ | X | X | | X |
+------------------------------------------------+-----------------------------------+-------------------+---+---+---+---+
@@ -149,15 +149,21 @@ Quick Reference
+------------------------------------------------+-----------------------------------+-------------------+---+---+---+---+
.. [#slots]
- A slot name in parentheses indicates it is (effectively) deprecated.
- Names in angle brackets should be treated as read-only.
- Names in square brackets are for internal use only.
- "" (as a prefix) means the field is required (must be non-``NULL``).
+
+ **()**: A slot name in parentheses indicates it is (effectively) deprecated.
+
+ **<>**: Names in angle brackets should be initially set to ``NULL`` and
+ treated as read-only.
+
+ **[]**: Names in square brackets are for internal use only.
+
+ **** (as a prefix) means the field is required (must be non-``NULL``).
+
.. [#cols] Columns:
- **"O"**: set on :c:type:`PyBaseObject_Type`
+ **"O"**: set on :c:data:`PyBaseObject_Type`
- **"T"**: set on :c:type:`PyType_Type`
+ **"T"**: set on :c:data:`PyType_Type`
**"D"**: default (if slot is set to ``NULL``)
@@ -333,15 +339,15 @@ slot typedefs
| :c:type:`allocfunc` | .. line-block:: | :c:type:`PyObject` * |
| | | |
| | :c:type:`PyTypeObject` * | |
-| | Py_ssize_t | |
+| | :c:type:`Py_ssize_t` | |
+-----------------------------+-----------------------------+----------------------+
-| :c:type:`destructor` | void * | void |
+| :c:type:`destructor` | :c:type:`PyObject` * | void |
+-----------------------------+-----------------------------+----------------------+
| :c:type:`freefunc` | void * | void |
+-----------------------------+-----------------------------+----------------------+
| :c:type:`traverseproc` | .. line-block:: | int |
| | | |
-| | void * | |
+| | :c:type:`PyObject` * | |
| | :c:type:`visitproc` | |
| | void * | |
+-----------------------------+-----------------------------+----------------------+
@@ -405,7 +411,7 @@ slot typedefs
+-----------------------------+-----------------------------+----------------------+
| :c:type:`iternextfunc` | :c:type:`PyObject` * | :c:type:`PyObject` * |
+-----------------------------+-----------------------------+----------------------+
-| :c:type:`lenfunc` | :c:type:`PyObject` * | Py_ssize_t |
+| :c:type:`lenfunc` | :c:type:`PyObject` * | :c:type:`Py_ssize_t` |
+-----------------------------+-----------------------------+----------------------+
| :c:type:`getbufferproc` | .. line-block:: | int |
| | | |
@@ -418,7 +424,7 @@ slot typedefs
| | :c:type:`PyObject` * | |
| | :c:type:`Py_buffer` * | |
+-----------------------------+-----------------------------+----------------------+
-| :c:type:`inquiry` | void * | int |
+| :c:type:`inquiry` | :c:type:`PyObject` * | int |
+-----------------------------+-----------------------------+----------------------+
| :c:type:`unaryfunc` | .. line-block:: | :c:type:`PyObject` * |
| | | |
@@ -438,12 +444,13 @@ slot typedefs
| :c:type:`ssizeargfunc` | .. line-block:: | :c:type:`PyObject` * |
| | | |
| | :c:type:`PyObject` * | |
-| | Py_ssize_t | |
+| | :c:type:`Py_ssize_t` | |
+-----------------------------+-----------------------------+----------------------+
| :c:type:`ssizeobjargproc` | .. line-block:: | int |
| | | |
| | :c:type:`PyObject` * | |
-| | Py_ssize_t | |
+| | :c:type:`Py_ssize_t` | |
+| | :c:type:`PyObject` * | |
+-----------------------------+-----------------------------+----------------------+
| :c:type:`objobjproc` | .. line-block:: | int |
| | | |
@@ -476,17 +483,17 @@ PyObject Slots
--------------
The type object structure extends the :c:type:`PyVarObject` structure. The
-:attr:`ob_size` field is used for dynamic types (created by :func:`type_new`,
+:c:member:`~PyVarObject.ob_size` field is used for dynamic types (created by :c:func:`!type_new`,
usually called from a class statement). Note that :c:data:`PyType_Type` (the
metatype) initializes :c:member:`~PyTypeObject.tp_itemsize`, which means that its instances (i.e.
-type objects) *must* have the :attr:`ob_size` field.
+type objects) *must* have the :c:member:`~PyVarObject.ob_size` field.
.. c:member:: Py_ssize_t PyObject.ob_refcnt
This is the type object's reference count, initialized to ``1`` by the
``PyObject_HEAD_INIT`` macro. Note that for :ref:`statically allocated type
- objects `, the type's instances (objects whose :attr:`ob_type`
+ objects `, the type's instances (objects whose :c:member:`~PyObject.ob_type`
points back to the type) do *not* count as references. But for
:ref:`dynamically allocated type objects `, the instances *do*
count as references.
@@ -510,8 +517,8 @@ type objects) *must* have the :attr:`ob_size` field.
Foo_Type.ob_type = &PyType_Type;
This should be done before any instances of the type are created.
- :c:func:`PyType_Ready` checks if :attr:`ob_type` is ``NULL``, and if so,
- initializes it to the :attr:`ob_type` field of the base class.
+ :c:func:`PyType_Ready` checks if :c:member:`~PyObject.ob_type` is ``NULL``, and if so,
+ initializes it to the :c:member:`~PyObject.ob_type` field of the base class.
:c:func:`PyType_Ready` will not change this field if it is non-zero.
**Inheritance:**
@@ -529,7 +536,7 @@ type objects) *must* have the :attr:`ob_size` field.
``PyObject_HEAD_INIT`` macro. For :ref:`statically allocated objects
`, these fields always remain ``NULL``. For :ref:`dynamically
allocated objects `, these two fields are used to link the
- object into a doubly-linked list of *all* live objects on the heap.
+ object into a doubly linked list of *all* live objects on the heap.
This could be used for various debugging purposes; currently the only uses
are the :func:`sys.getobjects` function and to print the objects that are
@@ -560,8 +567,8 @@ PyTypeObject Slots
Each slot has a section describing inheritance. If :c:func:`PyType_Ready`
may set a value when the field is set to ``NULL`` then there will also be
-a "Default" section. (Note that many fields set on :c:type:`PyBaseObject_Type`
-and :c:type:`PyType_Type` effectively act as defaults.)
+a "Default" section. (Note that many fields set on :c:data:`PyBaseObject_Type`
+and :c:data:`PyType_Type` effectively act as defaults.)
.. c:member:: const char* PyTypeObject.tp_name
@@ -570,7 +577,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
name, followed by a dot, followed by the type name; for built-in types, it
should be just the type name. If the module is a submodule of a package, the
full package name is part of the full module name. For example, a type named
- :class:`T` defined in module :mod:`M` in subpackage :mod:`Q` in package :mod:`P`
+ :class:`!T` defined in module :mod:`!M` in subpackage :mod:`!Q` in package :mod:`!P`
should have the :c:member:`~PyTypeObject.tp_name` initializer ``"P.Q.M.T"``.
For :ref:`dynamically allocated type objects `,
@@ -610,20 +617,20 @@ and :c:type:`PyType_Type` effectively act as defaults.)
instances have the same size, given in :c:member:`~PyTypeObject.tp_basicsize`.
For a type with variable-length instances, the instances must have an
- :attr:`ob_size` field, and the instance size is :c:member:`~PyTypeObject.tp_basicsize` plus N
+ :c:member:`~PyVarObject.ob_size` field, and the instance size is :c:member:`~PyTypeObject.tp_basicsize` plus N
times :c:member:`~PyTypeObject.tp_itemsize`, where N is the "length" of the object. The value of
- N is typically stored in the instance's :attr:`ob_size` field. There are
- exceptions: for example, ints use a negative :attr:`ob_size` to indicate a
+ N is typically stored in the instance's :c:member:`~PyVarObject.ob_size` field. There are
+ exceptions: for example, ints use a negative :c:member:`~PyVarObject.ob_size` to indicate a
negative number, and N is ``abs(ob_size)`` there. Also, the presence of an
- :attr:`ob_size` field in the instance layout doesn't mean that the instance
+ :c:member:`~PyVarObject.ob_size` field in the instance layout doesn't mean that the instance
structure is variable-length (for example, the structure for the list type has
- fixed-length instances, yet those instances have a meaningful :attr:`ob_size`
+ fixed-length instances, yet those instances have a meaningful :c:member:`~PyVarObject.ob_size`
field).
The basic size includes the fields in the instance declared by the macro
:c:macro:`PyObject_HEAD` or :c:macro:`PyObject_VAR_HEAD` (whichever is used to
- declare the instance struct) and this in turn includes the :attr:`_ob_prev` and
- :attr:`_ob_next` fields if they are present. This means that the only correct
+ declare the instance struct) and this in turn includes the :c:member:`~PyObject._ob_prev` and
+ :c:member:`~PyObject._ob_next` fields if they are present. This means that the only correct
way to get an initializer for the :c:member:`~PyTypeObject.tp_basicsize` is to use the
``sizeof`` operator on the struct used to declare the instance layout.
The basic size does not include the GC header size.
@@ -660,15 +667,15 @@ and :c:type:`PyType_Type` effectively act as defaults.)
memory buffers owned by the instance (using the freeing function corresponding
to the allocation function used to allocate the buffer), and call the type's
:c:member:`~PyTypeObject.tp_free` function. If the type is not subtypable
- (doesn't have the :const:`Py_TPFLAGS_BASETYPE` flag bit set), it is
+ (doesn't have the :c:macro:`Py_TPFLAGS_BASETYPE` flag bit set), it is
permissible to call the object deallocator directly instead of via
:c:member:`~PyTypeObject.tp_free`. The object deallocator should be the one used to allocate the
instance; this is normally :c:func:`PyObject_Del` if the instance was allocated
- using :c:func:`PyObject_New` or :c:func:`PyObject_VarNew`, or
+ using :c:macro:`PyObject_New` or :c:macro:`PyObject_NewVar`, or
:c:func:`PyObject_GC_Del` if the instance was allocated using
- :c:func:`PyObject_GC_New` or :c:func:`PyObject_GC_NewVar`.
+ :c:macro:`PyObject_GC_New` or :c:macro:`PyObject_GC_NewVar`.
- If the type supports garbage collection (has the :const:`Py_TPFLAGS_HAVE_GC`
+ If the type supports garbage collection (has the :c:macro:`Py_TPFLAGS_HAVE_GC`
flag bit set), the destructor should call :c:func:`PyObject_GC_UnTrack`
before clearing any member fields.
@@ -680,8 +687,9 @@ and :c:type:`PyType_Type` effectively act as defaults.)
Py_TYPE(self)->tp_free((PyObject *)self);
}
- Finally, if the type is heap allocated (:const:`Py_TPFLAGS_HEAPTYPE`), the
- deallocator should decrement the reference count for its type object after
+ Finally, if the type is heap allocated (:c:macro:`Py_TPFLAGS_HEAPTYPE`), the
+ deallocator should release the owned reference to its type object
+ (via :c:func:`Py_DECREF`) after
calling the type deallocator. In order to avoid dangling pointers, the
recommended way to achieve this is:
@@ -707,12 +715,12 @@ and :c:type:`PyType_Type` effectively act as defaults.)
a more efficient alternative
of the simpler :c:member:`~PyTypeObject.tp_call`.
- This field is only used if the flag :const:`Py_TPFLAGS_HAVE_VECTORCALL`
+ This field is only used if the flag :c:macro:`Py_TPFLAGS_HAVE_VECTORCALL`
is set. If so, this must be a positive integer containing the offset in the
instance of a :c:type:`vectorcallfunc` pointer.
The *vectorcallfunc* pointer may be ``NULL``, in which case the instance behaves
- as if :const:`Py_TPFLAGS_HAVE_VECTORCALL` was not set: calling the instance
+ as if :c:macro:`Py_TPFLAGS_HAVE_VECTORCALL` was not set: calling the instance
falls back to :c:member:`~PyTypeObject.tp_call`.
Any class that sets ``Py_TPFLAGS_HAVE_VECTORCALL`` must also set
@@ -727,12 +735,6 @@ and :c:type:`PyType_Type` effectively act as defaults.)
When a user sets :attr:`__call__` in Python code, only *tp_call* is updated,
likely making it inconsistent with the vectorcall function.
- .. note::
-
- The semantics of the ``tp_vectorcall_offset`` slot are provisional and
- expected to be finalized in Python 3.9.
- If you use vectorcall, plan for updating your code for Python 3.9.
-
.. versionchanged:: 3.8
Before version 3.8, this slot was named ``tp_print``.
@@ -742,12 +744,12 @@ and :c:type:`PyType_Type` effectively act as defaults.)
**Inheritance:**
This field is always inherited.
- However, the :const:`Py_TPFLAGS_HAVE_VECTORCALL` flag is not
+ However, the :c:macro:`Py_TPFLAGS_HAVE_VECTORCALL` flag is not
always inherited. If it's not, then the subclass won't use
:ref:`vectorcall `, except when
:c:func:`PyVectorcall_Call` is explicitly called.
This is in particular the case for types without the
- :const:`Py_TPFLAGS_IMMUTABLETYPE` flag set (including subclasses defined in
+ :c:macro:`Py_TPFLAGS_IMMUTABLETYPE` flag set (including subclasses defined in
Python).
@@ -761,7 +763,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
**Inheritance:**
- Group: :attr:`tp_getattr`, :attr:`tp_getattro`
+ Group: :c:member:`~PyTypeObject.tp_getattr`, :c:member:`~PyTypeObject.tp_getattro`
This field is inherited by subtypes together with :c:member:`~PyTypeObject.tp_getattro`: a subtype
inherits both :c:member:`~PyTypeObject.tp_getattr` and :c:member:`~PyTypeObject.tp_getattro` from its base type when
@@ -778,7 +780,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
**Inheritance:**
- Group: :attr:`tp_setattr`, :attr:`tp_setattro`
+ Group: :c:member:`~PyTypeObject.tp_setattr`, :c:member:`~PyTypeObject.tp_setattro`
This field is inherited by subtypes together with :c:member:`~PyTypeObject.tp_setattro`: a subtype
inherits both :c:member:`~PyTypeObject.tp_setattr` and :c:member:`~PyTypeObject.tp_setattro` from its base type when
@@ -802,7 +804,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
.. c:member:: reprfunc PyTypeObject.tp_repr
- .. index:: builtin: repr
+ .. index:: pair: built-in function; repr
An optional pointer to a function that implements the built-in function
:func:`repr`.
@@ -867,7 +869,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
.. c:member:: hashfunc PyTypeObject.tp_hash
- .. index:: builtin: hash
+ .. index:: pair: built-in function; hash
An optional pointer to a function that implements the built-in function
:func:`hash`.
@@ -880,7 +882,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
normal return value; when an error occurs during the computation of the hash
value, the function should set an exception and return ``-1``.
- When this field is not set (*and* :attr:`tp_richcompare` is not set),
+ When this field is not set (*and* :c:member:`~PyTypeObject.tp_richcompare` is not set),
an attempt to take the hash of the object raises :exc:`TypeError`.
This is the same as setting it to :c:func:`PyObject_HashNotImplemented`.
@@ -894,7 +896,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
**Inheritance:**
- Group: :attr:`tp_hash`, :attr:`tp_richcompare`
+ Group: :c:member:`~PyTypeObject.tp_hash`, :c:member:`~PyTypeObject.tp_richcompare`
This field is inherited by subtypes together with
:c:member:`~PyTypeObject.tp_richcompare`: a subtype inherits both of
@@ -953,7 +955,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
**Inheritance:**
- Group: :attr:`tp_getattr`, :attr:`tp_getattro`
+ Group: :c:member:`~PyTypeObject.tp_getattr`, :c:member:`~PyTypeObject.tp_getattro`
This field is inherited by subtypes together with :c:member:`~PyTypeObject.tp_getattr`: a subtype
inherits both :c:member:`~PyTypeObject.tp_getattr` and :c:member:`~PyTypeObject.tp_getattro` from its base type when
@@ -961,7 +963,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
**Default:**
- :c:type:`PyBaseObject_Type` uses :c:func:`PyObject_GenericGetAttr`.
+ :c:data:`PyBaseObject_Type` uses :c:func:`PyObject_GenericGetAttr`.
.. c:member:: setattrofunc PyTypeObject.tp_setattro
@@ -979,7 +981,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
**Inheritance:**
- Group: :attr:`tp_setattr`, :attr:`tp_setattro`
+ Group: :c:member:`~PyTypeObject.tp_setattr`, :c:member:`~PyTypeObject.tp_setattro`
This field is inherited by subtypes together with :c:member:`~PyTypeObject.tp_setattr`: a subtype
inherits both :c:member:`~PyTypeObject.tp_setattr` and :c:member:`~PyTypeObject.tp_setattro` from its base type when
@@ -987,7 +989,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
**Default:**
- :c:type:`PyBaseObject_Type` uses :c:func:`PyObject_GenericSetAttr`.
+ :c:data:`PyBaseObject_Type` uses :c:func:`PyObject_GenericSetAttr`.
.. c:member:: PyBufferProcs* PyTypeObject.tp_as_buffer
@@ -1019,9 +1021,9 @@ and :c:type:`PyType_Type` effectively act as defaults.)
this flag bit. The flag bits that pertain to extension structures are strictly
inherited if the extension structure is inherited, i.e. the base type's value of
the flag bit is copied into the subtype together with a pointer to the extension
- structure. The :const:`Py_TPFLAGS_HAVE_GC` flag bit is inherited together with
+ structure. The :c:macro:`Py_TPFLAGS_HAVE_GC` flag bit is inherited together with
the :c:member:`~PyTypeObject.tp_traverse` and :c:member:`~PyTypeObject.tp_clear` fields, i.e. if the
- :const:`Py_TPFLAGS_HAVE_GC` flag bit is clear in the subtype and the
+ :c:macro:`Py_TPFLAGS_HAVE_GC` flag bit is clear in the subtype and the
:c:member:`~PyTypeObject.tp_traverse` and :c:member:`~PyTypeObject.tp_clear` fields in the subtype exist and have
``NULL`` values.
@@ -1029,21 +1031,23 @@ and :c:type:`PyType_Type` effectively act as defaults.)
**Default:**
- :c:type:`PyBaseObject_Type` uses
+ :c:data:`PyBaseObject_Type` uses
``Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE``.
**Bit Masks:**
+ .. c:namespace:: NULL
+
The following bit masks are currently defined; these can be ORed together using
the ``|`` operator to form the value of the :c:member:`~PyTypeObject.tp_flags` field. The macro
:c:func:`PyType_HasFeature` takes a type and a flags value, *tp* and *f*, and
checks whether ``tp->tp_flags & f`` is non-zero.
- .. data:: Py_TPFLAGS_HEAPTYPE
+ .. c:macro:: Py_TPFLAGS_HEAPTYPE
This bit is set when the type object itself is allocated on the heap, for
example, types created dynamically using :c:func:`PyType_FromSpec`. In this
- case, the :attr:`ob_type` field of its instances is considered a reference to
+ case, the :c:member:`~PyObject.ob_type` field of its instances is considered a reference to
the type, and the type object is INCREF'ed when a new instance is created, and
DECREF'ed when an instance is destroyed (this does not apply to instances of
subtypes; only the type referenced by the instance's ob_type gets INCREF'ed or
@@ -1054,7 +1058,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
???
- .. data:: Py_TPFLAGS_BASETYPE
+ .. c:macro:: Py_TPFLAGS_BASETYPE
This bit is set when the type can be used as the base type of another type. If
this bit is clear, the type cannot be subtyped (similar to a "final" class in
@@ -1065,7 +1069,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
???
- .. data:: Py_TPFLAGS_READY
+ .. c:macro:: Py_TPFLAGS_READY
This bit is set when the type object has been fully initialized by
:c:func:`PyType_Ready`.
@@ -1075,7 +1079,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
???
- .. data:: Py_TPFLAGS_READYING
+ .. c:macro:: Py_TPFLAGS_READYING
This bit is set while :c:func:`PyType_Ready` is in the process of initializing
the type object.
@@ -1085,10 +1089,10 @@ and :c:type:`PyType_Type` effectively act as defaults.)
???
- .. data:: Py_TPFLAGS_HAVE_GC
+ .. c:macro:: Py_TPFLAGS_HAVE_GC
This bit is set when the object supports garbage collection. If this bit
- is set, instances must be created using :c:func:`PyObject_GC_New` and
+ is set, instances must be created using :c:macro:`PyObject_GC_New` and
destroyed using :c:func:`PyObject_GC_Del`. More information in section
:ref:`supporting-cycle-detection`. This bit also implies that the
GC-related fields :c:member:`~PyTypeObject.tp_traverse` and :c:member:`~PyTypeObject.tp_clear` are present in
@@ -1096,28 +1100,28 @@ and :c:type:`PyType_Type` effectively act as defaults.)
**Inheritance:**
- Group: :const:`Py_TPFLAGS_HAVE_GC`, :attr:`tp_traverse`, :attr:`tp_clear`
+ Group: :c:macro:`Py_TPFLAGS_HAVE_GC`, :c:member:`~PyTypeObject.tp_traverse`, :c:member:`~PyTypeObject.tp_clear`
- The :const:`Py_TPFLAGS_HAVE_GC` flag bit is inherited
- together with the :attr:`tp_traverse` and :attr:`tp_clear`
- fields, i.e. if the :const:`Py_TPFLAGS_HAVE_GC` flag bit is
- clear in the subtype and the :attr:`tp_traverse` and
- :attr:`tp_clear` fields in the subtype exist and have ``NULL``
+ The :c:macro:`Py_TPFLAGS_HAVE_GC` flag bit is inherited
+ together with the :c:member:`~PyTypeObject.tp_traverse` and :c:member:`~PyTypeObject.tp_clear`
+ fields, i.e. if the :c:macro:`Py_TPFLAGS_HAVE_GC` flag bit is
+ clear in the subtype and the :c:member:`~PyTypeObject.tp_traverse` and
+ :c:member:`~PyTypeObject.tp_clear` fields in the subtype exist and have ``NULL``
values.
- .. data:: Py_TPFLAGS_DEFAULT
+ .. c:macro:: Py_TPFLAGS_DEFAULT
This is a bitmask of all the bits that pertain to the existence of certain
fields in the type object and its extension structures. Currently, it includes
- the following bits: :const:`Py_TPFLAGS_HAVE_STACKLESS_EXTENSION`.
+ the following bits: :c:macro:`Py_TPFLAGS_HAVE_STACKLESS_EXTENSION`.
**Inheritance:**
???
- .. data:: Py_TPFLAGS_METHOD_DESCRIPTOR
+ .. c:macro:: Py_TPFLAGS_METHOD_DESCRIPTOR
This bit indicates that objects behave like unbound methods.
@@ -1138,21 +1142,21 @@ and :c:type:`PyType_Type` effectively act as defaults.)
**Inheritance:**
This flag is never inherited by types without the
- :const:`Py_TPFLAGS_IMMUTABLETYPE` flag set. For extension types, it is
+ :c:macro:`Py_TPFLAGS_IMMUTABLETYPE` flag set. For extension types, it is
inherited whenever :c:member:`~PyTypeObject.tp_descr_get` is inherited.
.. XXX Document more flags here?
- .. data:: Py_TPFLAGS_LONG_SUBCLASS
- .. data:: Py_TPFLAGS_LIST_SUBCLASS
- .. data:: Py_TPFLAGS_TUPLE_SUBCLASS
- .. data:: Py_TPFLAGS_BYTES_SUBCLASS
- .. data:: Py_TPFLAGS_UNICODE_SUBCLASS
- .. data:: Py_TPFLAGS_DICT_SUBCLASS
- .. data:: Py_TPFLAGS_BASE_EXC_SUBCLASS
- .. data:: Py_TPFLAGS_TYPE_SUBCLASS
+ .. c:macro:: Py_TPFLAGS_LONG_SUBCLASS
+ .. c:macro:: Py_TPFLAGS_LIST_SUBCLASS
+ .. c:macro:: Py_TPFLAGS_TUPLE_SUBCLASS
+ .. c:macro:: Py_TPFLAGS_BYTES_SUBCLASS
+ .. c:macro:: Py_TPFLAGS_UNICODE_SUBCLASS
+ .. c:macro:: Py_TPFLAGS_DICT_SUBCLASS
+ .. c:macro:: Py_TPFLAGS_BASE_EXC_SUBCLASS
+ .. c:macro:: Py_TPFLAGS_TYPE_SUBCLASS
These flags are used by functions such as
:c:func:`PyLong_Check` to quickly determine if a type is a subclass
@@ -1163,7 +1167,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
will behave differently depending on what kind of check is used.
- .. data:: Py_TPFLAGS_HAVE_FINALIZE
+ .. c:macro:: Py_TPFLAGS_HAVE_FINALIZE
This bit is set when the :c:member:`~PyTypeObject.tp_finalize` slot is present in the
type structure.
@@ -1176,7 +1180,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
type structure.
- .. data:: Py_TPFLAGS_HAVE_VECTORCALL
+ .. c:macro:: Py_TPFLAGS_HAVE_VECTORCALL
This bit is set when the class implements
the :ref:`vectorcall protocol `.
@@ -1185,12 +1189,12 @@ and :c:type:`PyType_Type` effectively act as defaults.)
**Inheritance:**
This bit is inherited for types with the
- :const:`Py_TPFLAGS_IMMUTABLETYPE` flag set, if
+ :c:macro:`Py_TPFLAGS_IMMUTABLETYPE` flag set, if
:c:member:`~PyTypeObject.tp_call` is also inherited.
.. versionadded:: 3.9
- .. data:: Py_TPFLAGS_IMMUTABLETYPE
+ .. c:macro:: Py_TPFLAGS_IMMUTABLETYPE
This bit is set for type objects that are immutable: type attributes cannot be set nor deleted.
@@ -1203,7 +1207,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
.. versionadded:: 3.10
- .. data:: Py_TPFLAGS_DISALLOW_INSTANTIATION
+ .. c:macro:: Py_TPFLAGS_DISALLOW_INSTANTIATION
Disallow creating instances of the type: set
:c:member:`~PyTypeObject.tp_new` to NULL and don't create the ``__new__``
@@ -1219,11 +1223,22 @@ and :c:type:`PyType_Type` effectively act as defaults.)
**Inheritance:**
This flag is not inherited.
+ However, subclasses will not be instantiable unless they provide a
+ non-NULL :c:member:`~PyTypeObject.tp_new` (which is only possible
+ via the C API).
+
+ .. note::
+
+ To disallow instantiating a class directly but allow instantiating
+ its subclasses (e.g. for an :term:`abstract base class`),
+ do not use this flag.
+ Instead, make :c:member:`~PyTypeObject.tp_new` only succeed for
+ subclasses.
.. versionadded:: 3.10
- .. data:: Py_TPFLAGS_MAPPING
+ .. c:macro:: Py_TPFLAGS_MAPPING
This bit indicates that instances of the class may match mapping patterns
when used as the subject of a :keyword:`match` block. It is automatically
@@ -1232,20 +1247,20 @@ and :c:type:`PyType_Type` effectively act as defaults.)
.. note::
- :const:`Py_TPFLAGS_MAPPING` and :const:`Py_TPFLAGS_SEQUENCE` are
+ :c:macro:`Py_TPFLAGS_MAPPING` and :c:macro:`Py_TPFLAGS_SEQUENCE` are
mutually exclusive; it is an error to enable both flags simultaneously.
**Inheritance:**
This flag is inherited by types that do not already set
- :const:`Py_TPFLAGS_SEQUENCE`.
+ :c:macro:`Py_TPFLAGS_SEQUENCE`.
.. seealso:: :pep:`634` -- Structural Pattern Matching: Specification
.. versionadded:: 3.10
- .. data:: Py_TPFLAGS_SEQUENCE
+ .. c:macro:: Py_TPFLAGS_SEQUENCE
This bit indicates that instances of the class may match sequence patterns
when used as the subject of a :keyword:`match` block. It is automatically
@@ -1254,13 +1269,13 @@ and :c:type:`PyType_Type` effectively act as defaults.)
.. note::
- :const:`Py_TPFLAGS_MAPPING` and :const:`Py_TPFLAGS_SEQUENCE` are
+ :c:macro:`Py_TPFLAGS_MAPPING` and :c:macro:`Py_TPFLAGS_SEQUENCE` are
mutually exclusive; it is an error to enable both flags simultaneously.
**Inheritance:**
This flag is inherited by types that do not already set
- :const:`Py_TPFLAGS_MAPPING`.
+ :c:macro:`Py_TPFLAGS_MAPPING`.
.. seealso:: :pep:`634` -- Structural Pattern Matching: Specification
@@ -1281,7 +1296,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
.. c:member:: traverseproc PyTypeObject.tp_traverse
An optional pointer to a traversal function for the garbage collector. This is
- only used if the :const:`Py_TPFLAGS_HAVE_GC` flag bit is set. The signature is::
+ only used if the :c:macro:`Py_TPFLAGS_HAVE_GC` flag bit is set. The signature is::
int tp_traverse(PyObject *self, visitproc visit, void *arg);
@@ -1291,8 +1306,8 @@ and :c:type:`PyType_Type` effectively act as defaults.)
The :c:member:`~PyTypeObject.tp_traverse` pointer is used by the garbage collector to detect
reference cycles. A typical implementation of a :c:member:`~PyTypeObject.tp_traverse` function
simply calls :c:func:`Py_VISIT` on each of the instance's members that are Python
- objects that the instance owns. For example, this is function :c:func:`local_traverse` from the
- :mod:`_thread` extension module::
+ objects that the instance owns. For example, this is function :c:func:`!local_traverse` from the
+ :mod:`!_thread` extension module::
static int
local_traverse(localobject *self, visitproc visit, void *arg)
@@ -1343,10 +1358,10 @@ and :c:type:`PyType_Type` effectively act as defaults.)
**Inheritance:**
- Group: :const:`Py_TPFLAGS_HAVE_GC`, :attr:`tp_traverse`, :attr:`tp_clear`
+ Group: :c:macro:`Py_TPFLAGS_HAVE_GC`, :c:member:`~PyTypeObject.tp_traverse`, :c:member:`~PyTypeObject.tp_clear`
This field is inherited by subtypes together with :c:member:`~PyTypeObject.tp_clear` and the
- :const:`Py_TPFLAGS_HAVE_GC` flag bit: the flag bit, :c:member:`~PyTypeObject.tp_traverse`, and
+ :c:macro:`Py_TPFLAGS_HAVE_GC` flag bit: the flag bit, :c:member:`~PyTypeObject.tp_traverse`, and
:c:member:`~PyTypeObject.tp_clear` are all inherited from the base type if they are all zero in
the subtype.
@@ -1354,7 +1369,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
.. c:member:: inquiry PyTypeObject.tp_clear
An optional pointer to a clear function for the garbage collector. This is only
- used if the :const:`Py_TPFLAGS_HAVE_GC` flag bit is set. The signature is::
+ used if the :c:macro:`Py_TPFLAGS_HAVE_GC` flag bit is set. The signature is::
int tp_clear(PyObject *);
@@ -1383,9 +1398,10 @@ and :c:type:`PyType_Type` effectively act as defaults.)
}
The :c:func:`Py_CLEAR` macro should be used, because clearing references is
- delicate: the reference to the contained object must not be decremented until
+ delicate: the reference to the contained object must not be released
+ (via :c:func:`Py_DECREF`) until
after the pointer to the contained object is set to ``NULL``. This is because
- decrementing the reference count may cause the contained object to become trash,
+ releasing the reference may cause the contained object to become trash,
triggering a chain of reclamation activity that may include invoking arbitrary
Python code (due to finalizers, or weakref callbacks, associated with the
contained object). If it's possible for such code to reference *self* again,
@@ -1410,10 +1426,10 @@ and :c:type:`PyType_Type` effectively act as defaults.)
**Inheritance:**
- Group: :const:`Py_TPFLAGS_HAVE_GC`, :attr:`tp_traverse`, :attr:`tp_clear`
+ Group: :c:macro:`Py_TPFLAGS_HAVE_GC`, :c:member:`~PyTypeObject.tp_traverse`, :c:member:`~PyTypeObject.tp_clear`
This field is inherited by subtypes together with :c:member:`~PyTypeObject.tp_traverse` and the
- :const:`Py_TPFLAGS_HAVE_GC` flag bit: the flag bit, :c:member:`~PyTypeObject.tp_traverse`, and
+ :c:macro:`Py_TPFLAGS_HAVE_GC` flag bit: the flag bit, :c:member:`~PyTypeObject.tp_traverse`, and
:c:member:`~PyTypeObject.tp_clear` are all inherited from the base type if they are all zero in
the subtype.
@@ -1435,21 +1451,23 @@ and :c:type:`PyType_Type` effectively act as defaults.)
The following constants are defined to be used as the third argument for
:c:member:`~PyTypeObject.tp_richcompare` and for :c:func:`PyObject_RichCompare`:
- +----------------+------------+
- | Constant | Comparison |
- +================+============+
- | :const:`Py_LT` | ``<`` |
- +----------------+------------+
- | :const:`Py_LE` | ``<=`` |
- +----------------+------------+
- | :const:`Py_EQ` | ``==`` |
- +----------------+------------+
- | :const:`Py_NE` | ``!=`` |
- +----------------+------------+
- | :const:`Py_GT` | ``>`` |
- +----------------+------------+
- | :const:`Py_GE` | ``>=`` |
- +----------------+------------+
+ .. c:namespace:: NULL
+
+ +--------------------+------------+
+ | Constant | Comparison |
+ +====================+============+
+ | .. c:macro:: Py_LT | ``<`` |
+ +--------------------+------------+
+ | .. c:macro:: Py_LE | ``<=`` |
+ +--------------------+------------+
+ | .. c:macro:: Py_EQ | ``==`` |
+ +--------------------+------------+
+ | .. c:macro:: Py_NE | ``!=`` |
+ +--------------------+------------+
+ | .. c:macro:: Py_GT | ``>`` |
+ +--------------------+------------+
+ | .. c:macro:: Py_GE | ``>=`` |
+ +--------------------+------------+
The following macro is defined to ease writing rich comparison functions:
@@ -1461,7 +1479,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
they may be C ints or floats). The third argument specifies the requested
operation, as for :c:func:`PyObject_RichCompare`.
- The return value's reference count is properly incremented.
+ The returned value is a new :term:`strong reference`.
On error, sets an exception and returns ``NULL`` from the function.
@@ -1469,7 +1487,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
**Inheritance:**
- Group: :attr:`tp_hash`, :attr:`tp_richcompare`
+ Group: :c:member:`~PyTypeObject.tp_hash`, :c:member:`~PyTypeObject.tp_richcompare`
This field is inherited by subtypes together with :c:member:`~PyTypeObject.tp_hash`:
a subtype inherits :c:member:`~PyTypeObject.tp_richcompare` and :c:member:`~PyTypeObject.tp_hash` when
@@ -1478,9 +1496,9 @@ and :c:type:`PyType_Type` effectively act as defaults.)
**Default:**
- :c:type:`PyBaseObject_Type` provides a :attr:`tp_richcompare`
+ :c:data:`PyBaseObject_Type` provides a :c:member:`~PyTypeObject.tp_richcompare`
implementation, which may be inherited. However, if only
- :attr:`tp_hash` is defined, not even the inherited function is used
+ :c:member:`~PyTypeObject.tp_hash` is defined, not even the inherited function is used
and instances of the type will not be able to participate in any
comparisons.
@@ -1490,8 +1508,8 @@ and :c:type:`PyType_Type` effectively act as defaults.)
If the instances of this type are weakly referenceable, this field is greater
than zero and contains the offset in the instance structure of the weak
reference list head (ignoring the GC header, if present); this offset is used by
- :c:func:`PyObject_ClearWeakRefs` and the :c:func:`PyWeakref_\*` functions. The
- instance structure needs to include a field of type :c:type:`PyObject*` which is
+ :c:func:`PyObject_ClearWeakRefs` and the ``PyWeakref_*`` functions. The
+ instance structure needs to include a field of type :c:expr:`PyObject*` which is
initialized to ``NULL``.
Do not confuse this field with :c:member:`~PyTypeObject.tp_weaklist`; that is the list head for
@@ -1616,7 +1634,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
to a pointer, are valid C99 address constants.
However, the unary '&' operator applied to a non-static variable
- like :c:func:`PyBaseObject_Type` is not required to produce an address
+ like :c:data:`PyBaseObject_Type` is not required to produce an address
constant. Compilers may support this (gcc does), MSVC does not.
Both compilers are strictly standard conforming in this particular
behavior.
@@ -1642,7 +1660,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
called; it may also be initialized to a dictionary containing initial attributes
for the type. Once :c:func:`PyType_Ready` has initialized the type, extra
attributes for the type may be added to this dictionary only if they don't
- correspond to overloaded operations (like :meth:`__add__`).
+ correspond to overloaded operations (like :meth:`~object.__add__`).
**Inheritance:**
@@ -1715,18 +1733,11 @@ and :c:type:`PyType_Type` effectively act as defaults.)
:c:member:`~PyTypeObject.tp_dictoffset` should be set to ``-4`` to indicate that the dictionary is
at the very end of the structure.
- The real dictionary offset in an instance can be computed from a negative
- :c:member:`~PyTypeObject.tp_dictoffset` as follows::
-
- dictoffset = tp_basicsize + abs(ob_size)*tp_itemsize + tp_dictoffset
- if dictoffset is not aligned on sizeof(void*):
- round up to sizeof(void*)
-
- where :c:member:`~PyTypeObject.tp_basicsize`, :c:member:`~PyTypeObject.tp_itemsize` and :c:member:`~PyTypeObject.tp_dictoffset` are
- taken from the type object, and :attr:`ob_size` is taken from the instance. The
- absolute value is taken because ints use the sign of :attr:`ob_size` to
- store the sign of the number. (There's never a need to do this calculation
- yourself; it is done for you by :c:func:`_PyObject_GetDictPtr`.)
+ The :c:member:`~PyTypeObject.tp_dictoffset` should be regarded as write-only.
+ To get the pointer to the dictionary call :c:func:`PyObject_GenericGetDict`.
+ Calling :c:func:`PyObject_GenericGetDict` may need to allocate memory for the
+ dictionary, so it is may be more efficient to call :c:func:`PyObject_GetAttr`
+ when accessing an attribute on the object.
**Inheritance:**
@@ -1750,17 +1761,17 @@ and :c:type:`PyType_Type` effectively act as defaults.)
**Default:**
This slot has no default. For :ref:`static types `, if the
- field is ``NULL`` then no :attr:`__dict__` gets created for instances.
+ field is ``NULL`` then no :attr:`~object.__dict__` gets created for instances.
.. c:member:: initproc PyTypeObject.tp_init
An optional pointer to an instance initialization function.
- This function corresponds to the :meth:`__init__` method of classes. Like
- :meth:`__init__`, it is possible to create an instance without calling
- :meth:`__init__`, and it is possible to reinitialize an instance by calling its
- :meth:`__init__` method again.
+ This function corresponds to the :meth:`~object.__init__` method of classes. Like
+ :meth:`!__init__`, it is possible to create an instance without calling
+ :meth:`!__init__`, and it is possible to reinitialize an instance by calling its
+ :meth:`!__init__` method again.
The function signature is::
@@ -1768,7 +1779,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
The self argument is the instance to be initialized; the *args* and *kwds*
arguments represent positional and keyword arguments of the call to
- :meth:`__init__`.
+ :meth:`~object.__init__`.
The :c:member:`~PyTypeObject.tp_init` function, if not ``NULL``, is called when an instance is
created normally by calling its type, after the type's :c:member:`~PyTypeObject.tp_new` function
@@ -1807,7 +1818,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
:c:func:`PyType_GenericAlloc`, to force a standard heap
allocation strategy.
- For static subtypes, :c:type:`PyBaseObject_Type` uses
+ For static subtypes, :c:data:`PyBaseObject_Type` uses
:c:func:`PyType_GenericAlloc`. That is the recommended value
for all statically defined types.
@@ -1834,7 +1845,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
in :c:member:`~PyTypeObject.tp_new`, while for mutable types, most initialization should be
deferred to :c:member:`~PyTypeObject.tp_init`.
- Set the :const:`Py_TPFLAGS_DISALLOW_INSTANTIATION` flag to disallow creating
+ Set the :c:macro:`Py_TPFLAGS_DISALLOW_INSTANTIATION` flag to disallow creating
instances of the type in Python.
**Inheritance:**
@@ -1868,9 +1879,9 @@ and :c:type:`PyType_Type` effectively act as defaults.)
In dynamic subtypes, this field is set to a deallocator suitable to
match :c:func:`PyType_GenericAlloc` and the value of the
- :const:`Py_TPFLAGS_HAVE_GC` flag bit.
+ :c:macro:`Py_TPFLAGS_HAVE_GC` flag bit.
- For static subtypes, :c:type:`PyBaseObject_Type` uses PyObject_Del.
+ For static subtypes, :c:data:`PyBaseObject_Type` uses :c:func:`PyObject_Del`.
.. c:member:: inquiry PyTypeObject.tp_is_gc
@@ -1879,7 +1890,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
The garbage collector needs to know whether a particular object is collectible
or not. Normally, it is sufficient to look at the object's type's
- :c:member:`~PyTypeObject.tp_flags` field, and check the :const:`Py_TPFLAGS_HAVE_GC` flag bit. But
+ :c:member:`~PyTypeObject.tp_flags` field, and check the :c:macro:`Py_TPFLAGS_HAVE_GC` flag bit. But
some types have a mixture of statically and dynamically allocated instances, and
the statically allocated instances are not collectible. Such types should
define this function; it should return ``1`` for a collectible instance, and
@@ -1898,15 +1909,26 @@ and :c:type:`PyType_Type` effectively act as defaults.)
**Default:**
This slot has no default. If this field is ``NULL``,
- :const:`Py_TPFLAGS_HAVE_GC` is used as the functional equivalent.
+ :c:macro:`Py_TPFLAGS_HAVE_GC` is used as the functional equivalent.
.. c:member:: PyObject* PyTypeObject.tp_bases
Tuple of base types.
- This is set for types created by a class statement. It should be ``NULL`` for
- statically defined types.
+ This field should be set to ``NULL`` and treated as read-only.
+ Python will fill it in when the type is :c:func:`initialized `.
+
+ For dynamically created classes, the ``Py_tp_bases``
+ :c:type:`slot ` can be used instead of the *bases* argument
+ of :c:func:`PyType_FromSpecWithBases`.
+ The argument form is preferred.
+
+ .. warning::
+
+ Multiple inheritance does not work well for statically defined types.
+ If you set ``tp_bases`` to a tuple, Python will not raise an error,
+ but some slots will only be inherited from the first base.
**Inheritance:**
@@ -1918,6 +1940,8 @@ and :c:type:`PyType_Type` effectively act as defaults.)
Tuple containing the expanded set of base types, starting with the type itself
and ending with :class:`object`, in Method Resolution Order.
+ This field should be set to ``NULL`` and treated as read-only.
+ Python will fill it in when the type is :c:func:`initialized `.
**Inheritance:**
@@ -1997,9 +2021,6 @@ and :c:type:`PyType_Type` effectively act as defaults.)
PyErr_Restore(error_type, error_value, error_traceback);
}
- For this field to be taken into account (even through inheritance),
- you must also set the :const:`Py_TPFLAGS_HAVE_FINALIZE` flags bit.
-
Also, note that, in a garbage collected Python,
:c:member:`~PyTypeObject.tp_dealloc` may be called from
any Python thread, not just the thread which created the object (if the object
@@ -2017,6 +2038,12 @@ and :c:type:`PyType_Type` effectively act as defaults.)
.. versionadded:: 3.4
+ .. versionchanged:: 3.8
+
+ Before version 3.8 it was necessary to set the
+ :c:macro:`Py_TPFLAGS_HAVE_FINALIZE` flags bit in order for this field to be
+ used. This is no longer required.
+
.. seealso:: "Safe object finalization" (:pep:`442`)
@@ -2026,7 +2053,7 @@ and :c:type:`PyType_Type` effectively act as defaults.)
In other words, it is used to implement
:ref:`vectorcall ` for ``type.__call__``.
If ``tp_vectorcall`` is ``NULL``, the default call implementation
- using :attr:`__new__` and :attr:`__init__` is used.
+ using :meth:`~object.__new__` and :meth:`~object.__init__` is used.
**Inheritance:**
@@ -2054,9 +2081,9 @@ This results in types that are limited relative to types defined in Python:
:ref:`sub-interpreters `, so they should not
include any subinterpreter-specific state.
-Also, since :c:type:`PyTypeObject` is not part of the :ref:`stable ABI `,
-any extension modules using static types must be compiled for a specific
-Python minor version.
+Also, since :c:type:`PyTypeObject` is only part of the :ref:`Limited API
+` as an opaque struct, any extension modules using static types must be
+compiled for a specific Python minor version.
.. _heap-types:
@@ -2066,7 +2093,7 @@ Heap Types
An alternative to :ref:`static types ` is *heap-allocated types*,
or *heap types* for short, which correspond closely to classes created by
-Python's ``class`` statement. Heap types have the :const:`Py_TPFLAGS_HEAPTYPE`
+Python's ``class`` statement. Heap types have the :c:macro:`Py_TPFLAGS_HEAPTYPE`
flag set.
This is done by filling a :c:type:`PyType_Spec` structure and calling
@@ -2146,8 +2173,8 @@ Number Object Structures
.. note::
- The :c:data:`nb_reserved` field should always be ``NULL``. It
- was previously called :c:data:`nb_long`, and was renamed in
+ The :c:member:`~PyNumberMethods.nb_reserved` field should always be ``NULL``. It
+ was previously called :c:member:`!nb_long`, and was renamed in
Python 3.0.1.
.. c:member:: binaryfunc PyNumberMethods.nb_add
@@ -2218,8 +2245,8 @@ Mapping Object Structures
.. c:member:: objobjargproc PyMappingMethods.mp_ass_subscript
This function is used by :c:func:`PyObject_SetItem`,
- :c:func:`PyObject_DelItem`, :c:func:`PyObject_SetSlice` and
- :c:func:`PyObject_DelSlice`. It has the same signature as
+ :c:func:`PyObject_DelItem`, :c:func:`PySequence_SetSlice` and
+ :c:func:`PySequence_DelSlice`. It has the same signature as
:c:func:`!PyObject_SetItem`, but *v* can also be set to ``NULL`` to delete
an item. If this slot is ``NULL``, the object does not support item
assignment and deletion.
@@ -2265,9 +2292,9 @@ Sequence Object Structures
This slot must be filled for the :c:func:`PySequence_Check`
function to return ``1``, it can be ``NULL`` otherwise.
- Negative indexes are handled as follows: if the :attr:`sq_length` slot is
+ Negative indexes are handled as follows: if the :c:member:`~PySequenceMethods.sq_length` slot is
filled, it is called and the sequence length is used to compute a positive
- index which is passed to :attr:`sq_item`. If :attr:`sq_length` is ``NULL``,
+ index which is passed to :c:member:`~PySequenceMethods.sq_item`. If :c:member:`!sq_length` is ``NULL``,
the index is passed as is to the function.
.. c:member:: ssizeobjargproc PySequenceMethods.sq_ass_item
@@ -2330,14 +2357,14 @@ Buffer Object Structures
Except for point (3), an implementation of this function MUST take these
steps:
- (1) Check if the request can be met. If not, raise :c:data:`PyExc_BufferError`,
- set :c:data:`view->obj` to ``NULL`` and return ``-1``.
+ (1) Check if the request can be met. If not, raise :exc:`BufferError`,
+ set :c:expr:`view->obj` to ``NULL`` and return ``-1``.
(2) Fill in the requested fields.
(3) Increment an internal counter for the number of exports.
- (4) Set :c:data:`view->obj` to *exporter* and increment :c:data:`view->obj`.
+ (4) Set :c:expr:`view->obj` to *exporter* and increment :c:expr:`view->obj`.
(5) Return ``0``.
@@ -2345,10 +2372,10 @@ Buffer Object Structures
schemes can be used:
* Re-export: Each member of the tree acts as the exporting object and
- sets :c:data:`view->obj` to a new reference to itself.
+ sets :c:expr:`view->obj` to a new reference to itself.
* Redirect: The buffer request is redirected to the root object of the
- tree. Here, :c:data:`view->obj` will be a new reference to the root
+ tree. Here, :c:expr:`view->obj` will be a new reference to the root
object.
The individual fields of *view* are described in section
@@ -2390,7 +2417,7 @@ Buffer Object Structures
*view* argument.
- This function MUST NOT decrement :c:data:`view->obj`, since that is
+ This function MUST NOT decrement :c:expr:`view->obj`, since that is
done automatically in :c:func:`PyBuffer_Release` (this scheme is
useful for breaking reference cycles).
@@ -2441,7 +2468,7 @@ Async Object Structures
PyObject *am_aiter(PyObject *self);
Must return an :term:`asynchronous iterator` object.
- See :meth:`__anext__` for details.
+ See :meth:`~object.__anext__` for details.
This slot may be set to ``NULL`` if an object does not implement
asynchronous iteration protocol.
@@ -2452,7 +2479,8 @@ Async Object Structures
PyObject *am_anext(PyObject *self);
- Must return an :term:`awaitable` object. See :meth:`__anext__` for details.
+ Must return an :term:`awaitable` object.
+ See :meth:`~object.__anext__` for details.
This slot may be set to ``NULL``.
.. c:member:: sendfunc PyAsyncMethods.am_send
@@ -2477,8 +2505,8 @@ Slot Type typedefs
The purpose of this function is to separate memory allocation from memory
initialization. It should return a pointer to a block of memory of adequate
length for the instance, suitably aligned, and initialized to zeros, but with
- :attr:`ob_refcnt` set to ``1`` and :attr:`ob_type` set to the type argument. If
- the type's :c:member:`~PyTypeObject.tp_itemsize` is non-zero, the object's :attr:`ob_size` field
+ :c:member:`~PyObject.ob_refcnt` set to ``1`` and :c:member:`~PyObject.ob_type` set to the type argument. If
+ the type's :c:member:`~PyTypeObject.tp_itemsize` is non-zero, the object's :c:member:`~PyVarObject.ob_size` field
should be initialized to *nitems* and the length of the allocated memory block
should be ``tp_basicsize + nitems*tp_itemsize``, rounded up to a multiple of
``sizeof(void*)``; otherwise, *nitems* is not used and the length of the block
@@ -2529,11 +2557,11 @@ Slot Type typedefs
.. c:type:: PyObject *(*descrgetfunc)(PyObject *, PyObject *, PyObject *)
- See :c:member:`~PyTypeObject.tp_descrget`.
+ See :c:member:`~PyTypeObject.tp_descr_get`.
.. c:type:: int (*descrsetfunc)(PyObject *, PyObject *, PyObject *)
- See :c:member:`~PyTypeObject.tp_descrset`.
+ See :c:member:`~PyTypeObject.tp_descr_set`.
.. c:type:: Py_hash_t (*hashfunc)(PyObject *)
@@ -2569,7 +2597,7 @@ Slot Type typedefs
.. c:type:: PyObject *(*ssizeargfunc)(PyObject *, Py_ssize_t)
-.. c:type:: int (*ssizeobjargproc)(PyObject *, Py_ssize_t)
+.. c:type:: int (*ssizeobjargproc)(PyObject *, Py_ssize_t, PyObject *)
.. c:type:: int (*objobjproc)(PyObject *, PyObject *)
@@ -2676,7 +2704,7 @@ A type that supports weakrefs, instance dicts, and hashing::
A str subclass that cannot be subclassed and cannot be called
to create instances (e.g. uses a separate factory func) using
-:c:data:`Py_TPFLAGS_DISALLOW_INSTANTIATION` flag::
+:c:macro:`Py_TPFLAGS_DISALLOW_INSTANTIATION` flag::
typedef struct {
PyUnicodeObject raw;
diff --git a/Doc/c-api/unicode.rst b/Doc/c-api/unicode.rst
index d139112578ca99..ffa2d131235f25 100644
--- a/Doc/c-api/unicode.rst
+++ b/Doc/c-api/unicode.rst
@@ -17,8 +17,8 @@ of Unicode characters while staying memory efficient. There are special cases
for strings where all code points are below 128, 256, or 65536; otherwise, code
points must be below 1114112 (which is the full Unicode range).
-:c:type:`Py_UNICODE*` and UTF-8 representations are created on demand and cached
-in the Unicode object. The :c:type:`Py_UNICODE*` representation is deprecated
+:c:expr:`Py_UNICODE*` and UTF-8 representations are created on demand and cached
+in the Unicode object. The :c:expr:`Py_UNICODE*` representation is deprecated
and inefficient.
Due to the transition between the old APIs and the new APIs, Unicode objects
@@ -30,7 +30,7 @@ can internally be in two states depending on how they were created:
* "legacy" Unicode objects have been created through one of the deprecated
APIs (typically :c:func:`PyUnicode_FromUnicode`) and only bear the
- :c:type:`Py_UNICODE*` representation; you will have to call
+ :c:expr:`Py_UNICODE*` representation; you will have to call
:c:func:`PyUnicode_READY` on them before calling any other API.
.. note::
@@ -87,19 +87,19 @@ Python:
The following APIs are C macros and static inlined functions for fast checks and
access to internal read-only data of Unicode objects:
-.. c:function:: int PyUnicode_Check(PyObject *o)
+.. c:function:: int PyUnicode_Check(PyObject *obj)
- Return true if the object *o* is a Unicode object or an instance of a Unicode
+ Return true if the object *obj* is a Unicode object or an instance of a Unicode
subtype. This function always succeeds.
-.. c:function:: int PyUnicode_CheckExact(PyObject *o)
+.. c:function:: int PyUnicode_CheckExact(PyObject *obj)
- Return true if the object *o* is a Unicode object, but not an instance of a
+ Return true if the object *obj* is a Unicode object, but not an instance of a
subtype. This function always succeeds.
-.. c:function:: int PyUnicode_READY(PyObject *o)
+.. c:function:: int PyUnicode_READY(PyObject *unicode)
Ensure the string object *o* is in the "canonical" representation. This is
required before using any of the access macros described below.
@@ -115,17 +115,17 @@ access to internal read-only data of Unicode objects:
This API will be removed with :c:func:`PyUnicode_FromUnicode`.
-.. c:function:: Py_ssize_t PyUnicode_GET_LENGTH(PyObject *o)
+.. c:function:: Py_ssize_t PyUnicode_GET_LENGTH(PyObject *unicode)
- Return the length of the Unicode string, in code points. *o* has to be a
+ Return the length of the Unicode string, in code points. *unicode* has to be a
Unicode object in the "canonical" representation (not checked).
.. versionadded:: 3.3
-.. c:function:: Py_UCS1* PyUnicode_1BYTE_DATA(PyObject *o)
- Py_UCS2* PyUnicode_2BYTE_DATA(PyObject *o)
- Py_UCS4* PyUnicode_4BYTE_DATA(PyObject *o)
+.. c:function:: Py_UCS1* PyUnicode_1BYTE_DATA(PyObject *unicode)
+ Py_UCS2* PyUnicode_2BYTE_DATA(PyObject *unicode)
+ Py_UCS4* PyUnicode_4BYTE_DATA(PyObject *unicode)
Return a pointer to the canonical representation cast to UCS1, UCS2 or UCS4
integer types for direct character access. No checks are performed if the
@@ -149,10 +149,10 @@ access to internal read-only data of Unicode objects:
``PyUnicode_WCHAR_KIND`` is deprecated.
-.. c:function:: unsigned int PyUnicode_KIND(PyObject *o)
+.. c:function:: int PyUnicode_KIND(PyObject *unicode)
Return one of the PyUnicode kind constants (see above) that indicate how many
- bytes per character this Unicode object uses to store its data. *o* has to
+ bytes per character this Unicode object uses to store its data. *unicode* has to
be a Unicode object in the "canonical" representation (not checked).
.. XXX document "0" return value?
@@ -160,15 +160,15 @@ access to internal read-only data of Unicode objects:
.. versionadded:: 3.3
-.. c:function:: void* PyUnicode_DATA(PyObject *o)
+.. c:function:: void* PyUnicode_DATA(PyObject *unicode)
- Return a void pointer to the raw Unicode buffer. *o* has to be a Unicode
+ Return a void pointer to the raw Unicode buffer. *unicode* has to be a Unicode
object in the "canonical" representation (not checked).
.. versionadded:: 3.3
-.. c:function:: void PyUnicode_WRITE(unsigned int kind, void *data, \
+.. c:function:: void PyUnicode_WRITE(int kind, void *data, \
Py_ssize_t index, Py_UCS4 value)
Write into a canonical representation *data* (as obtained with
@@ -181,7 +181,7 @@ access to internal read-only data of Unicode objects:
.. versionadded:: 3.3
-.. c:function:: Py_UCS4 PyUnicode_READ(unsigned int kind, void *data, \
+.. c:function:: Py_UCS4 PyUnicode_READ(int kind, void *data, \
Py_ssize_t index)
Read a code point from a canonical representation *data* (as obtained with
@@ -190,28 +190,28 @@ access to internal read-only data of Unicode objects:
.. versionadded:: 3.3
-.. c:function:: Py_UCS4 PyUnicode_READ_CHAR(PyObject *o, Py_ssize_t index)
+.. c:function:: Py_UCS4 PyUnicode_READ_CHAR(PyObject *unicode, Py_ssize_t index)
- Read a character from a Unicode object *o*, which must be in the "canonical"
+ Read a character from a Unicode object *unicode*, which must be in the "canonical"
representation. This is less efficient than :c:func:`PyUnicode_READ` if you
do multiple consecutive reads.
.. versionadded:: 3.3
-.. c:function:: Py_UCS4 PyUnicode_MAX_CHAR_VALUE(PyObject *o)
+.. c:function:: Py_UCS4 PyUnicode_MAX_CHAR_VALUE(PyObject *unicode)
Return the maximum code point that is suitable for creating another string
- based on *o*, which must be in the "canonical" representation. This is
+ based on *unicode*, which must be in the "canonical" representation. This is
always an approximation but more efficient than iterating over the string.
.. versionadded:: 3.3
-.. c:function:: Py_ssize_t PyUnicode_GET_SIZE(PyObject *o)
+.. c:function:: Py_ssize_t PyUnicode_GET_SIZE(PyObject *unicode)
Return the size of the deprecated :c:type:`Py_UNICODE` representation, in
- code units (this includes surrogate pairs as 2 units). *o* has to be a
+ code units (this includes surrogate pairs as 2 units). *unicode* has to be a
Unicode object (not checked).
.. deprecated-removed:: 3.3 3.12
@@ -219,24 +219,24 @@ access to internal read-only data of Unicode objects:
:c:func:`PyUnicode_GET_LENGTH`.
-.. c:function:: Py_ssize_t PyUnicode_GET_DATA_SIZE(PyObject *o)
+.. c:function:: Py_ssize_t PyUnicode_GET_DATA_SIZE(PyObject *unicode)
Return the size of the deprecated :c:type:`Py_UNICODE` representation in
- bytes. *o* has to be a Unicode object (not checked).
+ bytes. *unicode* has to be a Unicode object (not checked).
.. deprecated-removed:: 3.3 3.12
Part of the old-style Unicode API, please migrate to using
:c:func:`PyUnicode_GET_LENGTH`.
-.. c:function:: Py_UNICODE* PyUnicode_AS_UNICODE(PyObject *o)
- const char* PyUnicode_AS_DATA(PyObject *o)
+.. c:function:: Py_UNICODE* PyUnicode_AS_UNICODE(PyObject *unicode)
+ const char* PyUnicode_AS_DATA(PyObject *unicode)
Return a pointer to a :c:type:`Py_UNICODE` representation of the object. The
returned buffer is always terminated with an extra null code point. It
may also contain embedded null code points, which would cause the string
to be truncated when used in most C functions. The ``AS_DATA`` form
- casts the pointer to :c:type:`const char *`. The *o* argument has to be
+ casts the pointer to :c:expr:`const char *`. The *unicode* argument has to be
a Unicode object (not checked).
.. versionchanged:: 3.3
@@ -251,7 +251,7 @@ access to internal read-only data of Unicode objects:
:c:func:`PyUnicode_nBYTE_DATA` family of macros.
-.. c:function:: int PyUnicode_IsIdentifier(PyObject *o)
+.. c:function:: int PyUnicode_IsIdentifier(PyObject *unicode)
Return ``1`` if the string is a valid identifier according to the language
definition, section :ref:`identifiers`. Return ``0`` otherwise.
@@ -431,22 +431,22 @@ APIs:
.. versionadded:: 3.3
-.. c:function:: PyObject* PyUnicode_FromStringAndSize(const char *u, Py_ssize_t size)
+.. c:function:: PyObject* PyUnicode_FromStringAndSize(const char *str, Py_ssize_t size)
- Create a Unicode object from the char buffer *u*. The bytes will be
+ Create a Unicode object from the char buffer *str*. The bytes will be
interpreted as being UTF-8 encoded. The buffer is copied into the new
object. If the buffer is not ``NULL``, the return value might be a shared
object, i.e. modification of the data is not allowed.
- If *u* is ``NULL``, this function behaves like :c:func:`PyUnicode_FromUnicode`
+ If *str* is ``NULL``, this function behaves like :c:func:`PyUnicode_FromUnicode`
with the buffer set to ``NULL``. This usage is deprecated in favor of
:c:func:`PyUnicode_New`, and will be removed in Python 3.12.
-.. c:function:: PyObject *PyUnicode_FromString(const char *u)
+.. c:function:: PyObject *PyUnicode_FromString(const char *str)
Create a Unicode object from a UTF-8 encoded null-terminated char buffer
- *u*.
+ *str*.
.. c:function:: PyObject* PyUnicode_FromFormat(const char *format, ...)
@@ -497,11 +497,11 @@ APIs:
| :attr:`%llu` | unsigned long long | Equivalent to |
| | | ``printf("%llu")``. [1]_ |
+-------------------+---------------------+----------------------------------+
- | :attr:`%zd` | Py_ssize_t | Equivalent to |
- | | | ``printf("%zd")``. [1]_ |
+ | :attr:`%zd` | :c:type:`\ | Equivalent to |
+ | | Py_ssize_t` | ``printf("%zd")``. [1]_ |
+-------------------+---------------------+----------------------------------+
- | :attr:`%zi` | Py_ssize_t | Equivalent to |
- | | | ``printf("%zi")``. [1]_ |
+ | :attr:`%zi` | :c:type:`\ | Equivalent to |
+ | | Py_ssize_t` | ``printf("%zi")``. [1]_ |
+-------------------+---------------------+----------------------------------+
| :attr:`%zu` | size_t | Equivalent to |
| | | ``printf("%zu")``. [1]_ |
@@ -572,6 +572,15 @@ APIs:
arguments.
+.. c:function:: PyObject* PyUnicode_FromObject(PyObject *obj)
+
+ Copy an instance of a Unicode subtype to a new true Unicode object if
+ necessary. If *obj* is already a true Unicode object (not a subtype),
+ return a new :term:`strong reference` to the object.
+
+ Objects other than Unicode or its subtypes will cause a :exc:`TypeError`.
+
+
.. c:function:: PyObject* PyUnicode_FromEncodedObject(PyObject *obj, \
const char *encoding, const char *errors)
@@ -604,7 +613,7 @@ APIs:
Py_ssize_t how_many)
Copy characters from one Unicode object into another. This function performs
- character conversion when necessary and falls back to :c:func:`memcpy` if
+ character conversion when necessary and falls back to :c:func:`!memcpy` if
possible. Returns ``-1`` and sets an exception on error, otherwise returns
the number of copied characters.
@@ -649,29 +658,29 @@ APIs:
.. versionadded:: 3.3
-.. c:function:: PyObject* PyUnicode_Substring(PyObject *str, Py_ssize_t start, \
+.. c:function:: PyObject* PyUnicode_Substring(PyObject *unicode, Py_ssize_t start, \
Py_ssize_t end)
- Return a substring of *str*, from character index *start* (included) to
+ Return a substring of *unicode*, from character index *start* (included) to
character index *end* (excluded). Negative indices are not supported.
.. versionadded:: 3.3
-.. c:function:: Py_UCS4* PyUnicode_AsUCS4(PyObject *u, Py_UCS4 *buffer, \
+.. c:function:: Py_UCS4* PyUnicode_AsUCS4(PyObject *unicode, Py_UCS4 *buffer, \
Py_ssize_t buflen, int copy_null)
- Copy the string *u* into a UCS4 buffer, including a null character, if
+ Copy the string *unicode* into a UCS4 buffer, including a null character, if
*copy_null* is set. Returns ``NULL`` and sets an exception on error (in
particular, a :exc:`SystemError` if *buflen* is smaller than the length of
- *u*). *buffer* is returned on success.
+ *unicode*). *buffer* is returned on success.
.. versionadded:: 3.3
-.. c:function:: Py_UCS4* PyUnicode_AsUCS4Copy(PyObject *u)
+.. c:function:: Py_UCS4* PyUnicode_AsUCS4Copy(PyObject *unicode)
- Copy the string *u* into a new UCS4 buffer that is allocated using
+ Copy the string *unicode* into a new UCS4 buffer that is allocated using
:c:func:`PyMem_Malloc`. If this fails, ``NULL`` is returned with a
:exc:`MemoryError` set. The returned buffer always has an extra
null code point appended.
@@ -714,7 +723,7 @@ Extension modules can continue using them, as they will not be removed in Python
Return a read-only pointer to the Unicode object's internal
:c:type:`Py_UNICODE` buffer, or ``NULL`` on error. This will create the
- :c:type:`Py_UNICODE*` representation of the object if it is not yet
+ :c:expr:`Py_UNICODE*` representation of the object if it is not yet
available. The buffer is always terminated with an extra null code point.
Note that the resulting :c:type:`Py_UNICODE` string may also contain
embedded null code points, which would cause the string to be truncated when
@@ -730,7 +739,7 @@ Extension modules can continue using them, as they will not be removed in Python
Like :c:func:`PyUnicode_AsUnicode`, but also saves the :c:func:`Py_UNICODE`
array length (excluding the extra null terminator) in *size*.
- Note that the resulting :c:type:`Py_UNICODE*` string
+ Note that the resulting :c:expr:`Py_UNICODE*` string
may contain embedded null code points, which would cause the string to be
truncated when used in most C functions.
@@ -752,15 +761,6 @@ Extension modules can continue using them, as they will not be removed in Python
:c:func:`PyUnicode_GET_LENGTH`.
-.. c:function:: PyObject* PyUnicode_FromObject(PyObject *obj)
-
- Copy an instance of a Unicode subtype to a new true Unicode object if
- necessary. If *obj* is already a true Unicode object (not a subtype),
- return the reference with incremented refcount.
-
- Objects other than Unicode or its subtypes will cause a :exc:`TypeError`.
-
-
Locale Encoding
"""""""""""""""
@@ -768,7 +768,7 @@ The current locale encoding can be used to decode text from the operating
system.
.. c:function:: PyObject* PyUnicode_DecodeLocaleAndSize(const char *str, \
- Py_ssize_t len, \
+ Py_ssize_t length, \
const char *errors)
Decode a string from UTF-8 on Android and VxWorks, or from the current
@@ -800,7 +800,7 @@ system.
.. c:function:: PyObject* PyUnicode_DecodeLocale(const char *str, const char *errors)
Similar to :c:func:`PyUnicode_DecodeLocaleAndSize`, but compute the string
- length using :c:func:`strlen`.
+ length using :c:func:`!strlen`.
.. versionadded:: 3.3
@@ -849,7 +849,7 @@ argument parsing, the ``"O&"`` converter should be used, passing
ParseTuple converter: encode :class:`str` objects -- obtained directly or
through the :class:`os.PathLike` interface -- to :class:`bytes` using
:c:func:`PyUnicode_EncodeFSDefault`; :class:`bytes` objects are output as-is.
- *result* must be a :c:type:`PyBytesObject*` which must be released when it is
+ *result* must be a :c:expr:`PyBytesObject*` which must be released when it is
no longer used.
.. versionadded:: 3.1
@@ -866,7 +866,7 @@ conversion function:
ParseTuple converter: decode :class:`bytes` objects -- obtained either
directly or indirectly through the :class:`os.PathLike` interface -- to
:class:`str` using :c:func:`PyUnicode_DecodeFSDefaultAndSize`; :class:`str`
- objects are output as-is. *result* must be a :c:type:`PyUnicodeObject*` which
+ objects are output as-is. *result* must be a :c:expr:`PyUnicodeObject*` which
must be released when it is no longer used.
.. versionadded:: 3.2
@@ -875,7 +875,7 @@ conversion function:
Accepts a :term:`path-like object`.
-.. c:function:: PyObject* PyUnicode_DecodeFSDefaultAndSize(const char *s, Py_ssize_t size)
+.. c:function:: PyObject* PyUnicode_DecodeFSDefaultAndSize(const char *str, Py_ssize_t size)
Decode a string from the :term:`filesystem encoding and error handler`.
@@ -895,7 +895,7 @@ conversion function:
Use :c:data:`Py_FileSystemDefaultEncodeErrors` error handler.
-.. c:function:: PyObject* PyUnicode_DecodeFSDefault(const char *s)
+.. c:function:: PyObject* PyUnicode_DecodeFSDefault(const char *str)
Decode a null-terminated string from the :term:`filesystem encoding and
error handler`.
@@ -937,23 +937,23 @@ wchar_t Support
:c:type:`wchar_t` support for platforms which support it:
-.. c:function:: PyObject* PyUnicode_FromWideChar(const wchar_t *w, Py_ssize_t size)
+.. c:function:: PyObject* PyUnicode_FromWideChar(const wchar_t *wstr, Py_ssize_t size)
- Create a Unicode object from the :c:type:`wchar_t` buffer *w* of the given *size*.
+ Create a Unicode object from the :c:type:`wchar_t` buffer *wstr* of the given *size*.
Passing ``-1`` as the *size* indicates that the function must itself compute the length,
- using wcslen.
+ using :c:func:`!wcslen`.
Return ``NULL`` on failure.
-.. c:function:: Py_ssize_t PyUnicode_AsWideChar(PyObject *unicode, wchar_t *w, Py_ssize_t size)
+.. c:function:: Py_ssize_t PyUnicode_AsWideChar(PyObject *unicode, wchar_t *wstr, Py_ssize_t size)
- Copy the Unicode object contents into the :c:type:`wchar_t` buffer *w*. At most
+ Copy the Unicode object contents into the :c:type:`wchar_t` buffer *wstr*. At most
*size* :c:type:`wchar_t` characters are copied (excluding a possibly trailing
null termination character). Return the number of :c:type:`wchar_t` characters
- copied or ``-1`` in case of an error. Note that the resulting :c:type:`wchar_t*`
+ copied or ``-1`` in case of an error. Note that the resulting :c:expr:`wchar_t*`
string may or may not be null-terminated. It is the responsibility of the caller
- to make sure that the :c:type:`wchar_t*` string is null-terminated in case this is
- required by the application. Also, note that the :c:type:`wchar_t*` string
+ to make sure that the :c:expr:`wchar_t*` string is null-terminated in case this is
+ required by the application. Also, note that the :c:expr:`wchar_t*` string
might contain null characters, which would cause the string to be truncated
when used with most C functions.
@@ -965,10 +965,10 @@ wchar_t Support
of wide characters (excluding the trailing null termination character) into
*\*size*. Note that the resulting :c:type:`wchar_t` string might contain
null characters, which would cause the string to be truncated when used with
- most C functions. If *size* is ``NULL`` and the :c:type:`wchar_t*` string
+ most C functions. If *size* is ``NULL`` and the :c:expr:`wchar_t*` string
contains null characters a :exc:`ValueError` is raised.
- Returns a buffer allocated by :c:func:`PyMem_Alloc` (use
+ Returns a buffer allocated by :c:macro:`PyMem_New` (use
:c:func:`PyMem_Free` to free it) on success. On error, returns ``NULL``
and *\*size* is undefined. Raises a :exc:`MemoryError` if memory allocation
is failed.
@@ -976,7 +976,7 @@ wchar_t Support
.. versionadded:: 3.2
.. versionchanged:: 3.7
- Raises a :exc:`ValueError` if *size* is ``NULL`` and the :c:type:`wchar_t*`
+ Raises a :exc:`ValueError` if *size* is ``NULL`` and the :c:expr:`wchar_t*`
string contains null characters.
@@ -1014,10 +1014,10 @@ Generic Codecs
These are the generic codec APIs:
-.. c:function:: PyObject* PyUnicode_Decode(const char *s, Py_ssize_t size, \
+.. c:function:: PyObject* PyUnicode_Decode(const char *str, Py_ssize_t size, \
const char *encoding, const char *errors)
- Create a Unicode object by decoding *size* bytes of the encoded string *s*.
+ Create a Unicode object by decoding *size* bytes of the encoded string *str*.
*encoding* and *errors* have the same meaning as the parameters of the same name
in the :func:`str` built-in function. The codec to be used is looked up
using the Python codec registry. Return ``NULL`` if an exception was raised by
@@ -1040,13 +1040,13 @@ UTF-8 Codecs
These are the UTF-8 codec APIs:
-.. c:function:: PyObject* PyUnicode_DecodeUTF8(const char *s, Py_ssize_t size, const char *errors)
+.. c:function:: PyObject* PyUnicode_DecodeUTF8(const char *str, Py_ssize_t size, const char *errors)
Create a Unicode object by decoding *size* bytes of the UTF-8 encoded string
- *s*. Return ``NULL`` if an exception was raised by the codec.
+ *str*. Return ``NULL`` if an exception was raised by the codec.
-.. c:function:: PyObject* PyUnicode_DecodeUTF8Stateful(const char *s, Py_ssize_t size, \
+.. c:function:: PyObject* PyUnicode_DecodeUTF8Stateful(const char *str, Py_ssize_t size, \
const char *errors, Py_ssize_t *consumed)
If *consumed* is ``NULL``, behave like :c:func:`PyUnicode_DecodeUTF8`. If
@@ -1084,7 +1084,7 @@ These are the UTF-8 codec APIs:
The return type is now ``const char *`` rather of ``char *``.
.. versionchanged:: 3.10
- This function is a part of the :ref:`limited API `.
+ This function is a part of the :ref:`limited API `.
.. c:function:: const char* PyUnicode_AsUTF8(PyObject *unicode)
@@ -1103,7 +1103,7 @@ UTF-32 Codecs
These are the UTF-32 codec APIs:
-.. c:function:: PyObject* PyUnicode_DecodeUTF32(const char *s, Py_ssize_t size, \
+.. c:function:: PyObject* PyUnicode_DecodeUTF32(const char *str, Py_ssize_t size, \
const char *errors, int *byteorder)
Decode *size* bytes from a UTF-32 encoded buffer string and return the
@@ -1130,7 +1130,7 @@ These are the UTF-32 codec APIs:
Return ``NULL`` if an exception was raised by the codec.
-.. c:function:: PyObject* PyUnicode_DecodeUTF32Stateful(const char *s, Py_ssize_t size, \
+.. c:function:: PyObject* PyUnicode_DecodeUTF32Stateful(const char *str, Py_ssize_t size, \
const char *errors, int *byteorder, Py_ssize_t *consumed)
If *consumed* is ``NULL``, behave like :c:func:`PyUnicode_DecodeUTF32`. If
@@ -1153,7 +1153,7 @@ UTF-16 Codecs
These are the UTF-16 codec APIs:
-.. c:function:: PyObject* PyUnicode_DecodeUTF16(const char *s, Py_ssize_t size, \
+.. c:function:: PyObject* PyUnicode_DecodeUTF16(const char *str, Py_ssize_t size, \
const char *errors, int *byteorder)
Decode *size* bytes from a UTF-16 encoded buffer string and return the
@@ -1181,7 +1181,7 @@ These are the UTF-16 codec APIs:
Return ``NULL`` if an exception was raised by the codec.
-.. c:function:: PyObject* PyUnicode_DecodeUTF16Stateful(const char *s, Py_ssize_t size, \
+.. c:function:: PyObject* PyUnicode_DecodeUTF16Stateful(const char *str, Py_ssize_t size, \
const char *errors, int *byteorder, Py_ssize_t *consumed)
If *consumed* is ``NULL``, behave like :c:func:`PyUnicode_DecodeUTF16`. If
@@ -1204,13 +1204,13 @@ UTF-7 Codecs
These are the UTF-7 codec APIs:
-.. c:function:: PyObject* PyUnicode_DecodeUTF7(const char *s, Py_ssize_t size, const char *errors)
+.. c:function:: PyObject* PyUnicode_DecodeUTF7(const char *str, Py_ssize_t size, const char *errors)
Create a Unicode object by decoding *size* bytes of the UTF-7 encoded string
- *s*. Return ``NULL`` if an exception was raised by the codec.
+ *str*. Return ``NULL`` if an exception was raised by the codec.
-.. c:function:: PyObject* PyUnicode_DecodeUTF7Stateful(const char *s, Py_ssize_t size, \
+.. c:function:: PyObject* PyUnicode_DecodeUTF7Stateful(const char *str, Py_ssize_t size, \
const char *errors, Py_ssize_t *consumed)
If *consumed* is ``NULL``, behave like :c:func:`PyUnicode_DecodeUTF7`. If
@@ -1225,11 +1225,11 @@ Unicode-Escape Codecs
These are the "Unicode Escape" codec APIs:
-.. c:function:: PyObject* PyUnicode_DecodeUnicodeEscape(const char *s, \
+.. c:function:: PyObject* PyUnicode_DecodeUnicodeEscape(const char *str, \
Py_ssize_t size, const char *errors)
Create a Unicode object by decoding *size* bytes of the Unicode-Escape encoded
- string *s*. Return ``NULL`` if an exception was raised by the codec.
+ string *str*. Return ``NULL`` if an exception was raised by the codec.
.. c:function:: PyObject* PyUnicode_AsUnicodeEscapeString(PyObject *unicode)
@@ -1245,11 +1245,11 @@ Raw-Unicode-Escape Codecs
These are the "Raw Unicode Escape" codec APIs:
-.. c:function:: PyObject* PyUnicode_DecodeRawUnicodeEscape(const char *s, \
+.. c:function:: PyObject* PyUnicode_DecodeRawUnicodeEscape(const char *str, \
Py_ssize_t size, const char *errors)
Create a Unicode object by decoding *size* bytes of the Raw-Unicode-Escape
- encoded string *s*. Return ``NULL`` if an exception was raised by the codec.
+ encoded string *str*. Return ``NULL`` if an exception was raised by the codec.
.. c:function:: PyObject* PyUnicode_AsRawUnicodeEscapeString(PyObject *unicode)
@@ -1266,10 +1266,10 @@ These are the Latin-1 codec APIs: Latin-1 corresponds to the first 256 Unicode
ordinals and only these are accepted by the codecs during encoding.
-.. c:function:: PyObject* PyUnicode_DecodeLatin1(const char *s, Py_ssize_t size, const char *errors)
+.. c:function:: PyObject* PyUnicode_DecodeLatin1(const char *str, Py_ssize_t size, const char *errors)
Create a Unicode object by decoding *size* bytes of the Latin-1 encoded string
- *s*. Return ``NULL`` if an exception was raised by the codec.
+ *str*. Return ``NULL`` if an exception was raised by the codec.
.. c:function:: PyObject* PyUnicode_AsLatin1String(PyObject *unicode)
@@ -1286,10 +1286,10 @@ These are the ASCII codec APIs. Only 7-bit ASCII data is accepted. All other
codes generate errors.
-.. c:function:: PyObject* PyUnicode_DecodeASCII(const char *s, Py_ssize_t size, const char *errors)
+.. c:function:: PyObject* PyUnicode_DecodeASCII(const char *str, Py_ssize_t size, const char *errors)
Create a Unicode object by decoding *size* bytes of the ASCII encoded string
- *s*. Return ``NULL`` if an exception was raised by the codec.
+ *str*. Return ``NULL`` if an exception was raised by the codec.
.. c:function:: PyObject* PyUnicode_AsASCIIString(PyObject *unicode)
@@ -1304,16 +1304,16 @@ Character Map Codecs
This codec is special in that it can be used to implement many different codecs
(and this is in fact what was done to obtain most of the standard codecs
-included in the :mod:`encodings` package). The codec uses mappings to encode and
+included in the :mod:`!encodings` package). The codec uses mappings to encode and
decode characters. The mapping objects provided must support the
-:meth:`__getitem__` mapping interface; dictionaries and sequences work well.
+:meth:`~object.__getitem__` mapping interface; dictionaries and sequences work well.
These are the mapping codec APIs:
-.. c:function:: PyObject* PyUnicode_DecodeCharmap(const char *data, Py_ssize_t size, \
+.. c:function:: PyObject* PyUnicode_DecodeCharmap(const char *str, Py_ssize_t length, \
PyObject *mapping, const char *errors)
- Create a Unicode object by decoding *size* bytes of the encoded string *s*
+ Create a Unicode object by decoding *size* bytes of the encoded string *str*
using the given *mapping* object. Return ``NULL`` if an exception was raised
by the codec.
@@ -1340,7 +1340,7 @@ These are the mapping codec APIs:
The following codec API is special in that maps Unicode to Unicode.
-.. c:function:: PyObject* PyUnicode_Translate(PyObject *str, PyObject *table, const char *errors)
+.. c:function:: PyObject* PyUnicode_Translate(PyObject *unicode, PyObject *table, const char *errors)
Translate a string by applying a character mapping table to it and return the
resulting Unicode object. Return ``NULL`` if an exception was raised by the
@@ -1349,7 +1349,7 @@ The following codec API is special in that maps Unicode to Unicode.
The mapping table must map Unicode ordinal integers to Unicode ordinal integers
or ``None`` (causing deletion of the character).
- Mapping tables need only provide the :meth:`__getitem__` interface; dictionaries
+ Mapping tables need only provide the :meth:`~object.__getitem__` interface; dictionaries
and sequences work well. Unmapped character ordinals (ones which cause a
:exc:`LookupError`) are left untouched and are copied as-is.
@@ -1365,13 +1365,13 @@ use the Win32 MBCS converters to implement the conversions. Note that MBCS (or
DBCS) is a class of encodings, not just one. The target encoding is defined by
the user settings on the machine running the codec.
-.. c:function:: PyObject* PyUnicode_DecodeMBCS(const char *s, Py_ssize_t size, const char *errors)
+.. c:function:: PyObject* PyUnicode_DecodeMBCS(const char *str, Py_ssize_t size, const char *errors)
- Create a Unicode object by decoding *size* bytes of the MBCS encoded string *s*.
+ Create a Unicode object by decoding *size* bytes of the MBCS encoded string *str*.
Return ``NULL`` if an exception was raised by the codec.
-.. c:function:: PyObject* PyUnicode_DecodeMBCSStateful(const char *s, Py_ssize_t size, \
+.. c:function:: PyObject* PyUnicode_DecodeMBCSStateful(const char *str, Py_ssize_t size, \
const char *errors, Py_ssize_t *consumed)
If *consumed* is ``NULL``, behave like :c:func:`PyUnicode_DecodeMBCS`. If
@@ -1391,7 +1391,7 @@ the user settings on the machine running the codec.
Encode the Unicode object using the specified code page and return a Python
bytes object. Return ``NULL`` if an exception was raised by the codec. Use
- :c:data:`CP_ACP` code page to get the MBCS encoder.
+ :c:macro:`!CP_ACP` code page to get the MBCS encoder.
.. versionadded:: 3.3
@@ -1417,7 +1417,7 @@ They all return ``NULL`` or ``-1`` if an exception occurs.
Concat two strings giving a new Unicode string.
-.. c:function:: PyObject* PyUnicode_Split(PyObject *s, PyObject *sep, Py_ssize_t maxsplit)
+.. c:function:: PyObject* PyUnicode_Split(PyObject *unicode, PyObject *sep, Py_ssize_t maxsplit)
Split a string giving a list of Unicode strings. If *sep* is ``NULL``, splitting
will be done at all whitespace substrings. Otherwise, splits occur at the given
@@ -1425,10 +1425,10 @@ They all return ``NULL`` or ``-1`` if an exception occurs.
set. Separators are not included in the resulting list.
-.. c:function:: PyObject* PyUnicode_Splitlines(PyObject *s, int keepend)
+.. c:function:: PyObject* PyUnicode_Splitlines(PyObject *unicode, int keepends)
Split a Unicode string at line breaks, returning a list of Unicode strings.
- CRLF is considered to be one line break. If *keepend* is ``0``, the line break
+ CRLF is considered to be one line break. If *keepends* is ``0``, the Line break
characters are not included in the resulting strings.
@@ -1438,28 +1438,28 @@ They all return ``NULL`` or ``-1`` if an exception occurs.
Unicode string.
-.. c:function:: Py_ssize_t PyUnicode_Tailmatch(PyObject *str, PyObject *substr, \
+.. c:function:: Py_ssize_t PyUnicode_Tailmatch(PyObject *unicode, PyObject *substr, \
Py_ssize_t start, Py_ssize_t end, int direction)
- Return ``1`` if *substr* matches ``str[start:end]`` at the given tail end
+ Return ``1`` if *substr* matches ``unicode[start:end]`` at the given tail end
(*direction* == ``-1`` means to do a prefix match, *direction* == ``1`` a suffix match),
``0`` otherwise. Return ``-1`` if an error occurred.
-.. c:function:: Py_ssize_t PyUnicode_Find(PyObject *str, PyObject *substr, \
+.. c:function:: Py_ssize_t PyUnicode_Find(PyObject *unicode, PyObject *substr, \
Py_ssize_t start, Py_ssize_t end, int direction)
- Return the first position of *substr* in ``str[start:end]`` using the given
+ Return the first position of *substr* in ``unicode[start:end]`` using the given
*direction* (*direction* == ``1`` means to do a forward search, *direction* == ``-1`` a
backward search). The return value is the index of the first match; a value of
``-1`` indicates that no match was found, and ``-2`` indicates that an error
occurred and an exception has been set.
-.. c:function:: Py_ssize_t PyUnicode_FindChar(PyObject *str, Py_UCS4 ch, \
+.. c:function:: Py_ssize_t PyUnicode_FindChar(PyObject *unicode, Py_UCS4 ch, \
Py_ssize_t start, Py_ssize_t end, int direction)
- Return the first position of the character *ch* in ``str[start:end]`` using
+ Return the first position of the character *ch* in ``unicode[start:end]`` using
the given *direction* (*direction* == ``1`` means to do a forward search,
*direction* == ``-1`` a backward search). The return value is the index of the
first match; a value of ``-1`` indicates that no match was found, and ``-2``
@@ -1468,20 +1468,20 @@ They all return ``NULL`` or ``-1`` if an exception occurs.
.. versionadded:: 3.3
.. versionchanged:: 3.7
- *start* and *end* are now adjusted to behave like ``str[start:end]``.
+ *start* and *end* are now adjusted to behave like ``unicode[start:end]``.
-.. c:function:: Py_ssize_t PyUnicode_Count(PyObject *str, PyObject *substr, \
+.. c:function:: Py_ssize_t PyUnicode_Count(PyObject *unicode, PyObject *substr, \
Py_ssize_t start, Py_ssize_t end)
Return the number of non-overlapping occurrences of *substr* in
- ``str[start:end]``. Return ``-1`` if an error occurred.
+ ``unicode[start:end]``. Return ``-1`` if an error occurred.
-.. c:function:: PyObject* PyUnicode_Replace(PyObject *str, PyObject *substr, \
+.. c:function:: PyObject* PyUnicode_Replace(PyObject *unicode, PyObject *substr, \
PyObject *replstr, Py_ssize_t maxcount)
- Replace at most *maxcount* occurrences of *substr* in *str* with *replstr* and
+ Replace at most *maxcount* occurrences of *substr* in *unicode* with *replstr* and
return the resulting Unicode object. *maxcount* == ``-1`` means replace all
occurrences.
@@ -1495,9 +1495,9 @@ They all return ``NULL`` or ``-1`` if an exception occurs.
:c:func:`PyErr_Occurred` to check for errors.
-.. c:function:: int PyUnicode_CompareWithASCIIString(PyObject *uni, const char *string)
+.. c:function:: int PyUnicode_CompareWithASCIIString(PyObject *unicode, const char *string)
- Compare a Unicode object, *uni*, with *string* and return ``-1``, ``0``, ``1`` for less
+ Compare a Unicode object, *unicode*, with *string* and return ``-1``, ``0``, ``1`` for less
than, equal, and greater than, respectively. It is best to pass only
ASCII-encoded strings, but the function interprets the input string as
ISO-8859-1 if it contains non-ASCII characters.
@@ -1505,16 +1505,16 @@ They all return ``NULL`` or ``-1`` if an exception occurs.
This function does not raise exceptions.
-.. c:function:: PyObject* PyUnicode_RichCompare(PyObject *left, PyObject *right, int op)
+.. c:function:: PyObject* PyUnicode_RichCompare(PyObject *left, PyObject *right, int op)
Rich compare two Unicode strings and return one of the following:
* ``NULL`` in case an exception was raised
- * :const:`Py_True` or :const:`Py_False` for successful comparisons
- * :const:`Py_NotImplemented` in case the type combination is unknown
+ * :c:data:`Py_True` or :c:data:`Py_False` for successful comparisons
+ * :c:data:`Py_NotImplemented` in case the type combination is unknown
- Possible values for *op* are :const:`Py_GT`, :const:`Py_GE`, :const:`Py_EQ`,
- :const:`Py_NE`, :const:`Py_LT`, and :const:`Py_LE`.
+ Possible values for *op* are :c:macro:`Py_GT`, :c:macro:`Py_GE`, :c:macro:`Py_EQ`,
+ :c:macro:`Py_NE`, :c:macro:`Py_LT`, and :c:macro:`Py_LE`.
.. c:function:: PyObject* PyUnicode_Format(PyObject *format, PyObject *args)
@@ -1523,29 +1523,29 @@ They all return ``NULL`` or ``-1`` if an exception occurs.
``format % args``.
-.. c:function:: int PyUnicode_Contains(PyObject *container, PyObject *element)
+.. c:function:: int PyUnicode_Contains(PyObject *unicode, PyObject *substr)
- Check whether *element* is contained in *container* and return true or false
+ Check whether *substr* is contained in *unicode* and return true or false
accordingly.
- *element* has to coerce to a one element Unicode string. ``-1`` is returned
+ *substr* has to coerce to a one element Unicode string. ``-1`` is returned
if there was an error.
-.. c:function:: void PyUnicode_InternInPlace(PyObject **string)
+.. c:function:: void PyUnicode_InternInPlace(PyObject **p_unicode)
- Intern the argument *\*string* in place. The argument must be the address of a
+ Intern the argument :c:expr:`*p_unicode` in place. The argument must be the address of a
pointer variable pointing to a Python Unicode string object. If there is an
- existing interned string that is the same as *\*string*, it sets *\*string* to
- it (decrementing the reference count of the old string object and incrementing
- the reference count of the interned string object), otherwise it leaves
- *\*string* alone and interns it (incrementing its reference count).
- (Clarification: even though there is a lot of talk about reference counts, think
- of this function as reference-count-neutral; you own the object after the call
+ existing interned string that is the same as :c:expr:`*p_unicode`, it sets :c:expr:`*p_unicode` to
+ it (releasing the reference to the old string object and creating a new
+ :term:`strong reference` to the interned string object), otherwise it leaves
+ :c:expr:`*p_unicode` alone and interns it (creating a new :term:`strong reference`).
+ (Clarification: even though there is a lot of talk about references, think
+ of this function as reference-neutral; you own the object after the call
if and only if you owned it before the call.)
-.. c:function:: PyObject* PyUnicode_InternFromString(const char *v)
+.. c:function:: PyObject* PyUnicode_InternFromString(const char *str)
A combination of :c:func:`PyUnicode_FromString` and
:c:func:`PyUnicode_InternInPlace`, returning either a new Unicode string
diff --git a/Doc/c-api/veryhigh.rst b/Doc/c-api/veryhigh.rst
index 7bd47bb9c660a6..d4cf12a0d4ac6c 100644
--- a/Doc/c-api/veryhigh.rst
+++ b/Doc/c-api/veryhigh.rst
@@ -12,15 +12,15 @@ file or a buffer, but they will not let you interact in a more detailed way with
the interpreter.
Several of these functions accept a start symbol from the grammar as a
-parameter. The available start symbols are :const:`Py_eval_input`,
-:const:`Py_file_input`, and :const:`Py_single_input`. These are described
+parameter. The available start symbols are :c:data:`Py_eval_input`,
+:c:data:`Py_file_input`, and :c:data:`Py_single_input`. These are described
following the functions which accept them as parameters.
-Note also that several of these functions take :c:type:`FILE*` parameters. One
+Note also that several of these functions take :c:expr:`FILE*` parameters. One
particular issue which needs to be handled carefully is that the :c:type:`FILE`
structure for different C libraries can be different and incompatible. Under
Windows (at least), it is possible for dynamically linked extensions to actually
-use different libraries, so care should be taken that :c:type:`FILE*` parameters
+use different libraries, so care should be taken that :c:expr:`FILE*` parameters
are only passed to these functions if it is certain that they were created by
the same library that the Python runtime is using.
@@ -82,7 +82,7 @@ the same library that the Python runtime is using.
.. c:function:: int PyRun_SimpleString(const char *command)
This is a simplified interface to :c:func:`PyRun_SimpleStringFlags` below,
- leaving the :c:type:`PyCompilerFlags`\* argument set to ``NULL``.
+ leaving the :c:struct:`PyCompilerFlags`\* argument set to ``NULL``.
.. c:function:: int PyRun_SimpleStringFlags(const char *command, PyCompilerFlags *flags)
@@ -248,8 +248,8 @@ the same library that the Python runtime is using.
Parse and compile the Python source code in *str*, returning the resulting code
object. The start token is given by *start*; this can be used to constrain the
- code which can be compiled and should be :const:`Py_eval_input`,
- :const:`Py_file_input`, or :const:`Py_single_input`. The filename specified by
+ code which can be compiled and should be :c:data:`Py_eval_input`,
+ :c:data:`Py_file_input`, or :c:data:`Py_single_input`. The filename specified by
*filename* is used to construct the code object and may appear in tracebacks or
:exc:`SyntaxError` exception messages. This returns ``NULL`` if the code
cannot be parsed or compiled.
@@ -314,7 +314,7 @@ the same library that the Python runtime is using.
.. c:var:: int Py_eval_input
- .. index:: single: Py_CompileString()
+ .. index:: single: Py_CompileString (C function)
The start symbol from the Python grammar for isolated expressions; for use with
:c:func:`Py_CompileString`.
@@ -322,7 +322,7 @@ the same library that the Python runtime is using.
.. c:var:: int Py_file_input
- .. index:: single: Py_CompileString()
+ .. index:: single: Py_CompileString (C function)
The start symbol from the Python grammar for sequences of statements as read
from a file or other source; for use with :c:func:`Py_CompileString`. This is
@@ -331,21 +331,21 @@ the same library that the Python runtime is using.
.. c:var:: int Py_single_input
- .. index:: single: Py_CompileString()
+ .. index:: single: Py_CompileString (C function)
The start symbol from the Python grammar for a single statement; for use with
:c:func:`Py_CompileString`. This is the symbol used for the interactive
interpreter loop.
-.. c:type:: struct PyCompilerFlags
+.. c:struct:: PyCompilerFlags
This is the structure used to hold compiler flags. In cases where code is only
being compiled, it is passed as ``int flags``, and in cases where code is being
executed, it is passed as ``PyCompilerFlags *flags``. In this case, ``from
__future__ import`` can modify *flags*.
- Whenever ``PyCompilerFlags *flags`` is ``NULL``, :attr:`cf_flags` is treated as
+ Whenever ``PyCompilerFlags *flags`` is ``NULL``, :c:member:`~PyCompilerFlags.cf_flags` is treated as
equal to ``0``, and any modification due to ``from __future__ import`` is
discarded.
@@ -359,7 +359,7 @@ the same library that the Python runtime is using.
initialized to ``PY_MINOR_VERSION``.
The field is ignored by default, it is used if and only if
- ``PyCF_ONLY_AST`` flag is set in *cf_flags*.
+ ``PyCF_ONLY_AST`` flag is set in :c:member:`~PyCompilerFlags.cf_flags`.
.. versionchanged:: 3.8
Added *cf_feature_version* field.
diff --git a/Doc/c-api/weakref.rst b/Doc/c-api/weakref.rst
index 7b32e17a239729..f46507608606b9 100644
--- a/Doc/c-api/weakref.rst
+++ b/Doc/c-api/weakref.rst
@@ -11,18 +11,18 @@ simple reference object, and the second acts as a proxy for the original object
as much as it can.
-.. c:function:: int PyWeakref_Check(ob)
+.. c:function:: int PyWeakref_Check(PyObject *ob)
Return true if *ob* is either a reference or proxy object. This function
always succeeds.
-.. c:function:: int PyWeakref_CheckRef(ob)
+.. c:function:: int PyWeakref_CheckRef(PyObject *ob)
Return true if *ob* is a reference object. This function always succeeds.
-.. c:function:: int PyWeakref_CheckProxy(ob)
+.. c:function:: int PyWeakref_CheckProxy(PyObject *ob)
Return true if *ob* is a proxy object. This function always succeeds.
@@ -35,7 +35,7 @@ as much as it can.
callable object that receives notification when *ob* is garbage collected; it
should accept a single parameter, which will be the weak reference object
itself. *callback* may also be ``None`` or ``NULL``. If *ob* is not a
- weakly-referencable object, or if *callback* is not callable, ``None``, or
+ weakly referencable object, or if *callback* is not callable, ``None``, or
``NULL``, this will return ``NULL`` and raise :exc:`TypeError`.
@@ -47,14 +47,14 @@ as much as it can.
be a callable object that receives notification when *ob* is garbage
collected; it should accept a single parameter, which will be the weak
reference object itself. *callback* may also be ``None`` or ``NULL``. If *ob*
- is not a weakly-referencable object, or if *callback* is not callable,
+ is not a weakly referencable object, or if *callback* is not callable,
``None``, or ``NULL``, this will return ``NULL`` and raise :exc:`TypeError`.
.. c:function:: PyObject* PyWeakref_GetObject(PyObject *ref)
Return the referenced object from a weak reference, *ref*. If the referent is
- no longer live, returns :const:`Py_None`.
+ no longer live, returns ``Py_None``.
.. note::
@@ -67,3 +67,13 @@ as much as it can.
.. c:function:: PyObject* PyWeakref_GET_OBJECT(PyObject *ref)
Similar to :c:func:`PyWeakref_GetObject`, but does no error checking.
+
+
+.. c:function:: void PyObject_ClearWeakRefs(PyObject *object)
+
+ This function is called by the :c:member:`~PyTypeObject.tp_dealloc` handler
+ to clear weak references.
+
+ This iterates through the weak references for *object* and calls callbacks
+ for those references which have one. It returns when all callbacks have
+ been attempted.
diff --git a/Doc/conf.py b/Doc/conf.py
index e539da539e6551..1af8b94918f78b 100644
--- a/Doc/conf.py
+++ b/Doc/conf.py
@@ -6,16 +6,34 @@
# The contents of this file are pickled, so don't put values in the namespace
# that aren't pickleable (module imports are okay, they're removed automatically).
-import sys, os, time
+import os
+import sys
+import time
sys.path.append(os.path.abspath('tools/extensions'))
sys.path.append(os.path.abspath('includes'))
# General configuration
# ---------------------
-extensions = ['sphinx.ext.coverage', 'sphinx.ext.doctest',
- 'pyspecific', 'c_annotations', 'escape4chm',
- 'asdl_highlight', 'peg_highlight', 'glossary_search']
+extensions = [
+ 'asdl_highlight',
+ 'c_annotations',
+ 'escape4chm',
+ 'glossary_search',
+ 'peg_highlight',
+ 'pyspecific',
+ 'sphinx.ext.coverage',
+ 'sphinx.ext.doctest',
+]
+
+# Skip if downstream redistributors haven't installed it
+try:
+ import sphinxext.opengraph
+except ImportError:
+ pass
+else:
+ extensions.append('sphinxext.opengraph')
+
doctest_global_setup = '''
try:
@@ -28,7 +46,7 @@
# General substitutions.
project = 'Python'
-copyright = '2001-%s, Python Software Foundation' % time.strftime('%Y')
+copyright = f"2001-{time.strftime('%Y')}, Python Software Foundation"
# We look for the Include/patchlevel.h file in the current Python source tree
# and replace the values accordingly.
@@ -45,14 +63,202 @@
highlight_language = 'python3'
# Minimum version of sphinx required
-needs_sphinx = '1.8'
+needs_sphinx = '4.2'
+
+# Create table of contents entries for domain objects (e.g. functions, classes,
+# attributes, etc.). Default is True.
+toc_object_entries = False
+# Ignore any .rst files in the includes/ directory;
+# they're embedded in pages but not rendered individually.
# Ignore any .rst files in the venv/ directory.
-exclude_patterns = ['venv/*', 'README.rst']
+exclude_patterns = ['includes/*.rst', 'venv/*', 'README.rst']
venvdir = os.getenv('VENVDIR')
if venvdir is not None:
exclude_patterns.append(venvdir + '/*')
+nitpick_ignore = [
+ # Standard C functions
+ ('c:func', 'calloc'),
+ ('c:func', 'ctime'),
+ ('c:func', 'dlopen'),
+ ('c:func', 'exec'),
+ ('c:func', 'fcntl'),
+ ('c:func', 'fork'),
+ ('c:func', 'free'),
+ ('c:func', 'gettimeofday'),
+ ('c:func', 'gmtime'),
+ ('c:func', 'localeconv'),
+ ('c:func', 'localtime'),
+ ('c:func', 'main'),
+ ('c:func', 'malloc'),
+ ('c:func', 'mktime'),
+ ('c:func', 'printf'),
+ ('c:func', 'realloc'),
+ ('c:func', 'snprintf'),
+ ('c:func', 'sprintf'),
+ ('c:func', 'stat'),
+ ('c:func', 'strftime'),
+ ('c:func', 'system'),
+ ('c:func', 'vsnprintf'),
+ # Standard C types
+ ('c:type', 'FILE'),
+ ('c:type', 'int64_t'),
+ ('c:type', 'intmax_t'),
+ ('c:type', 'off_t'),
+ ('c:type', 'ptrdiff_t'),
+ ('c:type', 'siginfo_t'),
+ ('c:type', 'size_t'),
+ ('c:type', 'ssize_t'),
+ ('c:type', 'time_t'),
+ ('c:type', 'uint64_t'),
+ ('c:type', 'uintmax_t'),
+ ('c:type', 'uintptr_t'),
+ ('c:type', 'va_list'),
+ ('c:type', 'wchar_t'),
+ # Standard C structures
+ ('c:struct', 'in6_addr'),
+ ('c:struct', 'in_addr'),
+ ('c:struct', 'stat'),
+ ('c:struct', 'statvfs'),
+ # Standard C macros
+ ('c:macro', 'LLONG_MAX'),
+ ('c:macro', 'LLONG_MIN'),
+ ('c:macro', 'LONG_MAX'),
+ ('c:macro', 'LONG_MIN'),
+ # Standard C variables
+ ('c:data', 'errno'),
+ # Standard environment variables
+ ('envvar', 'BROWSER'),
+ ('envvar', 'COLUMNS'),
+ ('envvar', 'COMSPEC'),
+ ('envvar', 'DISPLAY'),
+ ('envvar', 'HOME'),
+ ('envvar', 'HOMEDRIVE'),
+ ('envvar', 'HOMEPATH'),
+ ('envvar', 'IDLESTARTUP'),
+ ('envvar', 'LANG'),
+ ('envvar', 'LANGUAGE'),
+ ('envvar', 'LC_ALL'),
+ ('envvar', 'LC_CTYPE'),
+ ('envvar', 'LC_COLLATE'),
+ ('envvar', 'LC_MESSAGES'),
+ ('envvar', 'LC_MONETARY'),
+ ('envvar', 'LC_NUMERIC'),
+ ('envvar', 'LC_TIME'),
+ ('envvar', 'LINES'),
+ ('envvar', 'LOGNAME'),
+ ('envvar', 'PAGER'),
+ ('envvar', 'PATH'),
+ ('envvar', 'PATHEXT'),
+ ('envvar', 'SOURCE_DATE_EPOCH'),
+ ('envvar', 'TEMP'),
+ ('envvar', 'TERM'),
+ ('envvar', 'TMP'),
+ ('envvar', 'TMPDIR'),
+ ('envvar', 'TZ'),
+ ('envvar', 'USER'),
+ ('envvar', 'USERNAME'),
+ ('envvar', 'USERPROFILE'),
+ # Deprecated function that was never documented:
+ ('py:func', 'getargspec'),
+ ('py:func', 'inspect.getargspec'),
+ # Undocumented modules that users shouldn't have to worry about
+ # (implementation details of `os.path`):
+ ('py:mod', 'ntpath'),
+ ('py:mod', 'posixpath'),
+]
+
+# Temporary undocumented names.
+# In future this list must be empty.
+nitpick_ignore += [
+ # C API: Standard Python exception classes
+ ('c:data', 'PyExc_ArithmeticError'),
+ ('c:data', 'PyExc_AssertionError'),
+ ('c:data', 'PyExc_AttributeError'),
+ ('c:data', 'PyExc_BaseException'),
+ ('c:data', 'PyExc_BlockingIOError'),
+ ('c:data', 'PyExc_BrokenPipeError'),
+ ('c:data', 'PyExc_BufferError'),
+ ('c:data', 'PyExc_ChildProcessError'),
+ ('c:data', 'PyExc_ConnectionAbortedError'),
+ ('c:data', 'PyExc_ConnectionError'),
+ ('c:data', 'PyExc_ConnectionRefusedError'),
+ ('c:data', 'PyExc_ConnectionResetError'),
+ ('c:data', 'PyExc_EOFError'),
+ ('c:data', 'PyExc_Exception'),
+ ('c:data', 'PyExc_FileExistsError'),
+ ('c:data', 'PyExc_FileNotFoundError'),
+ ('c:data', 'PyExc_FloatingPointError'),
+ ('c:data', 'PyExc_GeneratorExit'),
+ ('c:data', 'PyExc_ImportError'),
+ ('c:data', 'PyExc_IndentationError'),
+ ('c:data', 'PyExc_IndexError'),
+ ('c:data', 'PyExc_InterruptedError'),
+ ('c:data', 'PyExc_IsADirectoryError'),
+ ('c:data', 'PyExc_KeyboardInterrupt'),
+ ('c:data', 'PyExc_KeyError'),
+ ('c:data', 'PyExc_LookupError'),
+ ('c:data', 'PyExc_MemoryError'),
+ ('c:data', 'PyExc_ModuleNotFoundError'),
+ ('c:data', 'PyExc_NameError'),
+ ('c:data', 'PyExc_NotADirectoryError'),
+ ('c:data', 'PyExc_NotImplementedError'),
+ ('c:data', 'PyExc_OSError'),
+ ('c:data', 'PyExc_OverflowError'),
+ ('c:data', 'PyExc_PermissionError'),
+ ('c:data', 'PyExc_ProcessLookupError'),
+ ('c:data', 'PyExc_RecursionError'),
+ ('c:data', 'PyExc_ReferenceError'),
+ ('c:data', 'PyExc_RuntimeError'),
+ ('c:data', 'PyExc_StopAsyncIteration'),
+ ('c:data', 'PyExc_StopIteration'),
+ ('c:data', 'PyExc_SyntaxError'),
+ ('c:data', 'PyExc_SystemError'),
+ ('c:data', 'PyExc_SystemExit'),
+ ('c:data', 'PyExc_TabError'),
+ ('c:data', 'PyExc_TimeoutError'),
+ ('c:data', 'PyExc_TypeError'),
+ ('c:data', 'PyExc_UnboundLocalError'),
+ ('c:data', 'PyExc_UnicodeDecodeError'),
+ ('c:data', 'PyExc_UnicodeEncodeError'),
+ ('c:data', 'PyExc_UnicodeError'),
+ ('c:data', 'PyExc_UnicodeTranslateError'),
+ ('c:data', 'PyExc_ValueError'),
+ ('c:data', 'PyExc_ZeroDivisionError'),
+ # C API: Standard Python warning classes
+ ('c:data', 'PyExc_BytesWarning'),
+ ('c:data', 'PyExc_DeprecationWarning'),
+ ('c:data', 'PyExc_FutureWarning'),
+ ('c:data', 'PyExc_ImportWarning'),
+ ('c:data', 'PyExc_PendingDeprecationWarning'),
+ ('c:data', 'PyExc_ResourceWarning'),
+ ('c:data', 'PyExc_RuntimeWarning'),
+ ('c:data', 'PyExc_SyntaxWarning'),
+ ('c:data', 'PyExc_UnicodeWarning'),
+ ('c:data', 'PyExc_UserWarning'),
+ ('c:data', 'PyExc_Warning'),
+ # Do not error nit-picky mode builds when _SubParsersAction.add_parser cannot
+ # be resolved, as the method is currently undocumented. For context, see
+ # https://github.com/python/cpython/pull/103289.
+ ('py:meth', '_SubParsersAction.add_parser'),
+ # Attributes/methods/etc. that definitely should be documented better,
+ # but are deferred for now:
+ ('py:attr', '__annotations__'),
+ ('py:meth', '__missing__'),
+ ('py:attr', '__wrapped__'),
+ ('py:meth', 'index'), # list.index, tuple.index, etc.
+]
+
+# gh-106948: Copy standard C types declared in the "c:type" domain to the
+# "c:identifier" domain, since "c:function" markup looks for types in the
+# "c:identifier" domain. Use list() to not iterate on items which are being
+# added
+for role, name in list(nitpick_ignore):
+ if role == 'c:type':
+ nitpick_ignore.append(('c:identifier', name))
+del role, name
+
# Disable Docutils smartquotes for several translations
smartquotes_excludes = {
'languages': ['ja', 'fr', 'zh_TW', 'zh_CN'], 'builders': ['man', 'text'],
@@ -61,6 +267,11 @@
# Avoid a warning with Sphinx >= 2.0
master_doc = 'contents'
+# Allow translation of index directives
+gettext_additional_targets = [
+ 'index',
+]
+
# Options for HTML output
# -----------------------
@@ -74,12 +285,30 @@
'root_include_title': False # We use the version switcher instead.
}
+if os.getenv("READTHEDOCS"):
+ html_theme_options["hosted_on"] = 'Read the Docs'
+
+# Override stylesheet fingerprinting for Windows CHM htmlhelp to fix GH-91207
+# https://github.com/python/cpython/issues/91207
+if any('htmlhelp' in arg for arg in sys.argv):
+ html_style = 'pydoctheme.css'
+ print("\nWARNING: Windows CHM Help is no longer supported.")
+ print("It may be removed in the future\n")
+
# Short title used e.g. for HTML tags.
-html_short_title = '%s Documentation' % release
+html_short_title = f'{release} Documentation'
+
+# Deployment preview information
+# (See .readthedocs.yml and https://docs.readthedocs.io/en/stable/reference/environment-variables.html)
+repository_url = os.getenv("READTHEDOCS_GIT_CLONE_URL")
+html_context = {
+ "is_deployment_preview": os.getenv("READTHEDOCS_VERSION_TYPE") == "external",
+ "repository_url": repository_url.removesuffix(".git") if repository_url else None,
+ "pr_id": os.getenv("READTHEDOCS_VERSION")
+}
-# 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'
+# This 'Last updated on:' timestamp is inserted at the bottom of every page.
+html_last_updated_fmt = time.strftime('%b %d, %Y (%H:%M UTC)', time.gmtime())
# Path to find HTML templates.
templates_path = ['tools/templates']
@@ -102,7 +331,7 @@
html_use_opensearch = 'https://docs.python.org/' + version
# Additional static files.
-html_static_path = ['tools/static']
+html_static_path = ['_static', 'tools/static']
# Output file base name for HTML help builder.
htmlhelp_basename = 'python' + release.replace('.', '')
@@ -116,12 +345,9 @@
latex_engine = 'xelatex'
-# Get LaTeX to handle Unicode correctly
latex_elements = {
-}
-
-# Additional stuff for the LaTeX preamble.
-latex_elements['preamble'] = r'''
+ # For the LaTeX preamble.
+ 'preamble': r'''
\authoraddress{
\sphinxstrong{Python Software Foundation}\\
Email: \sphinxemail{docs@python.org}
@@ -129,13 +355,12 @@
\let\Verbatim=\OriginalVerbatim
\let\endVerbatim=\endOriginalVerbatim
\setcounter{tocdepth}{2}
-'''
-
-# The paper size ('letter' or 'a4').
-latex_elements['papersize'] = 'a4'
-
-# The font size ('10pt', '11pt' or '12pt').
-latex_elements['pointsize'] = '10pt'
+''',
+ # The paper size ('letter' or 'a4').
+ 'papersize': 'a4',
+ # The font size ('10pt', '11pt' or '12pt').
+ 'pointsize': '10pt',
+}
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title, author, document class [howto/manual]).
@@ -143,8 +368,6 @@
latex_documents = [
('c-api/index', 'c-api.tex',
'The Python/C API', _stdauthor, 'manual'),
- ('distributing/index', 'distributing.tex',
- 'Distributing Python Modules', _stdauthor, 'manual'),
('extending/index', 'extending.tex',
'Extending and Embedding Python', _stdauthor, 'manual'),
('installing/index', 'installing.tex',
@@ -202,9 +425,9 @@
# Regexes to find C items in the source files.
coverage_c_regexes = {
- 'cfunction': (r'^PyAPI_FUNC\(.*\)\s+([^_][\w_]+)'),
- 'data': (r'^PyAPI_DATA\(.*\)\s+([^_][\w_]+)'),
- 'macro': (r'^#define ([^_][\w_]+)\(.*\)[\s|\\]'),
+ 'cfunction': r'^PyAPI_FUNC\(.*\)\s+([^_][\w_]+)',
+ 'data': r'^PyAPI_DATA\(.*\)\s+([^_][\w_]+)',
+ 'macro': r'^#define ([^_][\w_]+)\(.*\)[\s|\\]',
}
# The coverage checker will ignore all C items whose names match these regexes
@@ -217,8 +440,49 @@
# Options for the link checker
# ----------------------------
-# Ignore certain URLs.
-linkcheck_ignore = [r'https://bugs.python.org/(issue)?\d+']
+linkcheck_allowed_redirects = {
+ # bpo-NNNN -> BPO -> GH Issues
+ r'https://bugs.python.org/issue\?@action=redirect&bpo=\d+': r'https://github.com/python/cpython/issues/\d+',
+ # GH-NNNN used to refer to pull requests
+ r'https://github.com/python/cpython/issues/\d+': r'https://github.com/python/cpython/pull/\d+',
+ # :source:`something` linking files in the repository
+ r'https://github.com/python/cpython/tree/.*': 'https://github.com/python/cpython/blob/.*',
+ # Intentional HTTP use at Misc/NEWS.d/3.5.0a1.rst
+ r'http://www.python.org/$': 'https://www.python.org/$',
+ # Used in license page, keep as is
+ r'https://www.zope.org/': r'https://www.zope.dev/',
+ # Microsoft's redirects to learn.microsoft.com
+ r'https://msdn.microsoft.com/.*': 'https://learn.microsoft.com/.*',
+ r'https://docs.microsoft.com/.*': 'https://learn.microsoft.com/.*',
+ r'https://go.microsoft.com/fwlink/\?LinkID=\d+': 'https://learn.microsoft.com/.*',
+ # Language redirects
+ r'https://toml.io': 'https://toml.io/en/',
+ r'https://www.redhat.com': 'https://www.redhat.com/en',
+ # Other redirects
+ r'https://www.boost.org/libs/.+': r'https://www.boost.org/doc/libs/\d_\d+_\d/.+',
+ r'https://support.microsoft.com/en-us/help/\d+': 'https://support.microsoft.com/en-us/topic/.+',
+ r'https://perf.wiki.kernel.org$': 'https://perf.wiki.kernel.org/index.php/Main_Page',
+ r'https://www.sqlite.org': 'https://www.sqlite.org/index.html',
+ r'https://mitpress.mit.edu/sicp$': 'https://mitpress.mit.edu/9780262510875/structure-and-interpretation-of-computer-programs/',
+ r'https://www.python.org/psf/': 'https://www.python.org/psf-landing/',
+}
+
+linkcheck_anchors_ignore = [
+ # ignore anchors that start with a '/', e.g. Wikipedia media files:
+ # https://en.wikipedia.org/wiki/Walrus#/media/File:Pacific_Walrus_-_Bull_(8247646168).jpg
+ r'\/.*',
+]
+
+linkcheck_ignore = [
+ # The crawler gets "Anchor not found"
+ r'https://developer.apple.com/documentation/.+?#.*',
+ r'https://devguide.python.org.+?/#.*',
+ r'https://github.com.+?#.*',
+ # Robot crawlers not allowed: "403 Client Error: Forbidden"
+ r'https://support.enthought.com/hc/.*',
+ # SSLError CertificateError, even though it is valid
+ r'https://unix.org/version2/whatsnew/lp64_wp.html',
+]
# Options for extensions
@@ -228,14 +492,12 @@
refcount_file = 'data/refcounts.dat'
stable_abi_file = 'data/stable_abi.dat'
-# Sphinx 2 and Sphinx 3 compatibility
-# -----------------------------------
-
-# bpo-40204: Allow Sphinx 2 syntax in the C domain
-c_allow_pre_v3 = True
-
-# bpo-40204: Disable warnings on Sphinx 2 syntax of the C domain since the
-# documentation is built with -W (warnings treated as errors).
-c_warn_on_allowed_pre_v3 = False
-
-strip_signature_backslash = True
+# sphinxext-opengraph config
+ogp_site_url = 'https://docs.python.org/3/'
+ogp_site_name = 'Python documentation'
+ogp_image = '_static/og-image.png'
+ogp_custom_meta_tags = [
+ '',
+ '',
+ '',
+]
diff --git a/Doc/constraints.txt b/Doc/constraints.txt
new file mode 100644
index 00000000000000..16b735ea07a72a
--- /dev/null
+++ b/Doc/constraints.txt
@@ -0,0 +1,24 @@
+# We have upper bounds on our transitive dependencies here
+# To avoid new releases unexpectedly breaking our build.
+# This file can be updated on an ad-hoc basis,
+# though it will probably have to be updated
+# whenever Doc/requirements.txt is updated.
+
+# Direct dependencies of Sphinx
+babel<3
+colorama<0.5
+imagesize<1.5
+Jinja2<3.2
+packaging<24
+Pygments>=2.16.1,<3
+requests<3
+snowballstemmer<3
+sphinxcontrib-applehelp<1.0.5
+sphinxcontrib-devhelp<1.0.6
+sphinxcontrib-htmlhelp<2.0.5
+sphinxcontrib-jsmath<1.1
+sphinxcontrib-qthelp<1.0.7
+sphinxcontrib-serializinghtml<1.1.10
+
+# Direct dependencies of Jinja2 (Jinja is a dependency of Sphinx, see above)
+MarkupSafe<2.2
diff --git a/Doc/contents.rst b/Doc/contents.rst
index 8690de77bf3d82..3eedede7ba49ab 100644
--- a/Doc/contents.rst
+++ b/Doc/contents.rst
@@ -11,7 +11,6 @@
library/index.rst
extending/index.rst
c-api/index.rst
- distributing/index.rst
installing/index.rst
howto/index.rst
faq/index.rst
diff --git a/Doc/copyright.rst b/Doc/copyright.rst
index e64a49328b4723..9b71683155eebe 100644
--- a/Doc/copyright.rst
+++ b/Doc/copyright.rst
@@ -4,7 +4,7 @@ Copyright
Python and this documentation is:
-Copyright © 2001-2022 Python Software Foundation. All rights reserved.
+Copyright © 2001-2023 Python Software Foundation. All rights reserved.
Copyright © 2000 BeOpen.com. All rights reserved.
diff --git a/Doc/data/python3.11.abi b/Doc/data/python3.11.abi
new file mode 100644
index 00000000000000..14ffe9cab2c33d
--- /dev/null
+++ b/Doc/data/python3.11.abi
@@ -0,0 +1,16643 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/Doc/data/refcounts.dat b/Doc/data/refcounts.dat
index 1694cad6f43ba7..0465668e8764e7 100644
--- a/Doc/data/refcounts.dat
+++ b/Doc/data/refcounts.dat
@@ -402,6 +402,21 @@ PyContextVar_Reset:int:::
PyContextVar_Reset:PyObject*:var:0:
PyContextVar_Reset:PyObject*:token:-1:
+PyCFunction_New:PyObject*::+1:
+PyCFunction_New:PyMethodDef*:ml::
+PyCFunction_New:PyObject*:self:+1:
+
+PyCFunction_NewEx:PyObject*::+1:
+PyCFunction_NewEx:PyMethodDef*:ml::
+PyCFunction_NewEx:PyObject*:self:+1:
+PyCFunction_NewEx:PyObject*:module:+1:
+
+PyCMethod_New:PyObject*::+1:
+PyCMethod_New:PyMethodDef*:ml::
+PyCMethod_New:PyObject*:self:+1:
+PyCMethod_New:PyObject*:module:+1:
+PyCMethod_New:PyObject*:cls:+1:
+
PyDate_Check:int:::
PyDate_Check:PyObject*:ob:0:
@@ -1010,10 +1025,10 @@ PyImport_Import:PyObject*::+1:
PyImport_Import:PyObject*:name:0:
PyImport_ImportFrozenModule:int:::
-PyImport_ImportFrozenModule:const char*:::
+PyImport_ImportFrozenModule:const char*:name::
PyImport_ImportFrozenModuleObject:int:::
-PyImport_ImportFrozenModuleObject:PyObject*::+1:
+PyImport_ImportFrozenModuleObject:PyObject*:name:+1:
PyImport_ImportModule:PyObject*::+1:
PyImport_ImportModule:const char*:name::
@@ -1594,6 +1609,13 @@ PyObject_Call:PyObject*:callable_object:0:
PyObject_Call:PyObject*:args:0:
PyObject_Call:PyObject*:kw:0:
+PyObject_CallNoArgs:PyObject*::+1:
+PyObject_CallNoArgs:PyObject*:callable_object:0:
+
+PyObject_CallOneArg:PyObject*::+1:
+PyObject_CallOneArg:PyObject*:callable_object:0:
+PyObject_CallOneArg:PyObject*:arg:0:
+
PyObject_CallFunction:PyObject*::+1:
PyObject_CallFunction:PyObject*:callable_object:0:
PyObject_CallFunction:const char*:format::
diff --git a/Doc/distributing/index.rst b/Doc/distributing/index.rst
index 136cf4e77b1543..8622ec60c0f2f6 100644
--- a/Doc/distributing/index.rst
+++ b/Doc/distributing/index.rst
@@ -1,179 +1,20 @@
+:orphan:
+
+.. This page is retained solely for existing links to /distributing/index.html.
+ Direct readers to the PPUG instead.
+
.. _distributing-index:
+.. _publishing-python-packages:
###############################
Distributing Python Modules
###############################
-:Email: distutils-sig@python.org
-
-
-As a popular open source development project, Python has an active
-supporting community of contributors and users that also make their software
-available for other Python developers to use under open source license terms.
-
-This allows Python users to share and collaborate effectively, benefiting
-from the solutions others have already created to common (and sometimes
-even rare!) problems, as well as potentially contributing their own
-solutions to the common pool.
-
-This guide covers the distribution part of the process. For a guide to
-installing other Python projects, refer to the
-:ref:`installation guide `.
-
.. note::
- For corporate and other institutional users, be aware that many
- organisations have their own policies around using and contributing to
- open source software. Please take such policies into account when making
- use of the distribution and installation tools provided with Python.
-
-
-Key terms
-=========
-
-* the `Python Package Index `__ is a public
- repository of open source licensed packages made available for use by
- other Python users
-* the `Python Packaging Authority
- `__ are the group of
- developers and documentation authors responsible for the maintenance and
- evolution of the standard packaging tools and the associated metadata and
- file format standards. They maintain a variety of tools, documentation
- and issue trackers on both `GitHub `__ and
- `Bitbucket `__.
-* :mod:`distutils` is the original build and distribution system first added
- to the Python standard library in 1998. While direct use of :mod:`distutils`
- is being phased out, it still laid the foundation for the current packaging
- and distribution infrastructure, and it not only remains part of the
- standard library, but its name lives on in other ways (such as the name
- of the mailing list used to coordinate Python packaging standards
- development).
-* `setuptools`_ is a (largely) drop-in replacement for :mod:`distutils` first
- published in 2004. Its most notable addition over the unmodified
- :mod:`distutils` tools was the ability to declare dependencies on other
- packages. It is currently recommended as a more regularly updated
- alternative to :mod:`distutils` that offers consistent support for more
- recent packaging standards across a wide range of Python versions.
-* `wheel`_ (in this context) is a project that adds the ``bdist_wheel``
- command to :mod:`distutils`/`setuptools`_. This produces a cross platform
- binary packaging format (called "wheels" or "wheel files" and defined in
- :pep:`427`) that allows Python libraries, even those including binary
- extensions, to be installed on a system without needing to be built
- locally.
-
-.. _setuptools: https://setuptools.readthedocs.io/en/latest/
-.. _wheel: https://wheel.readthedocs.io/
-
-Open source licensing and collaboration
-=======================================
-
-In most parts of the world, software is automatically covered by copyright.
-This means that other developers require explicit permission to copy, use,
-modify and redistribute the software.
-
-Open source licensing is a way of explicitly granting such permission in a
-relatively consistent way, allowing developers to share and collaborate
-efficiently by making common solutions to various problems freely available.
-This leaves many developers free to spend more time focusing on the problems
-that are relatively unique to their specific situation.
-
-The distribution tools provided with Python are designed to make it
-reasonably straightforward for developers to make their own contributions
-back to that common pool of software if they choose to do so.
-
-The same distribution tools can also be used to distribute software within
-an organisation, regardless of whether that software is published as open
-source software or not.
-
-
-Installing the tools
-====================
-
-The standard library does not include build tools that support modern
-Python packaging standards, as the core development team has found that it
-is important to have standard tools that work consistently, even on older
-versions of Python.
-
-The currently recommended build and distribution tools can be installed
-by invoking the ``pip`` module at the command line::
-
- python -m pip install setuptools wheel twine
-
-.. note::
-
- For POSIX users (including macOS and Linux users), these instructions
- assume the use of a :term:`virtual environment`.
-
- For Windows users, these instructions assume that the option to
- adjust the system PATH environment variable was selected when installing
- Python.
-
-The Python Packaging User Guide includes more details on the `currently
-recommended tools`_.
-
-.. _currently recommended tools: https://packaging.python.org/guides/tool-recommendations/#packaging-tool-recommendations
-
-.. index::
- single: Python Package Index (PyPI)
- single: PyPI; (see Python Package Index (PyPI))
-
-.. _publishing-python-packages:
-
-Reading the Python Packaging User Guide
-=======================================
-
-The Python Packaging User Guide covers the various key steps and elements
-involved in creating and publishing a project:
-
-* `Project structure`_
-* `Building and packaging the project`_
-* `Uploading the project to the Python Package Index`_
-* `The .pypirc file`_
-
-.. _Project structure: \
- https://packaging.python.org/tutorials/packaging-projects/#packaging-python-projects
-.. _Building and packaging the project: \
- https://packaging.python.org/tutorials/packaging-projects/#creating-the-package-files
-.. _Uploading the project to the Python Package Index: \
- https://packaging.python.org/tutorials/packaging-projects/#uploading-the-distribution-archives
-.. _The .pypirc file: \
- https://packaging.python.org/specifications/pypirc/
-
-
-How do I...?
-============
-
-These are quick answers or links for some common tasks.
-
-... choose a name for my project?
----------------------------------
-
-This isn't an easy topic, but here are a few tips:
-
-* check the Python Package Index to see if the name is already in use
-* check popular hosting sites like GitHub, Bitbucket, etc to see if there
- is already a project with that name
-* check what comes up in a web search for the name you're considering
-* avoid particularly common words, especially ones with multiple meanings,
- as they can make it difficult for users to find your software when
- searching for it
-
-
-... create and distribute binary extensions?
---------------------------------------------
-
-This is actually quite a complex topic, with a variety of alternatives
-available depending on exactly what you're aiming to achieve. See the
-Python Packaging User Guide for more information and recommendations.
-
-.. seealso::
-
- `Python Packaging User Guide: Binary Extensions
- `__
-
-.. other topics:
+ Information and guidance on distributing Python modules and packages
+ has been moved to the `Python Packaging User Guide`_,
+ and the tutorial on `packaging Python projects`_.
- Once the Development & Deployment part of PPUG is fleshed out, some of
- those sections should be linked from new questions here (most notably,
- we should have a question about avoiding depending on PyPI that links to
- https://packaging.python.org/en/latest/mirrors/)
+ .. _Python Packaging User Guide: https://packaging.python.org/
+ .. _packaging Python projects: https://packaging.python.org/en/latest/tutorials/packaging-projects/
diff --git a/Doc/distutils/apiref.rst b/Doc/distutils/apiref.rst
index 18a4aac4f70895..56bed7d63f1e90 100644
--- a/Doc/distutils/apiref.rst
+++ b/Doc/distutils/apiref.rst
@@ -11,7 +11,7 @@ API Reference
and other APIs, makes the API consistent across different Python versions,
and is hence recommended over using ``distutils`` directly.
-.. _New and changed setup.py arguments in setuptools: https://setuptools.readthedocs.io/en/latest/setuptools.html#new-and-changed-setup-keywords
+.. _New and changed setup.py arguments in setuptools: https://web.archive.org/web/20210614192516/https://setuptools.pypa.io/en/stable/userguide/keywords.html
.. include:: ./_setuptools_disclaimer.rst
@@ -1021,7 +1021,7 @@ directories.
Files in *src* that begin with :file:`.nfs` are skipped (more information on
these files is available in answer D2 of the `NFS FAQ page
- `_).
+ `_).
.. versionchanged:: 3.3.1
NFS files are ignored.
@@ -1198,7 +1198,7 @@ other utility module.
it contains certain values: see :func:`check_environ`. Raise :exc:`ValueError`
for any variables not found in either *local_vars* or ``os.environ``.
- Note that this is not a fully-fledged string interpolation function. A valid
+ Note that this is not a full-fledged string interpolation function. A valid
``$variable`` can consist only of upper and lower case letters, numbers and an
underscore. No { } or ( ) style quoting is available.
diff --git a/Doc/distutils/examples.rst b/Doc/distutils/examples.rst
index e492b7f6057596..49e4b6e4b984de 100644
--- a/Doc/distutils/examples.rst
+++ b/Doc/distutils/examples.rst
@@ -337,4 +337,4 @@ loads its values::
.. % \section{Putting it all together}
-.. _docutils: http://docutils.sourceforge.net
+.. _docutils: https://docutils.sourceforge.io
diff --git a/Doc/distutils/setupscript.rst b/Doc/distutils/setupscript.rst
index 4386a60b664bfb..8635c911622b2f 100644
--- a/Doc/distutils/setupscript.rst
+++ b/Doc/distutils/setupscript.rst
@@ -642,7 +642,7 @@ Notes:
'long string'
Multiple lines of plain text in reStructuredText format (see
- http://docutils.sourceforge.net/).
+ https://docutils.sourceforge.io/).
'list of strings'
See below.
diff --git a/Doc/extending/building.rst b/Doc/extending/building.rst
index 69dffbd56abf11..53817074ab1ee5 100644
--- a/Doc/extending/building.rst
+++ b/Doc/extending/building.rst
@@ -17,7 +17,7 @@ The initialization function has the signature:
.. c:function:: PyObject* PyInit_modulename(void)
-It returns either a fully-initialized module, or a :c:type:`PyModuleDef`
+It returns either a fully initialized module, or a :c:type:`PyModuleDef`
instance. See :ref:`initializing-modules` for details.
.. highlight:: python
diff --git a/Doc/extending/embedding.rst b/Doc/extending/embedding.rst
index 5f5abdf9c15067..4c7c7ec98a6c95 100644
--- a/Doc/extending/embedding.rst
+++ b/Doc/extending/embedding.rst
@@ -250,7 +250,7 @@ following two statements before the call to :c:func:`Py_Initialize`::
PyImport_AppendInittab("emb", &PyInit_emb);
These two lines initialize the ``numargs`` variable, and make the
-:func:`emb.numargs` function accessible to the embedded Python interpreter.
+:func:`!emb.numargs` function accessible to the embedded Python interpreter.
With these extensions, the Python script can do things like
.. code-block:: python
@@ -298,16 +298,16 @@ be directly useful to you:
.. code-block:: shell-session
- $ /opt/bin/python3.4-config --cflags
- -I/opt/include/python3.4m -I/opt/include/python3.4m -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
+ $ /opt/bin/python3.11-config --cflags
+ -I/opt/include/python3.11 -I/opt/include/python3.11 -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
-* ``pythonX.Y-config --ldflags`` will give you the recommended flags when
- linking:
+* ``pythonX.Y-config --ldflags --embed`` will give you the recommended flags
+ when linking:
.. code-block:: shell-session
- $ /opt/bin/python3.4-config --ldflags
- -L/opt/lib/python3.4/config-3.4m -lpthread -ldl -lutil -lm -lpython3.4m -Xlinker -export-dynamic
+ $ /opt/bin/python3.11-config --ldflags --embed
+ -L/opt/lib/python3.11/config-3.11-x86_64-linux-gnu -L/opt/lib -lpython3.11 -lpthread -ldl -lutil -lm
.. note::
To avoid confusion between several Python installations (and especially
diff --git a/Doc/extending/extending.rst b/Doc/extending/extending.rst
index 2e3362b834e6fb..394948a4d2ea6b 100644
--- a/Doc/extending/extending.rst
+++ b/Doc/extending/extending.rst
@@ -157,16 +157,16 @@ since you should be able to tell from the return value.
When a function *f* that calls another function *g* detects that the latter
fails, *f* should itself return an error value (usually ``NULL`` or ``-1``). It
-should *not* call one of the :c:func:`PyErr_\*` functions --- one has already
+should *not* call one of the ``PyErr_*`` functions --- one has already
been called by *g*. *f*'s caller is then supposed to also return an error
-indication to *its* caller, again *without* calling :c:func:`PyErr_\*`, and so on
+indication to *its* caller, again *without* calling ``PyErr_*``, and so on
--- the most detailed cause of the error was already reported by the function
that first detected it. Once the error reaches the Python interpreter's main
loop, this aborts the currently executing Python code and tries to find an
exception handler specified by the Python programmer.
(There are situations where a module can actually give a more detailed error
-message by calling another :c:func:`PyErr_\*` function, and in such cases it is
+message by calling another ``PyErr_*`` function, and in such cases it is
fine to do so. As a general rule, however, this is not necessary, and can cause
information about the cause of the error to be lost: most operations can fail
for a variety of reasons.)
@@ -195,7 +195,7 @@ The choice of which exception to raise is entirely yours. There are predeclared
C objects corresponding to all built-in Python exceptions, such as
:c:data:`PyExc_ZeroDivisionError`, which you can use directly. Of course, you
should choose exceptions wisely --- don't use :c:data:`PyExc_TypeError` to mean
-that a file couldn't be opened (that should probably be :c:data:`PyExc_IOError`).
+that a file couldn't be opened (that should probably be :c:data:`PyExc_OSError`).
If something's wrong with the argument list, the :c:func:`PyArg_ParseTuple`
function usually raises :c:data:`PyExc_TypeError`. If you have an argument whose
value must be in a particular range or must satisfy other conditions,
@@ -206,7 +206,7 @@ usually declare a static object variable at the beginning of your file::
static PyObject *SpamError;
-and initialize it in your module's initialization function (:c:func:`PyInit_spam`)
+and initialize it in your module's initialization function (:c:func:`!PyInit_spam`)
with an exception object::
PyMODINIT_FUNC
@@ -230,22 +230,22 @@ with an exception object::
return m;
}
-Note that the Python name for the exception object is :exc:`spam.error`. The
+Note that the Python name for the exception object is :exc:`!spam.error`. The
:c:func:`PyErr_NewException` function may create a class with the base class
being :exc:`Exception` (unless another class is passed in instead of ``NULL``),
described in :ref:`bltin-exceptions`.
-Note also that the :c:data:`SpamError` variable retains a reference to the newly
+Note also that the :c:data:`!SpamError` variable retains a reference to the newly
created exception class; this is intentional! Since the exception could be
removed from the module by external code, an owned reference to the class is
-needed to ensure that it will not be discarded, causing :c:data:`SpamError` to
+needed to ensure that it will not be discarded, causing :c:data:`!SpamError` to
become a dangling pointer. Should it become a dangling pointer, C code which
raises the exception could cause a core dump or other unintended side effects.
-We discuss the use of ``PyMODINIT_FUNC`` as a function return type later in this
+We discuss the use of :c:macro:`PyMODINIT_FUNC` as a function return type later in this
sample.
-The :exc:`spam.error` exception can be raised in your extension module using a
+The :exc:`!spam.error` exception can be raised in your extension module using a
call to :c:func:`PyErr_SetString` as shown below::
static PyObject *
@@ -279,9 +279,9 @@ statement::
It returns ``NULL`` (the error indicator for functions returning object pointers)
if an error is detected in the argument list, relying on the exception set by
:c:func:`PyArg_ParseTuple`. Otherwise the string value of the argument has been
-copied to the local variable :c:data:`command`. This is a pointer assignment and
+copied to the local variable :c:data:`!command`. This is a pointer assignment and
you are not supposed to modify the string to which it points (so in Standard C,
-the variable :c:data:`command` should properly be declared as ``const char
+the variable :c:data:`!command` should properly be declared as ``const char
*command``).
The next statement is a call to the Unix function :c:func:`system`, passing it
@@ -289,7 +289,7 @@ the string we just got from :c:func:`PyArg_ParseTuple`::
sts = system(command);
-Our :func:`spam.system` function must return the value of :c:data:`sts` as a
+Our :func:`!spam.system` function must return the value of :c:data:`!sts` as a
Python object. This is done using the function :c:func:`PyLong_FromLong`. ::
return PyLong_FromLong(sts);
@@ -298,7 +298,7 @@ In this case, it will return an integer object. (Yes, even integers are objects
on the heap in Python!)
If you have a C function that returns no useful argument (a function returning
-:c:type:`void`), the corresponding Python function must return ``None``. You
+:c:expr:`void`), the corresponding Python function must return ``None``. You
need this idiom to do so (which is implemented by the :c:macro:`Py_RETURN_NONE`
macro)::
@@ -315,7 +315,7 @@ contexts, as we have seen.
The Module's Method Table and Initialization Function
=====================================================
-I promised to show how :c:func:`spam_system` is called from Python programs.
+I promised to show how :c:func:`!spam_system` is called from Python programs.
First, we need to list its name and address in a "method table"::
static PyMethodDef SpamMethods[] = {
@@ -335,7 +335,7 @@ When using only ``METH_VARARGS``, the function should expect the Python-level
parameters to be passed in as a tuple acceptable for parsing via
:c:func:`PyArg_ParseTuple`; more information on this function is provided below.
-The :const:`METH_KEYWORDS` bit may be set in the third field if keyword
+The :c:macro:`METH_KEYWORDS` bit may be set in the third field if keyword
arguments should be passed to the function. In this case, the C function should
accept a third ``PyObject *`` parameter which will be a dictionary of keywords.
Use :c:func:`PyArg_ParseTupleAndKeywords` to parse the arguments to such a
@@ -354,7 +354,7 @@ The method table must be referenced in the module definition structure::
This structure, in turn, must be passed to the interpreter in the module's
initialization function. The initialization function must be named
-:c:func:`PyInit_name`, where *name* is the name of the module, and should be the
+:c:func:`!PyInit_name`, where *name* is the name of the module, and should be the
only non-\ ``static`` item defined in the module file::
PyMODINIT_FUNC
@@ -363,12 +363,12 @@ only non-\ ``static`` item defined in the module file::
return PyModule_Create(&spammodule);
}
-Note that PyMODINIT_FUNC declares the function as ``PyObject *`` return type,
+Note that :c:macro:`PyMODINIT_FUNC` declares the function as ``PyObject *`` return type,
declares any special linkage declarations required by the platform, and for C++
declares the function as ``extern "C"``.
-When the Python program imports module :mod:`spam` for the first time,
-:c:func:`PyInit_spam` is called. (See below for comments about embedding Python.)
+When the Python program imports module :mod:`!spam` for the first time,
+:c:func:`!PyInit_spam` is called. (See below for comments about embedding Python.)
It calls :c:func:`PyModule_Create`, which returns a module object, and
inserts built-in function objects into the newly created module based upon the
table (an array of :c:type:`PyMethodDef` structures) found in the module definition.
@@ -378,7 +378,7 @@ certain errors, or return ``NULL`` if the module could not be initialized
satisfactorily. The init function must return the module object to its caller,
so that it then gets inserted into ``sys.modules``.
-When embedding Python, the :c:func:`PyInit_spam` function is not called
+When embedding Python, the :c:func:`!PyInit_spam` function is not called
automatically unless there's an entry in the :c:data:`PyImport_Inittab` table.
To add the module to the initialization table, use :c:func:`PyImport_AppendInittab`,
optionally followed by an import of the module::
@@ -527,7 +527,7 @@ be part of a module definition::
}
This function must be registered with the interpreter using the
-:const:`METH_VARARGS` flag; this is described in section :ref:`methodtable`. The
+:c:macro:`METH_VARARGS` flag; this is described in section :ref:`methodtable`. The
:c:func:`PyArg_ParseTuple` function and its arguments are documented in section
:ref:`parsetuple`.
@@ -536,7 +536,7 @@ reference count of an object and are safe in the presence of ``NULL`` pointers
(but note that *temp* will not be ``NULL`` in this context). More info on them
in section :ref:`refcounts`.
-.. index:: single: PyObject_CallObject()
+.. index:: single: PyObject_CallObject (C function)
Later, when it is time to call the function, you call the C function
:c:func:`PyObject_CallObject`. This function has two arguments, both pointers to
@@ -627,7 +627,7 @@ the above example, we use :c:func:`Py_BuildValue` to construct the dictionary. :
Extracting Parameters in Extension Functions
============================================
-.. index:: single: PyArg_ParseTuple()
+.. index:: single: PyArg_ParseTuple (C function)
The :c:func:`PyArg_ParseTuple` function is declared as follows::
@@ -719,7 +719,7 @@ Some example calls::
Keyword Parameters for Extension Functions
==========================================
-.. index:: single: PyArg_ParseTupleAndKeywords()
+.. index:: single: PyArg_ParseTupleAndKeywords (C function)
The :c:func:`PyArg_ParseTupleAndKeywords` function is declared as follows::
@@ -1030,13 +1030,13 @@ Let's follow the control flow into :c:func:`PyList_SetItem`. The list owns
references to all its items, so when item 1 is replaced, it has to dispose of
the original item 1. Now let's suppose the original item 1 was an instance of a
user-defined class, and let's further suppose that the class defined a
-:meth:`__del__` method. If this class instance has a reference count of 1,
-disposing of it will call its :meth:`__del__` method.
+:meth:`!__del__` method. If this class instance has a reference count of 1,
+disposing of it will call its :meth:`!__del__` method.
-Since it is written in Python, the :meth:`__del__` method can execute arbitrary
+Since it is written in Python, the :meth:`!__del__` method can execute arbitrary
Python code. Could it perhaps do something to invalidate the reference to
-``item`` in :c:func:`bug`? You bet! Assuming that the list passed into
-:c:func:`bug` is accessible to the :meth:`__del__` method, it could execute a
+``item`` in :c:func:`!bug`? You bet! Assuming that the list passed into
+:c:func:`!bug` is accessible to the :meth:`!__del__` method, it could execute a
statement to the effect of ``del list[0]``, and assuming this was the last
reference to that object, it would free the memory associated with it, thereby
invalidating ``item``.
@@ -1057,7 +1057,7 @@ increment the reference count. The correct version of the function reads::
This is a true story. An older version of Python contained variants of this bug
and someone spent a considerable amount of time in a C debugger to figure out
-why his :meth:`__del__` methods would fail...
+why his :meth:`!__del__` methods would fail...
The second case of problems with a borrowed reference is a variant involving
threads. Normally, multiple threads in the Python interpreter can't get in each
@@ -1171,7 +1171,7 @@ other extension modules must be exported in a different way.
Python provides a special mechanism to pass C-level information (pointers) from
one extension module to another one: Capsules. A Capsule is a Python data type
-which stores a pointer (:c:type:`void \*`). Capsules can only be created and
+which stores a pointer (:c:expr:`void \*`). Capsules can only be created and
accessed via their C API, but they can be passed around like any other Python
object. In particular, they can be assigned to a name in an extension module's
namespace. Other extension modules can then import this module, retrieve the
@@ -1185,7 +1185,7 @@ different ways between the module providing the code and the client modules.
Whichever method you choose, it's important to name your Capsules properly.
The function :c:func:`PyCapsule_New` takes a name parameter
-(:c:type:`const char \*`); you're permitted to pass in a ``NULL`` name, but
+(:c:expr:`const char \*`); you're permitted to pass in a ``NULL`` name, but
we strongly encourage you to specify a name. Properly named Capsules provide
a degree of runtime type-safety; there is no feasible way to tell one unnamed
Capsule from another.
@@ -1203,19 +1203,19 @@ of certainty that the Capsule they load contains the correct C API.
The following example demonstrates an approach that puts most of the burden on
the writer of the exporting module, which is appropriate for commonly used
library modules. It stores all C API pointers (just one in the example!) in an
-array of :c:type:`void` pointers which becomes the value of a Capsule. The header
+array of :c:expr:`void` pointers which becomes the value of a Capsule. The header
file corresponding to the module provides a macro that takes care of importing
the module and retrieving its C API pointers; client modules only have to call
this macro before accessing the C API.
-The exporting module is a modification of the :mod:`spam` module from section
-:ref:`extending-simpleexample`. The function :func:`spam.system` does not call
+The exporting module is a modification of the :mod:`!spam` module from section
+:ref:`extending-simpleexample`. The function :func:`!spam.system` does not call
the C library function :c:func:`system` directly, but a function
-:c:func:`PySpam_System`, which would of course do something more complicated in
+:c:func:`!PySpam_System`, which would of course do something more complicated in
reality (such as adding "spam" to every command). This function
-:c:func:`PySpam_System` is also exported to other extension modules.
+:c:func:`!PySpam_System` is also exported to other extension modules.
-The function :c:func:`PySpam_System` is a plain C function, declared
+The function :c:func:`!PySpam_System` is a plain C function, declared
``static`` like everything else::
static int
@@ -1224,7 +1224,7 @@ The function :c:func:`PySpam_System` is a plain C function, declared
return system(command);
}
-The function :c:func:`spam_system` is modified in a trivial way::
+The function :c:func:`!spam_system` is modified in a trivial way::
static PyObject *
spam_system(PyObject *self, PyObject *args)
@@ -1278,7 +1278,7 @@ function must take care of initializing the C API pointer array::
}
Note that ``PySpam_API`` is declared ``static``; otherwise the pointer
-array would disappear when :func:`PyInit_spam` terminates!
+array would disappear when :c:func:`!PyInit_spam` terminates!
The bulk of the work is in the header file :file:`spammodule.h`, which looks
like this::
@@ -1332,8 +1332,8 @@ like this::
#endif /* !defined(Py_SPAMMODULE_H) */
All that a client module must do in order to have access to the function
-:c:func:`PySpam_System` is to call the function (or rather macro)
-:c:func:`import_spam` in its initialization function::
+:c:func:`!PySpam_System` is to call the function (or rather macro)
+:c:func:`!import_spam` in its initialization function::
PyMODINIT_FUNC
PyInit_client(void)
diff --git a/Doc/extending/index.rst b/Doc/extending/index.rst
index 0994e3e8627dfa..01b4df6d44acff 100644
--- a/Doc/extending/index.rst
+++ b/Doc/extending/index.rst
@@ -27,8 +27,8 @@ Recommended third party tools
This guide only covers the basic tools for creating extensions provided
as part of this version of CPython. Third party tools like
-`Cython `_, `cffi `_,
-`SWIG `_ and `Numba `_
+`Cython `_, `cffi `_,
+`SWIG `_ and `Numba `_
offer both simpler and more sophisticated approaches to creating C and C++
extensions for Python.
diff --git a/Doc/extending/newtypes.rst b/Doc/extending/newtypes.rst
index f75bee9e6f2a2b..b67693584d821b 100644
--- a/Doc/extending/newtypes.rst
+++ b/Doc/extending/newtypes.rst
@@ -89,8 +89,8 @@ If your type supports garbage collection, the destructor should call
}
.. index::
- single: PyErr_Fetch()
- single: PyErr_Restore()
+ single: PyErr_Fetch (C function)
+ single: PyErr_Restore (C function)
One important requirement of the deallocator function is that it leaves any
pending exceptions alone. This is important since deallocators are frequently
@@ -149,7 +149,7 @@ done. This can be done using the :c:func:`PyErr_Fetch` and
.. index::
single: string; object representation
- builtin: repr
+ pair: built-in function; repr
Object Presentation
-------------------
@@ -175,7 +175,7 @@ example::
}
If no :c:member:`~PyTypeObject.tp_repr` handler is specified, the interpreter will supply a
-representation that uses the type's :c:member:`~PyTypeObject.tp_name` and a uniquely-identifying
+representation that uses the type's :c:member:`~PyTypeObject.tp_name` and a uniquely identifying
value for the object.
The :c:member:`~PyTypeObject.tp_str` handler is to :func:`str` what the :c:member:`~PyTypeObject.tp_repr` handler
@@ -207,8 +207,8 @@ a special case, for which the new value passed to the handler is ``NULL``.
Python supports two pairs of attribute handlers; a type that supports attributes
only needs to implement the functions for one pair. The difference is that one
-pair takes the name of the attribute as a :c:type:`char\*`, while the other
-accepts a :c:type:`PyObject\*`. Each type can use whichever pair makes more
+pair takes the name of the attribute as a :c:expr:`char\*`, while the other
+accepts a :c:expr:`PyObject*`. Each type can use whichever pair makes more
sense for the implementation's convenience. ::
getattrfunc tp_getattr; /* char * version */
@@ -219,7 +219,7 @@ sense for the implementation's convenience. ::
If accessing attributes of an object is always a simple operation (this will be
explained shortly), there are generic implementations which can be used to
-provide the :c:type:`PyObject\*` version of the attribute management functions.
+provide the :c:expr:`PyObject*` version of the attribute management functions.
The actual need for type-specific attribute handlers almost completely
disappeared starting with Python 2.2, though there are many examples which have
not been updated to use some of the new generic mechanism that is available.
@@ -270,7 +270,7 @@ structure::
One entry should be defined for each method provided by the type; no entries are
needed for methods inherited from a base type. One additional entry is needed
at the end; it is a sentinel that marks the end of the array. The
-:attr:`ml_name` field of the sentinel must be ``NULL``.
+:c:member:`~PyMethodDef.ml_name` field of the sentinel must be ``NULL``.
The second table is used to define attributes which map directly to data stored
in the instance. A variety of primitive C types are supported, and access may
@@ -286,9 +286,9 @@ be read-only or read-write. The structures in the table are defined as::
For each entry in the table, a :term:`descriptor` will be constructed and added to the
type which will be able to extract a value from the instance structure. The
-:attr:`type` field should contain one of the type codes defined in the
+:c:member:`~PyMemberDef.type` field should contain one of the type codes defined in the
:file:`structmember.h` header; the value will be used to determine how to
-convert Python values to and from C values. The :attr:`flags` field is used to
+convert Python values to and from C values. The :c:member:`~PyMemberDef.flags` field is used to
store flags which control how the attribute can be accessed.
The following flag constants are defined in :file:`structmember.h`; they may be
@@ -305,10 +305,10 @@ combined using bitwise-OR.
+---------------------------+----------------------------------------------+
.. versionchanged:: 3.10
- :const:`RESTRICTED`, :const:`READ_RESTRICTED` and :const:`WRITE_RESTRICTED`
- are deprecated. However, :const:`READ_RESTRICTED` is an alias for
- :const:`PY_AUDIT_READ`, so fields that specify either :const:`RESTRICTED`
- or :const:`READ_RESTRICTED` will also raise an audit event.
+ :c:macro:`RESTRICTED`, :c:macro:`READ_RESTRICTED` and :c:macro:`WRITE_RESTRICTED`
+ are deprecated. However, :c:macro:`READ_RESTRICTED` is an alias for
+ :c:macro:`PY_AUDIT_READ`, so fields that specify either :c:macro:`RESTRICTED`
+ or :c:macro:`READ_RESTRICTED` will also raise an audit event.
.. index::
single: READONLY
@@ -321,9 +321,9 @@ An interesting advantage of using the :c:member:`~PyTypeObject.tp_members` table
descriptors that are used at runtime is that any attribute defined this way can
have an associated doc string simply by providing the text in the table. An
application can use the introspection API to retrieve the descriptor from the
-class object, and get the doc string using its :attr:`__doc__` attribute.
+class object, and get the doc string using its :attr:`!__doc__` attribute.
-As with the :c:member:`~PyTypeObject.tp_methods` table, a sentinel entry with a :attr:`name` value
+As with the :c:member:`~PyTypeObject.tp_methods` table, a sentinel entry with a :c:member:`~PyMethodDef.ml_name` value
of ``NULL`` is required.
.. XXX Descriptors need to be explained in more detail somewhere, but not here.
@@ -339,16 +339,16 @@ of ``NULL`` is required.
Type-specific Attribute Management
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-For simplicity, only the :c:type:`char\*` version will be demonstrated here; the
-type of the name parameter is the only difference between the :c:type:`char\*`
-and :c:type:`PyObject\*` flavors of the interface. This example effectively does
+For simplicity, only the :c:expr:`char\*` version will be demonstrated here; the
+type of the name parameter is the only difference between the :c:expr:`char\*`
+and :c:expr:`PyObject*` flavors of the interface. This example effectively does
the same thing as the generic example above, but does not use the generic
support added in Python 2.2. It explains how the handler functions are
called, so that if you do need to extend their functionality, you'll understand
what needs to be done.
The :c:member:`~PyTypeObject.tp_getattr` handler is called when the object requires an attribute
-look-up. It is called in the same situations where the :meth:`__getattr__`
+look-up. It is called in the same situations where the :meth:`~object.__getattr__`
method of a class would be called.
Here is an example::
@@ -367,8 +367,8 @@ Here is an example::
return NULL;
}
-The :c:member:`~PyTypeObject.tp_setattr` handler is called when the :meth:`__setattr__` or
-:meth:`__delattr__` method of a class instance would be called. When an
+The :c:member:`~PyTypeObject.tp_setattr` handler is called when the :meth:`~object.__setattr__` or
+:meth:`~object.__delattr__` method of a class instance would be called. When an
attribute should be deleted, the third parameter will be ``NULL``. Here is an
example that simply raises an exception; if this were really all you wanted, the
:c:member:`~PyTypeObject.tp_setattr` handler should be set to ``NULL``. ::
@@ -389,7 +389,7 @@ Object Comparison
The :c:member:`~PyTypeObject.tp_richcompare` handler is called when comparisons are needed. It is
analogous to the :ref:`rich comparison methods `, like
-:meth:`__lt__`, and also called by :c:func:`PyObject_RichCompare` and
+:meth:`!__lt__`, and also called by :c:func:`PyObject_RichCompare` and
:c:func:`PyObject_RichCompareBool`.
This function is called with two Python objects and the operator as arguments,
@@ -473,7 +473,7 @@ instance of your data type. Here is a simple example::
return result;
}
-:c:type:`Py_hash_t` is a signed integer type with a platform-varying width.
+:c:type:`!Py_hash_t` is a signed integer type with a platform-varying width.
Returning ``-1`` from :c:member:`~PyTypeObject.tp_hash` indicates an error,
which is why you should be careful to avoid returning it when hash computation
is successful, as seen above.
@@ -530,7 +530,7 @@ These functions provide support for the iterator protocol. Both handlers
take exactly one parameter, the instance for which they are being called,
and return a new reference. In the case of an error, they should set an
exception and return ``NULL``. :c:member:`~PyTypeObject.tp_iter` corresponds
-to the Python :meth:`__iter__` method, while :c:member:`~PyTypeObject.tp_iternext`
+to the Python :meth:`~object.__iter__` method, while :c:member:`~PyTypeObject.tp_iternext`
corresponds to the Python :meth:`~iterator.__next__` method.
Any :term:`iterable` object must implement the :c:member:`~PyTypeObject.tp_iter`
@@ -572,7 +572,7 @@ performance-critical objects (such as numbers).
For an object to be weakly referencable, the extension type must do two things:
-#. Include a :c:type:`PyObject\*` field in the C object structure dedicated to
+#. Include a :c:expr:`PyObject*` field in the C object structure dedicated to
the weak reference mechanism. The object's constructor should leave it
``NULL`` (which is automatic when using the default
:c:member:`~PyTypeObject.tp_alloc`).
@@ -589,7 +589,7 @@ with the required field::
PyObject *weakreflist; /* List of weak references */
} TrivialObject;
-And the corresponding member in the statically-declared type object::
+And the corresponding member in the statically declared type object::
static PyTypeObject TrivialType = {
PyVarObject_HEAD_INIT(NULL, 0)
diff --git a/Doc/extending/newtypes_tutorial.rst b/Doc/extending/newtypes_tutorial.rst
index 34c25d1f6f199c..f4684ceb1a72a4 100644
--- a/Doc/extending/newtypes_tutorial.rst
+++ b/Doc/extending/newtypes_tutorial.rst
@@ -24,7 +24,7 @@ The Basics
==========
The :term:`CPython` runtime sees all Python objects as variables of type
-:c:type:`PyObject\*`, which serves as a "base type" for all Python objects.
+:c:expr:`PyObject*`, which serves as a "base type" for all Python objects.
The :c:type:`PyObject` structure itself only contains the object's
:term:`reference count` and a pointer to the object's "type object".
This is where the action is; the type object determines which (C) functions
@@ -36,8 +36,8 @@ So, if you want to define a new extension type, you need to create a new type
object.
This sort of thing can only be explained by example, so here's a minimal, but
-complete, module that defines a new type named :class:`Custom` inside a C
-extension module :mod:`custom`:
+complete, module that defines a new type named :class:`!Custom` inside a C
+extension module :mod:`!custom`:
.. note::
What we're showing here is the traditional way of defining *static*
@@ -50,12 +50,12 @@ extension module :mod:`custom`:
Now that's quite a bit to take in at once, but hopefully bits will seem familiar
from the previous chapter. This file defines three things:
-#. What a :class:`Custom` **object** contains: this is the ``CustomObject``
- struct, which is allocated once for each :class:`Custom` instance.
-#. How the :class:`Custom` **type** behaves: this is the ``CustomType`` struct,
+#. What a :class:`!Custom` **object** contains: this is the ``CustomObject``
+ struct, which is allocated once for each :class:`!Custom` instance.
+#. How the :class:`!Custom` **type** behaves: this is the ``CustomType`` struct,
which defines a set of flags and function pointers that the interpreter
inspects when specific operations are requested.
-#. How to initialize the :mod:`custom` module: this is the ``PyInit_custom``
+#. How to initialize the :mod:`!custom` module: this is the ``PyInit_custom``
function and the associated ``custommodule`` struct.
The first bit is::
@@ -127,8 +127,8 @@ our objects and in some error messages, for example:
TypeError: can only concatenate str (not "custom.Custom") to str
Note that the name is a dotted name that includes both the module name and the
-name of the type within the module. The module in this case is :mod:`custom` and
-the type is :class:`Custom`, so we set the type name to :class:`custom.Custom`.
+name of the type within the module. The module in this case is :mod:`!custom` and
+the type is :class:`!Custom`, so we set the type name to :class:`!custom.Custom`.
Using the real dotted import path is important to make your type compatible
with the :mod:`pydoc` and :mod:`pickle` modules. ::
@@ -136,7 +136,7 @@ with the :mod:`pydoc` and :mod:`pickle` modules. ::
.tp_itemsize = 0,
This is so that Python knows how much memory to allocate when creating
-new :class:`Custom` instances. :c:member:`~PyTypeObject.tp_itemsize` is
+new :class:`!Custom` instances. :c:member:`~PyTypeObject.tp_itemsize` is
only used for variable-sized objects and should otherwise be zero.
.. note::
@@ -145,13 +145,13 @@ only used for variable-sized objects and should otherwise be zero.
:c:member:`~PyTypeObject.tp_basicsize` as its base type, you may have problems with multiple
inheritance. A Python subclass of your type will have to list your type first
in its :attr:`~class.__bases__`, or else it will not be able to call your type's
- :meth:`__new__` method without getting an error. You can avoid this problem by
+ :meth:`~object.__new__` method without getting an error. You can avoid this problem by
ensuring that your type has a larger value for :c:member:`~PyTypeObject.tp_basicsize` than its
base type does. Most of the time, this will be true anyway, because either your
base type will be :class:`object`, or else you will be adding data members to
your base type, and therefore increasing its size.
-We set the class flags to :const:`Py_TPFLAGS_DEFAULT`. ::
+We set the class flags to :c:macro:`Py_TPFLAGS_DEFAULT`. ::
.tp_flags = Py_TPFLAGS_DEFAULT,
@@ -164,20 +164,20 @@ We provide a doc string for the type in :c:member:`~PyTypeObject.tp_doc`. ::
.tp_doc = PyDoc_STR("Custom objects"),
To enable object creation, we have to provide a :c:member:`~PyTypeObject.tp_new`
-handler. This is the equivalent of the Python method :meth:`__new__`, but
+handler. This is the equivalent of the Python method :meth:`~object.__new__`, but
has to be specified explicitly. In this case, we can just use the default
implementation provided by the API function :c:func:`PyType_GenericNew`. ::
.tp_new = PyType_GenericNew,
Everything else in the file should be familiar, except for some code in
-:c:func:`PyInit_custom`::
+:c:func:`!PyInit_custom`::
if (PyType_Ready(&CustomType) < 0)
return;
-This initializes the :class:`Custom` type, filling in a number of members
-to the appropriate default values, including :attr:`ob_type` that we initially
+This initializes the :class:`!Custom` type, filling in a number of members
+to the appropriate default values, including :c:member:`~PyObject.ob_type` that we initially
set to ``NULL``. ::
Py_INCREF(&CustomType);
@@ -188,7 +188,7 @@ set to ``NULL``. ::
}
This adds the type to the module dictionary. This allows us to create
-:class:`Custom` instances by calling the :class:`Custom` class:
+:class:`!Custom` instances by calling the :class:`!Custom` class:
.. code-block:: pycon
@@ -220,7 +220,7 @@ Of course, the current Custom type is pretty uninteresting. It has no data and
doesn't do anything. It can't even be subclassed.
.. note::
- While this documentation showcases the standard :mod:`distutils` module
+ While this documentation showcases the standard :mod:`!distutils` module
for building C extensions, it is recommended in real-world use cases to
use the newer and better-maintained ``setuptools`` library. Documentation
on how to do this is out of scope for this document and can be found in
@@ -231,7 +231,7 @@ Adding data and methods to the Basic example
============================================
Let's extend the basic example to add some data and methods. Let's also make
-the type usable as a base class. We'll create a new module, :mod:`custom2` that
+the type usable as a base class. We'll create a new module, :mod:`!custom2` that
adds these capabilities:
.. literalinclude:: ../includes/custom2.c
@@ -246,7 +246,7 @@ We've added an extra include::
This include provides declarations that we use to handle attributes, as
described a bit later.
-The :class:`Custom` type now has three data attributes in its C struct,
+The :class:`!Custom` type now has three data attributes in its C struct,
*first*, *last*, and *number*. The *first* and *last* variables are Python
strings containing first and last names. The *number* attribute is a C integer.
@@ -279,7 +279,7 @@ This method first clears the reference counts of the two Python attributes.
``NULL`` (which might happen here if ``tp_new`` failed midway). It then
calls the :c:member:`~PyTypeObject.tp_free` member of the object's type
(computed by ``Py_TYPE(self)``) to free the object's memory. Note that
-the object's type might not be :class:`CustomType`, because the object may
+the object's type might not be :class:`!CustomType`, because the object may
be an instance of a subclass.
.. note::
@@ -318,10 +318,10 @@ and install it in the :c:member:`~PyTypeObject.tp_new` member::
.tp_new = Custom_new,
The ``tp_new`` handler is responsible for creating (as opposed to initializing)
-objects of the type. It is exposed in Python as the :meth:`__new__` method.
+objects of the type. It is exposed in Python as the :meth:`~object.__new__` method.
It is not required to define a ``tp_new`` member, and indeed many extension
types will simply reuse :c:func:`PyType_GenericNew` as done in the first
-version of the ``Custom`` type above. In this case, we use the ``tp_new``
+version of the :class:`!Custom` type above. In this case, we use the ``tp_new``
handler to initialize the ``first`` and ``last`` attributes to non-``NULL``
default values.
@@ -352,7 +352,7 @@ result against ``NULL`` before proceeding.
.. note::
If you are creating a co-operative :c:member:`~PyTypeObject.tp_new` (one
- that calls a base type's :c:member:`~PyTypeObject.tp_new` or :meth:`__new__`),
+ that calls a base type's :c:member:`~PyTypeObject.tp_new` or :meth:`~object.__new__`),
you must *not* try to determine what method to call using method resolution
order at runtime. Always statically determine what type you are going to
call, and call its :c:member:`~PyTypeObject.tp_new` directly, or via
@@ -395,14 +395,14 @@ by filling the :c:member:`~PyTypeObject.tp_init` slot. ::
.tp_init = (initproc) Custom_init,
The :c:member:`~PyTypeObject.tp_init` slot is exposed in Python as the
-:meth:`__init__` method. It is used to initialize an object after it's
+:meth:`~object.__init__` method. It is used to initialize an object after it's
created. Initializers always accept positional and keyword arguments,
and they should return either ``0`` on success or ``-1`` on error.
Unlike the ``tp_new`` handler, there is no guarantee that ``tp_init``
is called at all (for example, the :mod:`pickle` module by default
-doesn't call :meth:`__init__` on unpickled instances). It can also be
-called multiple times. Anyone can call the :meth:`__init__` method on
+doesn't call :meth:`~object.__init__` on unpickled instances). It can also be
+called multiple times. Anyone can call the :meth:`!__init__` method on
our objects. For this reason, we have to be extra careful when assigning
the new attribute values. We might be tempted, for example to assign the
``first`` member like this::
@@ -460,7 +460,7 @@ Further, the attributes can be deleted, setting the C pointers to ``NULL``. Eve
though we can make sure the members are initialized to non-``NULL`` values, the
members can be set to ``NULL`` if the attributes are deleted.
-We define a single method, :meth:`Custom.name()`, that outputs the objects name as the
+We define a single method, :meth:`!Custom.name()`, that outputs the objects name as the
concatenation of the first and last names. ::
static PyObject *
@@ -477,8 +477,8 @@ concatenation of the first and last names. ::
return PyUnicode_FromFormat("%S %S", self->first, self->last);
}
-The method is implemented as a C function that takes a :class:`Custom` (or
-:class:`Custom` subclass) instance as the first argument. Methods always take an
+The method is implemented as a C function that takes a :class:`!Custom` (or
+:class:`!Custom` subclass) instance as the first argument. Methods always take an
instance as the first argument. Methods often take positional and keyword
arguments as well, but in this case we don't take any and don't need to accept
a positional argument tuple or keyword argument dictionary. This method is
@@ -489,8 +489,8 @@ equivalent to the Python method:
def name(self):
return "%s %s" % (self.first, self.last)
-Note that we have to check for the possibility that our :attr:`first` and
-:attr:`last` members are ``NULL``. This is because they can be deleted, in which
+Note that we have to check for the possibility that our :attr:`!first` and
+:attr:`!last` members are ``NULL``. This is because they can be deleted, in which
case they are set to ``NULL``. It would be better to prevent deletion of these
attributes and to restrict the attribute values to be strings. We'll see how to
do that in the next section.
@@ -505,7 +505,7 @@ definitions::
{NULL} /* Sentinel */
};
-(note that we used the :const:`METH_NOARGS` flag to indicate that the method
+(note that we used the :c:macro:`METH_NOARGS` flag to indicate that the method
is expecting no arguments other than *self*)
and assign it to the :c:member:`~PyTypeObject.tp_methods` slot::
@@ -515,11 +515,11 @@ and assign it to the :c:member:`~PyTypeObject.tp_methods` slot::
Finally, we'll make our type usable as a base class for subclassing. We've
written our methods carefully so far so that they don't make any assumptions
about the type of the object being created or used, so all we need to do is
-to add the :const:`Py_TPFLAGS_BASETYPE` to our class flag definition::
+to add the :c:macro:`Py_TPFLAGS_BASETYPE` to our class flag definition::
.tp_flags = Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE,
-We rename :c:func:`PyInit_custom` to :c:func:`PyInit_custom2`, update the
+We rename :c:func:`!PyInit_custom` to :c:func:`!PyInit_custom2`, update the
module name in the :c:type:`PyModuleDef` struct, and update the full class
name in the :c:type:`PyTypeObject` struct.
@@ -538,18 +538,18 @@ Finally, we update our :file:`setup.py` file to build the new module:
Providing finer control over data attributes
============================================
-In this section, we'll provide finer control over how the :attr:`first` and
-:attr:`last` attributes are set in the :class:`Custom` example. In the previous
-version of our module, the instance variables :attr:`first` and :attr:`last`
+In this section, we'll provide finer control over how the :attr:`!first` and
+:attr:`!last` attributes are set in the :class:`!Custom` example. In the previous
+version of our module, the instance variables :attr:`!first` and :attr:`!last`
could be set to non-string values or even deleted. We want to make sure that
these attributes always contain strings.
.. literalinclude:: ../includes/custom3.c
-To provide greater control, over the :attr:`first` and :attr:`last` attributes,
+To provide greater control, over the :attr:`!first` and :attr:`!last` attributes,
we'll use custom getter and setter functions. Here are the functions for
-getting and setting the :attr:`first` attribute::
+getting and setting the :attr:`!first` attribute::
static PyObject *
Custom_getfirst(CustomObject *self, void *closure)
@@ -578,13 +578,13 @@ getting and setting the :attr:`first` attribute::
return 0;
}
-The getter function is passed a :class:`Custom` object and a "closure", which is
+The getter function is passed a :class:`!Custom` object and a "closure", which is
a void pointer. In this case, the closure is ignored. (The closure supports an
advanced usage in which definition data is passed to the getter and setter. This
could, for example, be used to allow a single set of getter and setter functions
that decide the attribute to get or set based on data in the closure.)
-The setter function is passed the :class:`Custom` object, the new value, and the
+The setter function is passed the :class:`!Custom` object, the new value, and the
closure. The new value may be ``NULL``, in which case the attribute is being
deleted. In our setter, we raise an error if the attribute is deleted or if its
new value is not a string.
@@ -673,11 +673,11 @@ still has a reference from itself. Its reference count doesn't drop to zero.
Fortunately, Python's cyclic garbage collector will eventually figure out that
the list is garbage and free it.
-In the second version of the :class:`Custom` example, we allowed any kind of
-object to be stored in the :attr:`first` or :attr:`last` attributes [#]_.
+In the second version of the :class:`!Custom` example, we allowed any kind of
+object to be stored in the :attr:`!first` or :attr:`!last` attributes [#]_.
Besides, in the second and third versions, we allowed subclassing
-:class:`Custom`, and subclasses may add arbitrary attributes. For any of
-those two reasons, :class:`Custom` objects can participate in cycles:
+:class:`!Custom`, and subclasses may add arbitrary attributes. For any of
+those two reasons, :class:`!Custom` objects can participate in cycles:
.. code-block:: pycon
@@ -687,8 +687,8 @@ those two reasons, :class:`Custom` objects can participate in cycles:
>>> n = Derived()
>>> n.some_attribute = n
-To allow a :class:`Custom` instance participating in a reference cycle to
-be properly detected and collected by the cyclic GC, our :class:`Custom` type
+To allow a :class:`!Custom` instance participating in a reference cycle to
+be properly detected and collected by the cyclic GC, our :class:`!Custom` type
needs to fill two additional slots and to enable a flag that enables these slots:
.. literalinclude:: ../includes/custom4.c
@@ -715,8 +715,8 @@ participate in cycles::
}
For each subobject that can participate in cycles, we need to call the
-:c:func:`visit` function, which is passed to the traversal method. The
-:c:func:`visit` function takes as arguments the subobject and the extra argument
+:c:func:`!visit` function, which is passed to the traversal method. The
+:c:func:`!visit` function takes as arguments the subobject and the extra argument
*arg* passed to the traversal method. It returns an integer value that must be
returned if it is non-zero.
@@ -781,7 +781,7 @@ and ``Custom_clear``::
Py_TYPE(self)->tp_free((PyObject *) self);
}
-Finally, we add the :const:`Py_TPFLAGS_HAVE_GC` flag to the class flags::
+Finally, we add the :c:macro:`Py_TPFLAGS_HAVE_GC` flag to the class flags::
.tp_flags = Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE | Py_TPFLAGS_HAVE_GC,
@@ -798,9 +798,9 @@ types. It is easiest to inherit from the built in types, since an extension can
easily use the :c:type:`PyTypeObject` it needs. It can be difficult to share
these :c:type:`PyTypeObject` structures between extension modules.
-In this example we will create a :class:`SubList` type that inherits from the
+In this example we will create a :class:`!SubList` type that inherits from the
built-in :class:`list` type. The new type will be completely compatible with
-regular lists, but will have an additional :meth:`increment` method that
+regular lists, but will have an additional :meth:`!increment` method that
increases an internal counter:
.. code-block:: pycon
@@ -818,7 +818,7 @@ increases an internal counter:
.. literalinclude:: ../includes/sublist.c
-As you can see, the source code closely resembles the :class:`Custom` examples in
+As you can see, the source code closely resembles the :class:`!Custom` examples in
previous sections. We will break down the main differences between them. ::
typedef struct {
@@ -830,7 +830,7 @@ The primary difference for derived type objects is that the base type's
object structure must be the first value. The base type will already include
the :c:func:`PyObject_HEAD` at the beginning of its structure.
-When a Python object is a :class:`SubList` instance, its ``PyObject *`` pointer
+When a Python object is a :class:`!SubList` instance, its ``PyObject *`` pointer
can be safely cast to both ``PyListObject *`` and ``SubListObject *``::
static int
@@ -842,7 +842,7 @@ can be safely cast to both ``PyListObject *`` and ``SubListObject *``::
return 0;
}
-We see above how to call through to the :attr:`__init__` method of the base
+We see above how to call through to the :meth:`~object.__init__` method of the base
type.
This pattern is important when writing a type with custom
@@ -886,7 +886,7 @@ slot with :c:func:`PyType_GenericNew` -- the allocation function from the base
type will be inherited.
After that, calling :c:func:`PyType_Ready` and adding the type object to the
-module is the same as with the basic :class:`Custom` examples.
+module is the same as with the basic :class:`!Custom` examples.
.. rubric:: Footnotes
diff --git a/Doc/extending/windows.rst b/Doc/extending/windows.rst
index c7b92c6ea24ca8..6e17225d08f691 100644
--- a/Doc/extending/windows.rst
+++ b/Doc/extending/windows.rst
@@ -106,8 +106,7 @@ Using DLLs in Practice
Windows Python is built in Microsoft Visual C++; using other compilers may or
-may not work (though Borland seems to). The rest of this section is MSVC++
-specific.
+may not work. The rest of this section is MSVC++ specific.
When creating DLLs in Windows, you must pass :file:`pythonXY.lib` to the linker.
To build two DLLs, spam and ni (which uses C functions found in spam), you could
@@ -133,5 +132,4 @@ modules (including Python) to be able to see your identifiers, you have to say
Developer Studio will throw in a lot of import libraries that you do not really
need, adding about 100K to your executable. To get rid of them, use the Project
Settings dialog, Link tab, to specify *ignore default libraries*. Add the
-correct :file:`msvcrtxx.lib` to the list of libraries.
-
+correct :file:`msvcrt{xx}.lib` to the list of libraries.
diff --git a/Doc/faq/design.rst b/Doc/faq/design.rst
index ff83a1b8134b77..d0c136deabad76 100644
--- a/Doc/faq/design.rst
+++ b/Doc/faq/design.rst
@@ -155,7 +155,7 @@ Why can't I use an assignment in an expression?
Starting in Python 3.8, you can!
-Assignment expressions using the walrus operator `:=` assign a variable in an
+Assignment expressions using the walrus operator ``:=`` assign a variable in an
expression::
while chunk := fp.read(200):
@@ -313,7 +313,7 @@ you're too lazy to define a function.
Functions are already first class objects in Python, and can be declared in a
local scope. Therefore the only advantage of using a lambda instead of a
-locally-defined function is that you don't need to invent a name for the
+locally defined function is that you don't need to invent a name for the
function -- but that's just a local variable to which the function object (which
is exactly the same type of object that a lambda expression yields) is assigned!
@@ -321,11 +321,10 @@ is exactly the same type of object that a lambda expression yields) is assigned!
Can Python be compiled to machine code, C or some other language?
-----------------------------------------------------------------
-`Cython `_ compiles a modified version of Python with
-optional annotations into C extensions. `Nuitka `_ is
+`Cython `_ compiles a modified version of Python with
+optional annotations into C extensions. `Nuitka `_ is
an up-and-coming compiler of Python into C++ code, aiming to support the full
-Python language. For compiling to Java you can consider
-`VOC `_.
+Python language.
How does Python manage memory?
@@ -339,8 +338,8 @@ cycles and deletes the objects involved. The :mod:`gc` module provides functions
to perform a garbage collection, obtain debugging statistics, and tune the
collector's parameters.
-Other implementations (such as `Jython `_ or
-`PyPy `_), however, can rely on a different mechanism
+Other implementations (such as `Jython `_ or
+`PyPy `_), however, can rely on a different mechanism
such as a full-blown garbage collector. This difference can cause some
subtle porting problems if your Python code depends on the behavior of the
reference counting implementation.
@@ -450,7 +449,7 @@ on the key and a per-process seed; for example, "Python" could hash to
to 1142331976. The hash code is then used to calculate a location in an
internal array where the value will be stored. Assuming that you're storing
keys that all have different hash values, this means that dictionaries take
-constant time -- O(1), in Big-O notation -- to retrieve a key.
+constant time -- *O*\ (1), in Big-O notation -- to retrieve a key.
Why must dictionary keys be immutable?
@@ -582,9 +581,9 @@ exhaustive test suites that exercise every line of code in a module.
An appropriate testing discipline can help build large complex applications in
Python as well as having interface specifications would. In fact, it can be
better because an interface specification cannot test certain properties of a
-program. For example, the :meth:`append` method is expected to add new elements
+program. For example, the :meth:`!list.append` method is expected to add new elements
to the end of some internal list; an interface specification cannot test that
-your :meth:`append` implementation will actually do this correctly, but it's
+your :meth:`!list.append` implementation will actually do this correctly, but it's
trivial to check this property in a test suite.
Writing test suites is very helpful, and you might want to design your code to
diff --git a/Doc/faq/extending.rst b/Doc/faq/extending.rst
index 1d2aca6f4c8d97..2a8b976925d042 100644
--- a/Doc/faq/extending.rst
+++ b/Doc/faq/extending.rst
@@ -41,18 +41,18 @@ on what you're trying to do.
.. XXX make sure these all work
-`Cython `_ and its relative `Pyrex
-`_ are compilers
+`Cython `_ and its relative `Pyrex
+`_ are compilers
that accept a slightly modified form of Python and generate the corresponding
C code. Cython and Pyrex make it possible to write an extension without having
to learn Python's C API.
If you need to interface to some C or C++ library for which no Python extension
currently exists, you can try wrapping the library's data types and functions
-with a tool such as `SWIG `_. `SIP
+with a tool such as `SWIG `_. `SIP
`__, `CXX
-`_ `Boost
-`_, or `Weave
+`_ `Boost
+`_, or `Weave
`_ are also
alternatives for wrapping C++ libraries.
@@ -81,13 +81,13 @@ How do I extract C values from a Python object?
That depends on the object's type. If it's a tuple, :c:func:`PyTuple_Size`
returns its length and :c:func:`PyTuple_GetItem` returns the item at a specified
-index. Lists have similar functions, :c:func:`PyListSize` and
+index. Lists have similar functions, :c:func:`PyList_Size` and
:c:func:`PyList_GetItem`.
For bytes, :c:func:`PyBytes_Size` returns its length and
:c:func:`PyBytes_AsStringAndSize` provides a pointer to its value and its
length. Note that Python bytes objects may contain null bytes so C's
-:c:func:`strlen` should not be used.
+:c:func:`!strlen` should not be used.
To test the type of an object, first make sure it isn't ``NULL``, and then use
:c:func:`PyBytes_Check`, :c:func:`PyTuple_Check`, :c:func:`PyList_Check`, etc.
@@ -286,6 +286,6 @@ Can I create an object class with some methods implemented in C and others in Py
Yes, you can inherit from built-in classes such as :class:`int`, :class:`list`,
:class:`dict`, etc.
-The Boost Python Library (BPL, http://www.boost.org/libs/python/doc/index.html)
+The Boost Python Library (BPL, https://www.boost.org/libs/python/doc/index.html)
provides a way of doing this from C++ (i.e. you can inherit from an extension
class written in C++ using the BPL).
diff --git a/Doc/faq/general.rst b/Doc/faq/general.rst
index bc4130aaa45c89..8727332594bda6 100644
--- a/Doc/faq/general.rst
+++ b/Doc/faq/general.rst
@@ -54,8 +54,8 @@ commercial use, to sell copies of Python in source or binary form (modified or
unmodified), or to sell products that incorporate Python in some form. We would
still like to know about all commercial use of Python, of course.
-See `the PSF license page `_ to find further
-explanations and a link to the full text of the license.
+See `the license page `_ to find further
+explanations and the full text of the PSF License.
The Python logo is trademarked, and in certain cases permission is required to
use it. Consult `the Trademark Usage Policy
@@ -113,8 +113,8 @@ to many different classes of problems.
The language comes with a large standard library that covers areas such as
string processing (regular expressions, Unicode, calculating differences between
-files), internet protocols (HTTP, FTP, SMTP, XML-RPC, POP, IMAP, CGI
-programming), software engineering (unit testing, logging, profiling, parsing
+files), internet protocols (HTTP, FTP, SMTP, XML-RPC, POP, IMAP),
+software engineering (unit testing, logging, profiling, parsing
Python code), and operating system interfaces (system calls, filesystems, TCP/IP
sockets). Look at the table of contents for :ref:`library-index` to get an idea
of what's available. A wide variety of third-party extensions are also
@@ -125,13 +125,17 @@ find packages of interest to you.
How does the Python version numbering scheme work?
--------------------------------------------------
-Python versions are numbered A.B.C or A.B. A is the major version number -- it
-is only incremented for really major changes in the language. B is the minor
-version number, incremented for less earth-shattering changes. C is the
-micro-level -- it is incremented for each bugfix release. See :pep:`6` for more
-information about bugfix releases.
+Python versions are numbered "A.B.C" or "A.B":
-Not all releases are bugfix releases. In the run-up to a new major release, a
+* *A* is the major version number -- it is only incremented for really major
+ changes in the language.
+* *B* is the minor version number -- it is incremented for less earth-shattering
+ changes.
+* *C* is the micro version number -- it is incremented for each bugfix release.
+
+See :pep:`6` for more information about bugfix releases.
+
+Not all releases are bugfix releases. In the run-up to a new feature release, a
series of development releases are made, denoted as alpha, beta, or release
candidate. Alphas are early releases in which interfaces aren't yet finalized;
it's not unexpected to see an interface change between two alpha releases.
@@ -139,12 +143,14 @@ Betas are more stable, preserving existing interfaces but possibly adding new
modules, and release candidates are frozen, making no changes except as needed
to fix critical bugs.
-Alpha, beta and release candidate versions have an additional suffix. The
-suffix for an alpha version is "aN" for some small number N, the suffix for a
-beta version is "bN" for some small number N, and the suffix for a release
-candidate version is "rcN" for some small number N. In other words, all versions
-labeled 2.0aN precede the versions labeled 2.0bN, which precede versions labeled
-2.0rcN, and *those* precede 2.0.
+Alpha, beta and release candidate versions have an additional suffix:
+
+* The suffix for an alpha version is "aN" for some small number *N*.
+* The suffix for a beta version is "bN" for some small number *N*.
+* The suffix for a release candidate version is "rcN" for some small number *N*.
+
+In other words, all versions labeled *2.0aN* precede the versions labeled
+*2.0bN*, which precede versions labeled *2.0rcN*, and *those* precede 2.0.
You may also find version numbers with a "+" suffix, e.g. "2.2+". These are
unreleased versions, built directly from the CPython development repository. In
@@ -182,7 +188,7 @@ at https://docs.python.org/3/. PDF, plain text, and downloadable HTML versions
also available at https://docs.python.org/3/download.html.
The documentation is written in reStructuredText and processed by `the Sphinx
-documentation tool `__. The reStructuredText source for
+documentation tool `__. The reStructuredText source for
the documentation is part of the Python source distribution.
@@ -209,7 +215,7 @@ every day, and Usenet readers are often more able to cope with this volume.
Announcements of new software releases and events can be found in
comp.lang.python.announce, a low-traffic moderated list that receives about five
postings per day. It's available as `the python-announce mailing list
-`_.
+`_.
More info about other mailing lists and newsgroups
can be found at https://www.python.org/community/lists/.
@@ -242,8 +248,8 @@ Are there any published articles about Python that I can reference?
It's probably best to cite your favorite book about Python.
-The very first article about Python was written in 1991 and is now quite
-outdated.
+The `very first article `_ about Python was
+written in 1991 and is now quite outdated.
Guido van Rossum and Jelke de Boer, "Interactively Testing Remote Servers
Using the Python Programming Language", CWI Quarterly, Volume 4, Issue 4
@@ -264,7 +270,7 @@ Where in the world is www.python.org located?
---------------------------------------------
The Python project's infrastructure is located all over the world and is managed
-by the Python Infrastructure Team. Details `here `__.
+by the Python Infrastructure Team. Details `here `__.
Why is it called Python?
@@ -291,9 +297,9 @@ How stable is Python?
Very stable. New, stable releases have been coming out roughly every 6 to 18
months since 1991, and this seems likely to continue. As of version 3.9,
-Python will have a major new release every 12 months (:pep:`602`).
+Python will have a new feature release every 12 months (:pep:`602`).
-The developers issue "bugfix" releases of older versions, so the stability of
+The developers issue bugfix releases of older versions, so the stability of
existing releases gradually improves. Bugfix releases, indicated by a third
component of the version number (e.g. 3.5.3, 3.6.2), are managed for stability;
only fixes for known problems are included in a bugfix release, and it's
@@ -329,8 +335,8 @@ Consulting the proceedings for `past Python conferences
different companies and organizations.
High-profile Python projects include `the Mailman mailing list manager
-`_ and `the Zope application server
-`_. Several Linux distributions, most notably `Red Hat
+`_ and `the Zope application server
+`_. Several Linux distributions, most notably `Red Hat
`_, have written part or all of their installer and
system administration software in Python. Companies that use Python internally
include Google, Yahoo, and Lucasfilm Ltd.
@@ -346,7 +352,7 @@ titled "Python X.Y Release Schedule", where X.Y is a version that hasn't been
publicly released yet.
New development is discussed on `the python-dev mailing list
-`_.
+`_.
Is it reasonable to propose incompatible changes to Python?
@@ -429,7 +435,7 @@ With the interpreter, documentation is never far from the student as they are
programming.
There are also good IDEs for Python. IDLE is a cross-platform IDE for Python
-that is written in Python using Tkinter. PythonWin is a Windows-specific IDE.
+that is written in Python using Tkinter.
Emacs users will be happy to know that there is a very good Python mode for
Emacs. All of these programming environments provide syntax highlighting,
auto-indenting, and access to the interactive interpreter while coding. Consult
diff --git a/Doc/faq/gui.rst b/Doc/faq/gui.rst
index 86c56d957cdfec..77c0a27a10c9a3 100644
--- a/Doc/faq/gui.rst
+++ b/Doc/faq/gui.rst
@@ -43,13 +43,13 @@ applications, the applications will not be truly stand-alone, as the application
will still need the Tcl and Tk libraries.
One solution is to ship the application with the Tcl and Tk libraries, and point
-to them at run-time using the :envvar:`TCL_LIBRARY` and :envvar:`TK_LIBRARY`
+to them at run-time using the :envvar:`!TCL_LIBRARY` and :envvar:`!TK_LIBRARY`
environment variables.
To get truly stand-alone applications, the Tcl scripts that form the library
have to be integrated into the application as well. One tool supporting that is
SAM (stand-alone modules), which is part of the Tix distribution
-(http://tix.sourceforge.net/).
+(https://tix.sourceforge.net/).
Build Tix with SAM enabled, perform the appropriate call to
:c:func:`Tclsam_init`, etc. inside Python's
@@ -62,7 +62,7 @@ Can I have Tk events handled while waiting for I/O?
On platforms other than Windows, yes, and you don't even
need threads! But you'll have to restructure your I/O
-code a bit. Tk has the equivalent of Xt's :c:func:`XtAddInput()` call, which allows you
+code a bit. Tk has the equivalent of Xt's :c:func:`!XtAddInput` call, which allows you
to register a callback function which will be called from the Tk mainloop when
I/O is possible on a file descriptor. See :ref:`tkinter-file-handlers`.
@@ -70,8 +70,9 @@ I/O is possible on a file descriptor. See :ref:`tkinter-file-handlers`.
I can't get key bindings to work in Tkinter: why?
-------------------------------------------------
-An often-heard complaint is that event handlers bound to events with the
-:meth:`bind` method don't get handled even when the appropriate key is pressed.
+An often-heard complaint is that event handlers :ref:`bound `
+to events with the :meth:`!bind` method
+don't get handled even when the appropriate key is pressed.
The most common cause is that the widget to which the binding applies doesn't
have "keyboard focus". Check out the Tk documentation for the focus command.
diff --git a/Doc/faq/library.rst b/Doc/faq/library.rst
index b9e541c150dc43..c69910718f0c92 100644
--- a/Doc/faq/library.rst
+++ b/Doc/faq/library.rst
@@ -111,7 +111,7 @@ Is there an equivalent to C's onexit() in Python?
-------------------------------------------------
The :mod:`atexit` module provides a register function that is similar to C's
-:c:func:`onexit`.
+:c:func:`!onexit`.
Why don't my signal handlers work?
@@ -180,8 +180,8 @@ How do I create documentation from doc strings?
The :mod:`pydoc` module can create HTML from the doc strings in your Python
source code. An alternative for creating API documentation purely from
-docstrings is `epydoc `_. `Sphinx
-`_ can also include docstring content.
+docstrings is `epydoc `_. `Sphinx
+`_ can also include docstring content.
How do I get a single keypress at a time?
@@ -397,7 +397,7 @@ These aren't::
D[x] = D[x] + 1
Operations that replace other objects may invoke those other objects'
-:meth:`__del__` method when their reference count reaches zero, and that can
+:meth:`~object.__del__` method when their reference count reaches zero, and that can
affect things. This is especially true for the mass updates to dictionaries and
lists. When in doubt, use a mutex!
@@ -483,8 +483,14 @@ including :func:`~shutil.copyfile`, :func:`~shutil.copytree`, and
How do I copy a file?
---------------------
-The :mod:`shutil` module contains a :func:`~shutil.copyfile` function. Note
-that on MacOS 9 it doesn't copy the resource fork and Finder info.
+The :mod:`shutil` module contains a :func:`~shutil.copyfile` function.
+Note that on Windows NTFS volumes, it does not copy
+`alternate data streams
+`_
+nor `resource forks `__
+on macOS HFS+ volumes, though both are now rarely used.
+It also doesn't copy file permissions and metadata, though using
+:func:`shutil.copy2` instead will preserve most (though not all) of it.
How do I read (or write) binary data?
@@ -560,7 +566,7 @@ use ``p.read(n)``.
Note on a bug in popen2: unless your program calls ``wait()`` or
``waitpid()``, finished child processes are never removed, and eventually
calls to popen2 will fail because of a limit on the number of child
- processes. Calling :func:`os.waitpid` with the :data:`os.WNOHANG` option can
+ processes. Calling :func:`os.waitpid` with the :const:`os.WNOHANG` option can
prevent this; a good place to insert such a call would be before calling
``popen2`` again.
@@ -603,7 +609,7 @@ use ``p.read(n)``.
substituted for standard input and output. You will have to use pseudo ttys
("ptys") instead of pipes. Or you can use a Python interface to Don Libes'
"expect" library. A Python extension that interfaces to expect is called
- "expy" and available from http://expectpy.sourceforge.net. A pure Python
+ "expy" and available from https://expectpy.sourceforge.net. A pure Python
solution that works like expect is `pexpect
`_.
@@ -664,7 +670,7 @@ A summary of available frameworks is maintained by Paul Boddie at
https://wiki.python.org/moin/WebProgramming\ .
Cameron Laird maintains a useful set of pages about Python web technologies at
-http://phaseit.net/claird/comp.lang.python/web_python.
+https://web.archive.org/web/20210224183619/http://phaseit.net/claird/comp.lang.python/web_python.
How can I mimic CGI form submission (METHOD=POST)?
@@ -759,14 +765,17 @@ The :mod:`select` module is commonly used to help with asynchronous I/O on
sockets.
To prevent the TCP connect from blocking, you can set the socket to non-blocking
-mode. Then when you do the :meth:`socket.connect`, you will either connect immediately
+mode. Then when you do the :meth:`~socket.socket.connect`,
+you will either connect immediately
(unlikely) or get an exception that contains the error number as ``.errno``.
``errno.EINPROGRESS`` indicates that the connection is in progress, but hasn't
finished yet. Different OSes will return different values, so you're going to
have to check what's returned on your system.
-You can use the :meth:`socket.connect_ex` method to avoid creating an exception. It will
-just return the errno value. To poll, you can call :meth:`socket.connect_ex` again later
+You can use the :meth:`~socket.socket.connect_ex` method
+to avoid creating an exception.
+It will just return the errno value.
+To poll, you can call :meth:`~socket.socket.connect_ex` again later
-- ``0`` or ``errno.EISCONN`` indicate that you're connected -- or you can pass this
socket to :meth:`select.select` to check if it's writable.
@@ -774,7 +783,7 @@ socket to :meth:`select.select` to check if it's writable.
The :mod:`asyncio` module provides a general purpose single-threaded and
concurrent asynchronous library, which can be used for writing non-blocking
network code.
- The third-party `Twisted `_ library is
+ The third-party `Twisted `_ library is
a popular and feature-rich alternative.
diff --git a/Doc/faq/programming.rst b/Doc/faq/programming.rst
index f87eaff9531fce..f43f69b8a1ea91 100644
--- a/Doc/faq/programming.rst
+++ b/Doc/faq/programming.rst
@@ -25,8 +25,9 @@ Reference Manual `. You can also write your own debugger by using the code
for pdb as an example.
The IDLE interactive development environment, which is part of the standard
-Python distribution (normally available as Tools/scripts/idle), includes a
-graphical debugger.
+Python distribution (normally available as
+`Tools/scripts/idle3 `_),
+includes a graphical debugger.
PythonWin is a Python IDE that includes a GUI debugger based on pdb. The
PythonWin debugger colors breakpoints and has quite a few cool features such as
@@ -35,7 +36,7 @@ debugging non-PythonWin programs. PythonWin is available as part of
as a part of the
`ActivePython `_ distribution.
-`Eric `_ is an IDE built on PyQt
+`Eric `_ is an IDE built on PyQt
and the Scintilla editing component.
`trepan3k `_ is a gdb-like debugger.
@@ -56,11 +57,11 @@ Are there tools to help find bugs or perform static analysis?
Yes.
-`Pylint `_ and
+`Pylint `_ and
`Pyflakes `_ do basic checking that will
help you catch bugs sooner.
-Static type checkers such as `Mypy `_,
+Static type checkers such as `Mypy `_,
`Pyre `_, and
`Pytype `_ can check type hints in Python
source code.
@@ -78,7 +79,8 @@ set of modules required by a program and bind these modules together with a
Python binary to produce a single executable.
One is to use the freeze tool, which is included in the Python source tree as
-``Tools/freeze``. It converts Python byte code to C arrays; with a C compiler you can
+`Tools/freeze `_.
+It converts Python byte code to C arrays; with a C compiler you can
embed all your modules into a new program, which is then linked with the
standard Python modules.
@@ -95,11 +97,11 @@ The following packages can help with the creation of console and GUI
executables:
* `Nuitka `_ (Cross-platform)
-* `PyInstaller `_ (Cross-platform)
+* `PyInstaller `_ (Cross-platform)
* `PyOxidizer `_ (Cross-platform)
* `cx_Freeze `_ (Cross-platform)
* `py2app `_ (macOS only)
-* `py2exe `_ (Windows only)
+* `py2exe `_ (Windows only)
Are there coding standards or a style guide for Python programs?
----------------------------------------------------------------
@@ -111,10 +113,12 @@ Yes. The coding style required for standard library modules is documented as
Core Language
=============
+.. _faq-unboundlocalerror:
+
Why am I getting an UnboundLocalError when the variable has a value?
--------------------------------------------------------------------
-It can be a surprise to get the UnboundLocalError in previously working
+It can be a surprise to get the :exc:`UnboundLocalError` in previously working
code when it is modified by adding an assignment statement somewhere in
the body of a function.
@@ -123,6 +127,7 @@ This code:
>>> x = 10
>>> def bar():
... print(x)
+ ...
>>> bar()
10
@@ -133,7 +138,7 @@ works, but this code:
... print(x)
... x += 1
-results in an UnboundLocalError:
+results in an :exc:`!UnboundLocalError`:
>>> foo()
Traceback (most recent call last):
@@ -155,6 +160,7 @@ global:
... global x
... print(x)
... x += 1
+ ...
>>> foobar()
10
@@ -176,6 +182,7 @@ keyword:
... x += 1
... bar()
... print(x)
+ ...
>>> foo()
10
11
@@ -273,7 +280,7 @@ main.py::
import mod
print(config.x)
-Note that using a module is also the basis for implementing the Singleton design
+Note that using a module is also the basis for implementing the singleton design
pattern, for the same reason.
@@ -291,10 +298,10 @@ using multiple imports per line uses less screen space.
It's good practice if you import modules in the following order:
-1. standard library modules -- e.g. ``sys``, ``os``, ``getopt``, ``re``
+1. standard library modules -- e.g. :mod:`sys`, :mod:`os`, :mod:`argparse`, :mod:`re`
2. third-party library modules (anything installed in Python's site-packages
- directory) -- e.g. mx.DateTime, ZODB, PIL.Image, etc.
-3. locally-developed modules
+ directory) -- e.g. :mod:`!dateutil`, :mod:`!requests`, :mod:`!PIL.Image`
+3. locally developed modules
It is sometimes necessary to move imports to a function or class to avoid
problems with circular imports. Gordon McMillan says:
@@ -409,8 +416,9 @@ What is the difference between arguments and parameters?
:term:`Parameters ` are defined by the names that appear in a
function definition, whereas :term:`arguments ` are the values
-actually passed to a function when calling it. Parameters define what types of
-arguments a function can accept. For example, given the function definition::
+actually passed to a function when calling it. Parameters define what
+:term:`kind of arguments ` a function can accept. For
+example, given the function definition::
def func(foo, bar=None, **kwargs):
pass
@@ -446,7 +454,7 @@ There are two factors that produce this result:
(the list), and both ``x`` and ``y`` refer to it.
2) Lists are :term:`mutable`, which means that you can change their content.
-After the call to :meth:`~list.append`, the content of the mutable object has
+After the call to :meth:`!append`, the content of the mutable object has
changed from ``[]`` to ``[10]``. Since both the variables refer to the same
object, using either name accesses the modified value ``[10]``.
@@ -470,7 +478,7 @@ object ``x`` refers to). After this assignment we have two objects (the ints
Some operations (for example ``y.append(10)`` and ``y.sort()``) mutate the
object, whereas superficially similar operations (for example ``y = y + [10]``
-and ``sorted(y)``) create a new object. In general in Python (and in all cases
+and :func:`sorted(y) `) create a new object. In general in Python (and in all cases
in the standard library) a method that mutates an object will return ``None``
to help avoid getting the two types of operations confused. So if you
mistakenly write ``y.sort()`` thinking it will give you a sorted copy of ``y``,
@@ -643,7 +651,7 @@ Sequences can be copied by slicing::
How can I find the methods or attributes of an object?
------------------------------------------------------
-For an instance x of a user-defined class, ``dir(x)`` returns an alphabetized
+For an instance ``x`` of a user-defined class, :func:`dir(x) ` returns an alphabetized
list of the names containing the instance attributes and methods and attributes
defined by its class.
@@ -668,9 +676,9 @@ callable. Consider the following code::
<__main__.A object at 0x16D07CC>
Arguably the class has a name: even though it is bound to two names and invoked
-through the name B the created instance is still reported as an instance of
-class A. However, it is impossible to say whether the instance's name is a or
-b, since both names are bound to the same value.
+through the name ``B`` the created instance is still reported as an instance of
+class ``A``. However, it is impossible to say whether the instance's name is ``a`` or
+``b``, since both names are bound to the same value.
Generally speaking it should not be necessary for your code to "know the names"
of particular values. Unless you are deliberately writing introspective
@@ -734,7 +742,7 @@ Is it possible to write obfuscated one-liners in Python?
--------------------------------------------------------
Yes. Usually this is done by nesting :keyword:`lambda` within
-:keyword:`!lambda`. See the following three examples, due to Ulf Bartelt::
+:keyword:`!lambda`. See the following three examples, slightly adapted from Ulf Bartelt::
from functools import reduce
@@ -747,7 +755,7 @@ Yes. Usually this is done by nesting :keyword:`lambda` within
f(x,f), range(10))))
# Mandelbrot set
- print((lambda Ru,Ro,Iu,Io,IM,Sx,Sy:reduce(lambda x,y:x+y,map(lambda y,
+ print((lambda Ru,Ro,Iu,Io,IM,Sx,Sy:reduce(lambda x,y:x+'\n'+y,map(lambda y,
Iu=Iu,Io=Io,Ru=Ru,Ro=Ro,Sy=Sy,L=lambda yc,Iu=Iu,Io=Io,Ru=Ru,Ro=Ro,i=IM,
Sx=Sx,Sy=Sy:reduce(lambda x,y:x+y,map(lambda x,xc=Ru,yc=yc,Ru=Ru,Ro=Ro,
i=i,Sx=Sx,F=lambda xc,yc,x,y,k,f=lambda xc,yc,x,y,k,f:(k<=0)or (x*x+y*y
@@ -770,7 +778,7 @@ What does the slash(/) in the parameter list of a function mean?
A slash in the argument list of a function denotes that the parameters prior to
it are positional-only. Positional-only parameters are the ones without an
-externally-usable name. Upon calling a function that accepts positional-only
+externally usable name. Upon calling a function that accepts positional-only
parameters, arguments are mapped to parameters based solely on their position.
For example, :func:`divmod` is a function that accepts positional-only
parameters. Its documentation looks like this::
@@ -840,7 +848,7 @@ How do I get int literal attribute instead of SyntaxError?
----------------------------------------------------------
Trying to lookup an ``int`` literal attribute in the normal manner gives
-a syntax error because the period is seen as a decimal point::
+a :exc:`SyntaxError` because the period is seen as a decimal point::
>>> 1.__class__
File "", line 1
@@ -886,7 +894,7 @@ leading '0' in a decimal number (except '0').
How do I convert a number to a string?
--------------------------------------
-To convert, e.g., the number 144 to the string '144', use the built-in type
+To convert, e.g., the number ``144`` to the string ``'144'``, use the built-in type
constructor :func:`str`. If you want a hexadecimal or octal representation, use
the built-in functions :func:`hex` or :func:`oct`. For fancy formatting, see
the :ref:`f-strings` and :ref:`formatstrings` sections,
@@ -1005,11 +1013,11 @@ Not as such.
For simple input parsing, the easiest approach is usually to split the line into
whitespace-delimited words using the :meth:`~str.split` method of string objects
and then convert decimal strings to numeric values using :func:`int` or
-:func:`float`. ``split()`` supports an optional "sep" parameter which is useful
+:func:`float`. :meth:`!split()` supports an optional "sep" parameter which is useful
if the line uses something other than whitespace as a separator.
For more complicated input parsing, regular expressions are more powerful
-than C's :c:func:`sscanf` and better suited for the task.
+than C's ``sscanf`` and better suited for the task.
What does 'UnicodeDecodeError' or 'UnicodeEncodeError' error mean?
@@ -1018,6 +1026,46 @@ What does 'UnicodeDecodeError' or 'UnicodeEncodeError' error mean?
See the :ref:`unicode-howto`.
+.. _faq-programming-raw-string-backslash:
+
+Can I end a raw string with an odd number of backslashes?
+---------------------------------------------------------
+
+A raw string ending with an odd number of backslashes will escape the string's quote::
+
+ >>> r'C:\this\will\not\work\'
+ File "", line 1
+ r'C:\this\will\not\work\'
+ ^
+ SyntaxError: unterminated string literal (detected at line 1)
+
+There are several workarounds for this. One is to use regular strings and double
+the backslashes::
+
+ >>> 'C:\\this\\will\\work\\'
+ 'C:\\this\\will\\work\\'
+
+Another is to concatenate a regular string containing an escaped backslash to the
+raw string::
+
+ >>> r'C:\this\will\work' '\\'
+ 'C:\\this\\will\\work\\'
+
+It is also possible to use :func:`os.path.join` to append a backslash on Windows::
+
+ >>> os.path.join(r'C:\this\will\work', '')
+ 'C:\\this\\will\\work\\'
+
+Note that while a backslash will "escape" a quote for the purposes of
+determining where the raw string ends, no escaping occurs when interpreting the
+value of the raw string. That is, the backslash remains present in the value of
+the raw string::
+
+ >>> r'backslash\'preserved'
+ "backslash\\'preserved"
+
+Also see the specification in the :ref:`language reference `.
+
Performance
===========
@@ -1065,7 +1113,7 @@ performance levels:
detrimental to readability).
If you have reached the limit of what pure Python can allow, there are tools
-to take you further away. For example, `Cython `_ can
+to take you further away. For example, `Cython `_ can
compile a slightly modified version of Python code into a C extension, and
can be used on many different platforms. Cython can take advantage of
compilation (and optional type annotations) to make your code significantly
@@ -1205,15 +1253,16 @@ difference is that a Python list can contain objects of many different types.
The ``array`` module also provides methods for creating arrays of fixed types
with compact representations, but they are slower to index than lists. Also
-note that NumPy and other third party packages define array-like structures with
+note that `NumPy `_
+and other third party packages define array-like structures with
various characteristics as well.
-To get Lisp-style linked lists, you can emulate cons cells using tuples::
+To get Lisp-style linked lists, you can emulate *cons cells* using tuples::
lisp_list = ("like", ("this", ("example", None) ) )
If mutability is desired, you could use lists instead of tuples. Here the
-analogue of lisp car is ``lisp_list[0]`` and the analogue of cdr is
+analogue of a Lisp *car* is ``lisp_list[0]`` and the analogue of *cdr* is
``lisp_list[1]``. Only do this if you're sure you really need to, because it's
usually a lot slower than using Python lists.
@@ -1269,16 +1318,28 @@ use a list comprehension::
A = [[None] * w for i in range(h)]
Or, you can use an extension that provides a matrix datatype; `NumPy
-`_ is the best known.
+`_ is the best known.
-How do I apply a method to a sequence of objects?
--------------------------------------------------
+How do I apply a method or function to a sequence of objects?
+-------------------------------------------------------------
-Use a list comprehension::
+To call a method or function and accumulate the return values is a list,
+a :term:`list comprehension` is an elegant solution::
result = [obj.method() for obj in mylist]
+ result = [function(obj) for obj in mylist]
+
+To just run the method or function without saving the return values,
+a plain :keyword:`for` loop will suffice::
+
+ for obj in mylist:
+ obj.method()
+
+ for obj in mylist:
+ function(obj)
+
.. _faq-augmented-assignment-tuple-error:
Why does a_tuple[i] += ['item'] raise an exception when the addition works?
@@ -1333,11 +1394,12 @@ that even though there was an error, the append worked::
['foo', 'item']
To see why this happens, you need to know that (a) if an object implements an
-``__iadd__`` magic method, it gets called when the ``+=`` augmented assignment
+:meth:`~object.__iadd__` magic method, it gets called when the ``+=`` augmented
+assignment
is executed, and its return value is what gets used in the assignment statement;
-and (b) for lists, ``__iadd__`` is equivalent to calling ``extend`` on the list
+and (b) for lists, :meth:`!__iadd__` is equivalent to calling :meth:`!extend` on the list
and returning the list. That's why we say that for lists, ``+=`` is a
-"shorthand" for ``list.extend``::
+"shorthand" for :meth:`!list.extend`::
>>> a_list = []
>>> a_list += [1]
@@ -1362,7 +1424,7 @@ Thus, in our tuple example what is happening is equivalent to::
...
TypeError: 'tuple' object does not support item assignment
-The ``__iadd__`` succeeds, and thus the list is extended, but even though
+The :meth:`!__iadd__` succeeds, and thus the list is extended, but even though
``result`` points to the same object that ``a_tuple[0]`` already points to,
that final assignment still results in an error, because tuples are immutable.
@@ -1439,7 +1501,8 @@ See also :ref:`why-self`.
How do I check if an object is an instance of a given class or of a subclass of it?
-----------------------------------------------------------------------------------
-Use the built-in function ``isinstance(obj, cls)``. You can check if an object
+Use the built-in function :func:`isinstance(obj, cls) `. You can
+check if an object
is an instance of any of a number of classes by providing a tuple instead of a
single class, e.g. ``isinstance(obj, (class1, class2, ...))``, and can also
check whether an object is one of Python's built-in types, e.g.
@@ -1536,13 +1599,13 @@ Here the ``UpperOut`` class redefines the ``write()`` method to convert the
argument string to uppercase before calling the underlying
``self._outfile.write()`` method. All other methods are delegated to the
underlying ``self._outfile`` object. The delegation is accomplished via the
-``__getattr__`` method; consult :ref:`the language reference `
+:meth:`~object.__getattr__` method; consult :ref:`the language reference `
for more information about controlling attribute access.
Note that for more general cases delegation can get trickier. When attributes
-must be set as well as retrieved, the class must define a :meth:`__setattr__`
+must be set as well as retrieved, the class must define a :meth:`~object.__setattr__`
method too, and it must do so carefully. The basic implementation of
-:meth:`__setattr__` is roughly equivalent to the following::
+:meth:`!__setattr__` is roughly equivalent to the following::
class X:
...
@@ -1550,7 +1613,8 @@ method too, and it must do so carefully. The basic implementation of
self.__dict__[name] = value
...
-Most :meth:`__setattr__` implementations must modify ``self.__dict__`` to store
+Most :meth:`!__setattr__` implementations must modify
+:meth:`self.__dict__ ` to store
local state for self without causing an infinite recursion.
@@ -1688,17 +1752,17 @@ My class defines __del__ but it is not called when I delete the object.
There are several possible reasons for this.
-The del statement does not necessarily call :meth:`__del__` -- it simply
+The :keyword:`del` statement does not necessarily call :meth:`~object.__del__` -- it simply
decrements the object's reference count, and if this reaches zero
-:meth:`__del__` is called.
+:meth:`!__del__` is called.
If your data structures contain circular links (e.g. a tree where each child has
a parent reference and each parent has a list of children) the reference counts
will never go back to zero. Once in a while Python runs an algorithm to detect
such cycles, but the garbage collector might run some time after the last
-reference to your data structure vanishes, so your :meth:`__del__` method may be
+reference to your data structure vanishes, so your :meth:`!__del__` method may be
called at an inconvenient and random time. This is inconvenient if you're trying
-to reproduce a problem. Worse, the order in which object's :meth:`__del__`
+to reproduce a problem. Worse, the order in which object's :meth:`!__del__`
methods are executed is arbitrary. You can run :func:`gc.collect` to force a
collection, but there *are* pathological cases where objects will never be
collected.
@@ -1706,7 +1770,7 @@ collected.
Despite the cycle collector, it's still a good idea to define an explicit
``close()`` method on objects to be called whenever you're done with them. The
``close()`` method can then remove attributes that refer to subobjects. Don't
-call :meth:`__del__` directly -- :meth:`__del__` should call ``close()`` and
+call :meth:`!__del__` directly -- :meth:`!__del__` should call ``close()`` and
``close()`` should make sure that it can be called more than once for the same
object.
@@ -1723,7 +1787,7 @@ and sibling references (if they need them!).
Normally, calling :func:`sys.exc_clear` will take care of this by clearing
the last recorded exception.
-Finally, if your :meth:`__del__` method raises an exception, a warning message
+Finally, if your :meth:`!__del__` method raises an exception, a warning message
is printed to :data:`sys.stderr`.
@@ -1839,7 +1903,7 @@ identity tests. This prevents the code from being confused by objects such as
``float('NaN')`` that are not equal to themselves.
For example, here is the implementation of
-:meth:`collections.abc.Sequence.__contains__`::
+:meth:`!collections.abc.Sequence.__contains__`::
def __contains__(self, value):
for v in self:
@@ -1851,8 +1915,8 @@ For example, here is the implementation of
How can a subclass control what data is stored in an immutable instance?
------------------------------------------------------------------------
-When subclassing an immutable type, override the :meth:`__new__` method
-instead of the :meth:`__init__` method. The latter only runs *after* an
+When subclassing an immutable type, override the :meth:`~object.__new__` method
+instead of the :meth:`~object.__init__` method. The latter only runs *after* an
instance is created, which is too late to alter data in an immutable
instance.
@@ -1896,6 +1960,8 @@ The classes can be used like this:
'blog-why-python-rocks'
+.. _faq-cache-method-calls:
+
How do I cache method calls?
----------------------------
@@ -1913,7 +1979,7 @@ method result will be released right away. The disadvantage is that if
instances accumulate, so too will the accumulated method results. They
can grow without bound.
-The *lru_cache* approach works with methods that have hashable
+The *lru_cache* approach works with methods that have :term:`hashable`
arguments. It creates a reference to the instance unless special
efforts are made to pass in weak references.
@@ -1952,8 +2018,8 @@ can't be made to work because it cannot detect changes to the
attributes.
To make the *lru_cache* approach work when the *station_id* is mutable,
-the class needs to define the *__eq__* and *__hash__* methods so that
-the cache can detect relevant attribute updates::
+the class needs to define the :meth:`~object.__eq__` and :meth:`~object.__hash__`
+methods so that the cache can detect relevant attribute updates::
class Weather:
"Example with a mutable station identifier"
diff --git a/Doc/faq/windows.rst b/Doc/faq/windows.rst
index 6b95819c8ee855..c0c92fdbbc84d1 100644
--- a/Doc/faq/windows.rst
+++ b/Doc/faq/windows.rst
@@ -26,8 +26,8 @@ with running programs from the Windows command line then everything will seem
obvious; otherwise, you might need a little more guidance.
Unless you use some sort of integrated development environment, you will end up
-*typing* Windows commands into what is variously referred to as a "DOS window"
-or "Command prompt window". Usually you can create such a window from your
+*typing* Windows commands into what is referred to as a
+"Command prompt window". Usually you can create such a window from your
search bar by searching for ``cmd``. You should be able to recognize
when you have started such a window because you will see a Windows "command
prompt", which usually looks like this:
@@ -167,7 +167,7 @@ How can I embed Python into a Windows application?
Embedding the Python interpreter in a Windows app can be summarized as follows:
-1. Do _not_ build Python into your .exe file directly. On Windows, Python must
+1. Do **not** build Python into your .exe file directly. On Windows, Python must
be a DLL to handle importing modules that are themselves DLL's. (This is the
first key undocumented fact.) Instead, link to :file:`python{NN}.dll`; it is
typically installed in ``C:\Windows\System``. *NN* is the Python version, a
@@ -186,15 +186,12 @@ Embedding the Python interpreter in a Windows app can be summarized as follows:
by the Windows ``GetProcAddress()`` routine. Macros can make using these
pointers transparent to any C code that calls routines in Python's C API.
- Borland note: convert :file:`python{NN}.lib` to OMF format using Coff2Omf.exe
- first.
-
.. XXX what about static linking?
2. If you use SWIG, it is easy to create a Python "extension module" that will
make the app's data and methods available to Python. SWIG will handle just
about all the grungy details for you. The result is C code that you link
- *into* your .exe file (!) You do _not_ have to create a DLL file, and this
+ *into* your .exe file (!) You do **not** have to create a DLL file, and this
also simplifies linking.
3. SWIG will create an init function (a C function) whose name depends on the
@@ -221,10 +218,10 @@ Embedding the Python interpreter in a Windows app can be summarized as follows:
5. There are two problems with Python's C API which will become apparent if you
use a compiler other than MSVC, the compiler used to build pythonNN.dll.
- Problem 1: The so-called "Very High Level" functions that take FILE *
+ Problem 1: The so-called "Very High Level" functions that take ``FILE *``
arguments will not work in a multi-compiler environment because each
- compiler's notion of a struct FILE will be different. From an implementation
- standpoint these are very _low_ level functions.
+ compiler's notion of a ``struct FILE`` will be different. From an implementation
+ standpoint these are very low level functions.
Problem 2: SWIG generates the following code when generating wrappers to void
functions:
@@ -280,3 +277,10 @@ Use the :mod:`msvcrt` module. This is a standard Windows-specific extension mod
It defines a function ``kbhit()`` which checks whether a keyboard hit is
present, and ``getch()`` which gets one character without echoing it.
+How do I solve the missing api-ms-win-crt-runtime-l1-1-0.dll error?
+-------------------------------------------------------------------
+
+This can occur on Python 3.5 and later when using Windows 8.1 or earlier without all updates having been installed.
+First ensure your operating system is supported and is up to date, and if that does not resolve the issue,
+visit the `Microsoft support page `_
+for guidance on manually installing the C Runtime update.
diff --git a/Doc/glossary.rst b/Doc/glossary.rst
index 75db433abd6007..f520df5de049b3 100644
--- a/Doc/glossary.rst
+++ b/Doc/glossary.rst
@@ -92,8 +92,8 @@ Glossary
asynchronous context manager
An object which controls the environment seen in an
- :keyword:`async with` statement by defining :meth:`__aenter__` and
- :meth:`__aexit__` methods. Introduced by :pep:`492`.
+ :keyword:`async with` statement by defining :meth:`~object.__aenter__` and
+ :meth:`~object.__aexit__` methods. Introduced by :pep:`492`.
asynchronous generator
A function which returns an :term:`asynchronous generator iterator`. It
@@ -113,36 +113,43 @@ Glossary
An object created by a :term:`asynchronous generator` function.
This is an :term:`asynchronous iterator` which when called using the
- :meth:`__anext__` method returns an awaitable object which will execute
+ :meth:`~object.__anext__` method returns an awaitable object which will execute
the body of the asynchronous generator function until the next
:keyword:`yield` expression.
Each :keyword:`yield` temporarily suspends processing, remembering the
location execution state (including local variables and pending
try-statements). When the *asynchronous generator iterator* effectively
- resumes with another awaitable returned by :meth:`__anext__`, it
+ resumes with another awaitable returned by :meth:`~object.__anext__`, it
picks up where it left off. See :pep:`492` and :pep:`525`.
asynchronous iterable
An object, that can be used in an :keyword:`async for` statement.
Must return an :term:`asynchronous iterator` from its
- :meth:`__aiter__` method. Introduced by :pep:`492`.
+ :meth:`~object.__aiter__` method. Introduced by :pep:`492`.
asynchronous iterator
- An object that implements the :meth:`__aiter__` and :meth:`__anext__`
- methods. ``__anext__`` must return an :term:`awaitable` object.
+ An object that implements the :meth:`~object.__aiter__` and :meth:`~object.__anext__`
+ methods. :meth:`~object.__anext__` must return an :term:`awaitable` object.
:keyword:`async for` resolves the awaitables returned by an asynchronous
- iterator's :meth:`__anext__` method until it raises a
+ iterator's :meth:`~object.__anext__` method until it raises a
:exc:`StopAsyncIteration` exception. Introduced by :pep:`492`.
attribute
- A value associated with an object which is referenced by name using
- dotted expressions. For example, if an object *o* has an attribute
+ A value associated with an object which is usually referenced by name
+ using dotted expressions.
+ For example, if an object *o* has an attribute
*a* it would be referenced as *o.a*.
+ It is possible to give an object an attribute whose name is not an
+ identifier as defined by :ref:`identifiers`, for example using
+ :func:`setattr`, if the object allows it.
+ Such an attribute will not be accessible using a dotted expression,
+ and would instead need to be retrieved with :func:`getattr`.
+
awaitable
An object that can be used in an :keyword:`await` expression. Can be
- a :term:`coroutine` or an object with an :meth:`__await__` method.
+ a :term:`coroutine` or an object with an :meth:`~object.__await__` method.
See also :pep:`492`.
BDFL
@@ -153,16 +160,17 @@ Glossary
A :term:`file object` able to read and write
:term:`bytes-like objects `.
Examples of binary files are files opened in binary mode (``'rb'``,
- ``'wb'`` or ``'rb+'``), :data:`sys.stdin.buffer`,
- :data:`sys.stdout.buffer`, and instances of :class:`io.BytesIO` and
- :class:`gzip.GzipFile`.
+ ``'wb'`` or ``'rb+'``), :data:`sys.stdin.buffer `,
+ :data:`sys.stdout.buffer `, and instances of
+ :class:`io.BytesIO` and :class:`gzip.GzipFile`.
See also :term:`text file` for a file object able to read and write
:class:`str` objects.
borrowed reference
- In Python's C API, a borrowed reference is a reference to an object.
- It does not modify the object reference count. It becomes a dangling
+ In Python's C API, a borrowed reference is a reference to an object,
+ where the code using the object does not own the reference.
+ It becomes a dangling
pointer if the object is destroyed. For example, a garbage collection can
remove the last :term:`strong reference` to the object and so destroy it.
@@ -203,6 +211,16 @@ Glossary
A list of bytecode instructions can be found in the documentation for
:ref:`the dis module `.
+ callable
+ A callable is an object that can be called, possibly with a set
+ of arguments (see :term:`argument`), with the following syntax::
+
+ callable(argument1, argument2, argumentN)
+
+ A :term:`function`, and by extension a :term:`method`, is a callable.
+ An instance of a class that implements the :meth:`~object.__call__`
+ method is also a callable.
+
callback
A subroutine function which is passed as an argument to be executed at
some point in the future.
@@ -230,7 +248,7 @@ Glossary
context manager
An object which controls the environment seen in a :keyword:`with`
- statement by defining :meth:`__enter__` and :meth:`__exit__` methods.
+ statement by defining :meth:`~object.__enter__` and :meth:`~object.__exit__` methods.
See :pep:`343`.
context variable
@@ -295,8 +313,9 @@ Glossary
:ref:`class definitions ` for more about decorators.
descriptor
- Any object which defines the methods :meth:`__get__`, :meth:`__set__`, or
- :meth:`__delete__`. When a class attribute is a descriptor, its special
+ Any object which defines the methods :meth:`~object.__get__`,
+ :meth:`~object.__set__`, or :meth:`~object.__delete__`.
+ When a class attribute is a descriptor, its special
binding behavior is triggered upon attribute lookup. Normally, using
*a.b* to get, set or delete an attribute looks up the object named *b* in
the class dictionary for *a*, but if *b* is a descriptor, the respective
@@ -310,7 +329,8 @@ Glossary
dictionary
An associative array, where arbitrary keys are mapped to values. The
- keys can be any object with :meth:`__hash__` and :meth:`__eq__` methods.
+ keys can be any object with :meth:`~object.__hash__` and
+ :meth:`~object.__eq__` methods.
Called a hash in Perl.
dictionary comprehension
@@ -330,7 +350,7 @@ Glossary
docstring
A string literal which appears as the first expression in a class,
function or module. While ignored when the suite is executed, it is
- recognized by the compiler and put into the :attr:`__doc__` attribute
+ recognized by the compiler and put into the :attr:`!__doc__` attribute
of the enclosing class, function or module. Since it is available via
introspection, it is the canonical place for documentation of the
object.
@@ -374,7 +394,7 @@ Glossary
file object
An object exposing a file-oriented API (with methods such as
- :meth:`read()` or :meth:`write()`) to an underlying resource. Depending
+ :meth:`!read` or :meth:`!write`) to an underlying resource. Depending
on the way it was created, a file object can mediate access to a real
on-disk file or to another type of storage or communication device
(for example standard input/output, in-memory buffers, sockets, pipes,
@@ -532,7 +552,7 @@ Glossary
machines.
However, some extension modules, either standard or third-party,
- are designed so as to release the GIL when doing computationally-intensive
+ are designed so as to release the GIL when doing computationally intensive
tasks such as compression or hashing. Also, the GIL is always released
when doing I/O.
@@ -550,8 +570,9 @@ Glossary
hashable
An object is *hashable* if it has a hash value which never changes during
- its lifetime (it needs a :meth:`__hash__` method), and can be compared to
- other objects (it needs an :meth:`__eq__` method). Hashable objects which
+ its lifetime (it needs a :meth:`~object.__hash__` method), and can be
+ compared to other objects (it needs an :meth:`~object.__eq__` method).
+ Hashable objects which
compare equal must have the same hash value.
Hashability makes an object usable as a dictionary key and a set member,
@@ -566,9 +587,9 @@ Glossary
from their :func:`id`.
IDLE
- An Integrated Development Environment for Python. IDLE is a basic editor
- and interpreter environment which ships with the standard distribution of
- Python.
+ An Integrated Development and Learning Environment for Python.
+ :ref:`idle` is a basic editor and interpreter environment
+ which ships with the standard distribution of Python.
immutable
An object with a fixed value. Immutable objects include numbers, strings and
@@ -627,7 +648,8 @@ Glossary
iterables include all sequence types (such as :class:`list`, :class:`str`,
and :class:`tuple`) and some non-sequence types like :class:`dict`,
:term:`file objects `, and objects of any classes you define
- with an :meth:`__iter__` method or with a :meth:`__getitem__` method
+ with an :meth:`~iterator.__iter__` method or with a
+ :meth:`~object.__getitem__` method
that implements :term:`sequence` semantics.
Iterables can be
@@ -636,7 +658,7 @@ Glossary
as an argument to the built-in function :func:`iter`, it returns an
iterator for the object. This iterator is good for one pass over the set
of values. When using iterables, it is usually not necessary to call
- :func:`iter` or deal with iterator objects yourself. The ``for``
+ :func:`iter` or deal with iterator objects yourself. The :keyword:`for`
statement does that automatically for you, creating a temporary unnamed
variable to hold the iterator for the duration of the loop. See also
:term:`iterator`, :term:`sequence`, and :term:`generator`.
@@ -647,8 +669,8 @@ Glossary
:func:`next`) return successive items in the stream. When no more data
are available a :exc:`StopIteration` exception is raised instead. At this
point, the iterator object is exhausted and any further calls to its
- :meth:`__next__` method just raise :exc:`StopIteration` again. Iterators
- are required to have an :meth:`__iter__` method that returns the iterator
+ :meth:`!__next__` method just raise :exc:`StopIteration` again. Iterators
+ are required to have an :meth:`~iterator.__iter__` method that returns the iterator
object itself so every iterator is also iterable and may be used in most
places where other iterables are accepted. One notable exception is code
which attempts multiple iteration passes. A container object (such as a
@@ -662,7 +684,7 @@ Glossary
.. impl-detail::
CPython does not consistently apply the requirement that an iterator
- define :meth:`__iter__`.
+ define :meth:`~iterator.__iter__`.
key function
A key function or collation function is a callable that returns a value
@@ -719,7 +741,7 @@ Glossary
list
A built-in Python :term:`sequence`. Despite its name it is more akin
to an array in other languages than to a linked list since access to
- elements is O(1).
+ elements is *O*\ (1).
list comprehension
A compact way to process all or part of the elements in a sequence and
@@ -856,7 +878,8 @@ Glossary
Old name for the flavor of classes now used for all class objects. In
earlier Python versions, only new-style classes could use Python's newer,
versatile features like :attr:`~object.__slots__`, descriptors,
- properties, :meth:`__getattribute__`, class methods, and static methods.
+ properties, :meth:`~object.__getattribute__`, class methods, and static
+ methods.
object
Any data with state (attributes or value) and defined behavior
@@ -865,7 +888,7 @@ Glossary
package
A Python :term:`module` which can contain submodules or recursively,
- subpackages. Technically, a package is a Python module with an
+ subpackages. Technically, a package is a Python module with a
``__path__`` attribute.
See also :term:`regular package` and :term:`namespace package`.
@@ -936,7 +959,7 @@ Glossary
finders implement.
path entry hook
- A callable on the :data:`sys.path_hook` list which returns a :term:`path
+ A callable on the :data:`sys.path_hooks` list which returns a :term:`path
entry finder` if it knows how to find modules on a specific :term:`path
entry`.
@@ -1067,21 +1090,23 @@ Glossary
sequence
An :term:`iterable` which supports efficient element access using integer
- indices via the :meth:`__getitem__` special method and defines a
- :meth:`__len__` method that returns the length of the sequence.
+ indices via the :meth:`~object.__getitem__` special method and defines a
+ :meth:`~object.__len__` method that returns the length of the sequence.
Some built-in sequence types are :class:`list`, :class:`str`,
:class:`tuple`, and :class:`bytes`. Note that :class:`dict` also
- supports :meth:`__getitem__` and :meth:`__len__`, but is considered a
+ supports :meth:`~object.__getitem__` and :meth:`!__len__`, but is considered a
mapping rather than a sequence because the lookups use arbitrary
:term:`immutable` keys rather than integers.
The :class:`collections.abc.Sequence` abstract base class
defines a much richer interface that goes beyond just
- :meth:`__getitem__` and :meth:`__len__`, adding :meth:`count`,
- :meth:`index`, :meth:`__contains__`, and
- :meth:`__reversed__`. Types that implement this expanded
+ :meth:`~object.__getitem__` and :meth:`~object.__len__`, adding
+ :meth:`!count`, :meth:`!index`, :meth:`~object.__contains__`, and
+ :meth:`~object.__reversed__`. Types that implement this expanded
interface can be registered explicitly using
- :func:`~abc.ABCMeta.register`.
+ :func:`~abc.ABCMeta.register`. For more documentation on sequence
+ methods generally, see
+ :ref:`Common Sequence Operations `.
set comprehension
A compact way to process all or part of the elements in an iterable and
@@ -1112,10 +1137,17 @@ Glossary
an :term:`expression` or one of several constructs with a keyword, such
as :keyword:`if`, :keyword:`while` or :keyword:`for`.
+ static type checker
+ An external tool that reads Python code and analyzes it, looking for
+ issues such as incorrect types. See also :term:`type hints `
+ and the :mod:`typing` module.
+
strong reference
In Python's C API, a strong reference is a reference to an object
- which increments the object's reference count when it is created and
- decrements the object's reference count when it is deleted.
+ which is owned by the code holding the reference. The strong
+ reference is taken by calling :c:func:`Py_INCREF` when the
+ reference is created and released with :c:func:`Py_DECREF`
+ when the reference is deleted.
The :c:func:`Py_NewRef` function can be used to create a strong reference
to an object. Usually, the :c:func:`Py_DECREF` function must be called on
@@ -1125,7 +1157,16 @@ Glossary
See also :term:`borrowed reference`.
text encoding
- A codec which encodes Unicode strings to bytes.
+ A string in Python is a sequence of Unicode code points (in range
+ ``U+0000``--``U+10FFFF``). To store or transfer a string, it needs to be
+ serialized as a sequence of bytes.
+
+ Serializing a string into a sequence of bytes is known as "encoding", and
+ recreating the string from the sequence of bytes is known as "decoding".
+
+ There are a variety of different text serialization
+ :ref:`codecs `, which are collectively referred to as
+ "text encodings".
text file
A :term:`file object` able to read and write :class:`str` objects.
@@ -1177,8 +1218,8 @@ Glossary
attribute, or a function parameter or return value.
Type hints are optional and are not enforced by Python but
- they are useful to static type analysis tools, and aid IDEs with code
- completion and refactoring.
+ they are useful to :term:`static type checkers `.
+ They can also aid IDEs with code completion and refactoring.
Type hints of global variables, class attributes, and functions,
but not local variables, can be accessed using
diff --git a/Doc/howto/annotations.rst b/Doc/howto/annotations.rst
index 2bc2f2d4c839e2..be8c7e6c827f57 100644
--- a/Doc/howto/annotations.rst
+++ b/Doc/howto/annotations.rst
@@ -32,195 +32,202 @@ Annotations Best Practices
Accessing The Annotations Dict Of An Object In Python 3.10 And Newer
====================================================================
- Python 3.10 adds a new function to the standard library:
- :func:`inspect.get_annotations`. In Python versions 3.10
- and newer, calling this function is the best practice for
- accessing the annotations dict of any object that supports
- annotations. This function can also "un-stringize"
- stringized annotations for you.
-
- If for some reason :func:`inspect.get_annotations` isn't
- viable for your use case, you may access the
- ``__annotations__`` data member manually. Best practice
- for this changed in Python 3.10 as well: as of Python 3.10,
- ``o.__annotations__`` is guaranteed to *always* work
- on Python functions, classes, and modules. If you're
- certain the object you're examining is one of these three
- *specific* objects, you may simply use ``o.__annotations__``
- to get at the object's annotations dict.
-
- However, other types of callables--for example,
- callables created by :func:`functools.partial`--may
- not have an ``__annotations__`` attribute defined. When
- accessing the ``__annotations__`` of a possibly unknown
- object, best practice in Python versions 3.10 and
- newer is to call :func:`getattr` with three arguments,
- for example ``getattr(o, '__annotations__', None)``.
+Python 3.10 adds a new function to the standard library:
+:func:`inspect.get_annotations`. In Python versions 3.10
+and newer, calling this function is the best practice for
+accessing the annotations dict of any object that supports
+annotations. This function can also "un-stringize"
+stringized annotations for you.
+
+If for some reason :func:`inspect.get_annotations` isn't
+viable for your use case, you may access the
+``__annotations__`` data member manually. Best practice
+for this changed in Python 3.10 as well: as of Python 3.10,
+``o.__annotations__`` is guaranteed to *always* work
+on Python functions, classes, and modules. If you're
+certain the object you're examining is one of these three
+*specific* objects, you may simply use ``o.__annotations__``
+to get at the object's annotations dict.
+
+However, other types of callables--for example,
+callables created by :func:`functools.partial`--may
+not have an ``__annotations__`` attribute defined. When
+accessing the ``__annotations__`` of a possibly unknown
+object, best practice in Python versions 3.10 and
+newer is to call :func:`getattr` with three arguments,
+for example ``getattr(o, '__annotations__', None)``.
+
+Before Python 3.10, accessing ``__annotations__`` on a class that
+defines no annotations but that has a parent class with
+annotations would return the parent's ``__annotations__``.
+In Python 3.10 and newer, the child class's annotations
+will be an empty dict instead.
Accessing The Annotations Dict Of An Object In Python 3.9 And Older
===================================================================
- In Python 3.9 and older, accessing the annotations dict
- of an object is much more complicated than in newer versions.
- The problem is a design flaw in these older versions of Python,
- specifically to do with class annotations.
+In Python 3.9 and older, accessing the annotations dict
+of an object is much more complicated than in newer versions.
+The problem is a design flaw in these older versions of Python,
+specifically to do with class annotations.
- Best practice for accessing the annotations dict of other
- objects--functions, other callables, and modules--is the same
- as best practice for 3.10, assuming you aren't calling
- :func:`inspect.get_annotations`: you should use three-argument
- :func:`getattr` to access the object's ``__annotations__``
- attribute.
+Best practice for accessing the annotations dict of other
+objects--functions, other callables, and modules--is the same
+as best practice for 3.10, assuming you aren't calling
+:func:`inspect.get_annotations`: you should use three-argument
+:func:`getattr` to access the object's ``__annotations__``
+attribute.
- Unfortunately, this isn't best practice for classes. The problem
- is that, since ``__annotations__`` is optional on classes, and
- because classes can inherit attributes from their base classes,
- accessing the ``__annotations__`` attribute of a class may
- inadvertently return the annotations dict of a *base class.*
- As an example::
+Unfortunately, this isn't best practice for classes. The problem
+is that, since ``__annotations__`` is optional on classes, and
+because classes can inherit attributes from their base classes,
+accessing the ``__annotations__`` attribute of a class may
+inadvertently return the annotations dict of a *base class.*
+As an example::
- class Base:
- a: int = 3
- b: str = 'abc'
+ class Base:
+ a: int = 3
+ b: str = 'abc'
- class Derived(Base):
- pass
+ class Derived(Base):
+ pass
- print(Derived.__annotations__)
+ print(Derived.__annotations__)
- This will print the annotations dict from ``Base``, not
- ``Derived``.
+This will print the annotations dict from ``Base``, not
+``Derived``.
- Your code will have to have a separate code path if the object
- you're examining is a class (``isinstance(o, type)``).
- In that case, best practice relies on an implementation detail
- of Python 3.9 and before: if a class has annotations defined,
- they are stored in the class's ``__dict__`` dictionary. Since
- the class may or may not have annotations defined, best practice
- is to call the ``get`` method on the class dict.
+Your code will have to have a separate code path if the object
+you're examining is a class (``isinstance(o, type)``).
+In that case, best practice relies on an implementation detail
+of Python 3.9 and before: if a class has annotations defined,
+they are stored in the class's ``__dict__`` dictionary. Since
+the class may or may not have annotations defined, best practice
+is to call the ``get`` method on the class dict.
- To put it all together, here is some sample code that safely
- accesses the ``__annotations__`` attribute on an arbitrary
- object in Python 3.9 and before::
+To put it all together, here is some sample code that safely
+accesses the ``__annotations__`` attribute on an arbitrary
+object in Python 3.9 and before::
- if isinstance(o, type):
- ann = o.__dict__.get('__annotations__', None)
- else:
- ann = getattr(o, '__annotations__', None)
+ if isinstance(o, type):
+ ann = o.__dict__.get('__annotations__', None)
+ else:
+ ann = getattr(o, '__annotations__', None)
- After running this code, ``ann`` should be either a
- dictionary or ``None``. You're encouraged to double-check
- the type of ``ann`` using :func:`isinstance` before further
- examination.
+After running this code, ``ann`` should be either a
+dictionary or ``None``. You're encouraged to double-check
+the type of ``ann`` using :func:`isinstance` before further
+examination.
- Note that some exotic or malformed type objects may not have
- a ``__dict__`` attribute, so for extra safety you may also wish
- to use :func:`getattr` to access ``__dict__``.
+Note that some exotic or malformed type objects may not have
+a ``__dict__`` attribute, so for extra safety you may also wish
+to use :func:`getattr` to access ``__dict__``.
Manually Un-Stringizing Stringized Annotations
==============================================
- In situations where some annotations may be "stringized",
- and you wish to evaluate those strings to produce the
- Python values they represent, it really is best to
- call :func:`inspect.get_annotations` to do this work
- for you.
-
- If you're using Python 3.9 or older, or if for some reason
- you can't use :func:`inspect.get_annotations`, you'll need
- to duplicate its logic. You're encouraged to examine the
- implementation of :func:`inspect.get_annotations` in the
- current Python version and follow a similar approach.
-
- In a nutshell, if you wish to evaluate a stringized annotation
- on an arbitrary object ``o``:
-
- * If ``o`` is a module, use ``o.__dict__`` as the
- ``globals`` when calling :func:`eval`.
- * If ``o`` is a class, use ``sys.modules[o.__module__].__dict__``
- as the ``globals``, and ``dict(vars(o))`` as the ``locals``,
- when calling :func:`eval`.
- * If ``o`` is a wrapped callable using :func:`functools.update_wrapper`,
- :func:`functools.wraps`, or :func:`functools.partial`, iteratively
- unwrap it by accessing either ``o.__wrapped__`` or ``o.func`` as
- appropriate, until you have found the root unwrapped function.
- * If ``o`` is a callable (but not a class), use
- ``o.__globals__`` as the globals when calling :func:`eval`.
-
- However, not all string values used as annotations can
- be successfully turned into Python values by :func:`eval`.
- String values could theoretically contain any valid string,
- and in practice there are valid use cases for type hints that
- require annotating with string values that specifically
- *can't* be evaluated. For example:
-
- * :pep:`604` union types using ``|``, before support for this
- was added to Python 3.10.
- * Definitions that aren't needed at runtime, only imported
- when :const:`typing.TYPE_CHECKING` is true.
-
- If :func:`eval` attempts to evaluate such values, it will
- fail and raise an exception. So, when designing a library
- API that works with annotations, it's recommended to only
- attempt to evaluate string values when explicitly requested
- to by the caller.
+In situations where some annotations may be "stringized",
+and you wish to evaluate those strings to produce the
+Python values they represent, it really is best to
+call :func:`inspect.get_annotations` to do this work
+for you.
+
+If you're using Python 3.9 or older, or if for some reason
+you can't use :func:`inspect.get_annotations`, you'll need
+to duplicate its logic. You're encouraged to examine the
+implementation of :func:`inspect.get_annotations` in the
+current Python version and follow a similar approach.
+
+In a nutshell, if you wish to evaluate a stringized annotation
+on an arbitrary object ``o``:
+
+* If ``o`` is a module, use ``o.__dict__`` as the
+ ``globals`` when calling :func:`eval`.
+* If ``o`` is a class, use ``sys.modules[o.__module__].__dict__``
+ as the ``globals``, and ``dict(vars(o))`` as the ``locals``,
+ when calling :func:`eval`.
+* If ``o`` is a wrapped callable using :func:`functools.update_wrapper`,
+ :func:`functools.wraps`, or :func:`functools.partial`, iteratively
+ unwrap it by accessing either ``o.__wrapped__`` or ``o.func`` as
+ appropriate, until you have found the root unwrapped function.
+* If ``o`` is a callable (but not a class), use
+ :attr:`o.__globals__ ` as the globals when calling
+ :func:`eval`.
+
+However, not all string values used as annotations can
+be successfully turned into Python values by :func:`eval`.
+String values could theoretically contain any valid string,
+and in practice there are valid use cases for type hints that
+require annotating with string values that specifically
+*can't* be evaluated. For example:
+
+* :pep:`604` union types using ``|``, before support for this
+ was added to Python 3.10.
+* Definitions that aren't needed at runtime, only imported
+ when :const:`typing.TYPE_CHECKING` is true.
+
+If :func:`eval` attempts to evaluate such values, it will
+fail and raise an exception. So, when designing a library
+API that works with annotations, it's recommended to only
+attempt to evaluate string values when explicitly requested
+to by the caller.
Best Practices For ``__annotations__`` In Any Python Version
============================================================
- * You should avoid assigning to the ``__annotations__`` member
- of objects directly. Let Python manage setting ``__annotations__``.
+* You should avoid assigning to the ``__annotations__`` member
+ of objects directly. Let Python manage setting ``__annotations__``.
- * If you do assign directly to the ``__annotations__`` member
- of an object, you should always set it to a ``dict`` object.
+* If you do assign directly to the ``__annotations__`` member
+ of an object, you should always set it to a ``dict`` object.
- * If you directly access the ``__annotations__`` member
- of an object, you should ensure that it's a
- dictionary before attempting to examine its contents.
+* If you directly access the ``__annotations__`` member
+ of an object, you should ensure that it's a
+ dictionary before attempting to examine its contents.
- * You should avoid modifying ``__annotations__`` dicts.
+* You should avoid modifying ``__annotations__`` dicts.
- * You should avoid deleting the ``__annotations__`` attribute
- of an object.
+* You should avoid deleting the ``__annotations__`` attribute
+ of an object.
``__annotations__`` Quirks
==========================
- In all versions of Python 3, function
- objects lazy-create an annotations dict if no annotations
- are defined on that object. You can delete the ``__annotations__``
- attribute using ``del fn.__annotations__``, but if you then
- access ``fn.__annotations__`` the object will create a new empty dict
- that it will store and return as its annotations. Deleting the
- annotations on a function before it has lazily created its annotations
- dict will throw an ``AttributeError``; using ``del fn.__annotations__``
- twice in a row is guaranteed to always throw an ``AttributeError``.
-
- Everything in the above paragraph also applies to class and module
- objects in Python 3.10 and newer.
-
- In all versions of Python 3, you can set ``__annotations__``
- on a function object to ``None``. However, subsequently
- accessing the annotations on that object using ``fn.__annotations__``
- will lazy-create an empty dictionary as per the first paragraph of
- this section. This is *not* true of modules and classes, in any Python
- version; those objects permit setting ``__annotations__`` to any
- Python value, and will retain whatever value is set.
-
- If Python stringizes your annotations for you
- (using ``from __future__ import annotations``), and you
- specify a string as an annotation, the string will
- itself be quoted. In effect the annotation is quoted
- *twice.* For example::
-
- from __future__ import annotations
- def foo(a: "str"): pass
-
- print(foo.__annotations__)
-
- This prints ``{'a': "'str'"}``. This shouldn't really be considered
- a "quirk"; it's mentioned here simply because it might be surprising.
+In all versions of Python 3, function
+objects lazy-create an annotations dict if no annotations
+are defined on that object. You can delete the ``__annotations__``
+attribute using ``del fn.__annotations__``, but if you then
+access ``fn.__annotations__`` the object will create a new empty dict
+that it will store and return as its annotations. Deleting the
+annotations on a function before it has lazily created its annotations
+dict will throw an ``AttributeError``; using ``del fn.__annotations__``
+twice in a row is guaranteed to always throw an ``AttributeError``.
+
+Everything in the above paragraph also applies to class and module
+objects in Python 3.10 and newer.
+
+In all versions of Python 3, you can set ``__annotations__``
+on a function object to ``None``. However, subsequently
+accessing the annotations on that object using ``fn.__annotations__``
+will lazy-create an empty dictionary as per the first paragraph of
+this section. This is *not* true of modules and classes, in any Python
+version; those objects permit setting ``__annotations__`` to any
+Python value, and will retain whatever value is set.
+
+If Python stringizes your annotations for you
+(using ``from __future__ import annotations``), and you
+specify a string as an annotation, the string will
+itself be quoted. In effect the annotation is quoted
+*twice.* For example::
+
+ from __future__ import annotations
+ def foo(a: "str"): pass
+
+ print(foo.__annotations__)
+
+This prints ``{'a': "'str'"}``. This shouldn't really be considered
+a "quirk"; it's mentioned here simply because it might be surprising.
diff --git a/Doc/howto/argparse.rst b/Doc/howto/argparse.rst
index a97d10cfe6bb69..06a301a120c1c7 100644
--- a/Doc/howto/argparse.rst
+++ b/Doc/howto/argparse.rst
@@ -1,10 +1,12 @@
+.. _argparse-tutorial:
+
*****************
Argparse Tutorial
*****************
:author: Tshepang Lekhonkhobe
-.. _argparse-tutorial:
+.. currentmodule:: argparse
This tutorial is intended to be a gentle introduction to :mod:`argparse`, the
recommended command-line parsing module in the Python standard library.
@@ -12,7 +14,7 @@ recommended command-line parsing module in the Python standard library.
.. note::
There are two other modules that fulfill the same task, namely
- :mod:`getopt` (an equivalent for :c:func:`getopt` from the C
+ :mod:`getopt` (an equivalent for ``getopt()`` from the C
language) and the deprecated :mod:`optparse`.
Note also that :mod:`argparse` is based on :mod:`optparse`,
and therefore very similar in terms of usage.
@@ -137,13 +139,13 @@ And running the code:
Here is what's happening:
-* We've added the :meth:`add_argument` method, which is what we use to specify
+* We've added the :meth:`~ArgumentParser.add_argument` method, which is what we use to specify
which command-line options the program is willing to accept. In this case,
I've named it ``echo`` so that it's in line with its function.
* Calling our program now requires us to specify an option.
-* The :meth:`parse_args` method actually returns some data from the
+* The :meth:`~ArgumentParser.parse_args` method actually returns some data from the
options specified, in this case, ``echo``.
* The variable is some form of 'magic' that :mod:`argparse` performs for free
@@ -256,7 +258,7 @@ Here is what is happening:
* To show that the option is actually optional, there is no error when running
the program without it. Note that by default, if an optional argument isn't
- used, the relevant variable, in this case :attr:`args.verbosity`, is
+ used, the relevant variable, in this case ``args.verbosity``, is
given ``None`` as a value, which is the reason it fails the truth
test of the :keyword:`if` statement.
@@ -299,7 +301,7 @@ Here is what is happening:
We even changed the name of the option to match that idea.
Note that we now specify a new keyword, ``action``, and give it the value
``"store_true"``. This means that, if the option is specified,
- assign the value ``True`` to :data:`args.verbose`.
+ assign the value ``True`` to ``args.verbose``.
Not specifying it implies ``False``.
* It complains when you specify a value, in true spirit of what flags
@@ -669,7 +671,7 @@ Conflicting options
So far, we have been working with two methods of an
:class:`argparse.ArgumentParser` instance. Let's introduce a third one,
-:meth:`add_mutually_exclusive_group`. It allows for us to specify options that
+:meth:`~ArgumentParser.add_mutually_exclusive_group`. It allows for us to specify options that
conflict with each other. Let's also change the rest of the program so that
the new functionality makes more sense:
we'll introduce the ``--quiet`` option,
@@ -732,9 +734,9 @@ your program, just in case they don't know::
if args.quiet:
print(answer)
elif args.verbose:
- print("{} to the power {} equals {}".format(args.x, args.y, answer))
+ print(f"{args.x} to the power {args.y} equals {answer}")
else:
- print("{}^{} == {}".format(args.x, args.y, answer))
+ print(f"{args.x}^{args.y} == {answer}")
Note that slight difference in the usage text. Note the ``[-v | -q]``,
which tells us that we can either use ``-v`` or ``-q``,
@@ -757,6 +759,59 @@ but not both at the same time:
-q, --quiet
+How to translate the argparse output
+====================================
+
+The output of the :mod:`argparse` module such as its help text and error
+messages are all made translatable using the :mod:`gettext` module. This
+allows applications to easily localize messages produced by
+:mod:`argparse`. See also :ref:`i18n-howto`.
+
+For instance, in this :mod:`argparse` output:
+
+.. code-block:: shell-session
+
+ $ python prog.py --help
+ usage: prog.py [-h] [-v | -q] x y
+
+ calculate X to the power of Y
+
+ positional arguments:
+ x the base
+ y the exponent
+
+ options:
+ -h, --help show this help message and exit
+ -v, --verbose
+ -q, --quiet
+
+The strings ``usage:``, ``positional arguments:``, ``options:`` and
+``show this help message and exit`` are all translatable.
+
+In order to translate these strings, they must first be extracted
+into a ``.po`` file. For example, using `Babel `__,
+run this command:
+
+.. code-block:: shell-session
+
+ $ pybabel extract -o messages.po /usr/lib/python3.12/argparse.py
+
+This command will extract all translatable strings from the :mod:`argparse`
+module and output them into a file named ``messages.po``. This command assumes
+that your Python installation is in ``/usr/lib``.
+
+You can find out the location of the :mod:`argparse` module on your system
+using this script::
+
+ import argparse
+ print(argparse.__file__)
+
+Once the messages in the ``.po`` file are translated and the translations are
+installed using :mod:`gettext`, :mod:`argparse` will be able to display the
+translated messages.
+
+To translate your own strings in the :mod:`argparse` output, use :mod:`gettext`.
+
Conclusion
==========
diff --git a/Doc/howto/clinic.rst b/Doc/howto/clinic.rst
index 04b1a2cac0b042..060977246149cf 100644
--- a/Doc/howto/clinic.rst
+++ b/Doc/howto/clinic.rst
@@ -1,1799 +1,14 @@
-.. highlight:: c
+:orphan:
+
+.. This page is retained solely for existing links to /howto/clinic.html.
+ Direct readers to the devguide.
**********************
Argument Clinic How-To
**********************
-:author: Larry Hastings
-
-
-.. topic:: Abstract
-
- Argument Clinic is a preprocessor for CPython C files.
- Its purpose is to automate all the boilerplate involved
- with writing argument parsing code for "builtins".
- This document shows you how to convert your first C
- function to work with Argument Clinic, and then introduces
- some advanced topics on Argument Clinic usage.
-
- Currently 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.
-
-The Goals Of Argument Clinic
-============================
-
-Argument Clinic's primary goal
-is to take over responsibility for all argument parsing code
-inside CPython. This means that, when you convert a function
-to work with Argument Clinic, that function should no longer
-do any of its own argument parsing—the code generated by
-Argument Clinic should be a "black box" to you, where CPython
-calls in at the top, and your code gets called at the bottom,
-with ``PyObject *args`` (and maybe ``PyObject *kwargs``)
-magically converted into the C variables and types you need.
-
-In order for Argument Clinic to accomplish its primary goal,
-it must be easy to use. Currently, working with CPython's
-argument parsing library is a chore, requiring maintaining
-redundant information in a surprising number of places.
-When you use Argument Clinic, you don't have to repeat yourself.
-
-Obviously, no one would want to use Argument Clinic unless
-it's solving their problem—and without creating new problems of
-its own.
-So it's paramount that Argument Clinic generate correct code.
-It'd be nice if the code was faster, too, but at the very least
-it should not introduce a major speed regression. (Eventually Argument
-Clinic *should* make a major speedup possible—we could
-rewrite its code generator to produce tailor-made argument
-parsing code, rather than calling the general-purpose CPython
-argument parsing library. That would make for the fastest
-argument parsing possible!)
-
-Additionally, Argument Clinic must be flexible enough to
-work with any approach to argument parsing. Python has
-some functions with some very strange parsing behaviors;
-Argument Clinic's goal is to support all of them.
-
-Finally, the original motivation for Argument Clinic was
-to provide introspection "signatures" for CPython builtins.
-It used to be, the introspection query functions would throw
-an exception if you passed in a builtin. With Argument
-Clinic, that's a thing of the past!
-
-One idea you should keep in mind, as you work with
-Argument Clinic: the more information you give it, the
-better job it'll be able to do.
-Argument Clinic is admittedly relatively simple right
-now. But as it evolves it will get more sophisticated,
-and it should be able to do many interesting and smart
-things with all the information you give it.
-
-
-Basic Concepts And Usage
-========================
-
-Argument Clinic ships with CPython; you'll find it in ``Tools/clinic/clinic.py``.
-If you run that script, specifying a C file as an argument:
-
-.. code-block:: shell-session
-
- $ python3 Tools/clinic/clinic.py foo.c
-
-Argument Clinic will scan over the file looking for lines that
-look exactly like this:
-
-.. code-block:: none
-
- /*[clinic input]
-
-When it finds one, it reads everything up to a line that looks
-exactly like this:
-
-.. code-block:: none
-
- [clinic start generated code]*/
-
-Everything in between these two lines is input for Argument Clinic.
-All of these lines, including the beginning and ending comment
-lines, are collectively called an Argument Clinic "block".
-
-When Argument Clinic parses one of these blocks, it
-generates output. This output is rewritten into the C file
-immediately after the block, followed by a comment containing a checksum.
-The Argument Clinic block now looks like this:
-
-.. code-block:: none
-
- /*[clinic input]
- ... clinic input goes here ...
- [clinic start generated code]*/
- ... clinic output goes here ...
- /*[clinic end generated code: checksum=...]*/
-
-If you run Argument Clinic on the same file a second time, Argument Clinic
-will discard the old output and write out the new output with a fresh checksum
-line. However, if the input hasn't changed, the output won't change either.
-
-You should never modify the output portion of an Argument Clinic block. Instead,
-change the input until it produces the output you want. (That's the purpose of the
-checksum—to detect if someone changed the output, as these edits would be lost
-the next time Argument Clinic writes out fresh output.)
-
-For the sake of clarity, here's the terminology we'll use with Argument Clinic:
-
-* The first line of the comment (``/*[clinic input]``) is the *start line*.
-* The last line of the initial comment (``[clinic start generated code]*/``) is the *end line*.
-* The last line (``/*[clinic end generated code: checksum=...]*/``) is the *checksum line*.
-* In between the start line and the end line is the *input*.
-* In between the end line and the checksum line is the *output*.
-* All the text collectively, from the start line to the checksum line inclusively,
- is the *block*. (A block that hasn't been successfully processed by Argument
- Clinic yet doesn't have output or a checksum line, but it's still considered
- a block.)
-
-
-Converting Your First Function
-==============================
-
-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 advanced concepts you'll see later on in
-the document (like "return converters" and "self converters").
-But we'll keep it simple for this walkthrough so you can learn.
-
-Let's dive in!
-
-0. Make sure you're working with a freshly updated checkout
- of the CPython trunk.
-
-1. 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 my example I'm using ``_pickle.Pickler.dump()``.
-
-2. If the call to the ``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. Argument Clinic *does*
- support all of these scenarios. But these are advanced
- topics—let's do something simpler for your first function.
-
- 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
- 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.
-
-3. Add the following boilerplate above the function, creating our block::
-
- /*[clinic input]
- [clinic start generated code]*/
-
-4. 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 ``help()`` on your builtin in the future,
- the first line will be built automatically based on the function's
- signature.)
-
- Sample::
-
- /*[clinic input]
- Write a pickled representation of obj to the open file.
- [clinic start generated code]*/
-
-5. 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.
-
- (Our example docstring consists solely of a summary line, so the sample
- code doesn't have to change for this step.)
-
-6. 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.
-
- Sample::
-
- /*[clinic input]
- _pickle.Pickler.dump
-
- Write a pickled representation of obj to the open file.
- [clinic start generated code]*/
-
-7. 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.
-
- Sample::
-
- /*[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]*/
-
-
-
-
-8. 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;
- please see :ref:`the section below on default values `
- for more information.
-
- 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 ``PyArg_Parse()`` format argument and
- specify *that* as its converter, as a quoted
- string. ("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]*/
-
-9. 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.
-
- (``_pickle.Pickler.dump`` has neither, so our sample is unchanged.)
-
-
-10. 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 all parameters as positional-only in Argument Clinic,
- add a ``/`` on a line by itself after the last parameter,
- indented the same as the parameter lines.
-
- Currently this is all-or-nothing; either all parameters are
- positional-only, or none of them are. (In the future Argument
- Clinic may relax this restriction.)
-
- 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]*/
-
-11. It's helpful to write a per-parameter docstring for each parameter.
- But per-parameter docstrings are optional; you can skip this step
- if you prefer.
-
- 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]*/
-
-12. Save and close the file, then run ``Tools/clinic/clinic.py`` on
- it. With luck everything worked---your block now has output, and
- a ``.c.h`` file has been generated! Reopen the file in your
- text editor to see::
-
- /*[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 ``.c.h``
- file. You'll need to include that in your original ``.c`` file,
- typically right after the clinic module block::
-
- #include "clinic/_pickle.c.h"
-
-13. 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, or 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.
-
-
-14. 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: checksum=...]*/
- {
- ...
-
- 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;
-
- ...
-
-15. 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. So 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 */
- };
-
-
-16. 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.
-
- Well, except for one difference: ``inspect.signature()`` run on your function
- should now provide a valid signature!
-
- Congratulations, you've ported your first function to work with Argument Clinic!
-
-Advanced Topics
-===============
-
-Now that you've had some experience working with Argument Clinic, it's time
-for some advanced topics.
-
-
-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 ``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``.)
-
-
-Renaming the 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
-``pickle.Pickler.dump``, it'd look like this::
-
- /*[clinic input]
- pickle.Pickler.dump as pickler_dumper
-
- ...
-
-The base function would now be named ``pickler_dumper()``,
-and the impl function would now be named ``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!
-
-
-Converting 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.
-
-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 ``range()``, which has
-an optional argument on the *left* side of its required argument!
-Another example is ``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 ``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.
-
-
-Using 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. And to be clear, their use is acceptable when porting code for
-Python 3.4.
-
-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 `
- 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.
-
-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" `
- 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
- ``_length``.
-
-Please note, not every possible combination of arguments will work.
-Usually these arguments are implemented by specific ``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'`` ``Py_UNICODE``
-``'u#'`` ``Py_UNICODE(zeroes=True)``
-``'w*'`` ``Py_buffer(accept={rwbuffer})``
-``'Y'`` ``PyByteArrayObject``
-``'y'`` ``str(accept={bytes})``
-``'y#'`` ``str(accept={robuffer}, zeroes=True)``
-``'y*'`` ``Py_buffer``
-``'Z'`` ``Py_UNICODE(accept={str, NoneType})``
-``'Z#'`` ``Py_UNICODE(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.
-
-Py_buffer
----------
-
-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).
-
-
-
-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 ``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
-``PyArg_Parse`` call by hand, you could theoretically decide at runtime what
-encoding string to pass in to :c:func:`PyArg_ParseTuple`. 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``.
-
-
-.. _default_values:
-
-Parameter default values
-------------------------
-
-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``.
-
-Expressions specified 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
-
-``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 "``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
-``sys.modules``. That's how it can find ``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.
-
-
-
-Using a return converter
-------------------------
-
-By default the impl function Argument Clinic generates for you returns ``PyObject *``.
-But your C function often computes some C type, then converts it into the ``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 ``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. 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 (``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
- int
- unsigned int
- long
- unsigned int
- size_t
- Py_ssize_t
- float
- double
- DecodeFSDefault
-
-None of these take parameters. For the first three, return -1 to indicate
-error. For ``DecodeFSDefault``, the return type is ``const char *``; return a ``NULL``
-pointer to indicate an error.
-
-(There's also an experimental ``NoneType`` converter, which lets you
-return ``Py_None`` on success or ``NULL`` on failure, without having
-to increment the reference count on ``Py_None``. I'm not sure it adds
-enough clarity to be worth using.)
-
-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.
-
-
-Cloning 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.
-
-Calling 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:...]*/
-
-
-Using a "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
-``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
-``self_converter`` but overwriting the ``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]*/
-
-
-Using a "defining class" converter
-----------------------------------
-
-Argument Clinic facilitates gaining access to the defining class of a method.
-This is useful for :ref:`heap type ` 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 ``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
-``__text_signature__``.
-
-The ``defining_class`` converter is not compatible with ``__init__`` and ``__new__``
-methods, which cannot use the ``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
-``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`.
-
-
-Writing a custom converter
---------------------------
-
-As we hinted at in the previous section... you can write your own converters!
-A converter is simply a Python class that inherits from ``CConverter``.
-The main purpose of a custom converter is if you have a parameter using
-the ``O&`` format unit—parsing this parameter means calling
-a :c:func:`PyArg_ParseTuple` "converter function".
-
-Your converter class should be named ``*something*_converter``.
-If the name follows this convention, then your converter class
-will be automatically registered with Argument Clinic; its name
-will be the name of your class with the ``_converter`` suffix
-stripped off. (This is accomplished with a metaclass.)
-
-You shouldn't subclass ``CConverter.__init__``. Instead, you should
-write a ``converter_init()`` function. ``converter_init()``
-always accepts a ``self`` parameter; after that, all additional
-parameters *must* be keyword-only. Any arguments passed in to
-the converter in Argument Clinic will be passed along to your
-``converter_init()``.
-
-There are some additional members of ``CConverter`` you may wish
-to specify in your subclass. Here's the current list:
-
-``type``
- The C type to use for this variable.
- ``type`` should be a Python string specifying the type, e.g. ``int``.
- If this is a pointer type, the type string should end with ``' *'``.
-
-``default``
- The Python default value for this parameter, as a Python value.
- Or the magic value ``unspecified`` if there is no default.
-
-``py_default``
- ``default`` as it should appear in Python code,
- as a string.
- Or ``None`` if there is no default.
-
-``c_default``
- ``default`` as it should appear in C code,
- as a string.
- Or ``None`` if there is no default.
-
-``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.
-
-``converter``
- The name of the C converter function, as a string.
-
-``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.
-
-``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`.
-
-
-Here's the simplest example of a custom converter, from ``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 to Argument Clinic named ``ssize_t``. Parameters
-declared as ``ssize_t`` will be declared as type ``Py_ssize_t``, and will
-be parsed by the ``'O&'`` format unit, which will call the
-``ssize_t_converter`` converter 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``.
-
-Writing 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 ``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 ``Tools/clinic/clinic.py``,
-specifically the implementation of ``CReturnConverter`` and
-all its subclasses.
-
-METH_O and METH_NOARGS
-----------------------------------------------
-
-To convert a function using ``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 ``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 ``METH_O``.
-
-tp_new and tp_init functions
-----------------------------------------------
-
-You can convert ``tp_new`` and ``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 ``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.)
-
-Changing and redirecting 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 ``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 ``"_"``,
- where ``""`` is the semantic object represented (the parsing function,
- the impl function, the docstring, or the methoddef structure) and ``""``
- 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 ``_pickle.c`` would be written to
- ``_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
-
-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
-
-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
-
-
-``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 [...]
-
-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 new
-
-This creates a new destination with name ```` and 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 new
-
- 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 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.
-
-
-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 ``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 ``PyMethodDef`` structure where that macro is used.
-
-
-
-Using 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
+.. note::
- #/*[python input]
- #print("def foo(): pass")
- #[python start generated code]*/
- def foo(): pass
- #/*[python checksum:...]*/
+ The Argument Clinic How-TO has been moved to the `Python Developer's Guide
+ `__.
diff --git a/Doc/howto/cporting.rst b/Doc/howto/cporting.rst
index ce7700fc599062..7773620b40b973 100644
--- a/Doc/howto/cporting.rst
+++ b/Doc/howto/cporting.rst
@@ -22,5 +22,5 @@ We recommend the following resources for porting extension modules to Python 3:
.. _Migrating C extensions: http://python3porting.com/cextensions.html
.. _Porting guide: https://py3c.readthedocs.io/en/latest/guide.html
-.. _Cython: http://cython.org/
+.. _Cython: https://cython.org/
.. _CFFI: https://cffi.readthedocs.io/en/latest/
diff --git a/Doc/howto/curses.rst b/Doc/howto/curses.rst
index 26c4ece5ae6df4..4828e2fa29bd24 100644
--- a/Doc/howto/curses.rst
+++ b/Doc/howto/curses.rst
@@ -4,6 +4,8 @@
Curses Programming with Python
**********************************
+.. currentmodule:: curses
+
:Author: A.M. Kuchling, Eric S. Raymond
:Release: 2.04
@@ -65,7 +67,7 @@ The Python module is a fairly simple wrapper over the C functions provided by
curses; if you're already familiar with curses programming in C, it's really
easy to transfer that knowledge to Python. The biggest difference is that the
Python interface makes things simpler by merging different C functions such as
-:c:func:`addstr`, :c:func:`mvaddstr`, and :c:func:`mvwaddstr` into a single
+:c:func:`!addstr`, :c:func:`!mvaddstr`, and :c:func:`!mvwaddstr` into a single
:meth:`~curses.window.addstr` method. You'll see this covered in more
detail later.
@@ -82,7 +84,7 @@ Before doing anything, curses must be initialized. This is done by
calling the :func:`~curses.initscr` function, which will determine the
terminal type, send any required setup codes to the terminal, and
create various internal data structures. If successful,
-:func:`initscr` returns a window object representing the entire
+:func:`!initscr` returns a window object representing the entire
screen; this is usually called ``stdscr`` after the name of the
corresponding C variable. ::
@@ -151,8 +153,8 @@ importing the :func:`curses.wrapper` function and using it like this::
The :func:`~curses.wrapper` function takes a callable object and does the
initializations described above, also initializing colors if color
-support is present. :func:`wrapper` then runs your provided callable.
-Once the callable returns, :func:`wrapper` will restore the original
+support is present. :func:`!wrapper` then runs your provided callable.
+Once the callable returns, :func:`!wrapper` will restore the original
state of the terminal. The callable is called inside a
:keyword:`try`...\ :keyword:`except` that catches exceptions, restores
the state of the terminal, and then re-raises the exception. Therefore
@@ -200,7 +202,7 @@ This is because curses was originally written with slow 300-baud
terminal connections in mind; with these terminals, minimizing the
time required to redraw the screen was very important. Instead curses
accumulates changes to the screen and displays them in the most
-efficient manner when you call :meth:`refresh`. For example, if your
+efficient manner when you call :meth:`!refresh`. For example, if your
program displays some text in a window and then clears the window,
there's no need to send the original text because they're never
visible.
@@ -210,7 +212,7 @@ really complicate programming with curses much. Most programs go into a flurry
of activity, and then pause waiting for a keypress or some other action on the
part of the user. All you have to do is to be sure that the screen has been
redrawn before pausing to wait for user input, by first calling
-``stdscr.refresh()`` or the :meth:`refresh` method of some other relevant
+:meth:`!stdscr.refresh` or the :meth:`!refresh` method of some other relevant
window.
A pad is a special case of a window; it can be larger than the actual display
@@ -234,7 +236,7 @@ displayed. ::
# : filled with pad content.
pad.refresh( 0,0, 5,5, 20,75)
-The :meth:`refresh` call displays a section of the pad in the rectangle
+The :meth:`!refresh` call displays a section of the pad in the rectangle
extending from coordinate (5,5) to coordinate (20,75) on the screen; the upper
left corner of the displayed section is coordinate (0,0) on the pad. Beyond
that difference, pads are exactly like ordinary windows and support the same
@@ -242,7 +244,7 @@ methods.
If you have multiple windows and pads on screen there is a more
efficient way to update the screen and prevent annoying screen flicker
-as each part of the screen gets updated. :meth:`refresh` actually
+as each part of the screen gets updated. :meth:`!refresh` actually
does two things:
1) Calls the :meth:`~curses.window.noutrefresh` method of each window
@@ -251,8 +253,8 @@ does two things:
2) Calls the function :func:`~curses.doupdate` function to change the
physical screen to match the desired state recorded in the data structure.
-Instead you can call :meth:`noutrefresh` on a number of windows to
-update the data structure, and then call :func:`doupdate` to update
+Instead you can call :meth:`!noutrefresh` on a number of windows to
+update the data structure, and then call :func:`!doupdate` to update
the screen.
@@ -261,11 +263,11 @@ Displaying Text
From a C programmer's point of view, curses may sometimes look like a
twisty maze of functions, all subtly different. For example,
-:c:func:`addstr` displays a string at the current cursor location in
-the ``stdscr`` window, while :c:func:`mvaddstr` moves to a given y,x
-coordinate first before displaying the string. :c:func:`waddstr` is just
-like :c:func:`addstr`, but allows specifying a window to use instead of
-using ``stdscr`` by default. :c:func:`mvwaddstr` allows specifying both
+:c:func:`!addstr` displays a string at the current cursor location in
+the ``stdscr`` window, while :c:func:`!mvaddstr` moves to a given y,x
+coordinate first before displaying the string. :c:func:`!waddstr` is just
+like :c:func:`!addstr`, but allows specifying a window to use instead of
+using ``stdscr`` by default. :c:func:`!mvwaddstr` allows specifying both
a window and a coordinate.
Fortunately the Python interface hides all these details. ``stdscr``
@@ -298,7 +300,7 @@ the next subsection.
The :meth:`~curses.window.addstr` method takes a Python string or
bytestring as the value to be displayed. The contents of bytestrings
are sent to the terminal as-is. Strings are encoded to bytes using
-the value of the window's :attr:`encoding` attribute; this defaults to
+the value of the window's :attr:`~window.encoding` attribute; this defaults to
the default system encoding as returned by :func:`locale.getencoding`.
The :meth:`~curses.window.addch` methods take a character, which can be
@@ -444,15 +446,15 @@ There are two methods for getting input from a window:
It's possible to not wait for the user using the
:meth:`~curses.window.nodelay` window method. After ``nodelay(True)``,
-:meth:`getch` and :meth:`getkey` for the window become
-non-blocking. To signal that no input is ready, :meth:`getch` returns
-``curses.ERR`` (a value of -1) and :meth:`getkey` raises an exception.
+:meth:`!getch` and :meth:`!getkey` for the window become
+non-blocking. To signal that no input is ready, :meth:`!getch` returns
+``curses.ERR`` (a value of -1) and :meth:`!getkey` raises an exception.
There's also a :func:`~curses.halfdelay` function, which can be used to (in
-effect) set a timer on each :meth:`getch`; if no input becomes
+effect) set a timer on each :meth:`!getch`; if no input becomes
available within a specified delay (measured in tenths of a second),
curses raises an exception.
-The :meth:`getch` method returns an integer; if it's between 0 and 255, it
+The :meth:`!getch` method returns an integer; if it's between 0 and 255, it
represents the ASCII code of the key pressed. Values greater than 255 are
special keys such as Page Up, Home, or the cursor keys. You can compare the
value returned to constants such as :const:`curses.KEY_PPAGE`,
@@ -525,7 +527,7 @@ If you're in doubt about the detailed behavior of the curses
functions, consult the manual pages for your curses implementation,
whether it's ncurses or a proprietary Unix vendor's. The manual pages
will document any quirks, and provide complete lists of all the
-functions, attributes, and :const:`ACS_\*` characters available to
+functions, attributes, and :ref:`ACS_\* ` characters available to
you.
Because the curses API is so large, some functions aren't supported in
@@ -536,12 +538,12 @@ Patches adding support for these would be welcome; see
`the Python Developer's Guide `_ to
learn more about submitting patches to Python.
-* `Writing Programs with NCURSES `_:
+* `Writing Programs with NCURSES `_:
a lengthy tutorial for C programmers.
* `The ncurses man page `_
-* `The ncurses FAQ `_
+* `The ncurses FAQ `_
* `"Use curses... don't swear" `_:
video of a PyCon 2013 talk on controlling terminals using curses or Urwid.
-* `"Console Applications with Urwid" `_:
+* `"Console Applications with Urwid" `_:
video of a PyCon CA 2012 talk demonstrating some applications written using
Urwid.
diff --git a/Doc/howto/descriptor.rst b/Doc/howto/descriptor.rst
index 5e9b110f0fe254..308aa84724e2ed 100644
--- a/Doc/howto/descriptor.rst
+++ b/Doc/howto/descriptor.rst
@@ -521,11 +521,11 @@ everyday Python programs.
Descriptor protocol
-------------------
-``descr.__get__(self, obj, type=None) -> value``
+``descr.__get__(self, obj, type=None)``
-``descr.__set__(self, obj, value) -> None``
+``descr.__set__(self, obj, value)``
-``descr.__delete__(self, obj) -> None``
+``descr.__delete__(self, obj)``
That is all there is to it. Define any of these methods and an object is
considered a descriptor and can override default behavior upon being looked up
@@ -582,11 +582,18 @@ a pure Python equivalent:
.. testcode::
+ def find_name_in_mro(cls, name, default):
+ "Emulate _PyType_Lookup() in Objects/typeobject.c"
+ for base in cls.__mro__:
+ if name in vars(base):
+ return vars(base)[name]
+ return default
+
def object_getattribute(obj, name):
"Emulate PyObject_GenericGetAttr() in Objects/object.c"
null = object()
objtype = type(obj)
- cls_var = getattr(objtype, name, null)
+ cls_var = find_name_in_mro(objtype, name, null)
descr_get = getattr(type(cls_var), '__get__', null)
if descr_get is not null:
if (hasattr(type(cls_var), '__set__')
@@ -663,6 +670,15 @@ a pure Python equivalent:
def __getattr__(self, name):
return ('getattr_hook', self, name)
+ class D1:
+ def __get__(self, obj, objtype=None):
+ return type(self), obj, objtype
+
+ class U1:
+ x = D1()
+
+ class U2(U1):
+ pass
.. doctest::
:hide:
@@ -696,6 +712,10 @@ a pure Python equivalent:
>>> b.g == b['g'] == ('getattr_hook', b, 'g')
True
+ >>> u2 = U2()
+ >>> object_getattribute(u2, 'x') == u2.x == (D1, u2, U2)
+ True
+
Note, there is no :meth:`__getattr__` hook in the :meth:`__getattribute__`
code. That is why calling :meth:`__getattribute__` directly or with
``super().__getattribute__`` will bypass :meth:`__getattr__` entirely.
@@ -759,8 +779,8 @@ by a search through the class's :term:`method resolution order`.
If a descriptor is found, it is invoked with ``desc.__get__(None, A)``.
-The full C implementation can be found in :c:func:`type_getattro()` and
-:c:func:`_PyType_Lookup()` in :source:`Objects/typeobject.c`.
+The full C implementation can be found in :c:func:`!type_getattro` and
+:c:func:`!_PyType_Lookup` in :source:`Objects/typeobject.c`.
Invocation from super
@@ -774,7 +794,7 @@ for the base class ``B`` immediately following ``A`` and then returns
``B.__dict__['m'].__get__(obj, A)``. If not a descriptor, ``m`` is returned
unchanged.
-The full C implementation can be found in :c:func:`super_getattro()` in
+The full C implementation can be found in :c:func:`!super_getattro` in
:source:`Objects/typeobject.c`. A pure Python equivalent can be found in
`Guido's Tutorial
`_.
@@ -816,8 +836,8 @@ and if they define :meth:`__set_name__`, that method is called with two
arguments. The *owner* is the class where the descriptor is used, and the
*name* is the class variable the descriptor was assigned to.
-The implementation details are in :c:func:`type_new()` and
-:c:func:`set_names()` in :source:`Objects/typeobject.c`.
+The implementation details are in :c:func:`!type_new` and
+:c:func:`!set_names` in :source:`Objects/typeobject.c`.
Since the update logic is in :meth:`type.__new__`, notifications only take
place at the time of class creation. If descriptors are added to the class
@@ -827,7 +847,7 @@ afterwards, :meth:`__set_name__` will need to be called manually.
ORM example
-----------
-The following code is simplified skeleton showing how data descriptors could
+The following code is a simplified skeleton showing how data descriptors could
be used to implement an `object relational mapping
`_.
@@ -923,6 +943,10 @@ it can be updated:
>>> Movie('Star Wars').director
'J.J. Abrams'
+.. testcleanup::
+
+ conn.close()
+
Pure Python Equivalents
^^^^^^^^^^^^^^^^^^^^^^^
@@ -1179,7 +1203,7 @@ instance::
>>> d.f.__self__
- <__main__.D object at 0x1012e1f98>
+ <__main__.D object at 0x00B18C90>
If you have ever wondered where *self* comes from in regular methods or where
*cls* comes from in class methods, this is it!
@@ -1253,11 +1277,14 @@ Using the non-data descriptor protocol, a pure Python version of
.. testcode::
+ import functools
+
class StaticMethod:
"Emulate PyStaticMethod_Type() in Objects/funcobject.c"
def __init__(self, f):
self.f = f
+ functools.update_wrapper(self, f)
def __get__(self, obj, objtype=None):
return self.f
@@ -1265,13 +1292,20 @@ Using the non-data descriptor protocol, a pure Python version of
def __call__(self, *args, **kwds):
return self.f(*args, **kwds)
+The :func:`functools.update_wrapper` call adds a ``__wrapped__`` attribute
+that refers to the underlying function. Also it carries forward
+the attributes necessary to make the wrapper look like the wrapped
+function: :attr:`~function.__name__`, :attr:`~function.__qualname__`,
+:attr:`~function.__doc__`, and :attr:`~function.__annotations__`.
+
.. testcode::
:hide:
class E_sim:
@StaticMethod
- def f(x):
- return x * 10
+ def f(x: int) -> str:
+ "Simple function example"
+ return "!" * x
wrapped_ord = StaticMethod(ord)
@@ -1279,11 +1313,51 @@ Using the non-data descriptor protocol, a pure Python version of
:hide:
>>> E_sim.f(3)
- 30
+ '!!!'
>>> E_sim().f(3)
- 30
+ '!!!'
+
+ >>> sm = vars(E_sim)['f']
+ >>> type(sm).__name__
+ 'StaticMethod'
+ >>> f = E_sim.f
+ >>> type(f).__name__
+ 'function'
+ >>> sm.__name__
+ 'f'
+ >>> f.__name__
+ 'f'
+ >>> sm.__qualname__
+ 'E_sim.f'
+ >>> f.__qualname__
+ 'E_sim.f'
+ >>> sm.__doc__
+ 'Simple function example'
+ >>> f.__doc__
+ 'Simple function example'
+ >>> sm.__annotations__
+ {'x': , 'return': }
+ >>> f.__annotations__
+ {'x': , 'return': }
+ >>> sm.__module__ == f.__module__
+ True
+ >>> sm(3)
+ '!!!'
+ >>> f(3)
+ '!!!'
+
>>> wrapped_ord('A')
65
+ >>> wrapped_ord.__module__ == ord.__module__
+ True
+ >>> wrapped_ord.__wrapped__ == ord
+ True
+ >>> wrapped_ord.__name__ == ord.__name__
+ True
+ >>> wrapped_ord.__qualname__ == ord.__qualname__
+ True
+ >>> wrapped_ord.__doc__ == ord.__doc__
+ True
Class methods
@@ -1339,11 +1413,14 @@ Using the non-data descriptor protocol, a pure Python version of
.. testcode::
+ import functools
+
class ClassMethod:
"Emulate PyClassMethod_Type() in Objects/funcobject.c"
def __init__(self, f):
self.f = f
+ functools.update_wrapper(self, f)
def __get__(self, obj, cls=None):
if cls is None:
@@ -1360,8 +1437,9 @@ Using the non-data descriptor protocol, a pure Python version of
# Verify the emulation works
class T:
@ClassMethod
- def cm(cls, x, y):
- return (cls, x, y)
+ def cm(cls, x: int, y: str) -> tuple[str, int, str]:
+ "Class method that returns a tuple"
+ return (cls.__name__, x, y)
@ClassMethod
@property
@@ -1373,17 +1451,40 @@ Using the non-data descriptor protocol, a pure Python version of
:hide:
>>> T.cm(11, 22)
- (, 11, 22)
+ ('T', 11, 22)
# Also call it from an instance
>>> t = T()
>>> t.cm(11, 22)
- (, 11, 22)
+ ('T', 11, 22)
# Check the alternate path for chained descriptors
>>> T.__doc__
"A doc for 'T'"
+ # Verify that T uses our emulation
+ >>> type(vars(T)['cm']).__name__
+ 'ClassMethod'
+
+ # Verify that update_wrapper() correctly copied attributes
+ >>> T.cm.__name__
+ 'cm'
+ >>> T.cm.__qualname__
+ 'T.cm'
+ >>> T.cm.__doc__
+ 'Class method that returns a tuple'
+ >>> T.cm.__annotations__
+ {'x': , 'y': , 'return': tuple[str, int, str]}
+
+ # Verify that __wrapped__ was added and works correctly
+ >>> f = vars(T)['cm'].__wrapped__
+ >>> type(f).__name__
+ 'function'
+ >>> f.__name__
+ 'cm'
+ >>> f(T, 11, 22)
+ ('T', 11, 22)
+
The code path for ``hasattr(type(self.f), '__get__')`` was added in
Python 3.9 and makes it possible for :func:`classmethod` to support
@@ -1403,6 +1504,13 @@ chained together. In Python 3.11, this functionality was deprecated.
>>> G.__doc__
"A doc for 'G'"
+The :func:`functools.update_wrapper` call in ``ClassMethod`` adds a
+``__wrapped__`` attribute that refers to the underlying function. Also
+it carries forward the attributes necessary to make the wrapper look
+like the wrapped function: :attr:`~function.__name__`,
+:attr:`~function.__qualname__`, :attr:`~function.__doc__`,
+and :attr:`~function.__annotations__`.
+
Member objects and __slots__
----------------------------
@@ -1515,6 +1623,8 @@ by member descriptors:
def __get__(self, obj, objtype=None):
'Emulate member_get() in Objects/descrobject.c'
# Also see PyMember_GetOne() in Python/structmember.c
+ if obj is None:
+ return self
value = obj._slotvalues[self.offset]
if value is null:
raise AttributeError(self.name)
@@ -1543,13 +1653,13 @@ variables:
class Type(type):
'Simulate how the type metaclass adds member objects for slots'
- def __new__(mcls, clsname, bases, mapping):
+ def __new__(mcls, clsname, bases, mapping, **kwargs):
'Emulate type_new() in Objects/typeobject.c'
# type_new() calls PyTypeReady() which calls add_methods()
slot_names = mapping.get('slot_names', [])
for offset, name in enumerate(slot_names):
mapping[name] = Member(name, clsname, offset)
- return type.__new__(mcls, clsname, bases, mapping)
+ return type.__new__(mcls, clsname, bases, mapping, **kwargs)
The :meth:`object.__new__` method takes care of creating instances that have
slots instead of an instance dictionary. Here is a rough simulation in pure
@@ -1560,7 +1670,7 @@ Python:
class Object:
'Simulate how object.__new__() allocates memory for __slots__'
- def __new__(cls, *args):
+ def __new__(cls, *args, **kwargs):
'Emulate object_new() in Objects/typeobject.c'
inst = super().__new__(cls)
if hasattr(cls, 'slot_names'):
@@ -1573,7 +1683,7 @@ Python:
cls = type(self)
if hasattr(cls, 'slot_names') and name not in cls.slot_names:
raise AttributeError(
- f'{type(self).__name__!r} object has no attribute {name!r}'
+ f'{cls.__name__!r} object has no attribute {name!r}'
)
super().__setattr__(name, value)
@@ -1582,7 +1692,7 @@ Python:
cls = type(self)
if hasattr(cls, 'slot_names') and name not in cls.slot_names:
raise AttributeError(
- f'{type(self).__name__!r} object has no attribute {name!r}'
+ f'{cls.__name__!r} object has no attribute {name!r}'
)
super().__delattr__(name)
diff --git a/Doc/howto/enum.rst b/Doc/howto/enum.rst
index 7b1cf75fa81f08..a533b5f1020a1b 100644
--- a/Doc/howto/enum.rst
+++ b/Doc/howto/enum.rst
@@ -173,6 +173,7 @@ yourself some work and use :func:`auto()` for the values::
... FRIDAY = auto()
... SATURDAY = auto()
... SUNDAY = auto()
+ ... WEEKEND = SATURDAY | SUNDAY
.. _enum-advanced-tutorial:
@@ -305,6 +306,10 @@ Iterating over the members of an enum does not provide the aliases::
>>> list(Shape)
[, , ]
+ >>> list(Weekday)
+ [, , , , , , ]
+
+Note that the aliases ``Shape.ALIAS_FOR_SQUARE`` and ``Weekday.WEEKEND`` aren't shown.
The special attribute ``__members__`` is a read-only ordered mapping of names
to members. It includes all names defined in the enumeration, including the
@@ -324,6 +329,11 @@ the enumeration members. For example, finding all the aliases::
>>> [name for name, member in Shape.__members__.items() if member.name != name]
['ALIAS_FOR_SQUARE']
+.. note::
+
+ Aliases for flags include values with multiple flags set, such as ``3``,
+ and no flags set, i.e. ``0``.
+
Comparisons
-----------
@@ -361,6 +371,11 @@ below)::
>>> Color.BLUE == 2
False
+.. warning::
+
+ It is possible to reload modules -- if a reloaded module contains
+ enums, they will be recreated, and the new members may not
+ compare identical/equal to the original members.
Allowed members and attributes of enumerations
----------------------------------------------
@@ -407,10 +422,17 @@ enumeration, with the exception of special methods (:meth:`__str__`,
:meth:`__add__`, etc.), descriptors (methods are also descriptors), and
variable names listed in :attr:`_ignore_`.
-Note: if your enumeration defines :meth:`__new__` and/or :meth:`__init__` then
+Note: if your enumeration defines :meth:`__new__` and/or :meth:`__init__`,
any value(s) given to the enum member will be passed into those methods.
See `Planet`_ for an example.
+.. note::
+
+ The :meth:`__new__` method, if defined, is used during creation of the Enum
+ members; it is then replaced by Enum's :meth:`__new__` which is used after
+ class creation for lookup of existing members. See :ref:`new-vs-init` for
+ more details.
+
Restricted Enum subclassing
---------------------------
@@ -469,7 +491,17 @@ from that module.
nested in other classes.
It is possible to modify how enum members are pickled/unpickled by defining
-:meth:`__reduce_ex__` in the enumeration class.
+:meth:`__reduce_ex__` in the enumeration class. The default method is by-value,
+but enums with complicated values may want to use by-name::
+
+ >>> import enum
+ >>> class MyEnum(enum.Enum):
+ ... __reduce_ex__ = enum.pickle_by_enum_name
+
+.. note::
+
+ Using by-name for flags is not recommended, as unnamed aliases will
+ not unpickle.
Functional API
@@ -541,9 +573,9 @@ The complete signature is::
start=1,
)
-:value: What the new enum class will record as its name.
+* *value*: What the new enum class will record as its name.
-:names: The enum members. This can be a whitespace- or comma-separated string
+* *names*: The enum members. This can be a whitespace- or comma-separated string
(values will start at 1 unless otherwise specified)::
'RED GREEN BLUE' | 'RED,GREEN,BLUE' | 'RED, GREEN, BLUE'
@@ -560,13 +592,13 @@ The complete signature is::
{'CHARTREUSE': 7, 'SEA_GREEN': 11, 'ROSEMARY': 42}
-:module: name of module where new enum class can be found.
+* *module*: name of module where new enum class can be found.
-:qualname: where in module new enum class can be found.
+* *qualname*: where in module new enum class can be found.
-:type: type to mix in to new enum class.
+* *type*: type to mix in to new enum class.
-:start: number to start counting at if only names are passed in.
+* *start*: number to start counting at if only names are passed in.
.. versionchanged:: 3.5
The *start* parameter was added.
@@ -705,7 +737,7 @@ be combined with them (but may lose :class:`IntFlag` membership::
>>> Perm.X | 4
- >>> Perm.X | 8
+ >>> Perm.X + 8
9
.. note::
@@ -751,7 +783,7 @@ flags being set, the boolean evaluation is :data:`False`::
False
Individual flags should have values that are powers of two (1, 2, 4, 8, ...),
-while combinations of flags won't::
+while combinations of flags will not::
>>> class Color(Flag):
... RED = auto()
@@ -822,19 +854,22 @@ Some rules:
4. When another data type is mixed in, the :attr:`value` attribute is *not the
same* as the enum member itself, although it is equivalent and will compare
equal.
-5. %-style formatting: ``%s`` and ``%r`` call the :class:`Enum` class's
+5. A ``data type`` is a mixin that defines :meth:`__new__`.
+6. %-style formatting: ``%s`` and ``%r`` call the :class:`Enum` class's
:meth:`__str__` and :meth:`__repr__` respectively; other codes (such as
``%i`` or ``%h`` for IntEnum) treat the enum member as its mixed-in type.
-6. :ref:`Formatted string literals `, :meth:`str.format`,
+7. :ref:`Formatted string literals `, :meth:`str.format`,
and :func:`format` will use the enum's :meth:`__str__` method.
.. note::
Because :class:`IntEnum`, :class:`IntFlag`, and :class:`StrEnum` are
designed to be drop-in replacements for existing constants, their
- :meth:`__str__` method has been reset to their data types
+ :meth:`__str__` method has been reset to their data types'
:meth:`__str__` method.
+.. _new-vs-init:
+
When to use :meth:`__new__` vs. :meth:`__init__`
------------------------------------------------
@@ -867,6 +902,11 @@ want one of them to be the value::
>>> print(Coordinate(3))
Coordinate.VY
+.. warning::
+
+ *Do not* call ``super().__new__()``, as the lookup-only ``__new__`` is the one
+ that is found; instead, use the data type directly.
+
Finer Points
^^^^^^^^^^^^
@@ -945,23 +985,11 @@ but remain normal attributes.
""""""""""""""""""""
Enum members are instances of their enum class, and are normally accessed as
-``EnumClass.member``. In Python versions ``3.5`` to ``3.10`` you could access
-members from other members -- this practice was discouraged, and in ``3.11``
-:class:`Enum` returns to not allowing it::
-
- >>> class FieldTypes(Enum):
- ... name = 0
- ... value = 1
- ... size = 2
- ...
- >>> FieldTypes.value.size
- Traceback (most recent call last):
- ...
- AttributeError: member has no attribute 'size'
-
+``EnumClass.member``. In certain situations, such as writing custom enum
+behavior, being able to access one member directly from another is useful,
+and is supported.
.. versionchanged:: 3.5
-.. versionchanged:: 3.11
Creating members that are mixed with other data types
@@ -1092,13 +1120,14 @@ the following are true:
There is a new boundary mechanism that controls how out-of-range / invalid
bits are handled: ``STRICT``, ``CONFORM``, ``EJECT``, and ``KEEP``:
- * STRICT --> raises an exception when presented with invalid values
- * CONFORM --> discards any invalid bits
- * EJECT --> lose Flag status and become a normal int with the given value
- * KEEP --> keep the extra bits
- - keeps Flag status and extra bits
- - extra bits do not show up in iteration
- - extra bits do show up in repr() and str()
+* STRICT --> raises an exception when presented with invalid values
+* CONFORM --> discards any invalid bits
+* EJECT --> lose Flag status and become a normal int with the given value
+* KEEP --> keep the extra bits
+
+ - keeps Flag status and extra bits
+ - extra bits do not show up in iteration
+ - extra bits do show up in repr() and str()
The default for Flag is ``STRICT``, the default for ``IntFlag`` is ``EJECT``,
and the default for ``_convert_`` is ``KEEP`` (see ``ssl.Options`` for an
@@ -1107,8 +1136,8 @@ example of when ``KEEP`` is needed).
.. _enum-class-differences:
-How are Enums different?
-------------------------
+How are Enums and Flags different?
+----------------------------------
Enums have a custom metaclass that affects many aspects of both derived :class:`Enum`
classes and their instances (members).
@@ -1120,11 +1149,18 @@ Enum Classes
The :class:`EnumType` metaclass is responsible for providing the
:meth:`__contains__`, :meth:`__dir__`, :meth:`__iter__` and other methods that
allow one to do things with an :class:`Enum` class that fail on a typical
-class, such as `list(Color)` or `some_enum_var in Color`. :class:`EnumType` is
+class, such as ``list(Color)`` or ``some_enum_var in Color``. :class:`EnumType` is
responsible for ensuring that various other methods on the final :class:`Enum`
class are correct (such as :meth:`__new__`, :meth:`__getnewargs__`,
:meth:`__str__` and :meth:`__repr__`).
+Flag Classes
+^^^^^^^^^^^^
+
+Flags have an expanded view of aliasing: to be canonical, the value of a flag
+needs to be a power-of-two value, and not a duplicate name. So, in addition to the
+:class:`Enum` definition of alias, a flag with no value (a.k.a. ``0``) or with more than one
+power-of-two value (e.g. ``3``) is considered an alias.
Enum Members (aka instances)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -1134,9 +1170,35 @@ The most interesting thing about enum members is that they are singletons.
and then puts a custom :meth:`__new__` in place to ensure that no new ones are
ever instantiated by returning only the existing member instances.
+Flag Members
+^^^^^^^^^^^^
+
+Flag members can be iterated over just like the :class:`Flag` class, and only the
+canonical members will be returned. For example::
+
+ >>> list(Color)
+ [, , ]
+
+(Note that ``BLACK``, ``PURPLE``, and ``WHITE`` do not show up.)
+
+Inverting a flag member returns the corresponding positive value,
+rather than a negative value --- for example::
+
+ >>> ~Color.RED
+
+
+Flag members have a length corresponding to the number of power-of-two values
+they contain. For example::
+
+ >>> len(Color.PURPLE)
+ 2
+
.. _enum-cookbook:
+Enum Cookbook
+-------------
+
While :class:`Enum`, :class:`IntEnum`, :class:`StrEnum`, :class:`Flag`, and
:class:`IntFlag` are expected to cover the majority of use-cases, they cannot
@@ -1270,6 +1332,13 @@ to handle any extra arguments::
members; it is then replaced by Enum's :meth:`__new__` which is used after
class creation for lookup of existing members.
+.. warning::
+
+ *Do not* call ``super().__new__()``, as the lookup-only ``__new__`` is the one
+ that is found; instead, use the data type directly -- e.g.::
+
+ obj = int.__new__(cls, value)
+
OrderedEnum
^^^^^^^^^^^
@@ -1310,7 +1379,7 @@ enumerations)::
DuplicateFreeEnum
^^^^^^^^^^^^^^^^^
-Raises an error if a duplicate member name is found instead of creating an
+Raises an error if a duplicate member value is found instead of creating an
alias::
>>> class DuplicateFreeEnum(Enum):
@@ -1330,7 +1399,7 @@ alias::
... GRENE = 2
...
Traceback (most recent call last):
- ...
+ ...
ValueError: aliases not allowed in DuplicateFreeEnum: 'GRENE' --> 'GREEN'
.. note::
diff --git a/Doc/howto/functional.rst b/Doc/howto/functional.rst
index 695b9b31a762bd..efc25dac695da0 100644
--- a/Doc/howto/functional.rst
+++ b/Doc/howto/functional.rst
@@ -315,9 +315,15 @@ line of a file like this::
Sets can take their contents from an iterable and let you iterate over the set's
elements::
- S = {2, 3, 5, 7, 11, 13}
- for i in S:
- print(i)
+ >>> S = {2, 3, 5, 7, 11, 13}
+ >>> for i in S:
+ ... print(i)
+ 2
+ 3
+ 5
+ 7
+ 11
+ 13
@@ -335,18 +341,18 @@ List comprehensions and generator expressions (short form: "listcomps" and
functional programming language Haskell (https://www.haskell.org/). You can strip
all the whitespace from a stream of strings with the following code::
- line_list = [' line 1\n', 'line 2 \n', ...]
+ >>> line_list = [' line 1\n', 'line 2 \n', ' \n', '']
- # Generator expression -- returns iterator
- stripped_iter = (line.strip() for line in line_list)
+ >>> # Generator expression -- returns iterator
+ >>> stripped_iter = (line.strip() for line in line_list)
- # List comprehension -- returns list
- stripped_list = [line.strip() for line in line_list]
+ >>> # List comprehension -- returns list
+ >>> stripped_list = [line.strip() for line in line_list]
You can select only certain elements by adding an ``"if"`` condition::
- stripped_list = [line.strip() for line in line_list
- if line != ""]
+ >>> stripped_list = [line.strip() for line in line_list
+ ... if line != ""]
With a list comprehension, you get back a Python list; ``stripped_list`` is a
list containing the resulting lines, not an iterator. Generator expressions
@@ -363,7 +369,8 @@ have the form::
if condition1
for expr2 in sequence2
if condition2
- for expr3 in sequence3 ...
+ for expr3 in sequence3
+ ...
if condition3
for exprN in sequenceN
if conditionN )
@@ -734,7 +741,7 @@ further because you risk skipping a discarded element.
The itertools module
====================
-The :mod:`itertools` module contains a number of commonly-used iterators as well
+The :mod:`itertools` module contains a number of commonly used iterators as well
as functions for combining several iterators. This section will introduce the
module's contents by showing small examples.
@@ -987,7 +994,7 @@ requesting iterator-2 and its corresponding key.
The functools module
====================
-The :mod:`functools` module in Python 2.5 contains some higher-order functions.
+The :mod:`functools` module contains some higher-order functions.
A **higher-order function** takes one or more functions as input and returns a
new function. The most useful tool in this module is the
:func:`functools.partial` function.
@@ -1065,8 +1072,8 @@ write the obvious :keyword:`for` loop::
A related function is :func:`itertools.accumulate(iterable, func=operator.add)
`. It performs the same calculation, but instead of
-returning only the final result, :func:`accumulate` returns an iterator that
-also yields each partial result::
+returning only the final result, :func:`~itertools.accumulate` returns an iterator
+that also yields each partial result::
itertools.accumulate([1, 2, 3, 4, 5]) =>
1, 3, 6, 10, 15
@@ -1201,14 +1208,14 @@ General
-------
**Structure and Interpretation of Computer Programs**, by Harold Abelson and
-Gerald Jay Sussman with Julie Sussman. Full text at
-https://mitpress.mit.edu/sicp/. In this classic textbook of computer science,
+Gerald Jay Sussman with Julie Sussman. The book can be found at
+https://mitpress.mit.edu/sicp. In this classic textbook of computer science,
chapters 2 and 3 discuss the use of sequences and streams to organize the data
flow inside a program. The book uses Scheme for its examples, but many of the
design approaches described in these chapters are applicable to functional-style
Python code.
-http://www.defmacro.org/ramblings/fp.html: A general introduction to functional
+https://www.defmacro.org/ramblings/fp.html: A general introduction to functional
programming that uses Java examples and has a lengthy historical introduction.
https://en.wikipedia.org/wiki/Functional_programming: General Wikipedia entry
@@ -1221,7 +1228,7 @@ https://en.wikipedia.org/wiki/Currying: Entry for the concept of currying.
Python-specific
---------------
-http://gnosis.cx/TPiP/: The first chapter of David Mertz's book
+https://gnosis.cx/TPiP/: The first chapter of David Mertz's book
:title-reference:`Text Processing in Python` discusses functional programming
for text processing, in the section titled "Utilizing Higher-Order Functions in
Text Processing".
diff --git a/Doc/howto/index.rst b/Doc/howto/index.rst
index eae8f143ee206f..c53c613bc5b1c6 100644
--- a/Doc/howto/index.rst
+++ b/Doc/howto/index.rst
@@ -28,7 +28,7 @@ Currently, the HOWTOs are:
urllib2.rst
argparse.rst
ipaddress.rst
- clinic.rst
instrumentation.rst
annotations.rst
+ isolating-extensions.rst
diff --git a/Doc/howto/instrumentation.rst b/Doc/howto/instrumentation.rst
index 4a59ae82f96e2d..9c99fcecce1fcb 100644
--- a/Doc/howto/instrumentation.rst
+++ b/Doc/howto/instrumentation.rst
@@ -13,9 +13,9 @@ DTrace and SystemTap are monitoring tools, each providing a way to inspect
what the processes on a computer system are doing. They both use
domain-specific languages allowing a user to write scripts which:
- - filter which processes are to be observed
- - gather data from the processes of interest
- - generate reports on the data
+- filter which processes are to be observed
+- gather data from the processes of interest
+- generate reports on the data
As of Python 3.6, CPython can be built with embedded "markers", also
known as "probes", that can be observed by a DTrace or SystemTap script,
@@ -123,7 +123,7 @@ Sufficiently modern readelf can print the metadata::
Arguments: 8@%rbp 8@%r12 -4@%eax
The above metadata contains information for SystemTap describing how it
-can patch strategically-placed machine code instructions to enable the
+can patch strategically placed machine code instructions to enable the
tracing hooks used by a SystemTap script.
@@ -246,11 +246,9 @@ The output looks like this:
where the columns are:
- - time in microseconds since start of script
-
- - name of executable
-
- - PID of process
+- time in microseconds since start of script
+- name of executable
+- PID of process
and the remainder indicates the call/return hierarchy as the script executes.
@@ -292,11 +290,11 @@ Available static markers
.. object:: function__return(str filename, str funcname, int lineno)
- This marker is the converse of :c:func:`function__entry`, and indicates that
+ This marker is the converse of :c:func:`!function__entry`, and indicates that
execution of a Python function has ended (either via ``return``, or via an
exception). It is only triggered for pure-Python (bytecode) functions.
- The arguments are the same as for :c:func:`function__entry`
+ The arguments are the same as for :c:func:`!function__entry`
.. object:: line(str filename, str funcname, int lineno)
@@ -304,7 +302,7 @@ Available static markers
the equivalent of line-by-line tracing with a Python profiler. It is
not triggered within C functions.
- The arguments are the same as for :c:func:`function__entry`.
+ The arguments are the same as for :c:func:`!function__entry`.
.. object:: gc__start(int generation)
@@ -410,7 +408,7 @@ needing to directly name the static markers:
The following script uses the tapset above to provide a top-like view of all
-running CPython code, showing the top 20 most frequently-entered bytecode
+running CPython code, showing the top 20 most frequently entered bytecode
frames, each second, across the whole system:
.. code-block:: none
diff --git a/Doc/howto/isolating-extensions.rst b/Doc/howto/isolating-extensions.rst
new file mode 100644
index 00000000000000..a2a1f6eb0cfa73
--- /dev/null
+++ b/Doc/howto/isolating-extensions.rst
@@ -0,0 +1,627 @@
+.. highlight:: c
+
+***************************
+Isolating Extension Modules
+***************************
+
+.. topic:: Abstract
+
+ Traditionally, state belonging to Python extension modules was kept in C
+ ``static`` variables, which have process-wide scope. This document
+ describes problems of such per-process state and shows a safer way:
+ per-module state.
+
+ The document also describes how to switch to per-module state where
+ possible. This transition involves allocating space for that state, potentially
+ switching from static types to heap types, and—perhaps most
+ importantly—accessing per-module state from code.
+
+
+Who should read this
+====================
+
+This guide is written for maintainers of :ref:`C-API ` extensions
+who would like to make that extension safer to use in applications where
+Python itself is used as a library.
+
+
+Background
+==========
+
+An *interpreter* is the context in which Python code runs. It contains
+configuration (e.g. the import path) and runtime state (e.g. the set of
+imported modules).
+
+Python supports running multiple interpreters in one process. There are
+two cases to think about—users may run interpreters:
+
+- in sequence, with several :c:func:`Py_InitializeEx`/:c:func:`Py_FinalizeEx`
+ cycles, and
+- in parallel, managing "sub-interpreters" using
+ :c:func:`Py_NewInterpreter`/:c:func:`Py_EndInterpreter`.
+
+Both cases (and combinations of them) would be most useful when
+embedding Python within a library. Libraries generally shouldn't make
+assumptions about the application that uses them, which include
+assuming a process-wide "main Python interpreter".
+
+Historically, Python extension modules don't handle this use case well.
+Many extension modules (and even some stdlib modules) use *per-process*
+global state, because C ``static`` variables are extremely easy to use.
+Thus, data that should be specific to an interpreter ends up being shared
+between interpreters. Unless the extension developer is careful, it is very
+easy to introduce edge cases that lead to crashes when a module is loaded in
+more than one interpreter in the same process.
+
+Unfortunately, *per-interpreter* state is not easy to achieve. Extension
+authors tend to not keep multiple interpreters in mind when developing,
+and it is currently cumbersome to test the behavior.
+
+Enter Per-Module State
+----------------------
+
+Instead of focusing on per-interpreter state, Python's C API is evolving
+to better support the more granular *per-module* state.
+This means that C-level data is be attached to a *module object*.
+Each interpreter creates its own module object, keeping the data separate.
+For testing the isolation, multiple module objects corresponding to a single
+extension can even be loaded in a single interpreter.
+
+Per-module state provides an easy way to think about lifetime and
+resource ownership: the extension module will initialize when a
+module object is created, and clean up when it's freed. In this regard,
+a module is just like any other :c:expr:`PyObject *`; there are no "on
+interpreter shutdown" hooks to think—or forget—about.
+
+Note that there are use cases for different kinds of "globals":
+per-process, per-interpreter, per-thread or per-task state.
+With per-module state as the default, these are still possible,
+but you should treat them as exceptional cases:
+if you need them, you should give them additional care and testing.
+(Note that this guide does not cover them.)
+
+
+Isolated Module Objects
+-----------------------
+
+The key point to keep in mind when developing an extension module is
+that several module objects can be created from a single shared library.
+For example:
+
+.. code-block:: pycon
+
+ >>> import sys
+ >>> import binascii
+ >>> old_binascii = binascii
+ >>> del sys.modules['binascii']
+ >>> import binascii # create a new module object
+ >>> old_binascii == binascii
+ False
+
+As a rule of thumb, the two modules should be completely independent.
+All objects and state specific to the module should be encapsulated
+within the module object, not shared with other module objects, and
+cleaned up when the module object is deallocated.
+Since this just is a rule of thumb, exceptions are possible
+(see `Managing Global State`_), but they will need more
+thought and attention to edge cases.
+
+While some modules could do with less stringent restrictions, isolated
+modules make it easier to set clear expectations and guidelines that
+work across a variety of use cases.
+
+
+Surprising Edge Cases
+---------------------
+
+Note that isolated modules do create some surprising edge cases. Most
+notably, each module object will typically not share its classes and
+exceptions with other similar modules. Continuing from the
+`example above `__,
+note that ``old_binascii.Error`` and ``binascii.Error`` are
+separate objects. In the following code, the exception is *not* caught:
+
+.. code-block:: pycon
+
+ >>> old_binascii.Error == binascii.Error
+ False
+ >>> try:
+ ... old_binascii.unhexlify(b'qwertyuiop')
+ ... except binascii.Error:
+ ... print('boo')
+ ...
+ Traceback (most recent call last):
+ File "", line 2, in
+ binascii.Error: Non-hexadecimal digit found
+
+This is expected. Notice that pure-Python modules behave the same way:
+it is a part of how Python works.
+
+The goal is to make extension modules safe at the C level, not to make
+hacks behave intuitively. Mutating ``sys.modules`` "manually" counts
+as a hack.
+
+
+Making Modules Safe with Multiple Interpreters
+==============================================
+
+
+Managing Global State
+---------------------
+
+Sometimes, the state associated with a Python module is not specific to that module, but
+to the entire process (or something else "more global" than a module).
+For example:
+
+- The ``readline`` module manages *the* terminal.
+- A module running on a circuit board wants to control *the* on-board
+ LED.
+
+In these cases, the Python module should provide *access* to the global
+state, rather than *own* it. If possible, write the module so that
+multiple copies of it can access the state independently (along with
+other libraries, whether for Python or other languages). If that is not
+possible, consider explicit locking.
+
+If it is necessary to use process-global state, the simplest way to
+avoid issues with multiple interpreters is to explicitly prevent a
+module from being loaded more than once per process—see
+`Opt-Out: Limiting to One Module Object per Process`_.
+
+
+Managing Per-Module State
+-------------------------
+
+To use per-module state, use
+:ref:`multi-phase extension module initialization `.
+This signals that your module supports multiple interpreters correctly.
+
+Set ``PyModuleDef.m_size`` to a positive number to request that many
+bytes of storage local to the module. Usually, this will be set to the
+size of some module-specific ``struct``, which can store all of the
+module's C-level state. In particular, it is where you should put
+pointers to classes (including exceptions, but excluding static types)
+and settings (e.g. ``csv``'s :py:data:`~csv.field_size_limit`)
+which the C code needs to function.
+
+.. note::
+ Another option is to store state in the module's ``__dict__``,
+ but you must avoid crashing when users modify ``__dict__`` from
+ Python code. This usually means error- and type-checking at the C level,
+ which is easy to get wrong and hard to test sufficiently.
+
+ However, if module state is not needed in C code, storing it in
+ ``__dict__`` only is a good idea.
+
+If the module state includes ``PyObject`` pointers, the module object
+must hold references to those objects and implement the module-level hooks
+``m_traverse``, ``m_clear`` and ``m_free``. These work like
+``tp_traverse``, ``tp_clear`` and ``tp_free`` of a class. Adding them will
+require some work and make the code longer; this is the price for
+modules which can be unloaded cleanly.
+
+An example of a module with per-module state is currently available as
+`xxlimited `__;
+example module initialization shown at the bottom of the file.
+
+
+Opt-Out: Limiting to One Module Object per Process
+--------------------------------------------------
+
+A non-negative ``PyModuleDef.m_size`` signals that a module supports
+multiple interpreters correctly. If this is not yet the case for your
+module, you can explicitly make your module loadable only once per
+process. For example::
+
+ static int loaded = 0;
+
+ static int
+ exec_module(PyObject* module)
+ {
+ if (loaded) {
+ PyErr_SetString(PyExc_ImportError,
+ "cannot load module more than once per process");
+ return -1;
+ }
+ loaded = 1;
+ // ... rest of initialization
+ }
+
+
+Module State Access from Functions
+----------------------------------
+
+Accessing the state from module-level functions is straightforward.
+Functions get the module object as their first argument; for extracting
+the state, you can use ``PyModule_GetState``::
+
+ static PyObject *
+ func(PyObject *module, PyObject *args)
+ {
+ my_struct *state = (my_struct*)PyModule_GetState(module);
+ if (state == NULL) {
+ return NULL;
+ }
+ // ... rest of logic
+ }
+
+.. note::
+ ``PyModule_GetState`` may return ``NULL`` without setting an
+ exception if there is no module state, i.e. ``PyModuleDef.m_size`` was
+ zero. In your own module, you're in control of ``m_size``, so this is
+ easy to prevent.
+
+
+Heap Types
+==========
+
+Traditionally, types defined in C code are *static*; that is,
+``static PyTypeObject`` structures defined directly in code and
+initialized using ``PyType_Ready()``.
+
+Such types are necessarily shared across the process. Sharing them
+between module objects requires paying attention to any state they own
+or access. To limit the possible issues, static types are immutable at
+the Python level: for example, you can't set ``str.myattribute = 123``.
+
+.. impl-detail::
+ Sharing truly immutable objects between interpreters is fine,
+ as long as they don't provide access to mutable objects.
+ However, in CPython, every Python object has a mutable implementation
+ detail: the reference count. Changes to the refcount are guarded by the GIL.
+ Thus, code that shares any Python objects across interpreters implicitly
+ depends on CPython's current, process-wide GIL.
+
+Because they are immutable and process-global, static types cannot access
+"their" module state.
+If any method of such a type requires access to module state,
+the type must be converted to a *heap-allocated type*, or *heap type*
+for short. These correspond more closely to classes created by Python's
+``class`` statement.
+
+For new modules, using heap types by default is a good rule of thumb.
+
+
+Changing Static Types to Heap Types
+-----------------------------------
+
+Static types can be converted to heap types, but note that
+the heap type API was not designed for "lossless" conversion
+from static types—that is, creating a type that works exactly like a given
+static type.
+So, when rewriting the class definition in a new API,
+you are likely to unintentionally change a few details (e.g. pickleability
+or inherited slots).
+Always test the details that are important to you.
+
+Watch out for the following two points in particular (but note that this is not
+a comprehensive list):
+
+* Unlike static types, heap type objects are mutable by default.
+ Use the :c:macro:`Py_TPFLAGS_IMMUTABLETYPE` flag to prevent mutability.
+* Heap types inherit :c:member:`~PyTypeObject.tp_new` by default,
+ so it may become possible to instantiate them from Python code.
+ You can prevent this with the :c:macro:`Py_TPFLAGS_DISALLOW_INSTANTIATION` flag.
+
+
+Defining Heap Types
+-------------------
+
+Heap types can be created by filling a :c:struct:`PyType_Spec` structure, a
+description or "blueprint" of a class, and calling
+:c:func:`PyType_FromModuleAndSpec` to construct a new class object.
+
+.. note::
+ Other functions, like :c:func:`PyType_FromSpec`, can also create
+ heap types, but :c:func:`PyType_FromModuleAndSpec` associates the module
+ with the class, allowing access to the module state from methods.
+
+The class should generally be stored in *both* the module state (for
+safe access from C) and the module's ``__dict__`` (for access from
+Python code).
+
+
+Garbage-Collection Protocol
+---------------------------
+
+Instances of heap types hold a reference to their type.
+This ensures that the type isn't destroyed before all its instances are,
+but may result in reference cycles that need to be broken by the
+garbage collector.
+
+To avoid memory leaks, instances of heap types must implement the
+garbage collection protocol.
+That is, heap types should:
+
+- Have the :c:macro:`Py_TPFLAGS_HAVE_GC` flag.
+- Define a traverse function using ``Py_tp_traverse``, which
+ visits the type (e.g. using ``Py_VISIT(Py_TYPE(self))``).
+
+Please refer to the the documentation of
+:c:macro:`Py_TPFLAGS_HAVE_GC` and :c:member:`~PyTypeObject.tp_traverse`
+for additional considerations.
+
+The API for defining heap types grew organically, leaving it
+somewhat awkward to use in its current state.
+The following sections will guide you through common issues.
+
+
+``tp_traverse`` in Python 3.8 and lower
+.......................................
+
+The requirement to visit the type from ``tp_traverse`` was added in Python 3.9.
+If you support Python 3.8 and lower, the traverse function must *not*
+visit the type, so it must be more complicated::
+
+ static int my_traverse(PyObject *self, visitproc visit, void *arg)
+ {
+ if (Py_Version >= 0x03090000) {
+ Py_VISIT(Py_TYPE(self));
+ }
+ return 0;
+ }
+
+Unfortunately, :c:data:`Py_Version` was only added in Python 3.11.
+As a replacement, use:
+
+* :c:macro:`PY_VERSION_HEX`, if not using the stable ABI, or
+* :py:data:`sys.version_info` (via :c:func:`PySys_GetObject` and
+ :c:func:`PyArg_ParseTuple`).
+
+
+Delegating ``tp_traverse``
+..........................
+
+If your traverse function delegates to the :c:member:`~PyTypeObject.tp_traverse`
+of its base class (or another type), ensure that ``Py_TYPE(self)`` is visited
+only once.
+Note that only heap type are expected to visit the type in ``tp_traverse``.
+
+For example, if your traverse function includes::
+
+ base->tp_traverse(self, visit, arg)
+
+...and ``base`` may be a static type, then it should also include::
+
+ if (base->tp_flags & Py_TPFLAGS_HEAPTYPE) {
+ // a heap type's tp_traverse already visited Py_TYPE(self)
+ } else {
+ if (Py_Version >= 0x03090000) {
+ Py_VISIT(Py_TYPE(self));
+ }
+ }
+
+It is not necessary to handle the type's reference count in
+:c:member:`~PyTypeObject.tp_new` and :c:member:`~PyTypeObject.tp_clear`.
+
+
+Defining ``tp_dealloc``
+.......................
+
+If your type has a custom :c:member:`~PyTypeObject.tp_dealloc` function,
+it needs to:
+
+- call :c:func:`PyObject_GC_UnTrack` before any fields are invalidated, and
+- decrement the reference count of the type.
+
+To keep the type valid while ``tp_free`` is called, the type's refcount needs
+to be decremented *after* the instance is deallocated. For example::
+
+ static void my_dealloc(PyObject *self)
+ {
+ PyObject_GC_UnTrack(self);
+ ...
+ PyTypeObject *type = Py_TYPE(self);
+ type->tp_free(self);
+ Py_DECREF(type);
+ }
+
+The default ``tp_dealloc`` function does this, so
+if your type does *not* override
+``tp_dealloc`` you don't need to add it.
+
+
+Not overriding ``tp_free``
+..........................
+
+The :c:member:`~PyTypeObject.tp_free` slot of a heap type must be set to
+:c:func:`PyObject_GC_Del`.
+This is the default; do not override it.
+
+
+Avoiding ``PyObject_New``
+.........................
+
+GC-tracked objects need to be allocated using GC-aware functions.
+
+If you use use :c:func:`PyObject_New` or :c:func:`PyObject_NewVar`:
+
+- Get and call type's :c:member:`~PyTypeObject.tp_alloc` slot, if possible.
+ That is, replace ``TYPE *o = PyObject_New(TYPE, typeobj)`` with::
+
+ TYPE *o = typeobj->tp_alloc(typeobj, 0);
+
+ Replace ``o = PyObject_NewVar(TYPE, typeobj, size)`` with the same,
+ but use size instead of the 0.
+
+- If the above is not possible (e.g. inside a custom ``tp_alloc``),
+ call :c:func:`PyObject_GC_New` or :c:func:`PyObject_GC_NewVar`::
+
+ TYPE *o = PyObject_GC_New(TYPE, typeobj);
+
+ TYPE *o = PyObject_GC_NewVar(TYPE, typeobj, size);
+
+
+Module State Access from Classes
+--------------------------------
+
+If you have a type object defined with :c:func:`PyType_FromModuleAndSpec`,
+you can call :c:func:`PyType_GetModule` to get the associated module, and then
+:c:func:`PyModule_GetState` to get the module's state.
+
+To save a some tedious error-handling boilerplate code, you can combine
+these two steps with :c:func:`PyType_GetModuleState`, resulting in::
+
+ my_struct *state = (my_struct*)PyType_GetModuleState(type);
+ if (state === NULL) {
+ return NULL;
+ }
+
+
+Module State Access from Regular Methods
+----------------------------------------
+
+Accessing the module-level state from methods of a class is somewhat more
+complicated, but is possible thanks to API introduced in Python 3.9.
+To get the state, you need to first get the *defining class*, and then
+get the module state from it.
+
+The largest roadblock is getting *the class a method was defined in*, or
+that method's "defining class" for short. The defining class can have a
+reference to the module it is part of.
+
+Do not confuse the defining class with ``Py_TYPE(self)``. If the method
+is called on a *subclass* of your type, ``Py_TYPE(self)`` will refer to
+that subclass, which may be defined in different module than yours.
+
+.. note::
+ The following Python code can illustrate the concept.
+ ``Base.get_defining_class`` returns ``Base`` even
+ if ``type(self) == Sub``:
+
+ .. code-block:: python
+
+ class Base:
+ def get_type_of_self(self):
+ return type(self)
+
+ def get_defining_class(self):
+ return __class__
+
+ class Sub(Base):
+ pass
+
+For a method to get its "defining class", it must use the
+:ref:`METH_METHOD | METH_FASTCALL | METH_KEYWORDS `
+:c:type:`calling convention `
+and the corresponding :c:type:`PyCMethod` signature::
+
+ PyObject *PyCMethod(
+ PyObject *self, // object the method was called on
+ PyTypeObject *defining_class, // defining class
+ PyObject *const *args, // C array of arguments
+ Py_ssize_t nargs, // length of "args"
+ PyObject *kwnames) // NULL, or dict of keyword arguments
+
+Once you have the defining class, call :c:func:`PyType_GetModuleState` to get
+the state of its associated module.
+
+For example::
+
+ static PyObject *
+ example_method(PyObject *self,
+ PyTypeObject *defining_class,
+ PyObject *const *args,
+ Py_ssize_t nargs,
+ PyObject *kwnames)
+ {
+ my_struct *state = (my_struct*)PyType_GetModuleState(defining_class);
+ if (state === NULL) {
+ return NULL;
+ }
+ ... // rest of logic
+ }
+
+ PyDoc_STRVAR(example_method_doc, "...");
+
+ static PyMethodDef my_methods[] = {
+ {"example_method",
+ (PyCFunction)(void(*)(void))example_method,
+ METH_METHOD|METH_FASTCALL|METH_KEYWORDS,
+ example_method_doc}
+ {NULL},
+ }
+
+
+Module State Access from Slot Methods, Getters and Setters
+----------------------------------------------------------
+
+.. note::
+
+ This is new in Python 3.11.
+
+ .. After adding to limited API:
+
+ If you use the :ref:`limited API `,
+ you must update ``Py_LIMITED_API`` to ``0x030b0000``, losing ABI
+ compatibility with earlier versions.
+
+Slot methods—the fast C equivalents for special methods, such as
+:c:member:`~PyNumberMethods.nb_add` for :py:attr:`~object.__add__` or
+:c:member:`~PyTypeObject.tp_new` for initialization—have a very simple API that
+doesn't allow passing in the defining class, unlike with :c:type:`PyCMethod`.
+The same goes for getters and setters defined with
+:c:type:`PyGetSetDef`.
+
+To access the module state in these cases, use the
+:c:func:`PyType_GetModuleByDef` function, and pass in the module definition.
+Once you have the module, call :c:func:`PyModule_GetState`
+to get the state::
+
+ PyObject *module = PyType_GetModuleByDef(Py_TYPE(self), &module_def);
+ my_struct *state = (my_struct*)PyModule_GetState(module);
+ if (state === NULL) {
+ return NULL;
+ }
+
+:c:func:`!PyType_GetModuleByDef` works by searching the
+:term:`method resolution order` (i.e. all superclasses) for the first
+superclass that has a corresponding module.
+
+.. note::
+
+ In very exotic cases (inheritance chains spanning multiple modules
+ created from the same definition), :c:func:`!PyType_GetModuleByDef` might not
+ return the module of the true defining class. However, it will always
+ return a module with the same definition, ensuring a compatible
+ C memory layout.
+
+
+Lifetime of the Module State
+----------------------------
+
+When a module object is garbage-collected, its module state is freed.
+For each pointer to (a part of) the module state, you must hold a reference
+to the module object.
+
+Usually this is not an issue, because types created with
+:c:func:`PyType_FromModuleAndSpec`, and their instances, hold a reference
+to the module.
+However, you must be careful in reference counting when you reference
+module state from other places, such as callbacks for external
+libraries.
+
+
+Open Issues
+===========
+
+Several issues around per-module state and heap types are still open.
+
+Discussions about improving the situation are best held on the `capi-sig
+mailing list