[Python-3000] PEP 3107 - Function Annotations
tony at pagedna.com
Thu Dec 28 17:13:05 CET 2006
On Dec 27, 2006, at 10:53 PM, Neal Norwitz wrote:
> I checked in a modified version of the patch (rev 53170). Mostly I:
> * added error checking
> * updated N_TOKENS in Include/token.h (and Lib/token.py) since a
> token was added
> * Changed some code in Lib/compiler/pycodegen.py (I couldn't let
> Guido see a 2-space indent or he might think Google had corrupted you
> * Made "return" an interned string
> Some outstanding questions I have:
> * Should annotations be allowed to be a subclass of dict?
> (currently subclasses of dicts are allowed, but generic mappings
> are not)
A subclass should be fine. There is no need to check for exactly a dict.
> * With the modification of MAKE_FUNCTION to be a 32-bit value, this
> means that EXTENDED_ARG is now used. This means that the peephole
> optimizer won't work for the outer function. I think we should
> correct this.
Ok. Something like this should fix it in peephople.c. I can post a
@@ -535,8 +535,13 @@
- goto exitUnchanged;
+ if (codestr[i+3] != MAKE_FUNCTION)
+ goto exitUnchanged;
+ /* don't visit MAKE_FUNCTION as
GETARG will be wrong */
+ i += 3;
> * I don't understand why there was a new annotations (flag) parameter
> added in symtable. My guess was that this was to support lambdas
> without annotations. If this is true, it would be nicer if we didn't
> have to special case. I think there was talk about requiring parens
> around lambda params. I don't recall the outcome though.
The flag is there to re-use the logic for visiting parameters, once
annotations, once for the parameter names. Those need to be separate
because the parameter names are added to the functions symbol table,
to the outer symbol table.
The thread about requiring parens was here, I took the outcome to be
> * We should update doc
I will start looking at the doc changes that are needed.
> Tony, you cleaned up quite a few places in the AST, care to do more
> cleanup? I liked your refactorings.
Sure, anything in particular?
> I also don't love all the names in Grammar. Guido had mentioned about
> cleaning up the Grammar. I don't know if he still wants to or if it
> can be improved. It would be nice once all the basic features are in
> if we could make a cleanup pass for things like Grammar, obsolete
> APIs, etc.
The only name changes I made in Grammar were made to allow
the same compiler code to process either lambda's arguments without
annotations or def's arguments with annotations. fpdef became tfpdef
and vfpdef, fplist became tfplist and vfplist. tname is a new
that holds the annotation itself, and vname is the corresponding version
without an annotation. "tname" replaced NAME in many places.
Maybe there is a better naming convention that "t" and "v" prefixes? Or
perhaps "tname/vname" could be improved?
More information about the Python-3000