Feature or enhancement

Proposal:

Right now, most uses of PySequence_Fast are invalid in a nogil context when it is passed an existing list; PySequence_FAST_ITEMS returns a reference to the internal array of PyObject*s that can be resized at any time if other threads add or delete items, PySequence_FAST_GET_SIZE similarly reports a size that is invalid an instant after it's reported. Similarly, if individual items are replaced without changing size, you'd have similar issues.

But when the argument passed is a tuple (incref-ed and returned unchanged, but safe due to immutability) or any non-list type (converted to new list) no lock is needed. Per conversation with Dino, going to create macros, to be called after a call to PySequence_Fast, to conditionally lock and unlock the original list when applicable, while avoiding locks in all other cases, before any other PySequence* APIs are used.

Preliminary (subject to bike-shedding) macro names are:

Py_BEGIN_CRITICAL_SECTION_SEQUENCE_FAST
Py_END_CRITICAL_SECTION_SEQUENCE_FAST

both defined in pycore_critical_section.h.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

Discussion occurred with Dino during CPython core sprints.

Linked PRs

• gh-119247: Add macros to use PySequence_Fast safely in free-threaded build #119315
• [3.13] gh-119247: Add macros to use PySequence_Fast safely in free-threaded build (GH-119315) #119419