| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
(gh-101920)
The test verifies the behavior of single-phase init modules when loaded in multiple interpreters.
https://github.com/python/cpython/issues/101758
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change is almost entirely moving code around and hiding import state behind internal API. We introduce no changes to behavior, nor to non-internal API. (Since there was already going to be a lot of churn, I took this as an opportunity to re-organize import.c into topically-grouped sections of code.) The motivation is to simplify a number of upcoming changes.
Specific changes:
* move existing import-related code to import.c, wherever possible
* add internal API for interacting with import state (both global and per-interpreter)
* use only API outside of import.c (to limit churn there when changing the location, etc.)
* consolidate the import-related state of PyInterpreterState into a single struct field (this changes layout slightly)
* add macros for import state in import.c (to simplify changing the location)
* group code in import.c into sections
*remove _PyState_AddModule()
https://github.com/python/cpython/issues/101758
|
|
|
| |
Automerge-Triggered-By: GH:erlend-aasland
|
|
|
| |
Fix refleak in SEND instruction.
|
|
|
|
|
| |
The new test exercises the most important variants for single-phase init extension modules. We also add some explanation about those variants to import.c.
https://github.com/python/cpython/issues/101758
|
| |
|
| |
|
|
|
|
| |
coroutines. (GH-101788)
|
|
|
| |
Co-authored-by: Eric Snow <ericsnowcurrently@gmail.com>
|
|
|
|
|
|
|
|
|
|
| |
* Write output and metadata in a single run
This halves the time to run the cases generator
(most of the time goes into parsing the input).
* Declare or define opcode metadata based on NEED_OPCODE_TABLES
* Use generated metadata for stack_effect()
* compile.o depends on opcode_metadata.h
* Return -1 from _PyOpcode_num_popped/pushed for unknown opcode
|
|
|
| |
Includes a slight improvement to `DECREF_INPUTS()`.
|
| |
|
|
|
|
| |
modules for incompatibility (GH-101615)
|
|
|
|
|
|
|
|
|
|
| |
* Make sure that the current exception is always normalized.
* Remove redundant type and traceback fields for the current exception.
* Add new API functions: PyErr_GetRaisedException, PyErr_SetRaisedException
* Add new API functions: PyException_GetArgs, PyException_SetArgs
|
|
|
| |
New generator feature: Move CHECK_EVAL_BREAKER() call to just before DISPATCH().
|
|
|
| |
Generator update: support balanced parentheses and brackets in conditions and size expressions.
|
|
|
| |
New generator feature: Generate useful glue for output arrays, so you can just write values to the output array (no bounds checking). Rewrote UNPACK_SEQUENCE_TWO_TUPLE to use this, and also UNPACK_SEQUENCE_{TUPLE,LIST}.
|
| |
|
|
|
|
| |
the instruction definition DSL (#101641)
|
|
|
| |
Co-authored-by: Irit Katriel <1055913+iritkatriel@users.noreply.github.com>
|
|
|
|
|
| |
(#101127)
Co-authored-by: Łukasz Langa <lukasz@langa.pl>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
(gh-101431)
The GILState API (PEP 311) implementation from 2003 made the assumption that only one thread state would ever be used for any given OS thread, explicitly disregarding the case of subinterpreters. However, PyThreadState_Swap() still facilitated switching between subinterpreters, meaning the "current" thread state (holding the GIL), and the GILState thread state could end up out of sync, causing problems (including crashes).
This change addresses the issue by keeping the two in sync in PyThreadState_Swap(). I verified the fix against gh-99040.
Note that the other GILState-subinterpreter incompatibility (with autoInterpreterState) is not resolved here.
https://github.com/python/cpython/issues/59956
|
|
|
|
| |
definition DSL (#101529)
|
|
|
|
| |
instruction definition DSL (#101516)
|
|
|
|
| |
DSL (#101511)
|
| |
|
|
|
|
| |
definition DSL (#101481)
|
| |
|
| |
|
|
|
|
| |
definition DSL (#101458)
|
|
|
|
| |
the instruction definition DSL (#101443)
|
|
|
|
| |
RETURN_IF_ERROR where appropriate. Fix a couple of bugs. (#101412)
|
|
|
|
| |
are not in a loop (#101413)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A PyThreadState can be in one of many states in its lifecycle, represented by some status value. Those statuses haven't been particularly clear, so we're addressing that here. Specifically:
* made the distinct lifecycle statuses clear on PyThreadState
* identified expectations of how various lifecycle-related functions relate to status
* noted the various places where those expectations don't match the actual behavior
At some point we'll need to address the mismatches.
(This change also includes some cleanup.)
https://github.com/python/cpython/issues/59956
|
|
|
|
| |
PyLongValue struct. (GH-101292)
|
| |
|
| |
|
|
|
|
|
| |
`warnings.warn()` gains the ability to skip stack frames based on code
filename prefix rather than only a numeric `stacklevel=` via a new
`skip_file_prefixes=` keyword argument.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The comment at the top was rather outdated. :-)
Also added a note about the dangers of dump_stack().
|
|
|
|
| |
(#101287)
|
|
|
|
|
|
| |
(GH-101013)
* Store exception stack depth in YIELD_VALUE's oparg and use it avoid expensive gen.throw() in gen.close() where possible.
|
|
|
|
| |
(#101269)
|
|
|
|
|
|
|
|
|
|
|
|
| |
(gh-101209)
We've factored out a struct from the two PyThreadState fields. This accomplishes two things:
* make it clear that the trashcan-related code doesn't need any other parts of PyThreadState
* allows us to use the trashcan mechanism even when there isn't a "current" thread state
We still expect the caller to hold the GIL.
https://github.com/python/cpython/issues/59956
|
| |
|
|
|
| |
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
|
|
|
|
|
| |
This is a follow-up to gh-101161. The objective is to make it easier to read Python/pystate.c by grouping the functions there in a consistent way. This exclusively involves moving code around and adding various kinds of comments.
https://github.com/python/cpython/issues/59956
|