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.
My 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.
How 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.
"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.
