On 6/19/2011 3:28 PM, Jim Jewett wrote:
On Fri, Jun 17, 2011 at 4:58 PM, Terry Reedy<tjreedy@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