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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4