-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
Improvements to test.support.interpreters.Interpreter #132775
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
3.14
bugs and security fixes
stdlib
Python modules in the Lib dir
topic-subinterpreters
type-feature
A feature request or enhancement
Comments
This was referenced Apr 25, 2025
ericsnowcurrently
added a commit
that referenced
this issue
Apr 28, 2025
…h-132974) This change consists of adding tests and moving code around, with some renaming thrown in.
ericsnowcurrently
added a commit
that referenced
this issue
Apr 28, 2025
…eUTF8() (gh-132979) They are derived from the existing `PyModule_GetFilenameObject(). They are used by a later change related to pickle and handling __main__.
ericsnowcurrently
added a commit
that referenced
this issue
Apr 28, 2025
We replace it with _Py_GetMainModule(), and add _Py_CheckMainModule(), but both in the internal-only C-API. We also add _PyImport_GetModulesRef(), which is the equivalent of _PyImport_GetModules(), but which increfs before the lock is released. This is used by a later change related to pickle and handling __main__.
ericsnowcurrently
added a commit
that referenced
this issue
Apr 28, 2025
This is the base for several other XIData wrappers, like pickle and marshal. It is essentially a refactor of the existing bytes XIData code.
This was referenced Apr 28, 2025
ericsnowcurrently
added a commit
that referenced
this issue
Apr 28, 2025
Note that the bulk of this change is tests.
ericsnowcurrently
added a commit
that referenced
this issue
Apr 29, 2025
The function indicates whether or not the function has a return statement. This is used by a later change related treating some functions like scripts.
Could you elaborate what the "minor issues" are? It isn't clear to me why, for example, #132981 is needed, or if it is the right solution to whatever the problem is. |
ericsnowcurrently
added a commit
that referenced
this issue
Apr 30, 2025
This helper is useful in a variety of ways, including in demonstrating how the different counts relate to one another. It will be used in a later change to help identify if a function is "stateless", meaning it doesn't have any free vars or globals. Note that a majority of this change is tests.
ericsnowcurrently
added a commit
that referenced
this issue
Apr 30, 2025
There's some extra complexity due to making sure we we get things right when handling functions and classes defined in the __main__ module. This is also reflected in the tests, including the addition of extra functions in test.support.import_helper.
ericsnowcurrently
added a commit
to ericsnowcurrently/cpython
that referenced
this issue
May 1, 2025
This reverts commit 94b4fcd.
ericsnowcurrently
added a commit
that referenced
this issue
May 1, 2025
ericsnowcurrently
added a commit
to ericsnowcurrently/cpython
that referenced
this issue
May 1, 2025
This reverts commit 811edcf (pythongh-133128).
ericsnowcurrently
added a commit
that referenced
this issue
May 5, 2025
"Stateless" code is a function or code object which does not rely on external state or internal state. It may rely on arguments and builtins, but not globals or a closure. I've left a comment in pycore_code.h that provides more detail. We also add _PyFunction_VerifyStateless(). The new functions will be used in several later changes that facilitate "sharing" functions and code objects between interpreters.
This was referenced May 5, 2025
ericsnowcurrently
added a commit
that referenced
this issue
May 5, 2025
…gh-133472) This is a follow-up to gh-133107. I realized that we could end up with an infinite recursion if we try to run a function from __main__ in a subinterpreter.
ericsnowcurrently
added a commit
that referenced
this issue
May 5, 2025
This was referenced May 5, 2025
encukou
added a commit
to encukou/cpython
that referenced
this issue
May 6, 2025
…)" This reverts commit d270bb5. Note that the test functions in _code_definitions are not reverted.
hugovk
pushed a commit
that referenced
this issue
May 6, 2025
ericsnowcurrently
added a commit
to ericsnowcurrently/cpython
that referenced
this issue
May 6, 2025
…tateless() (pythongh-133221)" (python#133497)" This reverts commit 3c73cf5.
This was referenced May 6, 2025
miss-islington
pushed a commit
to miss-islington/cpython
that referenced
this issue
May 8, 2025
This converts functions, code, str, bytes, bytearray, and memoryview objects to PyCodeObject, and ensure that the object looks like a script. That means no args, no return, and no closure. _PyCode_GetPureScriptXIData() takes it a step further and ensures there are no globals. We also add _PyObject_SupportedAsScript() to the internal C-API. (cherry picked from commit c81fa2b) Co-authored-by: Eric Snow <[email protected]>
ChVeen
pushed a commit
to ChVeen/cpython
that referenced
this issue
May 8, 2025
This converts functions, code, str, bytes, bytearray, and memoryview objects to PyCodeObject, and ensure that the object looks like a script. That means no args, no return, and no closure. _PyCode_GetPureScriptXIData() takes it a step further and ensures there are no globals. We also add _PyObject_SupportedAsScript() to the internal C-API.
ericsnowcurrently
added a commit
that referenced
this issue
May 8, 2025
This converts functions, code, str, bytes, bytearray, and memoryview objects to PyCodeObject, and ensure that the object looks like a script. That means no args, no return, and no closure. _PyCode_GetPureScriptXIData() takes it a step further and ensures there are no globals. We also add _PyObject_SupportedAsScript() to the internal C-API. (cherry picked from commit c81fa2b, AKA gh-133480) Co-authored-by: Eric Snow <[email protected]>
ericsnowcurrently
added a commit
that referenced
this issue
May 12, 2025
miss-islington
pushed a commit
to miss-islington/cpython
that referenced
this issue
May 12, 2025
(cherry picked from commit 8cf4947) Co-authored-by: Eric Snow <[email protected]>
ericsnowcurrently
added a commit
that referenced
this issue
May 12, 2025
(cherry picked from commit 8cf4947, AKA gh-133481) Co-authored-by: Eric Snow <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
3.14
bugs and security fixes
stdlib
Python modules in the Lib dir
topic-subinterpreters
type-feature
A feature request or enhancement
Interpreter.call()
should be able to support arbitrary callables, full args, and return values.Linked PRs
The text was updated successfully, but these errors were encountered: