[Python-Dev] Acquire/release functionality (Was: Extended Function syntax)

[holger krekel]

Walter D?rwald wrote:
> Paul Moore wrote:
> 
> > Guido van Rossum <guido@python.org> writes:
> > 
> > 
> >>I'm now wondering if there aren't really only two interesting cases,
> >>none of which require saving the thunk and calling it later:
> >>
> >>- synchronized-like, where the block should connect to its environment
> >>
> >>- property-like, where the block should introduce a new scope, and the
> >>  caller should be able to inspect or control that scope's namespace
> > 
> > 
> > I certainly haven't seen any use cases other than these two. In fact,
> > pretty much all of the cases I am aware of are synchronised-like,
> > which I've been referring to as acquire/release. The only
> > property-like cases I'm aware of are properties themselves.
> 
> A use case I can think of is some kind of XML DOM API (Ruby does
> something like that with it's cgi module, where node content is
> created inside a block).
> 
> With the current Python you can have something like that:
> 
>     node = html.table(
>        html.tr(
>           html.th("foo"),
>           html.td("bar")
>        ),
>        html.tr(
>           html.th("spam"),
>           html.td("eggs")
>        ),
>        border=0,
>        cellpadding=3
>     )
> 
> i.e. element classes that use * and ** arguments in their constructor
> to collect content and attribute nodes.
> 
> The problem with this approach is, that the attributes are maximally
> separated from their element and that control structures (like if) are 
> not possible inside the constructor.
> 
> With blocks ifs and fors could look like this:
> 
>     node = html.table(border=0, cellpadding=0):
>        html.tr():
>           html.th(): "foo"
>           html.td(): "bar"
>        if cond:
>           html.tr():
>              html.th(): "spam"
>              html.td(): "eggs"
>        for i in xrange(10):
>           html.tr():
>              html.th(): i
>              html.td(): i*i

you probably missed my other posting where i actually went
one step further and implemented this via <...> syntax. 

Actually i tried *exactly* the syntax you propose here first but
i think it's *hopelessly* ambigous with the Python grammar. 

You simple have no way to know which construct you are in
until you read the ':'.  Until then you could be in a
normal expression.  The 'class', 'def', 'if', 'while' etc.
keywords disambiguate this right at the beginning.

Without a much deeper parser look-ahead this can't 
be done, i am afraid.

    holger