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


not interpreted as


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




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




(which would be a TypeError)?



On 8/13/07, Chris Monsanto <[EMAIL PROTECTED]> 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
> 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:
> (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
> Unsubscribe:

--Guido van Rossum (home page:
Python-3000 mailing list

Reply via email to