Bengt Richter wrote: > On Sun, 17 Apr 2005 15:25:04 +0200, Reinhold Birkenfeld <[EMAIL PROTECTED]> > wrote:
>>> 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? The '**::', for example. I would surely prefer a keyword instead of '::'. > 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' > )) No, it doesn't. And I surely wouldn't write such code. y = (f(11, 22, x=1, y='y for f') * g(*args_from_somewhere, x='x for g', y='y for g', foo=lambda: return 'foo for g')) or, if you tolerate more lines, y = (f(11, 22, x=1, y='y for f') * g(*args_from_somewhere, x='x for g', y='y for g', foo=lambda: return 'foo for g')) would be my current way to express this. But still, the less lines, the less confusing it is. > 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 ;-) I understand the general idea, but still I don't like the idea of "suite expressions". My main concern is the following: After a suite expression, where does code follow? As in your example: y = f(**:: x = 1 # indented one level, as indents can go any number of spaces ) # indented one level too, but differently (currently an IndentantionError) > [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. Uses are neat, i concur. >>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. I don't say brackets are better, but the problem of where to put the following code is tricky. Reinhold -- http://mail.python.org/mailman/listinfo/python-list