Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #9757 > unrolled thread

Crazy what-if idea for function/method calling syntax

Back to article view | Back to comp.lang.python

Contents

  Crazy what-if idea for function/method calling syntax ΤΖΩΤΖΙΟΥ <tzotzioy@gmail.com> - 2011-07-17 15:54 -0700
    Re: Crazy what-if idea for function/method calling syntax Thomas Jollans <t@jollybox.de> - 2011-07-18 01:19 +0200
    Re: Crazy what-if idea for function/method calling syntax Cameron Simpson <cs@zip.com.au> - 2011-07-18 12:04 +1000
    Re: Crazy what-if idea for function/method calling syntax Ian Kelly <ian.g.kelly@gmail.com> - 2011-07-17 21:29 -0600
    Re: Crazy what-if idea for function/method calling syntax Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-18 15:54 +1000
      Re: Crazy what-if idea for function/method calling syntax Pierre Quentel <pierre.quentel@gmail.com> - 2011-07-18 13:34 -0700

#9757 — Crazy what-if idea for function/method calling syntax

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.

[toc] | [next] | [standalone]

#9759

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.

[toc] | [prev] | [next] | [standalone]

#9775

On 17Jul2011 15:54, ΤΖΩΤΖΙΟΥ <tzotzioy@gmail.com> 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 <cs@zip.com.au> 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 <pauld@cs.washington.edu>

[toc] | [prev] | [next] | [standalone]

#9777

2011/7/17 ΤΖΩΤΖΙΟΥ <tzotzioy@gmail.com>:
> 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. :-)

[toc] | [prev] | [next] | [standalone]

#9781

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

[toc] | [prev] | [next] | [standalone]

#9835

On 18 juil, 07:54, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> 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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web