"Phillip J. Eby" <pje at telecommunity.com> writes: >> @staticmethod >> def foo(a,b,c): >> pass >> >> [staticmethod] >> def foo(a,b,c): >> pass >> >>and >> >> def foo(a,b,c) [staticmethod]: >> pass >> >>Hey - guess what? Writing them out like that, I find that my initial >>preference for the 3rd one has gone. To be honest, I no longer have a >>strong opinion between the three. In fact, if anything, I'd say I have >>a very mild preference for Guido's option (number 2). I dislike the >>ambiguity problem with it, though. > > IMO, the ambiguity is resolved if some kind of visible invocation occurs, e.g.: > > [declare_staticmethod()] > def foo(a,b,c): > pass > > While '[staticmethod]' by itself may appear to be a useless and > ignorable statement, adding the () makes it clear that you have to > know what the called function *does* before you could consider > removing the statement. > > When you add in the fact that this syntax can be made to work in > Python 2.2 and better, not just 2.4, it makes the syntax a big winner > in my book. > > I would like to reverse the application order, though: Guido's patch > uses the same order for syntax 2 as for syntax 3, and now that I've > played with syntax 2 "for real", I think that right-to-left > application should be used for any syntax where the decorators come > before the 'def'. Here's another syntactic idea that could be made to work without core language changes: [as.staticmethod] def foo(a,b,c): pass I think that one's pretty sweet. It can be extended any number of ways: [as.staticmethod, as.classmethod, ...] def foo(a,b,c): pass [as.staticmethod|classmethod| ...] def foo(a,b,c): pass -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
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