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