[Python-ideas] Fwd: Make parenthesis optional in parameterless functions definitions

Steven D'Aprano steve at pearwood.info
Thu Mar 31 20:27:22 EDT 2016


On Thu, Mar 31, 2016 at 10:49:47PM +0200, Sven R. Kunze wrote:
> On 31.03.2016 20:06, Terry Reedy wrote:
> >
> >>def greet: # note the missing parenthesis
> >>     print('hello')
> >
> >-1  This will lead people to think even more often than they do now 
> >that they can omit () in the call.
> 
> Interesting that you mentioned it. Doesn't Ruby handle it this way?
> 
> Let's see how this would look like in Python:
> 
> 
> def distance of point1, point2:
>     # Pythagoras
> 
> point1 = (3, 1)
> point2 = (1, 4)
> print distance of point1, point2

I don't know that Ruby allows function calls like that. It doesn't work 
in Ruby 1.8, which is the most recent version I have installed:

steve at orac:~$ irb
irb(main):001:0> def foo(x)
irb(main):002:1> return x+1
irb(main):003:1> end
=> nil
irb(main):004:0> foo(7)
=> 8
irb(main):005:0> foo of 7
NoMethodError: undefined method `of' for main:Object
        from (irb):5
        from :0
irb(main):006:0>



However, Hypertalk, and other similar "XTalk" languages, do. Function 
calls in Hypertalk generally have a long form and a short form. The long 
form will be something like:

  total = the sum of field "expenses"

while the short form is the more familiar:

  total = sum(field "expenses")


Although Hypercard only allowed the long form if there was exactly one 
argument.



> Hmmm. Although I like the lightness of this, it's somewhat confusing, isn't?

In Hypertalk, it worked very well. But I wouldn't think it would be a 
good fit to Python.



In a previous email, Sven also wrote:

> I think the keystrokes are less important than the visual clutter 
> one have with those parentheses.

I don't think they introduce "visual clutter" to the function. I think 
they make it explicit and clear that the function has no arguments. 
That's not clutter.

When I was learning Python, I found it hard to remember when I needed parens 
and when I didn't, because the inconsistency between class and def 
confused me. I would write `class X()` or `def spam` and get a syntax 
error (this was back in Python 1.5). My own experience tells me strongly 
that the inconsistency between:

class X:  # must not use parens in Python 1.5

class Y(X):  # must use parens

and the inconsistency between class and def was harmful. If I could, I'd 
make parens mandatory for both. So I think that making parens optional 
for functions doesn't simplify the syntax so much as make the syntax 
*more complicated* and therefore harder to learn.

And I do not agree that the empty parens are "clutter" or make the 
function definition harder to read.



-- 
Steve


More information about the Python-ideas mailing list