On 21. 07. 21 14:18, Nick Coghlan wrote:
> On Mon, 19 Jul 2021 at 21:32, Petr Viktorin <encukou@gmail.com> wrote:
>> The proposal assumes that in the future, ``PyLocals_Get``, and thus
>> ``locals()``, will never gain another kind of return value, however
>> unlikely that is.
>> AFAICS, code that uses this will usually check for a single special case
>> and fall back (or error) for the other(s), so I think it'd be reasonable
>> to make this an "enum" with two values. e.g.:
>>
>> int PyLocals_GetReturnBehavior();  # better name?
>> #define PyLocals_DIRECT_REFERENCE 0
>> #define PyLocals_SHALLOW_COPY 1
>
> After looking at PyUnicode_Kind, PySendResult, and other already
> public enums for inspiration, my proposed spelling is as follows:
>
> ====================
> typedef enum {
>      PyLocals_UNDEFINED = -1;
>      PyLocals_DIRECT_REFERENCE = 0,
>      PyLocals_SHALLOW_COPY = 1
> } PyLocals_Kind;
>
> PyLocals_Kind PyLocals_GetKind(void);
> PyLocals_Kind PyFrame_GetLocalsKind(PyFrameObject *);
> ====================
>
> The PyLocals_UNDEFINED case comes from PyLocals_GetKind() needing an
> error value to return when the query API is called with no active
> thread state.
>
> I've updated the draft reference implementation to use this API, and
> added the associated PEP changes to the review PR at
> https://github.com/python/peps/pull/2038/files

Please don't put the enum in the stable ABI. If we would add another
value and then an older extension would receive it, we'd get undefined
behavior.