On Feb 26, 2004, at 5:02 PM, Doug Holton wrote:
would also be sensible syntax. But, the real monkeywrench here is that: def func1(x as int, y as float) as staticmethod: now looks like it *returns* a staticmethod, which is wrong.
So, thanks to your argument, I'm now leaning a little more towards using [] rather than "as", because "as" looks like syntax that should be reserved for adaptation at a future time. :)
You're right. I had forgotten that Visual Basic uses "as" to specify the return type of a function too.
I guess [] (or any list object) is better for method decorators.
Maybe in the future you could have something like:
def myfunc(x as int, y as float) [synchronized, staticmethod] as int: ...
So "as" is always and only associated with adaptation.
x = myfunc(1, 2.0) --> means x = adapt(myfunc(adapt(1,int),adapt(2.0,float)), int)
p = q as int --> means p = adapt(q, int)
def myfunc(x, y) [accepts(int, int), returns(int)]: pass Nothing stops you from (ab)using this syntax to do it.. but you may need to specify kwarg names twice if you want to skip some, and you would probably have a hard time deciding how to spell adaptation of *args or **kwargs :) -bob