[Python-Dev] Why co_names? Wouldn't be simpler to just use co_consts?

[Nick Coghlan]

On 29 January 2015 at 04:53, Andrea Griffini <agriff at tin.it> wrote:
> The names stored in op_names are totally unrelated as they can be attribute
> names, module names, global names; you basically don't know much about them
> unless you also inspect the actual bytecode using them (and the same name
> can be used in completely different ways in different parts of the same code
> object). In my opinion introspection code telling me that the name `foo` is
> used but not knowing if it's about a global, a module name or an attribute
> name is not going to be that useful, on the other hand if you do inspect the
> bytecode then using co_consts doesn't make things more complicate.

It makes more sense once you know there are a couple of related passes
over the AST in the compiler, one to build the symbol table (i.e. just
looking at what names exist, where they're defined, and what
references them), and a second pass to do the actual code generation
(already armed with the symbol details from the symbol table pass).

So co_names relates to things that come up in the symbol table pass,
while co_consts is only relevant to actual code generation and
execution. co_names also doesn't get used in isolation - it's combined
with co_varnames and various other attributes in a way that's actually
structured more for the convenience of the interpreter eval loop than
it is for human readers.

As a general rule, by the time we get to the code object level, we're
well down into the weeds of needing to think about how the underlying
Python interpreter *works*, rather than just what it allows a Python
programmer to do.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia