On Mon, Jun 20, 2011 at 7:10 AM, Terry Reedy <tjreedy@udel.edu> wrote:
The main problem of my idea as originally conceived is that it only really works everywhere for constant expressions limited to literals and builtin names (as were my examples). While that would be useful and eliminate one category of default arg misuse, it probably is not enough for new syntax.
Oops, I should have finished reading the thread before replying :)
For general expressions, it is only guaranteed to work as intended for top-level def statements in interactive mode, which are compiled immediately before execution. Otherwise, there is a gap between creation of the code-object and first execution of the def statement. So name-resolution may be too early or even impossible (as it is for .pyc files). Or some new mechanism would be needed to patch the code object.
This gets to the point that compilation time and hence code-object creation time seems more an implementation detail than part of the language def. CPython creates code objects just once for each function body, and reuses them for each def or lambda invocation, but this may be an optimization rather than language requirement.
The compilation time/definition time/execution time split is part of the language definition, as is the immutability of code objects (although, interestingly enough, the compile time distinction is mentioned in the language reference, but not well defined - it is mostly implicit in the definition of the compile() builtin). An implementation doesn't *have* to reuse the code objects when multiple function objects share the same definition, but there's no real reason not to. I created an issue pointing out that these semantics should really be clarified in the execution model section of the language reference: http://bugs.python.org/issue12374 Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia