[Python-ideas] 'Injecting' objects as function-local constants
tjreedy at udel.edu
Sun Jun 19 23:10:38 CEST 2011
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
More information about the Python-ideas