Cc. @adriangb
The "stub documentation" in `types.rst` does already link to the
in-depth docs in `stdtypes.rst`, but the link isn't obvious for new
users. It deserves to be made more prominent.
- Issue: https://github.com/python/cpython/issues/103721
<!--
Thanks for your contribution!
Please read this comment in its entirety. It's quite important.
# Pull Request title
It should be in the following format:
```
gh-NNNNN: Summary of the changes made
```
Where: gh-NNNNN refers to the GitHub issue number.
Most PRs will require an issue number. Trivial changes, like fixing a
typo, do not need an issue.
# Backport Pull Request title
If this is a backport PR (PR made against branches other than `main`),
please ensure that the PR title is in the following format:
```
[X.Y] <title from the original PR> (GH-NNNN)
```
Where: [X.Y] is the branch name, e.g. [3.6].
GH-NNNN refers to the PR number from `main`.
-->
<!-- gh-issue-number: gh-103726 -->
* Issue: gh-103726
<!-- /gh-issue-number -->
Turns out we always need to remember/restore fstring buffers in all of
the stack of tokenizer modes, cause they might change to
`TOK_REGULAR_MODE` and have newlines inside the braces (which is when we
need to reallocate the buffer and restore the fstring ones).
gh-82814: Adds `errno.EACCES` to the list of ignored errors on
`_copyxattr`. EPERM and EACCES are different constants but
in general should be treated the same.
News entry authored by: Gregory P. Smith <greg@krypto.org>
"awaiting changes" means somebody put a review that requested changes.
"awaiting change review" means that the PR author published changes
after a red review and then requested a re-review.
This PR makes some minor linting adjustments to the Lib/test module
caught by [ruff](https://github.com/charliermarsh/ruff). The adjustments
are all related to the `F541 f-string without any placeholders` issue.
Issue: https://github.com/python/cpython/issues/103805
<!-- gh-issue-number: gh-103805 -->
* Issue: gh-103805
<!-- /gh-issue-number -->
---------
Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com>
Co-authored-by: Gregory P. Smith <greg@krypto.org>
This is strictly about moving the "obmalloc" runtime state from
`_PyRuntimeState` to `PyInterpreterState`. Doing so improves isolation
between interpreters, specifically most of the memory (incl. objects)
allocated for each interpreter's use. This is important for a
per-interpreter GIL, but such isolation is valuable even without it.
FWIW, a per-interpreter obmalloc is the proverbial
canary-in-the-coalmine when it comes to the isolation of objects between
interpreters. Any object that leaks (unintentionally) to another
interpreter is highly likely to cause a crash (on debug builds at
least). That's a useful thing to know, relative to interpreter
isolation.
This PR makes three minor linting adjustments to the `wasm` module
caught by [ruff](https://github.com/charliermarsh/ruff).
<!-- gh-issue-number: gh-103801 -->
* Issue: gh-103801
<!-- /gh-issue-number -->
---------
Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com>
sockserver gains ForkingUnixStreamServer and ForkingUnixDatagramServer classes for consistency with all of the others. Ironically these existed but were buried in our test suite.
Addresses #103673
<!-- gh-issue-number: gh-103673 -->
* Issue: gh-103673
<!-- /gh-issue-number -->
---------
Co-authored-by: Gregory P. Smith <greg@krypto.org>
Co-authored-by: Nikita Sobolev <mail@sobolevn.me>
Core static types will continue to use the global value. All other types
will use the per-interpreter value. They all share the same range, where
the global types use values < 2^16 and each interpreter uses values
higher than that.
This speeds up `super()` (by around 85%, for a simple one-level
`super().meth()` microbenchmark) by avoiding allocation of a new
single-use `super()` object on each use.
Deep-frozen code objects are cannot be shared (currently) by
interpreters, due to how adaptive specialization can modify the
bytecodes. We work around this by only using the deep-frozen objects in
the main interpreter. This does incur a performance penalty for
subinterpreters, which we may be able to resolve later.
* Clean up unused variables and imports in the email module
* Remove extra newline char
* Remove superflous dict+unpacking syntax
* Remove unused 'msg' var
* Clean up unused variables and imports in the email module
* Remove extra newline char
* Remove superflous dict+unpacking syntax
* Remove unused 'msg' var
---------
Co-authored-by: Barry Warsaw <barry@python.org>
This removes a section of the `strftime` and `strptime` documentation that refers to a bygone era when `strftime` would return an encoded byte string.
---------
Co-authored-by: Paul Ganssle <1377457+pganssle@users.noreply.github.com>
The new wording better reflects the cases where `datetime.strptime` differs from` time.strptime`.
---------
Co-authored-by: Paul Ganssle <git@m.ganssle.io>
This avoids conflicting with the shebang of the called scripts as well
as avoiding hard errors on platforms where the called script runs a
failing unchecked command in the usual course of checking since
`SHELL=/bin/sh -e` as of a90863c.
Fixes gh-103776.
We replace _PyRuntime.tstate_current with a thread-local variable. As part of this change, we add a _Py_thread_local macro in pyport.h (only for the core runtime) to smooth out the compiler differences. The main motivation here is in support of a per-interpreter GIL, but this change also provides some performance improvement opportunities.
Note that we do not provide a fallback to the thread-local, either falling back to the old tstate_current or to thread-specific storage (PyThread_tss_*()). If that proves problematic then we can circle back. I consider it unlikely, but will run the buildbots to double-check.
Also note that this does not change any of the code related to the GILState API, where it uses a thread state stored in thread-specific storage. I suspect we can combine that with _Py_tss_tstate (from here). However, that can be addressed separately and is not urgent (nor critical).
(While this change was mostly done independently, I did take some inspiration from earlier (~2020) work by @markshannon (main...markshannon:threadstate_in_tls) and @vstinner (#23976).)
The word 'dependent' is both an adjective and a noun. A 'dependant' is a British alternative spelling for the noun form. In idlelib.sidebar, 'OS-dependant' is an adjective and clearly wrong. In 'Using', 'dependant' as a noun would be acceptable in Britain, but we use American spellings in Python docs.
https://www.merriam-webster.com/words-at-play/spelling-variants-dependent-vs-dependant
