[Python-3000] PEP 3107 - Function Annotations

[Tony Lownds]

On Jan 6, 2007, at 11:45 AM, Phillip J. Eby wrote:

> At 11:13 AM 1/6/2007 -0800, Tony Lownds wrote:
>
>> On Jan 5, 2007, at 9:18 AM, Phillip J. Eby wrote:
>>
>>> At 10:53 PM 12/27/2006 -0800, Neal Norwitz wrote:
>>>>  * 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.
>>>
>>> Why not just follow the MAKE_FUNCTION with the calculation of the
>>> annotations, followed by a STORE_ATTR to attach them to the
>>> function?  Why do we have to change MAKE_FUNCTION for this?
>>> (I.e., can't we just compute the annotation values *after* the
>>> function is created, but before it's bound to its name?)
>>
>> Yes, it's possible, I tried the approach and it was more C code, more
>> bytecode, and it ran slower.
>
> ...and doesn't require EXTENDED_ARG,

Is that a problem in and of itself?

> doesn't introduce a new
> backward-compatibility issue for PyPy, Psyco, or other bytecode- 
> based tools
> (I'm assuming here we'll want to backport annotations to 2.x)

Keyword-only arguments also introduces a backward-compatibility  
issue; so
the additional work to understand the annotations portion of  
Python-3000's
MAKE_FUNCTION is not large.

> or require
> changes to the optimizer.

A pretty small change.

> The additional bytecode and slowdown, IIUC, amounts to a few stack
> manipulations per annotation; the computation of the annotation values
> themselves should still be the bulk of the time used, unless the  
> values are
> constants.

Yes, that's probably the case. Also, MAKE_FUNCTION is not often executed
in a loop, so the runtime speed of that opcode probably doesn't  
matter much.

-Tony