The problem with "as" [was "Re: PEP 318"]
joe at notcharles.ca
Tue Mar 23 09:28:54 CET 2004
In article <mailman.264.1080014839.742.python-list at python.org>, Skip Montanaro wrote:
> DH> Possible future Python example that uses "as" differently:
> DH> def foo(x as int, y as float) as int:
> DH> "this function returns an integer, and takes an int & float params"
> With no extension beyond the current PEP 318 proposal, you might postulate
> returns() and accepts() decorators:
> def foo(x, y) [accepts(int, float), returns(int)]:
> which extend foo() with code to enforce input and output types. Further,
> function attributes could be added which could be used by tools like
> pychecker for intermodule type checking.
Not a big fan of that syntax - I have to keep the parameter names and
types in sync by counting.
def foo(x [accepts(int)], y [accepts(float)]) [returns(int)]:
is a little better, except now we're getting very verbose.
For decorators in general, I like
def foo() as [decor1, decor2, decor3]:
You get an explicit list syntax, but it's set off by a keyword so they don't
run together to the eye. Because the keyword keeps it unambiguous, you
could even allow a tuple instead of a list: "def foo() as (x, y, z)".
So I definitely favour a keyword, but perhaps "as" is to generic. What
about "has" or "with"?
More information about the Python-list