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 <[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 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@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/)
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
