On Aug 2, 2013, at 9:00, Antoine Pitrou <solipsis@pitrou.net> wrote:That's fine if callbacks are the _only_ case you want to handle, but as Nick just explained, there are many other cases that are also useful. The middle of an if expression in a comprehension, for example, isn't a function parameter.
>> Using "@" as the marker character is also problematic, since the
>> following degenerate case will probably confuse the parser (due to it
>> looking too much like a decorator clause):
>>
>> @something() given:
>> ...
>
> No, that would simply be forbidden. In this proposal, "@" can only mark
> names of parameters in function calls. We already reuse "*" and "**"
> for a specific meaning in front of function call parameters, so there's
> a precedent for such polysemy.
Also, when you have a long function call expression--as you almost always do in, say, PyObjC or PyWin32 GUIs--you often want to put each parameter on its own line. While that won't confuse the parser, it could easily confuse a human, who will see "@callback," on a line by itself and think "decorator".
It's probably worth taking some real examples from a bunch of different domains where you've defined something out-of-line but would use this proposal if you could, and rewriting them with each variation to see what they look like.