skip at pobox.com
Mon Mar 22 23:33:26 CET 2004
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]:
More information about the Python-list