GeezerVison

Some thoughts on the API.

I don't like the word "fast". It has no meaning and just makes names longer. I'd much prefer "variables" to "fastlocals".
The point of your refactoring was to hide implementation details, but by exposing things like the arrays of locals and kinds we are just exposing different ones.

So I was thinking...
What is the use case for accessing this data? Presumably debuggers, profilers and dis.
Would it not be more useful for them to be able to query the metadata, rather than having to parse it?
E.g. (and this is just off the top of my head)

class CodeType:
     def get_variable_name(self, n:int):
           "Return the names of the nth variable"
     def get_variable_scope(self, n:int):
           "Returns the scope of the nth var (one of LOCAL, ESCAPES, FREE)"
     def get_variable_kind(self, n:int):
           "Return the kind of nth var (one of LOCAL, ARG, VARARG, etc)"

or

class CodeType:
     def get_variable_metadata(self, n:int):
          "Returns a triple (name, scope, kind) for nth variable"

What do you think?

I don't like the word "fast". It has no meaning and just makes names longer. I'd much prefer "variables" to "fastlocals".

Yeah, they were fast several decades ago when this was an improvement over storing locals in a dict. :-) But it's a traditional name, and changing it would just add a bunch of additional unneeded churn (e.g. we have LOAD_FAST etc. -- to be consistent you'd have to rename those too).

Plus, these locals really are pretty fast. :-)

[...]

Would it not be more useful for them to be able to query the metadata, rather than having to parse it?

At least some debuggers access this data in C, so we'd have to introduce C API functions as well. I don't think we'll actually be able to come up with abstractions that won't have to change if this stuff changes again in the future.

I think that at least for this PR, we should leave well enough alone -- at some point in the future, co_fastlocalnames and friends will be presumably lazily computed, at least when accessed from Python code (e.g. pdb, dis).

If the abstraction models the language, then it shouldn't need to change (unless the language does).

The scope (local, escapes, or free), the kind (arg, kwarg, non-arg, etc), and the name are all properties of the variable and independent of the data structures used.

Why not do it now? What is the advantage of exposing things to hide them later.

Some thoughts on the API.

[...]

What do you think?

I'm fine with taking a more neutral approach, along the lines you suggested. However, I don't want to introduce a new public API (in Python or in C) in this PR.

@markshannon, please take another look at this PR when you get the chance.

Windows warnings need fixing: https://github.com/python/cpython/pull/26388/files#diff-ebc983d9f91e5bcf73500e377ac65e85863c4f77fd5b6b6caf4fcdf7c0f0b057R7253

You say that you don't want to add a public API, but that is what you are doing by adding co_fastlocalnames and co_fastlocalkinds.
I'd rather that we added the API first then changed the implementation behind that API, but to get things moving can you just make the attributes "private" by prefixing them with an underscore?

You say that you don't want to add a public API, but that is what you are doing by adding co_fastlocalnames and co_fastlocalkinds.
I'd rather that we added the API first then changed the implementation behind that API, but to get things moving can you just make the attributes "private" by prefixing them with an underscore?

You mean the fields on the struct? I was talking about the attributes exposed to Python code. As far as the struct goes, I'm fine with adding an underscore prefix but I don't see the point since using the fields is required and given the class of expected users. I'd rather make PyCodeObject opaque in the public C-API (moving it to Include/internal/pycore_code.h), but that is a separate matter.

In the meantime I will add an undercore prefix to those fields so we can move this along.

I meant the Python attributes, but it looks like you've already removed them 👍

Thanks, @markshannon!