From: Eric S. Raymond [mailto:esr@thyrsus.com]
> Zack Weinberg <zack@codesourcery.com>:
>> I.e. allow a dictionary constructor expression between the argument
>> list and the colon; this initializes the property dictionary of the
>> code object. One could stick a call to spark.rule() in there, or =
have
>> a metaclass do it automatically.
>>=20
>> This allows the square bracket notation to be reserved for
>> [classmethod] and the like. I suppose there's nothing stopping =
square
>> brackets from being used for both, but I like having consistency with
>> other dictionary constructor expressions.
>
> I like this argument. +1.
All of the notations involving "stuff" between the definition and the
colon look reasonable when the "stuff" is small, but start to look odd
when it gets bigger (because it usually means that the colon is not on
the same line as the "def").
How about leaving the [...] construct between the args and the colon,
on the assumption that "normal use" is for short stuff, like =
[classmethod].
But for the dictionary option for function attributes, locate it after =
the
docstring. The we have
def p_expr_term(self,args):
"""docstring here"""
{ 'rule' :
"""expr ::=3D expr + term
term ::=3D term * factor"""
}
pass
It may get (slightly) hairy to parse, but should be OK, as docstrings =
are
a precedent for bare literals at the start of a function definition =
having
special meaning.
Paul.
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