pre-PEP: Suite-Based Keywords - syntax proposal

[Ron]

Steven Bethard wrote:

> Ron wrote:
> 
>> How about using ***name in the same way as *name, and **name are used? 
>> It extends the current argument options in a consistent manner and 'I 
>> believe' is easy to explain and visually says something different is 
>> happening here.
>>
>> This builds on the already present arg, *arg, **arg,  and so why not a 
>> ***arg to represent the 4th alternative, a suite?
> 
> 
> I dont' see how this is consistent.  *arg and **arg correspond to the 
> two different container protocols: sequence/iterable and mapping.  Which 
> container protocol do you se ***arg as corresponding to?  Note that 
> namespaces are just mappings, so if you want to treat a block like a 
> namespace, **arg makes more sense...
> 
> STeVe

Another possibility is to use an additional symbol to indicate "not 
here", "over there" or "outside this": %**args.  That has the advantage 
of allowing further expansion in the future if it's needed without 
getting into long strings of '******'s.  Although I don't think that 
would happen.

Too many various thoughts on this are are jumping in my mind right now. 
Which is partly why I've been staying out of this discussion. So here 
are some of them in no particular order.

(Q1.) Is it possible that a new container might be added to python 3000 
(or earlier) to correspond to a names suite?  Or a named lazy suite? 
ie.. one that might be evaluated at the function call versus at the 
define?  Or evaluated upon request?

[1] If so, the ***arg could be consistent in being a container protocol.


(Q2.)  Are the use of '*'s and '**'s allowed anywhere else beside within 
function call def's and call's?  I presume not because it would conflict 
with multiply and exponent operators. So this suggests to me it is 
specific function 'use' case's of function arguments and not general 
container protocol representation that can be used else where.

[1] If there are conflicts outside of function call use, then again 
**args should be preferred as not to create any additional conflicts.

[3] If the use of '*', and '**',  are used specifically to tell function 
calls and defs how to evaluate and use an argument vs a general 
container indicator.  Then ***arg has the advantage of indicating to use 
a named suite or an dict to be defined within the function body.  Named 
suites outside the function could use **arg as they would have already 
been evaluated.


     # arg suite defined in the function.
     x = function(***arg)
	arg:
	    a = 1
	    b = 22
             #continued ...
	#body


     # arg suite defined prior to function call.
     arg:
	a = 1
         #continued ...
     x = function(**arg)


Q3.  Which is more important, compiler/byte code representation of 
objects and operators or the user/syntax representation of objects and 
operators?  Are we more concerned with the low level representation to 
the compiler or the higher level representation to the user?

[1.] From a 'higher level'/'differing syntax' stand point,  the ***arg 
alternative more clearly communicates that there is a difference in it's 
use to the programmer. (although the low level representation may be the 
same as **arg)

[2.] If it's more important that an accurate representation of the lower 
level inner workings be maintained, then **args should again be preferred.


As far as my reference to consistency, forget I said that.  I think 
practicality might be more important than consistency here.  Consistency 
between small groups of one to three items is not a very strong 
association in any case.


Cheers,
Ron_Adam