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*********@gm ail.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 <miki.teb...@gm ail.com>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.ne t(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.n l>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C 4]
Private email: pi**@vanoostrum .org

[Jason]

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

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, incomprehensibl e 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.ne twrote:

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

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(nam e3))

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.