Feature or enhancement

Proposal:

Right now, most uses ofPySequence_Fast are invalid in a nogil context when it is passed an existinglist;PySequence_FAST_ITEMS returns a reference to the internal array ofPyObject*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 atuple (incref-ed and returned unchanged, but safe due to immutability) or any non-list type (converted to newlist) no lock is needed. Per conversation with Dino, going to create macros, to be called after a call toPySequence_Fast, to conditionally lock and unlock theoriginallist when applicable, while avoiding locks in all other cases, before any otherPySequence* 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 inpycore_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