[Python-3000] 100% backwards compatible parenless function call statements

[Guido van Rossum]

This is a topic for python-ideas, not python-3000.

To be absolutely brutally honest, it doesn't look like you understand
parsing well enough to be able to write a PEP. E.g. why is

  cos(3)+4

not interpreted as

  cos((3)+4)

in your proposal?

Python's predecessor had something like this, and they *did* do it
properly. The result was that if you wanted the other interpretation
you'd have to write

  (cos 3) + 4

Similarly in Haskell, I believe.

In any case, I don't believe the claim from the subject, especially if
you don't distinguish between

  f.close

and

  f.close()

How would you even know that 'close' is a method and not an attibute?
E.g. how do you avoid interpreting

  f.closed

as

  f.closed()

(which would be a TypeError)?

Skeptically,

--Guido

On 8/13/07, Chris Monsanto <chris.monsanto at gmail.com> wrote:
> Since Python makes such a distinction between statements and expressions, I
> am proposing that function calls as statements should be allowed to omit
> parentheses. What I am proposing is 100% compatible with Python 2.x's
> behavior of function calls; so those uncomfortable with this (basic) idea
> can continue to use parens in their function calls. Expressions still
> require parens because of ambiguity and clarity issues.
>
> --Some examples:--
>
> print "Parenless function call!", file=my_file
>
> print(".. but this is still allowed")
>
> # We still need parens for calls to functions where the sole argument is a
> tuple
> # But you'd have to do this anyway in Python 2.x... nothing lost.
> print((1, 2))
>
> # Need parens if the function call isnt the only thing in the statement
> cos(3) + 4
>
> # Need parens if function call isnt a statement, otherwise how would we get
> the function itself?
> x = cos(3)
>
> # Make a the value of my_func...
> my_func2 = my_func
> my_func2 # call other function
> my_func2() # call it again
>
> # Method call?
> f = open("myfile")
> f.close
>
> # Chained method
> obj.something().somethinganother().yeah
>
> --Notes:--
>
> A lot of other things in Python 2.x/Python 3k at the moment have this same
> behavior...
>
> # No parens required
> x, y = b, a
>
> # But sometimes they are
> func((1, 2))
>
> # Generator expressions sometimes don't need parens
> func(i for i in list)
>
> # But sometimes they do
> func(a, (i for i in list))
>
> --Pros:--
>
> 1) Removes unnecessary verbosity for the majority of situations.
> 2) Python 2.x code works the same unmodified.
> 3) No weird stuff with non-first class objects, ala Ruby meth.call().
> Functions still remain assignable to other values without other trickery.
> 4) Because it's completely backwards compatible, you could even have
> something like from __future__ import parenless in Python 2.6 for a
> transition.
>
> --Cons:--
>
> 1) Can't type "func" bare in interpreter to get its repr. I think this is a
> non-issue; I personally never do this, and with parenless calls you can just
> type "repr func" anyway. Specifically I think this shouldn't be considered
> because in scripts doing something like " f.close" does absolutely nothing
> and giving it some functionality would be nice. It also solves one of the
> Python gotchas found here:
> http://www.ferg.org/projects/python_gotchas.html
> (specifically #5)
>
> I'm willing to write up a proper PEP if anyone is interested in the idea. I
> figured I'd poll around first.
>
>
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/guido%40python.org
>
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)