| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
(GH-118645)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This PR adds the ability to enable the GIL if it was disabled at
interpreter startup, and modifies the multi-phase module initialization
path to enable the GIL when loading a module, unless that module's spec
includes a slot indicating it can run safely without the GIL.
PEP 703 called the constant for the slot `Py_mod_gil_not_used`; I went
with `Py_MOD_GIL_NOT_USED` for consistency with gh-104148.
A warning will be issued up to once per interpreter for the first
GIL-using module that is loaded. If `-v` is given, a shorter message
will be printed to stderr every time a GIL-using module is loaded
(including the first one that issues a warning).
|
| |
|
|
|
|
|
| |
Basically, I've turned most of _PyImport_LoadDynamicModuleWithSpec() into two new functions (_PyImport_GetModInitFunc() and _PyImport_RunModInitFunc()) and moved the rest of it out into _imp_create_dynamic_impl(). There shouldn't be any changes in behavior.
This change makes some future changes simpler. This is particularly relevant to potentially calling each module init function in the main interpreter first. Thus the critical part of the PR is the addition of _PyImport_RunModInitFunc(), which is strictly focused on running the init func and validating the result. A later PR will take it a step farther by capturing error information rather than raising exceptions.
FWIW, this change also helps readers by clarifying a bit more about what happens when an extension/builtin module is imported.
|
| |
|
|
|
|
|
| |
Py_LIMITED_API (gh-111707)
This should have been done in gh-104148.
(A similar fix has already be done for that slot's value macros, and backported to 3.12. See gh-110968.)
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
* Only add Py_MOD_PER_INTERPRETER_GIL_SUPPORTED to limited C API
version 3.13.
* errno, xxlimited and _ctypes_test extensions now need the limited C
API version 3.13 to get Py_MOD_PER_INTERPRETER_GIL_SUPPORTED. They
now include standard header files explicitly: <errno.h>, <string.h>
and <stdio.h>.
* xxlimited_35: Remove Py_mod_multiple_interpreters slot,
incompatible with limited C API version 3.5.
|
| |
|
|
|
|
|
|
|
|
|
| |
Move private _PyModule API to the internal C API
(pycore_moduleobject.h):
* _PyModule_Clear()
* _PyModule_ClearDict()
* _PyModuleSpec_IsInitializing()
* _PyModule_IsExtension()
No longer export these functions.
|
| |
|
| |
Here we are doing no more than adding the value for Py_mod_multiple_interpreters and using it for stdlib modules. We will start checking for it in gh-104206 (once PyInterpreterState.ceval.own_gil is added in gh-104204).
|
| |
|
| |
I'll be adding a value to indicate support for per-interpreter GIL in gh-99114.
|
| |
|
|
|
| |
We also move the closely related max_module_number and add comments documenting the group of struct members.
https://github.com/python/cpython/issues/81057
|
| | |
|
| |
|
|
| |
The PyModuleDef_HEAD_INIT macro now uses _Py_NULL to fix C++ compiler
warnings when using it in C++.
|
| |
|
| |
Move the type definition to pytypedefs.h.
|
| |
|
|
| |
Thanks to the new pytypedefs.h, it becomes to use type names like
PyObject rather like structure names like "struct _object".
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move forward declarations of Python C API types to a new pytypedefs.h
header file to solve interdependency issues between header files.
pytypedefs.h contains forward declarations of the following types:
* PyCodeObject
* PyFrameObject
* PyGetSetDef
* PyInterpreterState
* PyLongObject
* PyMemberDef
* PyMethodDef
* PyModuleDef
* PyObject
* PyThreadState
* PyTypeObject
|
| |
|
|
|
|
|
| |
The Py_FatalError() function and the faulthandler module now dump the
list of extension modules on a fatal error.
Add _Py_DumpExtensionModules() and _PyModule_IsExtension() internal
functions.
|
| |
|
| |
Co-Author: Neil Schemenauer <nas-github@arctrix.com>
|
| | |
|
| |
|
|
| |
(GH-6398)
|
| |\
| |
| |
| |
| | |
available only when Py_LIMITED_API is set to the PY_VERSION_HEX value of
the minimum Python version supporting this API.
|
| | |
| |
| |
| |
| | |
available only when Py_LIMITED_API is set to the PY_VERSION_HEX value of
the minimum Python version supporting this API.
|
| |/
|
|
| |
functions.
|
| |
|
|
|
|
|
|
| |
Multi-phase extension module import now correctly allows the
``m_methods`` field to be used to add module level functions
to instances of non-module types returned from ``Py_create_mod``.
Patch by Xiang Zhang.
|
| |
|
|
| |
Patch by Petr Viktorin.
|
| |
|
|
| |
(stable ABI)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Known limitations of the current implementation:
- documentation changes are incomplete
- there's a reference leak I haven't tracked down yet
The leak is most visible by running:
./python -m test -R3:3 test_importlib
However, you can also see it by running:
./python -X showrefcount
Importing the array or _testmultiphase modules, and
then deleting them from both sys.modules and the local
namespace shows significant increases in the total
number of active references each cycle. By contrast,
with _testcapi (which continues to use single-phase
initialisation) the global refcounts stabilise after
a couple of cycles.
|
| |
|
|
| |
cleaning other modules. The sys and builtins modules are cleaned last.
|
| | |
|
| |
|
|
|
| |
repr(module) uses %R to format module name and filenames, instead of '%s' and
'%U', so surrogates from undecodable bytes in a filename (PEP 383) are escaped.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
zero-initialize all fields, fixing compiler warnings seen when building
extension modules with gcc with "-Wmissing-field-initializers" (implied
by "-W")
|
| |
|
|
|
|
| |
... to get the filename as a unicode object, instead of a byte string. Function
needed to support unencodable filenames. Deprecate PyModule_GetFilename() in
favor on the new function.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
svn+ssh://pythondev@svn.python.org/python/branches/p3yk
................
r56477 | martin.v.loewis | 2007-07-21 09:04:38 +0200 (Sa, 21 Jul 2007) | 11 lines
Merged revisions 56466-56476 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r56476 | martin.v.loewis | 2007-07-21 08:55:02 +0200 (Sa, 21 Jul 2007) | 4 lines
PEP 3123: Provide forward compatibility with Python 3.0, while keeping
backwards compatibility. Add Py_Refcnt, Py_Type, Py_Size, and
PyVarObject_HEAD_INIT.
........
................
r56478 | martin.v.loewis | 2007-07-21 09:47:23 +0200 (Sa, 21 Jul 2007) | 2 lines
PEP 3123: Use proper C inheritance for PyObject.
................
r56479 | martin.v.loewis | 2007-07-21 10:06:55 +0200 (Sa, 21 Jul 2007) | 3 lines
Add longintrepr.h to Python.h, so that the compiler can
see that PyFalse is really some kind of PyObject*.
................
r56480 | martin.v.loewis | 2007-07-21 10:47:18 +0200 (Sa, 21 Jul 2007) | 2 lines
Qualify SHIFT, MASK, BASE.
................
r56482 | martin.v.loewis | 2007-07-21 19:10:57 +0200 (Sa, 21 Jul 2007) | 2 lines
Correctly refer to _ob_next.
................
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In C++, it's an error to pass a string literal to a char* function
without a const_cast(). Rather than require every C++ extension
module to put a cast around string literals, fix the API to state the
const-ness.
I focused on parts of the API where people usually pass literals:
PyArg_ParseTuple() and friends, Py_BuildValue(), PyMethodDef, the type
slots, etc. Predictably, there were a large set of functions that
needed to be fixed as a result of these changes. The most pervasive
change was to make the keyword args list passed to
PyArg_ParseTupleAndKewords() to be a const char *kwlist[].
One cast was required as a result of the changes: A type object
mallocs the memory for its tp_doc slot and later frees it.
PyTypeObject says that tp_doc is const char *; but if the type was
created by type_new(), we know it is safe to cast to char *.
|
| |
|
|
| |
Thanks to Skip Montanaro and Kalle Svensson for the patches.
|
| |
|
|
| |
Preliminary support. What's here works, but needs fine-tuning.
|
| | |
|
| |
|
|
| |
This should match the situation in the 1.6b1 tree.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
clear_carefully() used to do in import.c. Differences: leave only
__builtins__ alone in the 2nd pass; and don't clear the dictionary (on
the theory that as long as there are references left to the
dictionary, those might be destructors that might expect __builtins__
to be alive when they run; and __builtins__ can't normally be part of
a cycle).
|
| | |
|
| | |
|