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 <[email protected]>
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

 

[Bjoern Schliessmann]

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

 

[Diez B. Roggisch]

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]

d> I think it should result
d> result = func1(func2, arg)
d> if you want
d> result = func1(func2(arg))
d> you should use
d> result = func1 (func2 arg)
d> if
d> ... = word1 word2 word3 ...
d> then only word "word1" should be call to func "word1" with parameters
d> word2, 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.

 

[Jason]

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]

+ 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]

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]

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

 

[Steve Holden]

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

 

[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]

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]

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.

 

[Bruno Desthuilliers]

(e-mail address removed) 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).

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.

 

[Dennis Lee Bieber]

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>
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Laurent Pointal]

Dennis Lee Bieber a écrit :

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

<G>

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