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.

[Miki]

Hello Dmitrey,

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

If you have
result = func1 func2 arg
is it
result = func1(func2, arg)
or
result = func1(func2(arg))

Miki <mi*********@gmail.com>
http://pythonwise.blogspot.com

[dmitrey]

I think it should result
result = func1(func2, arg)
if you want
result = func1(func2(arg))
you should use
result = func1 (func2 arg)
if
.... = word1 word2 word3 ...
then only word "word1" should be call to func "word1" with parameters
word2, word3 etc

If you have
result = func1 func2 arg
is it
result = func1(func2, arg)
or
result = func1(func2(arg))

Miki <[e-mail]>http://pythonwise.blogspot.com

[Bjoern Schliessmann]

dmitrey wrote:

it would reduce length of code lines and make them more readable,
+ no needs to write annoing charecters.

IMHO, it's less readable.

I suppose I'm not on my own with this opinion.

Regards,
Björn

--
BOFH excuse #34:

(l)user error

[Diez B. Roggisch]

dmitrey wrote:

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.

This is not true, there is no shorter code lines:

foo bar baz
foo(bar,baz)

And the "more readable" part certainly depends on the habits of the user -
to me, it's harder to read.

Apart from that, even if both statements were true, I doubt there is even
the slightest chance of including it - after all, you'd have to keep around
the "old" way of doing things anyway, and thus you'd end up with two styles
of coding - certainly _not_ something anybody in the python developer
community is interested in.

Diez

[Piet van Oostrum]

>>>>"dmitrey" <op*****@ukr.net(d) wrote:

>dI think it should result
dresult = func1(func2, arg)
dif you want
dresult = func1(func2(arg))
dyou should use
dresult = func1 (func2 arg)
dif
d... = word1 word2 word3 ...
dthen only word "word1" should be call to func "word1" with parameters
dword2, word3 etc

That depends whether you want function application to be left-associative
or right-associative. For example, in haskell it is left associative which
is the more obvious choice because it has currying.
--
Piet van Oostrum <pi**@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: pi**@vanoostrum.org

[Jason]

On Mar 21, 8:38 am, "dmitrey" <[e-mail]:

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.

In my opinion, it is much less readable. That may be due to my
experiences with TCL, BASH-scripting, with C, C++, and Python. The
parenthesis make it very obvious that a function call is going on, and
mirrors the mathematical notations that denote using a function.

With touch-typing on an American keyboard, the ()'s are not really any
more annoying than any of the various top-row digits. I personally
find the backslash character (\) to be far more annoying, as it can
have one of several locations depending on the keyboard style. (Most
sanely put it above the "Enter" key.)

As others have pointed out, the code that you presented really isn't
all that much shorter. Short code isn't really what Python's about.
Perl has many ways to write very short, incomprehensible code.

A further ambiguity to consider:

result = func1

Is the name "result" bound to the function func1? Or is func1 called,
and its result is bound to the name "result"?

Good luck with your PEP.

--Jason

[Duncan Booth]

"dmitrey" <op*****@ukr.netwrote:

+ it will not yield incompabilities with previous Python versions.

So how would you write:

func(-3)
func(*param)

with your scheme? These already have an incompatible meaning:

func -3
func *param1

[Bart Ogryczak]

On Mar 21, 3:38 pm, "dmitrey" <[e-mail]:

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

How would you write "a = b(c())"?

In my opinion it'll make code extremely obfuscaded. The great thing
about Python, when comparing with eg. Perl or C, is that code is
readable, even if written by experienced hacker.

[Steven D'Aprano]

On Wed, 21 Mar 2007 07:55:08 -0700, dmitrey top posted:

I think it should result

What's "it"? Please don't top post, it makes your answer hard to
understand and makes your readers have to do more work to read your posts.
We're not being paid to read your posts, so I'd estimate that about 70% of
readers have just clicked "Delete" at this point and ignored you.

For those remaining:

The Original Poster, dmitrey, wants to copy caml syntax, because he
doesn't like brackets and commas.

The problem is that the expression:

name1 name2

is ambiguous. Does it mean name1(name2) or (name1, name2)? Add a third
name, and the ambiguity increases: there are now at least four ways to
interpret name1 name2 name3:

(name1, name2, name3)
(name1, name2(name3))
name1(name2, name3)
name1(name2(name3))

Dmitrey thinks that the third way is the "right" way to interpret the
proposed expression, just because it seems natural to him. But that is
illogical: it means that *different* parsing rules are applied to the
"name2 name3" part than to the "name1 *" part (where "*" stands in for
anything):

Dmitry wants "name1 *" to equal name1(*) which is fair enough as it
stands. But he wants to expand the * part, not by following the same rule,
but by following the different rule "name2 name3" =(name2, name3) and
form a tuple.

So what should "a b c d" be?

(a, b, c, d)
a(b, c, d)
a(b, (c, d))
a(b(c, d))
a(b(c(d)))

Have I missed anything? Which is the "right" way? Who can tell?

Who can guess?

I don't know how caml resolves these ambiguities, or even if caml resolves
them, or if it is a good solution. But I propose that an even better
solution is to insist on EXPLICIT function calls and tuple construction,
that is to insist on brackets and commas.

In other words, to go back to Dmitry's original post where he wrote:

"it would reduce length of code lines and make them more readable"

I would change that to say "it would reduce length of code lines and make
them LESS readable and MORE ambiguous, leading to MORE bugs".
--
Steven.

[Steve Holden]

Bart Ogryczak wrote:

On Mar 21, 3:38 pm, "dmitrey" <[e-mail]:

>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

How would you write "a = b(c())"?

In my opinion it'll make code extremely obfuscaded. The great thing
about Python, when comparing with eg. Perl or C, is that code is
readable, even if written by experienced hacker.

Yes, but let's not forget that we are in half-baked idea territory here.

The fact that dmitrey didn't twig that the absence of such a proposal
was likely for good reasons implies either an intellectual arrogance
beyond that of most mere mortals or a goodly dollop of ignorance.

Maybe we could omit the leading whitespace as well?

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

[dmitrey]

>foo bar baz

>foo(bar,baz)

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)

result = func1

for this case should using
result = func1()
should remain
+ remaining function defenitions
def myfun(param1, param2,...,paramk, *args, **kwargs)

How would you write "a = b(c())"?

a = b c()

>So what should "a b c d" be?

>(a, b, c, d)
a(b, c, d)
a(b, (c, d))
a(b(c, d))
a(b(c(d)))

I mentioned above that it should be 2nd case

>I don't know how caml resolves these ambiguities, or even if caml resolves

them
Yes, he does it perfectly, hence Python could have same abilities. But
I don't insist anything, I only proposed. Since majority disagreed
with the proposition, it don't worth further discussion.
WBR, D.
P.S. Steven, many people aren't able speak English as good as you, so
do I. I hope majority of readers will forgive me for wasting their
costly attantion & time.

[Bruno Desthuilliers]

dmitrey a écrit :

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

Not by a noticeable amount

and make them more readable,

I guess it's a matter of personal taste, experience with other languages
and whatnot, but as far a I'm concerned, I find the actual syntax more
readable - I don't have to think twice to know that it's a function call
and what are the params.

Also, and FWIW, in Python, the parens are the call operator. Given that
a function may return another function, how would you handle the
following case:

result = my_hof(foo, bar)(baaz)

And while where at it, since Python functions are first class objects,
how would you handle this other case:

def somefunc(arg):
return 2 * arg

alias = somefunc
# some code here
result = alias(42)

+ no
needs to write annoing charecters.

Could it be that these 'annoying characters' have a good reason to be
here ? Strange as it might be, Python has not been built randomly.

Maybe it will require more work than I suppose,

Probably, yes.

but anyway I think it worth.

So try to solve the above problems and come back here with an example
working implementation.

+ it will not yield incompabilities with previous Python versions.

Hmmm. I would not bet my life on this...

[Steven Bethard]

dmitrey wrote:

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

You should really post this somewhere that Guido will see it so he can
add it to PEP 3099: "Things that will Not Change in Python 3000".
Really, there's no way this is going to fly, so you might as well drop
it or write your own language.

STeVe

P.S. If you use IPython, I believe you can get some of this.

[Terry Reedy]

You asked two questions; the first others have asked also.

Mathematicians sometimes use brackets to indicate function application and
sometimes just juxtaposition. When they do the latter and when there are
things other than functions (to exclude pure lambda calculus), then there
are usually (always?) typographic conventions to differentiate between
function names and value names.

A common convention is value names one letter, function names multiple
letters; as in 'exp cos ln x'. Note that the functions all take one arg.
Another is that functions get capital letters, as in 'Fx'.

Without such differentiation, and without declaritive typing of *names*,
the reader cannot parse a sequence of expressions into function calls until
names are resolved into objects. And if calls can return either callable
or non-callable objects, as in Python, but rare in mathematics, then one
cannot parse until calls are actually made (or at least attempted, and an
exception raised). I mention 'attempted' because in Python there is no
certain way to be sure an object is callable except by calling it. It is
much more flexible and extensible than most math systems.

Other have alluded to this problem: if you have 'f' mean what 'f()' now
means, then you need another way to mean what 'f' now means, such as '`f'
(quote f). But again, Python names are not typed. And how would you then
indicate 'f()()' instead of 'f()'. The math notations without brackets
generally don't have to deal with callables returning callables.

I don't like typing ()s much either, but they seem necessary for Python,
and become easier with practice.

As for ,s: they are rather easy to type. More importantly, they turn
certain extraneous spaces into syntax errors instead of runtime bugs that
might pass silently and give bad answers. For instance, 'x_y' mistyped as
'x y'. Most importantly, making space syntactically significant either
within call brackets or everywhere would require prohibiting currently
optional spaces. For instance, 'daffodils + crocuses' would have to be
written 'daffodils+crocuses', like it or not.

Terry Jan Reedy

[bearophileHUGS]

I have nothing against brackets, and I think Python has used them for
too much time to allow a so big change in its syntax.
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.

Bye,
bearophile

[Erik Max Francis]

Diez B. Roggisch wrote:

dmitrey wrote:

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

This is not true, there is no shorter code lines:

foo bar baz
foo(bar,baz)

And the "more readable" part certainly depends on the habits of the user -
to me, it's harder to read.

I agree. Not to mention, the secondary stated goal of saving typing
should be very, very low down on the list of priorities in programming
language design. Excessive and needless verbosity is one thing; but
saving keystrokes for its own sake is not a priority and never should be.

--
Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM, Y!M erikmaxfrancis
I am not afraid / To be a lone Bohemian
-- Lamya

[Bruno Desthuilliers]

be************@lycos.com a écrit :

I have nothing against brackets, and I think Python has used them for
too much time to allow a so big change in its syntax.
But I think in some situations Ruby allows to omit them,

<iirc notice="please someone correct me if I say something wrong">
Yes. But in Ruby, there's a clear distinction between attributes and
methods, and attributes are always private, so you can only access them
thru method calls. Also, Ruby's methods are not really first class
objects - at least not the way they are in Python -, so when returning a
'callable' object from a method, you have to call a method of the object
(something like callable.call IIRC).
</iirc>

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.

I'd say 'a bit more elegant', not necessarily 'better'. But that's of
course very subjective, and I have far less experience with Ruby.

[Laurent Pointal]

Dennis Lee Bieber a écrit :

On Thu, 22 Mar 2007 03:27:37 +1100, Steven D'Aprano
<st***@REMOVE.THIS.cybersource.com.audeclaimed the following in
comp.lang.python:

>So what should "a b c d" be?

(a, b, c, d)
a(b, c, d)
a(b, (c, d))
a(b(c, d))
a(b(c(d)))

Have I missed anything? Which is the "right" way? Who can tell?

a(b)(c)(d)
or, explicit,
((a(b))(c))(d)

<G>

(Yeah ((Lisp) (is back)))

[Sebastian Kaliszewski]

dmitrey wrote:

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]

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***@holdenweb.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 "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.

--
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***@holdenweb.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.dyndns.org R'lyeh wgah'nagl fhtagn!