On Mon, 19 Jul 2021 at 22:08, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Mon, 19 Jul 2021, 9:32 pm 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?
We've used "Kind" for similar APIs elsewhere, so calling this API "PyLocals_Kind()" would make sense to me.
However, there's a potential point of confusion here, as there's already an implementation level "locals kind" that the runtime uses. This public kind is related to that internal kind, but they're not the same.
Now that I'm on my actual computer rather than my phone, some further details on the new-in-Python-3.11 internal-only API that already refers to "locals kind": Typedef name: _PyLocals_Kind Value flags: CO_FAST_LOCAL, CO_FAST_CELL, CO_FAST_FREE (with more expected to be defined in the future) Frame local variable lookup API: _PyLocals_GetKind, _PyLocals_SetKind Rather than relating to the frame as a whole, these flags relate to individual variables on the frame. CO_FAST_FREE can even be used on non-optimised frames, since classes defined inside functions have access to variables defined in the function scope. Due to this, I'd definitely want to hear Mark Shannon's opinion before we went down the path of using "PyLocals_Kind" (or variations on that theme) as a public API, since we'd need to rename the internal APIs to avoid confusion if we did that. I don't think a rename would be too bad though - since the existing flags relate to individual local variables, my suggestion would be to use `LocalVar` instead of `Locals`, giving the revised enum name _PyLocalVar_Kind, and _PyLocalVar_GetKind and _PyLocalVar_SetKind as the access and update methods. (There are only 27 hits on the _PyLocals prefix across the current 3.11 code base, all relating to this internal API) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia