<br><br><div><span class="gmail_quote">On 11/26/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;">
<div style=""><br><div><span class="q"><div>On Nov 26, 2006, at 1:10 PM, Brett Cannon wrote:</div><br><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" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
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></div></span><div>I see, through the bytecode inspection that inspect.py does.</div></div></div></blockquote><div><br>Yep.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div><span class="q"><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></div></span><div>Yes, it is the compiler that would implement this. I have it implemented as follows.</div><div><br></div><div>>>> def f(a, (b, c), d=1, *e, f, g=1, **h): pass
</div><span class="q"><div>... </div><div>>>> f.func_code.co_argnames</div></span><div>('a', ('b', 'c'), 'd', '*e', 'f', 'g', '**h')</div><div><br></div><div>However since inspect.py doesn't need this and neither does my code, I'll drop it.
</div></div></div></blockquote><div><br>OK. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div><span class="q">
<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></div></span></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></div><div>eg, for</div><div>
<br></div><div>def f((x:1, y))->3: pass</div><div><br></div><div>the bytecode is...</div><div><br></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></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></blockquote><div><br>Ah, I see how you are doing it. Well, as I said, as long as the info is available in some way that can be used to infer what the type annotations are per argument then I should be fine. It doesn't have to be overly clean just for signature objects.
<br><br>-Brett<br></div><br></div><br>