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

[dmitrey]

Hi all,
I looked to the PEPs & didn't find a proposition to remove brackets &
commas for to make Python func call syntax caml- or tcl- like: instead
of
result = myfun(param1, myfun2(param5, param8), param3)
just make possible using
result = myfun param1 (myfun2 param5 param8) param3

it would reduce length of code lines and make them more readable, + no
needs to write annoing charecters.
Maybe it will require more work than I suppose, for example handling
of things like
result = myfun(param1, myfun2(param5, param8), param3=15, param4=200)
to
result = myfun param1 (myfun2 param5 param8) param3=15 param4=200 #so
it needs some more efforts to decode by compiler

but anyway I think it worth.
+ it will not yield incompabilities with previous Python versions.

WBR, D.

[Bart Willems]

dmitrey wrote:

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]

Bart Willems wrote:

dmitrey wrote:

>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?

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
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Recent Ramblings http://holdenweb.blogspot.com

[Paul Rubin]

Steve Holden <st***@holdenwe b.comwrites:

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.

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]

<be************ @lycos.comwrote :

But I think in some situations Ruby allows to omit them, solving some
of the "impossibil e" 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.

--
blog: http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site: http://www.akropolix.net/rik0/ | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.

[Jorgen Grahn]

On Thu, 22 Mar 2007 14:20:42 -0400, Steve Holden <st***@holdenwe b.comwrote:
....

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

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyn dns.org R'lyeh wgah'nagl fhtagn!