3 ms·
But the use as an operator and the use as a decorator is easily distinguished by where they appear in the grammar. Neither the parser nor human readers (as far
by mcherm 13y ago
But the use as an operator and the use as a decorator is easily distinguished by where they appear in the grammar. Neither the parser nor human readers (as far as I can tell) have any difficulty determining which use is which. So let's not confuse the two: they are two different uses that happen to utilize the same symbol.
- scrollaway 13y agoMy point is that if @<func> is re-implemented as, for example, the function.__dec__, then it can be overridden and some cool DSL uses can pop up. As it stands, the use of @ as a (class-)decorator is built in to the grammar, rather than simply being a prefix operator.
- ecma 13y agoHow might that implementation be used in code? Would coders be directly accessing and overriding the __dec__ attribute? Since decorators are definition time anyway, I don't really see much potential that decorated function factories can't already provide.
- scrollaway 13y ago"x = @y" will call y.__dec__. "@foo" behind a function will call foo.__dec__ with the function as an argument, meaning decoration behaviour can then be altered or be even completely different for other classes. As I said, there is DSL potential. As it stands, it's just something that is not possible.
- jessaustin 13y agoThe core python devs don't really care about DSLs.