PEP 318

[Skip Montanaro]

    Hung Jung> Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote in message news:<7x1xnlqs77.fsf at ruckus.brouhaha.com>...

    >> "def foo() as staticmethod" certainly looks best to me aesthetically.
    >> The syntax can be extended, i.e. "def foo() as generator" looks to me
    >> to be a lot more explicit than "def foo()" followed by having the
    >> compiler search the function body for a yield statement in order to
    >> decide if it's a generator.

    Hung Jung> True, but if a method were both generator and static, then we
    Hung Jung> would have:

    Hung Jung> def foo() as generator staticmethod:
    Hung Jung>     ...

    Hung Jung> Add another keyword for thread behavior:

Gotta stop thinking of decorators as keywords.  That would be a complete
non-starter.  It would be both inflexible (need to modify the parser every
time a new one was added) and constraining (require everyone to use the same
small set of "approved" decorators).  Decorators are variables referencing
objects which are located at function/method/class definition time.

    Hung Jung> def foo() as synchronized generator staticmethod:
    Hung Jung>     ....

    Hung Jung> And another keyword for privacy:

    Hung Jung> def foo() as private synchronized generator staticmethod:
    Hung Jung>     ....

    Hung Jung> And your language become pretty close to... Java! :)

And gets fairly unreadable because of the lack of punctuation.  I think
square brackets and commas improve readability a bit for those nearly
unreadable long sequences of decorators:

    def foo() [private, synchronized, generator, staticmethod]:

Skip