pre-PEP: Suite-Based Keywords

[Reinhold Birkenfeld]

Bengt Richter wrote:
> On Sun, 17 Apr 2005 15:25:04 +0200, Reinhold Birkenfeld <reinhold-birkenfeld-nospam at wolke7.net> 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