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

Doug Holton d.holton at vanderbilt.edu
Thu Feb 26 14:04:41 EST 2004


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





More information about the Python-Dev mailing list