On 19 Nov., 10:14, Peter Otten <[EMAIL PROTECTED]> wrote:
>
> Every code object has its own co_names attribute (a tuple). The arguments
> are offsets into that tuple.
>
> Using Python 2.5 I can't reproduce your example, I get 0 offsets in both
> cases. Here's a simpler one:
>
> >>> import dis
> >>> def f():
>
> ... x
> ... y
> ...>>> def g():
>
> ... y
> ...>>> dis.dis(f)
>
> 2 0 LOAD_GLOBAL 0 (x)
> 3 POP_TOP
>
> 3 4 LOAD_GLOBAL 1 (y)
> 7 POP_TOP
> 8 LOAD_CONST 0 (None)
> 11 RETURN_VALUE>>> dis.dis(g)
>
> 2 0 LOAD_GLOBAL 0 (y)
> 3 POP_TOP
> 4 LOAD_CONST 0 (None)
> 7 RETURN_VALUE>>> f.func_code.co_names
> ('x', 'y')
> >>> g.func_code.co_names
>
> ('y',)
>
> Peter
Ok, thanks a lot. That helped me understand the offsets. Your
disassembly misses the code in the global scope that creates the two
methods from the code objects. That code looks like this for your
example (dis won't give you this. I use a modified version of the
byteplay disassembler which can disassemble a module without loading
it):
1, LOAD_CONST, 1 //Loads the code object for function f
4, MAKE_FUNCTION, 0 //Creates a function from the code object
7, STORE_NAME, 0 //Stores it as 'f' using STORE_NAME
10, LOAD_CONST, 2 //Loads the code object for function g
13, MAKE_FUNCTION, 0 //Creates the function
16, STORE_NAME, 1 //Stores it as 'g' using STORE_NAME
19, LOAD_CONST, 0 //Loads None
22, RETURN_VALUE, None //Exists the program with status None
The two last bytecodes are there because I didn't use the interactive
mode. I guess I narrowed down my other question to whether the
semantics are that stuff saved using STORE_NAME in the global scope
can be loaded everywhere else using LOAD_GLOBAL. What baffled me was
that there is actually a STORE_GLOBAL byte code.
--
http://mail.python.org/mailman/listinfo/python-list
