why brackets & commas in func calls can't be ommited? (maybe it could be PEP?)

[Sebastian Kaliszewski]

if you want
result = func1(func2(arg))
you should use
result = func1 (func2 arg)

This is in conflict with current meanig, Ergo it breaks old code

rgds
\SK

 

[Bart Willems]

1st still is shorter by 1 char; considering majority of people use
space after comma & number of parameters can be big it yileds
foo bar baz bar2 bar3 bar4
vs
foo(bar, baz, bar2, bar3, bar4)

I think most readers already agree on the ambiguities part. Now, for the
length of the code...
I agree that in you example the first syntax yields a full /five/ spaces
less than the second syntax. However, it ignores the fact that if you
are creating functions with that many arguments, you are probably doing
something wrong. Can't those arguments be provided as a list?
Let's see what is shorter:

foo bar baz bar2 bar3 bar4
or
foo *bars

Not to mention that it might (or might not) be a good idea to wrap the
function in some kind of class where you can specify a whole bunch of
attributes, so that you do not have to call a function with that many
arguments to start with.

Regards,
Bart

 

[Steve Holden]

I think most readers already agree on the ambiguities part. Now, for the
length of the code...
I agree that in you example the first syntax yields a full /five/ spaces
less than the second syntax. However, it ignores the fact that if you
are creating functions with that many arguments, you are probably doing
something wrong. Can't those arguments be provided as a list?

I'm in danger of getting short-tempered on c.l.py for the first time in
a long time. If you think that five arguments is an excessive number for
a function then you live in a world of toy programs.

Let's see what is shorter:

foo bar baz bar2 bar3 bar4
or
foo *bars

Not to mention that it might (or might not) be a good idea to wrap the
function in some kind of class where you can specify a whole bunch of
attributes, so that you do not have to call a function with that many
arguments to start with.

Right, I think I have to assume that you're taking the piss.

regards
Steve

 

[Paul Rubin]

I'm in danger of getting short-tempered on c.l.py for the first time
in a long time. If you think that five arguments is an excessive
number for a function then you live in a world of toy programs.

There's no need for functions of more than one argument. Even in
existing Python syntax, instead of

def f(a,b,c,d,e): ...

you could say

def f((a,b,c,d,e)): ...

and receive a,b,c,d,e in a single tuple.

 

[Enrico 'Mc Osten' Franchi]

But I think in some situations Ruby allows to omit them, solving some
of the "impossibile" problems shown in this thread. This makes Ruby a
bit better than Python to create application-specific mini languages,
that are quite useful in some situations.

Yes. However, Ruby parser has to resort to heuristic in many cases:

<http://www.rubycentral.com/book/language.html>

"When Ruby sees a name such as ``a'' in an expression, it needs to
determine if it is a local variable reference or a call to a method with
no parameters. To decide which is the case, Ruby uses a heuristic."

In fact it is something I don't really like about Ruby (even though I
find it useful in some cases).

This is a 'pathological example'

def a
print "Function 'a' called\n"
99
end


for i in 1..2
if i == 2
print "a=", a, "\n"
else
a = 1
print "a=", a, "\n"
end
end


But I have to say that omitting brackets in a language such as Python or
Ruby can make the code very hardly readable. The interpreter isn't the
only one who has to resort to heuristic: everytime you read a name with
no parenthesis you may have to go back and see whether it is a bound
variable, a method (so you may have to check documentation for various
modules) or an 'invalid' variable you forgot to initialize.

In fact, when I'm reading code from a project I'm not familiar with, it
can be quite hard in the first place.

In fact most Rubyists advice to use parentheses (unless you want to
achieve a DSL like effect, or in very simple cases like

puts s

)

The third problem I found out is related to blocks ({} and do have
different precedence order). They are only syntax errors, but I find
them annoying.

 

[Jorgen Grahn]

I'm in danger of getting short-tempered on c.l.py for the first time in
a long time. If you think that five arguments is an excessive number for
a function then you live in a world of toy programs.

Or at least in a world where people have good taste and time to Do It
Right(tm).

I personally believe many five-argument methods would be better off
refactored. I killed one today which had fourteen (most of which were
unused). But I don't pretend that it's always worth the effort of
doing that, in the real world.

/Jorgen