On Sat, 16 Apr 2005 14:01:56 -0700, Brian Sabbey <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
