[Python-ideas] 'Injecting' objects as function-local constants

[Nick Coghlan]

On Mon, Jun 20, 2011 at 7:10 AM, Terry Reedy <tjreedy at 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 at gmail.com   |   Brisbane, Australia