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
