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

[Terry Reedy]

On 6/19/2011 2:56 AM, Nick Coghlan wrote:

> Indeed. If anyone was curious as to why I've been recently trying to
> steer the discussion back specifically towards Jan's original idea of
> replacing current (ab)uses of the default argument hack (and nothing
> more), this is pretty much it.

Along that line, I posted the following concrete suggestion a couple of 
days ago, but have seen no response:
'''
for the purpose of the OP, named local constants (for speed or freezing 
the meaning of an expression or both), we do not need [a new namespace]. 
There is already a fourth 'namespace' for constants, a tuple 
f.__code__.co_consts, whose 'names' are indexes, just as with the locals 
array. Given

def f(a, **, b=1001, len = len): return 2001 # one possible spelling

def f(a):                                    # alternate
     constant b = 1001, len = len
     return 2001

the compiler should put 1001 and len into co.consts and convert 'b' and 
'len' into the corresponding indexes, just like it does with 'a', and 
use the LOAD_CONST bytecode just as with literal constants like 2001 in 
the body. Constant names would not go into .co_names and not increment 
.co_argcount. This would make named constants as fast and def-time 
frozen as default args without the disadvantages of being included in 
the signature and over-writable on calls.
'''
Did this not actually go through?

> We *know* those use cases exist because there is code in the wild that
> uses them (including in the standard library). Saying "don't do that"
> isn't an adequate response as, for anyone that knows about the hack
> and how it works, the alternatives are far harder to read (in addition
> to being far more verbose and error prone to write in the first
> place).
>
> Extrapolating to additional functionality that is difficult or
> impossible in current Python code is sheer speculation that is likely
> to weigh down any proposal with unnecessary cruft that gets it
> rejected.
>
> What is needed now is one or more volunteers that are willing and able to:
>
> 1. Write a PEP that:
>    - distils the core discussion in this thread down into a specific
> proposal that can be brought up on python-dev

The above is a specific proposal (with two possible syntax spellings) 
and an outline of a specific implementation.

>    - explains *why* the default argument hack is undesirable in general
> (unintuitive, hard to look up, harmful to introspection, invites
> errors when calling affected functions)
>    - clearly articulates the uses of the default argument hack that the
> proposal aims to eliminate (early binding, shared locals, performance)

By 'shared locals' do you mean nonlocals? That is not quite what Jan was 
requesting.

>    - include real world example of such uses from the standard library
> (and potentially other code bases)
>    - optionally, also describe the potential "function factories" that
> could be developed based on the semantics I proposed (see Eric Snow's
> post for a sketch of how such factories might work once given a
> template function to work with)
> 2. Create a reference implementation targeting Python 3.3
>
> (with step 1 being significantly more important at this stage - while
> the implementation can't be called *easy*, it should be a reasonably
> straightforward combination of the existing code that handles nonlocal
> statements and that which handles the calculation and storage of
> default arguments).

I do not see what nonlocals has to do or needs to have to do with 
*local* constants. My proposal is that to store named constants, we 
reuse the current code to recognize and calculate named defaulted locals 
with the current code to store and retrieve anonymous constants,

-- 
Terry Jan Reedy