Why co_names? Wouldn't be simpler to just use co_consts?
Sorry if the question is naive, but why is co_names needed? Wouldn't be simpler to just use co_consts? Andrea
Andrea Griffini wrote:
Sorry if the question is naive, but why is co_names needed? Wouldn't be simpler to just use co_consts?
One reason might be that keeping them separate means you can have up to 256 names and 256 consts using 1-byte opcode arguments. Otherwise, you'd be limited to a total of 256 of both. -- Greg
On 28 January 2015 at 21:21, Greg Ewing
Andrea Griffini wrote:
Sorry if the question is naive, but why is co_names needed? Wouldn't be simpler to just use co_consts?
One reason might be that keeping them separate means you can have up to 256 names and 256 consts using 1-byte opcode arguments. Otherwise, you'd be limited to a total of 256 of both.
They're logically distinct things accessed by different opcodes for very different purposes. While you theoretically *could* use one array to hold both, it would make the eval code harder to read, and various introspection tasks (like "tell me all the names referenced from this code object") significantly more difficult. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
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.
Anyway I was just curious to know if there was any technical reason (that I
couldn't see) or if it was more a style/historic reason.
Thank you for the clarification
On Wed, Jan 28, 2015 at 1:40 PM, Nick Coghlan
On 28 January 2015 at 21:21, Greg Ewing
wrote: Andrea Griffini wrote:
Sorry if the question is naive, but why is co_names needed? Wouldn't be simpler to just use co_consts?
One reason might be that keeping them separate means you can have up to 256 names and 256 consts using 1-byte opcode arguments. Otherwise, you'd be limited to a total of 256 of both.
They're logically distinct things accessed by different opcodes for very different purposes. While you theoretically *could* use one array to hold both, it would make the eval code harder to read, and various introspection tasks (like "tell me all the names referenced from this code object") significantly more difficult.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/agriff%40tin.it
On 29 January 2015 at 04:53, Andrea Griffini
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@gmail.com | Brisbane, Australia
participants (3)
-
Andrea Griffini
-
Greg Ewing
-
Nick Coghlan