[Python-ideas] Enhance definition of functions

Michael Walter michael.walter at gmail.com
Fri Aug 2 18:41:22 CEST 2013


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

Best wishes,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130802/6ae36e6d/attachment-0001.html>


More information about the Python-ideas mailing list