other uses for "as" [was Re: new syntax for wrapping (PEP 318)]
Skip> If you are going to add [...] as a function modifier syntax, Skip> I would argue that it should allow the full power of list Skip> (or generator) comprehensions.
Agreed. And why limit it to lists - why not any expression that evaluates to a list? Or maybe any sequence? Which is one reason that a bare "[...]" doesn't seem sufficient.
The "as" syntax is easier to understand and more readable, but you'd like to have the full power of lists as well (plus make the parsing easier). When there is just a single item though, the list syntax seems overkill. I can already tell if this feature is added it will likely stick with the list syntax instead of the "as" keyword because that is the easier solution to code. But here is an "as" solution that doesn't require extra coding for now. Have the parser check for a single item OR a list of items. You could add an "as" keyword but essentially ignore it in this case. This would mean though that this would not work: def myfunc(x, y) as synchronized, classmethod: ... You'd have to use the list syntax for multiple modifiers. If there is a decision to add the "as" keyword, here are some possible future expansions of its use. What it does is make the use of modifiers and type checking more readable. In general "X as Y" would mean --> Y(X) and "X as [Y, Z]" would mean --> Z(Y(X)) for example: X = temp_val as int means --> x = int(temp_val) thisobject = obj as MyType means --> thisobject = MyType(obj) Then there are Visual Basic -like params (let's not start a war about it): def func1(x as int, y as float): ... instead of: def func1(x, y): try: x2 = int(x) y2 = float(y) ...
At 01:04 PM 2/26/04 -0600, Doug Holton wrote:
Skip> If you are going to add [...] as a function modifier syntax, Skip> I would argue that it should allow the full power of list Skip> (or generator) comprehensions.
Agreed. And why limit it to lists - why not any expression that evaluates to a list? Or maybe any sequence? Which is one reason that a bare "[...]" doesn't seem sufficient.
The "as" syntax is easier to understand and more readable, but you'd like to have the full power of lists as well (plus make the parsing easier). When there is just a single item though, the list syntax seems overkill.
I can already tell if this feature is added it will likely stick with the list syntax instead of the "as" keyword because that is the easier solution to code.
But here is an "as" solution that doesn't require extra coding for now. Have the parser check for a single item OR a list of items. You could add an "as" keyword but essentially ignore it in this case. This would mean though that this would not work: def myfunc(x, y) as synchronized, classmethod: ... You'd have to use the list syntax for multiple modifiers.
If there is a decision to add the "as" keyword, here are some possible future expansions of its use. What it does is make the use of modifiers and type checking more readable.
In general "X as Y" would mean --> Y(X) and "X as [Y, Z]" would mean --> Z(Y(X))
for example: X = temp_val as int means --> x = int(temp_val)
thisobject = obj as MyType means --> thisobject = MyType(obj)
Hm, that sounds more like syntax for PEP 246 (adaptation).
Then there are Visual Basic -like params (let's not start a war about it):
def func1(x as int, y as float): ...
This also seems like syntax for adaptation. But I don't see this latter use as an argument for "as", since: def func1(x [int], y [float]): 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. :)
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)
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
Bob Ippolito wrote:
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 :)
Why? Inventing obcure syntax is an easy part: def myfunc(*x, **y) [accepts([int], {string:int}), returns(int)]: pass Hard part is keep it simple and useful. ;) Mike
On Feb 26, 2004, at 7:59 PM, Mike Rovner wrote:
Bob Ippolito wrote:
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 :)
Why? Inventing obcure syntax is an easy part:
def myfunc(*x, **y) [accepts([int], {string:int}), returns(int)]: pass
Hard part is keep it simple and useful. ;)
I meant getting the 'collective' to decide .. If you check your mail in a few minutes, I'm sure someone will counter the usefulness of this syntax and suggest a different way :) -bob
"Phillip J. Eby" <pje@telecommunity.com>:
"as" looks like syntax that should be reserved for adaptation at a future time. :)
I'd also like to see "as" reserved for possible future use to specify a metaclass in class declarations, which is relevant if we want class decorators with the same syntax as function decorators. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
participants (5)
-
Bob Ippolito -
Doug Holton -
Greg Ewing -
Mike Rovner -
Phillip J. Eby