Another Language Change for Debate

Fri Jan 11 23:22:36 EST 2002

[Gareth McCaughan]
> I much prefer a different approach.
>
>     class MyClass:
>         def staticmethod bar(y):
>             blah()
>             stuff += stuff
>         def classmethod baz(z):
>             return 1
>
> This generalizes in an obvious way:
>     def <name1> <name2>(<formals>): <body>
> turns into
>     def <name2>(<formals>): <body>
>     <name2> = <name1>(<name2>)
> which would make it possible, e.g., to define
> a function called "memo" which memoizes its argument
> and say (typical useless example follows):
>     def memo fib(n):
>         if n<2: return n
>         return fib(n-2)+fib(n-1)
> and get only O(n) calls to "fib" on doing fib(n).
>
> Perhaps there's an obvious reason why this doesn't
> work, but I can't see what it might be right now.
> Would it be difficult for the parser?

It's more that a gazillion "toy parser" tools out there (from Emacs
python-mode to Python's own pyclbr.py) would have to be changed too, lest
they all end up thinking you have an unbounded number of methods named
"staticmethod" (etc).  You won't take this seriously until a dozen legacy
tools you don't even remember you're using break <wink>.