Crazy what-if idea for function/method calling syntax

Discussion in 'Python' started by ÔÆÙÔÆÉÏÕ, Jul 17, 2011.

  1. 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)

    I believe it makes code more readable; it's also a more terse
    alternate to a call like:
    place_at(item=item, x=x, y=y)

    Another example:
    group(iterable)_by(callable)

    I can think of some objections myself; the most important is whether
    the current parser (with a complexity defined by the wishes of Guido,
    which I faintly recall reading about a long time ago) can do that or
    not. I also don't know if any other language exists supporting this
    construct.

    There is also a big window for misuse (i.e. break the function/method
    name in illogical places), but I would classify this under “consenting
    adults”. It might be suggested as good form that function names break
    at underscores, like my examples.

    I know it seems extreme. I only posted this idea here because I would
    like some input about how feasible it can be and whether people like
    it or not. Any input is welcome; however, I kindly request that
    negative replies include counter-arguments (an abrupt “no” or “yuck!”
    does not help others improve their knowledge of Python or Pythonic-
    ness :).

    Thanks in advance.
    ÔÆÙÔÆÉÏÕ, Jul 17, 2011
    #1
    1. Advertising

  2. 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.
    Thomas Jollans, Jul 18, 2011
    #2
    1. Advertising

  3. On 17Jul2011 15:54, ΤΖΩΤΖΙΟΥ <> wrote:
    | 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)
    [...]
    | There is also a big window for misuse (i.e. break the function/method
    | name in illogical places), but I would classify this under “consenting
    | adultsâ€. It might be suggested as good form that function names break
    | at underscores, like my examples.

    Another problem is the scope for error. I can easily imagine typing:

    x=foo(x)bah(y)

    when I intended to type:

    x=foo(x)+bah(y)

    Adding your syntax causes silent breakage later instead of immediate
    syntax error now.

    Cheers,
    --
    Cameron Simpson <> DoD#743
    http://www.cskk.ezoshosting.com/cs/

    hybrid rather than pure; compromising rather than clean;
    distorted rather than straightforward; ambiguous rather than
    articulated; both-and rather than either-or; the difficult
    unity of inclusion rather than the easy unity of exclusion.
    - Paul Barton-Davis <>
    Cameron Simpson, Jul 18, 2011
    #3
  4. ÔÆÙÔÆÉÏÕ

    Ian Kelly Guest

    2011/7/17 ÔÆÙÔÆÉÏÕ <>:
    > 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)



    class place(object):
    def __init__(self, item):
    self.__item = item
    def at(self, x, y):
    # place self.__item at (x, y)
    pass

    Then you can do:

    place(item).at(x, y)

    No syntax changes required. :)
    Ian Kelly, Jul 18, 2011
    #4
  5. On Mon, 18 Jul 2011 08: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.


    I don't think it does that. I think it is misleading, as it looks like two
    independent function calls. It also makes it hard to search for a function
    call -- instead of searching for

    do_something\(.*\)

    you have to now search for

    do_something\(.*\)
    do\(.*\)_something\(.*\)
    do_\(.*\)something\(.*\)
    do_some\(.*\)thing\(.*\)

    and so on.



    > Example:
    > def place_at(item, x, y): blah blah
    > could be called as
    > place(item)_at(x, y)


    You would probably like the Xtalk family of languages, starting with
    Hypertalk from Apple in the late 80s or early 90s.

    There's a neat implementation here: http://code.google.com/p/openxion/


    Xtalk includes syntax like this:

    put newStr into character 23 to 42 of theStr
    put suffix after theStr
    delete first char of theStr

    although this only applied to built-in functions, not user-functions.


    --
    Steven
    Steven D'Aprano, Jul 18, 2011
    #5
  6. On 18 juil, 07:54, Steven D'Aprano <steve
    > wrote:
    > On Mon, 18 Jul 2011 08: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.

    >
    > I don't think it does that. I think it is misleading, as it looks like two
    > independent function calls. It also makes it hard to search for a function
    > call -- instead of searching for
    >
    > do_something\(.*\)
    >
    > you have to now search for
    >
    > do_something\(.*\)
    > do\(.*\)_something\(.*\)
    > do_\(.*\)something\(.*\)
    > do_some\(.*\)thing\(.*\)
    >
    > and so on.
    >
    > > Example:
    > >   def place_at(item, x, y): blah blah
    > > could be called as
    > >   place(item)_at(x, y)

    >
    > You would probably like the Xtalk family of languages, starting with
    > Hypertalk from Apple in the late 80s or early 90s.
    >
    > There's a neat implementation here:http://code.google.com/p/openxion/
    >
    > Xtalk includes syntax like this:
    >
    > put newStr into character 23 to 42 of theStr
    > put suffix after theStr
    > delete first char of theStr
    >
    > although this only applied to built-in functions, not user-functions.
    >
    > --
    > Steven


    If I understand correctly, you propose to translate "do something to X
    with arguments a,b,c" to

    (1) do_something_to(X)_with_arguments(a,b,c)

    instead of

    (2) do_something(X,a,b,c)

    I agree that the first one is more readable than the second, because
    in the arguments list in (2) you mix the object you are working on and
    the parameters used. But there is another option :

    (3) X.do_something_with_arguments(a,b,c)

    which would be in your examples : "item.place_at(x,y)" or
    "iterable.group_by(collection)"

    It's valid Python code and probably as readable than what you suggest,
    with a clear distinction between the object and the arguments

    - Pierre
    Pierre Quentel, Jul 18, 2011
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. onkar

    C garbage collection -crazy idea

    onkar, Dec 15, 2006, in forum: C Programming
    Replies:
    3
    Views:
    337
    Richard Heathfield
    Dec 16, 2006
  2. onkar

    C garbage collection -crazy idea

    onkar, Dec 15, 2006, in forum: C Programming
    Replies:
    28
    Views:
    765
    Giorgos Keramidas
    Dec 25, 2006
  3. XLiIV
    Replies:
    4
    Views:
    337
    Terry Reedy
    May 9, 2008
  4. optimistx

    Augmenting ECMA-262 specs: crazy idea?

    optimistx, Nov 6, 2009, in forum: Javascript
    Replies:
    8
    Views:
    137
    Dmitry A. Soshnikov
    Nov 9, 2009
  5. DL

    Crazy idea?

    DL, May 2, 2010, in forum: Javascript
    Replies:
    6
    Views:
    124
    Ry Nohryb
    May 7, 2010
Loading...

Share This Page