[Python-ideas] Syntax for easy binding __name__, __module__, __qualname__ to arbitrary objects

[Ron Adam]

On 05/13/2013 10:49 PM, Nick Coghlan wrote:
> What Piotr's proposal crystalised for me is the idea that we really
> have two different kinds of name binding in Python. I'm going to call
> them "incidental binding" and "definitive binding".


As far as conceptual aspects of python go, I like to think of the ':' as a 
associate operator.  (*)

This works both in function definitions, class definitions, and dictionary 
literals.  The part before the colon is associated to the part after the 
colon.

Then def, class, and {}'s, determine the specific type of association being 
made.  So they are associate modifiers.  In the case of class and def, it's 
associating a code object created from the following block of code.  And in 
dictionary literals, it associates a key/object pair.


An '=' is a simple name/object association with restrictions on the name, 
the object must already exist, and the associated pair is put in the 
current name space.  Associate modifiers for '=' are 'global' and 'non_local'.


There are a number of ways you could expand on this theme.  One is to 
create additional modifiers such as 'enum', or combine the '=' with the ':' 
to get ':=' and '=:'.

Possibly ':=' could be an enum, and maybe '=:' would be a lambda or local 
named block of code.


I don't particularly like reusing def.  I've always thought of 'def' as 
being short for 'define function' and 'class' for being short for 'define 
class'.   So 'def foo(x): code_block'  spells "define function 'foo' that 
takes args (x), and associate it to code_block.  Where 'associate' is the ':'.


Reusing either def or class to do something different doesn't seem correct 
to me.  I think it would make python more confusing to those just starting out.

But Probably the above consistencies were never thought out in this way, or 
maybe they were at one time and there was never a need to express it 
publicly.  But I kind of like how it fits together conceptually even if 
it's just my own way of looking at it.

Cheers,
    Ron


(* Except in slicing syntax, which isn't related at all.)