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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
