On Sun, 17 Apr 2005 15:25:04 +0200, Reinhold Birkenfeld <[EMAIL PROTECTED]>
wrote:
>Bengt Richter wrote:
>
>> 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'
>> )
>
>You know that this is dead ugly?
What aspect in particular? I.e., does this (currently legal) look prettier:
y = f(11,22, **dict(
x = 1,
y = 'y for f'
))*g(*args_from_somewhere, **dict(
x = 'x for g',
y = 'y for g',
foo = lambda: return 'foo for g'
))
Can you express the same semantics in a prettier way?
To boil it down, doesn't a suite bindings expression like
d = ::
x = 1
y = 'y for f'
(which in this case doesn't even need parens) seem prettier than
d = dict(
x = 1,
y = 'y for f'
)
to you, especially given that (:: ...) gives you the power
of full suite syntax to create bindings
any way you want[1], not just keyword=<expression> ?
(and you can leave out the commas ;-)
[1] I.e., this should work to extend the power of the type expression in a way
that shows what you can't do with dict(...) ;-)
type('C', (), ::
def __repr__(self):
return '<alternatively-created-class-object at %08x>'%
(hex(id(self)&(2L**32-1))
def cname(self): return type(self).__name__
classvar = 123
# ... anything you can do in a class definition body
)
IMO that's pretty clean.
>
>The real ``problem'' (if you see one) is that the indentation syntax
>doesn't allow for suites in expressions.
I was trying to solve that "problem" with my "suite expressions" ;-)
::<suite> # suite bindings expression (as ordered dict)
def(<arglist>):<suite> # anonymous def
(<arglist>):<suite> # thunk (anonymous callable suite sharing local
namespace)
I think suite indentation rules for suite expressions are not that hard, once
you decide
to deal with it as a separate indentation space from outside the expression.
That's already
done to allow multiline expressions without indentation interpretation inside
bracketed expressions.
This is just adding indentation processing within certain types of expressions
("suite expressions" ;-)
For the most part I like indentation syntax very well, and
I suspect that if there were optional brackets, you would still be indenting
for clarity, so the chances are the bracket version of the above would
mainly add bracket noise to something close to the above.
Regards,
Bengt Richter
--
http://mail.python.org/mailman/listinfo/python-list
