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
