PEP 318

[Hung Jung Lu]

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.

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

def foo() as generator staticmethod:
    ...

Add another keyword for thread behavior:

def foo() as synchronized generator staticmethod:
    ....

And another keyword for privacy:

def foo() as private synchronized generator staticmethod:
    ....

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

Or, following C#, you can also specify some attributes:

[attr1=2,
 attr2=3
 attr3="Hello"]
def foo():
    ....

-----------------------------------------

Of course there must be some reasonable compromise. I am coming from
the other end of the spectrum: meta-programming. In modern software
development, especially for large and complex systems,
meta-programming becomes more and more essential. If your language is
to grow with time, more and more keywords does not seem to be the way
to go. In some message-based languages like Io, even the if-statements
and the for-loops are not keywords: they are methods.

In the old days, when OOP just appeared, you used to see constructors
with long list of parameters. Nowadays it is much more common to see
things like SetAttribute() to change the behavior of an object. That
is, things are becoming more dynamic.

Metaprogramming is an unavoidable trend, in my opinion. In Java/C# you
use code generators. In C++ you use macros and templates. In Python
the staticmethod() can be interpreted also as a small metaprogramming
statement, not as a declaration of method type.

I am not against the "def foo() as staticmethod" syntax. I am just
bringing up a perspective on possible future problems. It is a little
bit like database table design: you could keep adding new columns to
your table for every new attribute, or you could normalize the table
by allowing a column to specify the attribute name/index, and a
different column for the value. In the first approach, you need to
modify the table definition and your programs when you want to add one
more feature. In the second approach, it becomes easy to add more and
more features, without redefining the table or modifying your program.

regards,

Hung Jung