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