<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Nov 26, 2006, at 1:10 PM, Brett Cannon wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><DIV><SPAN class="gmail_quote">On 11/24/06, <B class="gmail_sendername">Tony Lownds</B> <<A href="mailto:tony@pagedna.com">tony@pagedna.com</A>> wrote:</SPAN><BLOCKQUOTE class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > Obviously signature objects would grow support for annotations, but I<BR>> still need the information to be carried on the code object to<BR>> incorporate into signature objects.<BR>><BR><BR>Signature objects still need a way to know the nested parameters, right? </BLOCKQUOTE><DIV><BR>They already handle them. <BR></DIV><BR></DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I see, through the bytecode inspection that inspect.py does.</DIV><BR><BLOCKQUOTE type="cite"><DIV><BLOCKQUOTE class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">How about a co_argnames attribute? eg for <BR><BR>def f((x, y), z): pass<BR><BR>f.func_code.co_argnames would be (('x', 'y'), 'z')</BLOCKQUOTE><DIV><BR>That's fine, but the compiler would need to change if it were to use this. Plus I am still hoping to make nested parameters disappear in Py3K (I won't be pushing for it any sooner than PyCon, though). <BR></DIV><BR></DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Yes, it is the compiler that would implement this. I have it implemented as follows.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>>>> def f(a, (b, c), d=1, *e, f, g=1, **h): pass</DIV><DIV>... </DIV><DIV>>>> f.func_code.co_argnames</DIV><DIV>('a', ('b', 'c'), 'd', '*e', 'f', 'g', '**h')</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>However since inspect.py doesn't need this and neither does my code, I'll drop it.</DIV><BR><BLOCKQUOTE type="cite"><DIV><BLOCKQUOTE class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I need to implement something like this to properly build<BR>func_annotations<BR> inside MAKE_FUNCTION.</BLOCKQUOTE><DIV><BR><BR>I don't quite follow. Don't you already have support in MAKE_FUNCTION when the object is created?<BR><BR></DIV></DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV></DIV><DIV>The support available is the code object and anything pushed onto the stack. Just looking at the code object,</DIV><DIV>the information is simply not available outside of reverse-engineering co_code (as inspect does).</DIV><DIV>I ended up pushing a tuple of argument names onto the stack.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>eg, for</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>def f((x:1, y))->3: pass</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>the bytecode is...</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV> 1 0 LOAD_CONST 0 (1)</DIV><DIV> 3 LOAD_CONST 1 (3)</DIV><DIV> 6 LOAD_CONST 2 (('x', 'return'))</DIV><DIV> 9 LOAD_CONST 3 (<code object f at 0xb7ecd848, file "<str>", line 1>)</DIV><DIV> 12 EXTENDED_ARG 3</DIV><DIV> 15 MAKE_FUNCTION 196608 </DIV><DIV> 18 STORE_NAME 0 (f)</DIV><DIV> 21 LOAD_CONST 4 (None)</DIV><DIV> 24 RETURN_VALUE </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>(the argument is so big because I need to pass the # of annotations in the argument of MAKE_FUNCTION so </DIV><DIV>that the stack effect can be easily calculated)</DIV><DIV><BR class="khtml-block-placeholder"></DIV></BODY></HTML>