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"?
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