print(1, 2, 3)
supposed to print 1 2 3
or (1, 2, 3)
?What about
print (1, 2, 3)
?Are they the same? Should they be different? I know what the answer is in Python 3.8. A few weeks or months of programming in a Python where parens are optional, though, and I wouldn't be so sure anymore.
To solve the conflict the first parameter cannot start with a paren.
I'm also going to throw another reference to PEP-20 in the mix here: "There should be one-- and preferably only one --obvious way to do it." This implies either forcing parens everywhere or not using them at all. Paired with "explicit is better than implicit", I'd say that points pretty clearly at using parens everywhere.
There are several languages that people like for this sort of flexibility, but I think Python's relative rigidity has always been one of its strengths.
That was my first thought. Why would we turn a simple, binary choice -- "< 3: statement, >= 3: function" into a big old... maybe?
The binary choice hurts, because it dictates changes. Sure. People dislike change, but it's easy to support.
However, there's one thing worse than change, and that's inconsistency and uncertainty. like, in this case, going "zoinks, your change wasn't actually necessary!". Except, now we have both choices. So it'd be even more confusing.
edit: And just to be clear, I'm fine with making print a function for all new code. There were ways that the python community could have accomplished that [and the unicode switch] without breaking the entire language.
Imagine we'd drop HTTPS for a new protocol because it fixes the 'Referrer' spelling error.
Python 3 is the version with breaking changes from 2.x and while stuff is being broken, they decided to fix the print statement.
Python 3 wasn't invented to fix the print statement.
The problem with that is that the entire python ecosystem had to deal with that instead...
I'm going way past rant territory at this point, but there's a reason that Microsoft and Amazon are worth a trillion dollars a piece, and it's not because of beautiful and elegant APIs.
The following still compiles and runs, on the compiler that comes with the latest OpenBSD:
main()
{
printf("hello, world\n");
}
Somehow the C language has managed to survive and thrive without breaking the canonical example program.There is no reason to not require parenthesis. No reason.
This is what I hate about Ruby, not having parenthesis gets a bit confusing and adds a couple of gotchas
Print statement is no more. It is gone. It went to meet its maker. Forget about it
Doing away with parenthesis is not syntactic sugar, it's the watermelon seeds that get in the way
f(a)
f((a))
(f)(a)
(f)((a))
etc. and those all mean the same thing, and no-one finds this confusing.
What I do not like is TMTOWTDI. And I do not like Python violating its own principles (namely, "explicit is better than implicit"). As far as I am concerned, in Python, which does not have partial application, function application is handled by a special `(...)` operator that explicitly applies whatever function comes before the parens to whatever is inside the parens. Making the parens optional gives you two different ways to apply a function - and, by extension, one more place for people to argue about style - one of which is just an implicit version of the other.
You've got to have a way better reason to do that to a language than just, "Hey, isn't this cool? And also, I miss the Python 2 vs Python 3 wars, so wouldn't it be fun to give that pot another stir for old time's sake?"
I get it, the change from a print statement to a print function caused some pain. But it did bring some practical benefits, and the transition is in the past now, and, to quote the Zen of Python again, "special cases aren't special enough to break the rules."