Crazy what-if idea for function/method calling syntax
Thomas Jollans
t at jollybox.de
Sun Jul 17 19:19:23 EDT 2011
On 07/18/2011 12:54 AM, ΤΖΩΤΖΙΟΥ wrote:
> Jumping in:
>
> What if a construct
>
> xx(*args1, **kwargs1)yy(*args2, **kwargs2)
>
> was interpreted as
>
> xxyy(*(args1+args2), **(kwargs1+kwargs2))
>
> (Note: with **(kwargs1+kwargs2) I mean “put keyword arguments in the
> order given”, since dicts can't be added)
>
> This construct is currently a syntax error. The intent of this idea is
> to help improve legibility.
>
> Example:
> def place_at(item, x, y): blah blah
> could be called as
> place(item)_at(x, y)
Objective C does something similar. I don't actually know Objective C,
but from what I remember from when I briefly read up on in (somebody
please correct me), that call could, in Objective C, look something like:
[ place:item atPositionX:x Y:y ]
The idiomatic Python way for this is the following:
def place(item, at): pass
place(item, at=(x,y))
Your suggestion would open up an infinite number of different, mostly
unreadable, ways to call a single method. This completely goes against
the principle of encouraging there being only one way to do things.
Multi-part method names (with fixed, non-optional, "split" points, if
you know what I mean) are slightly interesting, but don't fit in, and,
more importantly, don't add anything to the language: all the possible
readability benefits are already provided (and trumped) by keyword
arguments.
More information about the Python-list
mailing list