[Python-Dev] Re: A syntax for function attributes?

[Phillip J. Eby]

At 07:58 PM 7/31/03 +0100, Paul Moore wrote:

>To be honest, the *only* serious reason for any of this syntax (PEP
>318, something for attributes, whatever) is to keep metadata near the
>definition (or at least, the def statement, rather than after the
>code...)

Agreed.


>I like Michael Hudson's variation on PEP 318,
>
>     def f() [mod1, mod2]:
>         pass
>
>It's minimal, flexible, and has an implementation.
>
>The downsides that I see are:
>
>1. It doesn't help with properties. To be honest, I don't see this as
>    much of an issue, as properties are a very different beast (they
>    effectively combine multiple functions in one). People have
>    demonstrated clever hacks to make properties possible, which leads
>    me nicely to...
>
>2. It's possibly *too* flexible. The temptation to define clever hacks
>    may be just a little high. The example of attrs() mentioned above
>    is a good example. It satisfies a real need, it's simple, and it's
>    easy to implement via the [...] syntax. But is it really the best
>    way of handling function attributes? I really don't know, without
>    trying it out. And that leads me onto...
>
>3. It's almost impossible to tell whether it will look right in
>    practice, without implementing it and trying it out. And once that
>    happens, it'll probably never get removed, even if it's *not* the
>    right answer.

Actually, between classmethod and PEAK's 'binding.Once', I use function 
modifiers a *lot*, and I'm not keen on waiting for 2.4 to address the 
issue.  So I've been thinking about writing a processor that would let me do:

def f(...): # [classmethod,...]
     ...

f = classmethod(f)

And the processor would make sure that the f=classmethod(f) part matched 
the comment.  Actually, if I could work up an editor macro that would do 
this for me, it'd be even better.


>My canonical case for function attributes comes from the parser Spark,
>which (mis-)uses docstrings to contain the grammar rule for which the
>function is an action:
>
>     def p_expr_term(self, args):
>         '''
>             expr ::= expr + term
>             term ::= term * factor
>         '''
>         return AST(type=args[1],
>                    left=args[0],
>                    right=args[2])
>
>
>To me, this certainly *isn't* going to work with something like
>attrs() - imagine
>
>     def p_expr_term(self, args) [attrs(
>         rule='''
>             expr ::= expr + term
>             term ::= term * factor
>         ''')]:
>         return AST(type=args[1],
>                    left=args[0],
>                    right=args[2])
>
>Yuk.


Me, I could probably live with:

def p_expr_term(self,args) [
     spark.rule(
         """expr ::= expr + term
            term ::= term * factor"""
     )
]:
     return AST(...)

But then, I'd personally be a bit more more likely to do:

EXPR_TERM = spark.rule(
     """etc."""
)

def p_expr_term(self,args) [EXPR_TERM]:
     ...


>I'm sorry, this rambled on a bit. I think that, in summary, my points
>are:
>
>     * My preferred solution for PEP 318 is Michael Hudson's patch.

I like it too, but "as" isn't bad either.  A number of people have objected 
to [] on the grounds that it is hard to look up in a documentation index.


>     * It may be too general, in tempting people to mis-use the feature
>       in inappropriate ways (but what the heck, anything can be
>       misused, at some level).

What would you define as "inappropriate"?