[Python-ideas] Enhance definition of functions

[Nick Coghlan]

On 3 August 2013 02:41, Michael Walter <michael.walter at gmail.com> wrote:
> On Fri, Aug 2, 2013 at 6:25 PM, Andrew Barnert <abarnert at yahoo.com> wrote:
>>
>> On Aug 2, 2013, at 9:00, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>
>> >> 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.
>>
>> 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.
>>
>> 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.
>
>
> Is the reason to mark up the variables that are defined in the
> with/where/given block only a technical one (to support the parser)?

It's more than just the parser that needs that extra help to make it
implementable :)

However, the syntactic marker is helpful for human readers, too - it
makes it clear which names come from the statement local namespace,
and which are just ordinary name references.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia