[Python-3000] optional argument annotations

[Brett Cannon]

On 11/26/06, Tony Lownds <tony at pagedna.com> wrote:
>
>
> On Nov 26, 2006, at 1:10 PM, Brett Cannon wrote:
>
> On 11/24/06, Tony Lownds <tony at pagedna.com> wrote:
> >
> > > Obviously signature objects would grow support for annotations, but I
> > > still need the information to be carried on the code object to
> > > incorporate into signature objects.
> > >
> >
> > Signature objects still need a way to know the nested parameters, right?
> >
>
>
> They already handle them.
>
>
> I see, through the bytecode inspection that inspect.py does.
>

Yep.

How about a co_argnames attribute? eg for
> >
> > def f((x, y), z): pass
> >
> > f.func_code.co_argnames would be (('x', 'y'), 'z')
>
>
> 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).
>
>
> Yes, it is the compiler that would implement this. I have it implemented
> as follows.
>
> >>> def f(a, (b, c), d=1, *e, f, g=1, **h): pass
> ...
> >>> f.func_code.co_argnames
> ('a', ('b', 'c'), 'd', '*e', 'f', 'g', '**h')
>
> However since inspect.py doesn't need this and neither does my code, I'll
> drop it.
>

OK.

I need to implement something like this to properly build
> > func_annotations
> > inside MAKE_FUNCTION.
>
>
>
> I don't quite follow.  Don't you already have support in MAKE_FUNCTION
> when the object is created?
>
>
> The support available is the code object and anything pushed onto the
> stack. Just looking at the code object,
> the information is simply not available outside of reverse-engineering
> co_code (as inspect does).
> I ended up pushing a tuple of argument names onto the stack.
>
> eg, for
>
> def f((x:1, y))->3: pass
>
> the bytecode is...
>
>   1           0 LOAD_CONST               0 (1)
>               3 LOAD_CONST               1 (3)
>               6 LOAD_CONST               2 (('x', 'return'))
>               9 LOAD_CONST               3 (<code object f at 0xb7ecd848,
> file "<str>", line 1>)
>              12 EXTENDED_ARG             3
>              15 MAKE_FUNCTION        196608
>              18 STORE_NAME               0 (f)
>              21 LOAD_CONST               4 (None)
>              24 RETURN_VALUE
>
> (the argument is so big because I need to pass the # of annotations in the
> argument of MAKE_FUNCTION so
> that the stack effect can be easily calculated)
>

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.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20061127/eb33f641/attachment.htm