pre-PEP: Suite-Based Keywords

[Bengt Richter]

On Sat, 16 Apr 2005 14:01:56 -0700, Brian Sabbey <sabbey at u.washington.edu> wrote:

>Reinhold Birkenfeld wrote:
>> Brian Sabbey wrote:
>>> Here is a pre-PEP for what I call "suite-based keyword arguments". The
>>> mechanism described here is intended to act as a complement to thunks.
>>> Please let me know what you think.
>>>
>>> Suite-Based Keyword Arguments
>>> -----------------------------
>>>
>>> Passing complicated arguments to functions is currently awkward in Python.
>>> For example, the typical way to define a class property winds up polluting
>>> the class's namespace with the property's get/set methods.  By allowing
>>> keyword arguments to be defined in a suite following a function call,
>>> complicated arguments can be passed in a cleaner, easier way.
>>>
>>> Examples
>>> ========
>>>
>>> Using suite-based keyword arguments, the code
>>>
>>> f(x = 1)
>>>
>>> is equivalent to
>>>
>>> f():
>>>     x = 1
>>
>> Pretty cool, but it interferes with current suites.
>>
>> How would you write
>>
>> if f(x=1):
>>    print "yes"
>>
>> using suite-based keyword args?
>>
>> Reinhold
>>
>
   if f(x=1) where: x=23:
       print "yes"

"where:" expression trailer intoduces a suite whose net bindings are used to evaluate the names
in the expression it trails, which means the calling parameters, if the expression is a call.
Syntacticaly where:<suite> should be equivalent to '' other than its name binding effect (which
is only for the call -- i.e.,
    x = 123
    foo(x) where: x=1  # => foo(1)
    print x # => 123

>You wouldn't be able to use suite keywords in that situation.  Also, one 
>would not be able to use suite keywords when there is more than one 
>function call on the same line:
>
>y = f()*g():
>  	x = 1    # ??  not allowed

Stretching for it, using my latest and greatest ;-)

    y = f(**::
           x = 1
           y = 'y for f'
        )*g(**::
           x = 'x for g'
           y = 'y for g'
           def foo(): return 'foo for g'
        )

Note that there is no problem adding other parameters, because ::<suite> is just
a unary expression returning dict subtype instance, e.g.,

    y = f(11,22,**::
           x = 1
           y = 'y for f'
        )*g(*args_from_somewhere, **::
           x = 'x for g'
           y = 'y for g'
           def foo(): return 'foo for g'
        )


This assumes that the unary ::<suite> expression returns an ordered dict subtype
instance containing the bindings created in the suite following the unary suite operator ::
E.g,
    d = ::
        x = 1
        y = 2
    print d # => {'x':1, 'y':2}

(Ignore version of previous posts where :: returned d.items() in place of d here)
>
>There is only so much suites can do.  Cases in which you want to do both 
>are probably far enough between that it seems acceptable to me to require 
>two suites:
>
>t = f():
>          x = 1
>if t:
>          y = 1

It's a little clunky, but

    if self.f(self, z, *a) where:
            z=123
            a = getarglist(): # ':' terminates transparent where:<suite>
        y = 1  # indentation as if where:<suite> were == ''

>
>In general, I think that anything more than just a function call with an 
>optional assignment should be disallowed:
>
>y = [f()]:      #  ? probably shouldn't be allowed
>  	x = 1

    y = [f(**:: x=1)] # sort form with single-line <suite> for ::<suite>
or
    y = [f(**::
             x = 1
        )]

isolates the suite better, in case it has logic and fancy stuff
Regards,
Bengt Richter