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
bpo-37222: Fix for CacheFTPHandler in urllib
A call to FTP.ntransfercmd must be followed by FTP.voidresp to clear
the "end transfer" message. Without this, the client and server get
out of sync, which will result in an error if the FTP instance is
reused to open a second URL. This scenario occurs for even the most
basic usage of CacheFTPHandler.
Reverts the patch merged as a resolution to bpo-16270 and adds a test
case for the CacheFTPHandler in test_urllib2net.py.
Co-authored-by: Senthil Kumaran <senthil@python.org>
This is the implementation of PEP683
Motivation:
The PR introduces the ability to immortalize instances in CPython which bypasses reference counting. Tagging objects as immortal allows up to skip certain operations when we know that the object will be around for the entire execution of the runtime.
Note that this by itself will bring a performance regression to the runtime due to the extra reference count checks. However, this brings the ability of having truly immutable objects that are useful in other contexts such as immutable data sharing between sub-interpreters.