<br><br><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><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><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>-Brett <br></div><br><br></div>