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

[Terry Reedy]

On 6/19/2011 3:28 PM, Jim Jewett wrote:
> On Fri, Jun 17, 2011 at 4:58 PM, Terry Reedy<tjreedy at udel.edu>  wrote:
>> On 6/17/2011 9:26 AM, Nick Coghlan wrote:
>
>>> This is why the nonlocal and global directives exist: to tell the
>>> compiler to change how it treats certain names. Arguments (including
>>> the associated default values) are given additional special treatment
>>> due to their placement in the function header. If we want to create a
>>> new namespace that is given special treatment by the compiler,
>
>> I do not really want a new namespace and for the purpose of the OP,
>> named local constants (for speed or freezing the meaning of an
>> expression or both), we do not need one.  There is already a fourth
>> 'namespace' for constants, a tuple f.__code__.co_consts, whose
>> 'names' are indexes, just as with the locals array.
>
> I really like this idea.
>
> The only concerns I can see are losing the name for use in debugging
> or embedded functions, and I assume that those can be dealt with.

I consider that a secondary detail. If the names are recorded, in a 
method that distinguishes them from parameter names, then they can be 
introspected, just like other local names. They could be included in 
locals(), though I hardly ever use that and am not familiar with the 
details of its runtime construction.

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.

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.

-- 
Terry Jan Reedy