[Python-Dev] other uses for "as" [was Re: new syntax for wrapping (PEP 318)]

[Phillip J. Eby]

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.  :)