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

[Jack Diederich]

On Thu, Jul 31, 2003 at 07:58:40PM +0100, Paul Moore wrote:
> 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...

I agree

> 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...

This doesn't worry me too much.  I think it will clear out more hacks
by providing a generally readable syntax that takes the place of everyone's
personal hacks.

>
> 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])

This is an abuse of doc strings any way you slice it, the SPARC folks wanted
a mini-language and decided to use python as the interpreter.  They found a
way to define _most_ of the info through other tricks, but had to cram a
little into docstrings.

Their mini-language isn't working around the lack of method decorators,
it is working around the lack of macros.

A more pythonic way to write what SPARC wants would be to write out the python
that SPARC translates the above into.  something more like

def anonfunc1(self, args):
  return AST(type=args[1],left=args[0],right=args[2])

g = Grammar(Rule('expr', 'expr + term', anonfunc1),
            Rule('term', 'term * factor', anonfunc1),
           )

So method decorators might make this kind of hack easier, but they don't
change its hackiness.  It only bothers me a little the way SPARC does it,
the abuse of docstrings makes for more readable code once you know that
it is a sparc file.  The fully written out way requires reading around too
much.

So the fact that they might use decorators instead of docstrings to implement
their mini-language is a non-issue for me.

I'm still dying to write (python3k rules!):

class MyClass: # knows I meant 'class MyClass(object)'
  def func1(arg1) [staticmethod, memoized]: # memoized defined elsewhere
    # do stuff
    return answer

> 
> It's also interesting to note that classmethod/staticmethod and
> properties get used in spite of the lack of syntactic support, whereas
> function attributes generally don't seem to. I'm not quite sure what
> this implies about the usefulness of function attributes...

I'm not exactly sure what function attributes are, does this just mean:

def func1(a, b):
  return a + b
func.priority = 1

def func2(a, b):
  return a * b
func.priority = 2

If so I'm not sure what I would use that for except overloading the interpreter
to write mini-languages, which I don't do much.

-jackdied