- move the Py_Main documentation from the very high level API section
to the initialization and finalization section
- make it clear that it encapsulates a full Py_Initialize/Finalize
cycle of its own
- point out that exactly which settings will be read and applied
correctly when Py_Main is called after a separate runtime
initialization call is version dependent
- be explicit that Py_IsInitialized can be called prior to
initialization
- actually test that Py_IsInitialized can be called prior to
initialization
- flush stdout in the embedding tests that run code so it appears
in the expected order when running with "-vv"
- make "-vv" on the subinterpreter embedding tests less spammy
---------
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
The term "free variable" has unfortunately become genuinely
ambiguous over the years (presumably due to the names of
some relevant code object instance attributes).
While we can't eliminate that ambiguity at this late date, we can
at least alert people to the potential ambiguity by describing
both the formal meaning of the term and the common
alternative use as a direct synonym for "closure variable".
---------
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
Instead of surprise crashes and memory corruption, we now hang threads that attempt to re-enter the Python interpreter after Python runtime finalization has started. These are typically daemon threads (our long standing mis-feature) but could also be threads spawned by extension modules that then try to call into Python. This marks the `PyThread_exit_thread` public C API as deprecated as there is no plausible safe way to accomplish that on any supported platform in the face of things like C++ code with finalizers anywhere on a thread's stack. Doing this was the least bad option.
Co-authored-by: Gregory P. Smith <greg@krypto.org>
Make `versionchanged:: next`` expand to current (unreleased) version.
When a new CPython release is cut, the release manager will replace
all such occurences of "next" with the just-released version.
(See the issue for release-tools and devguide PRs.)
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Add PyConfig_Get(), PyConfig_GetInt(), PyConfig_Set() and
PyConfig_Names() functions to get and set the current runtime Python
configuration.
Add visibility and "sys spec" to config and preconfig specifications.
_PyConfig_AsDict() now converts PyConfig.xoptions as a dictionary.
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
Return -1 and set an exception on error; return 0 if the iterator is
exhausted, and return 1 if the next item was fetched successfully.
Prefer this API to PyIter_Next(), which requires the caller to use
PyErr_Occurred() to differentiate between iterator exhaustion and errors.
Co-authered-by: Irit Katriel <iritkatriel@yahoo.com>
Corrected some grammar and spelling issues in documentation.
Co-authored-by: Russell Keith-Magee <russell@keith-magee.com>
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
* Switch PyUnicode_InternInPlace to _PyUnicode_InternMortal, clarify docs
* Document immortality in some functions that take `const char *`
This is PyUnicode_InternFromString;
PyDict_SetItemString, PyObject_SetAttrString;
PyObject_DelAttrString; PyUnicode_InternFromString;
and the PyModule_Add convenience functions.
Always point out a non-immortalizing alternative.
* Don't immortalize user-provided attr names in _ctypes
Alyssa Coghlan
Victor Stinner
ffelixg
Donghee Na
Jeremy Maitin-Shepard
Pablo Galindo Salgado
Petr Viktorin
Max Bachmann
Alex Waygood
Jason Fried
Adam Turner
Sergey B Kirpichev
neonene
Rafael Fontenelle
Oleg Iarygin
Wenzel Jakob
Peter Bierma
Wei-Hsiang (Matt) Wang
Wulian
sobolevn
Eddie Elizondo
Erlend E. Aasland
Ville Skyttä
Serhiy Storchaka