[Python-Dev] other uses for "as" [was Re: new syntax for
wrapping (PEP 318)]
Phillip J. Eby
pje at telecommunity.com
Thu Feb 26 14:40:08 EST 2004
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
>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))
>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. :)
More information about the Python-Dev