5 ms·

OK, so I sort of get it. I love ML style syntax. I love the way that it supports great things like partial application. What I do not like is TMTOWTDI. And I d

OK, so I sort of get it. I love ML style syntax. I love the way that it supports great things like partial application. 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."

lmm 6y ago
I don't think having two different syntactic ways to write the the same thing - at a purely syntactic level - is a violation of TMTOWTDI. After all, Python already lets you write: f(a) f((a)) (f)(a) (f)((a)) etc. and those all mean the same thing, and no-one finds this confusing.
jacquesm 6y ago
I don't see why they couldn't just leave the old print statement in place so it wouldn't break as much code as it did.
- kevin_thibedeau 6y ago
  It was an inconsistent albatross of a special case. The whole point of 3 was to break things that were bad ideas.
  - moreaccountspls 6y ago
    So what? In the history of Python, there was literally 0 bugs caused by print being a statement. Breaking backwards compatibility for shit like that is amateur hour. 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.
    - kevin_thibedeau 6y ago
      Being a statement is less of an issue than the special behavior of the trailing comma, '>>' token, and the inability to augment behavior with named arguments. The lexer shouldn't have to deal with that sort of stuff.
      - moreaccountspls 6y ago
        > The lexer shouldn't have to deal with that sort of stuff. 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.
        kevin_thibedeau 6y ago
        The whole ecosystem had over ten years to import print_function and fix their shit for the eventual flag day.
        PhantomGremlin 6y ago
        Python 3 literally broke "hello, world". For some vague notion of aesthetics. Or for some even more obscure "inside baseball" reason that 99% of Python users could care less about. 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.
Karuhanga 6y ago
> which does not have partial application functools.partial?
raverbashing 6y ago
Agreed 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
- fomine3 6y ago
  Method call without parenthesis is very useful for making DSL.
amelius 6y ago
If Python wants to come closer to a functional style of programming, then they should allow inline lambda functions which span multiple lines and still follow the normal syntax (i.e., escaping newlines would be cheating).
riknos314 6y ago
This is on point. 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.
mumblemumble 6y ago
Another thought: This would create ambiguities in the language that would harm its readability. Maybe not as far as the computer is concerned, but certainly as far as the humans are concerned. Is 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.
- yuchi 6y ago
  This is explicitely explained in the linked article. To solve the conflict the first parameter cannot start with a paren.
  - mumblemumble 6y ago
    By, "Maybe not as far as the computer is concerned, but certainly as far as the humans are concerned.", I meant to invoke the principle that there's more to a good grammar than the computer being able to parse it reliably. It's also got to not be confusing for its wet, squishy readers.
tetha 6y ago
> 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?" 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.
jcfields 6y ago
As they say, the road to Perl is paved with good intentions. 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.

lmm 6y ago

I don't think having two different syntactic ways to write the the same thing - at a purely syntactic level - is a violation of TMTOWTDI. After all, Python already lets you write: f(a) f((a)) (f)(a) (f)((a)) etc. and those all mean the same thing, and no-one finds this confusing.

jacquesm 6y ago

I don't see why they couldn't just leave the old print statement in place so it wouldn't break as much code as it did.

kevin_thibedeau 6y ago
It was an inconsistent albatross of a special case. The whole point of 3 was to break things that were bad ideas.
- moreaccountspls 6y ago
  So what? In the history of Python, there was literally 0 bugs caused by print being a statement. Breaking backwards compatibility for shit like that is amateur hour. 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.
  - kevin_thibedeau 6y ago
    Being a statement is less of an issue than the special behavior of the trailing comma, '>>' token, and the inability to augment behavior with named arguments. The lexer shouldn't have to deal with that sort of stuff.
    - moreaccountspls 6y ago
      > The lexer shouldn't have to deal with that sort of stuff. 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.
      - kevin_thibedeau 6y ago
        The whole ecosystem had over ten years to import print_function and fix their shit for the eventual flag day.
        PhantomGremlin 6y ago
        Python 3 literally broke "hello, world". For some vague notion of aesthetics. Or for some even more obscure "inside baseball" reason that 99% of Python users could care less about. 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.

Karuhanga 6y ago

> which does not have partial application functools.partial?

raverbashing 6y ago

Agreed 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

fomine3 6y ago
Method call without parenthesis is very useful for making DSL.

amelius 6y ago

If Python wants to come closer to a functional style of programming, then they should allow inline lambda functions which span multiple lines and still follow the normal syntax (i.e., escaping newlines would be cheating).

riknos314 6y ago

This is on point. 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.

mumblemumble 6y ago

Another thought: This would create ambiguities in the language that would harm its readability. Maybe not as far as the computer is concerned, but certainly as far as the humans are concerned. Is 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.

yuchi 6y ago
This is explicitely explained in the linked article. To solve the conflict the first parameter cannot start with a paren.
- mumblemumble 6y ago
  By, "Maybe not as far as the computer is concerned, but certainly as far as the humans are concerned.", I meant to invoke the principle that there's more to a good grammar than the computer being able to parse it reliably. It's also got to not be confusing for its wet, squishy readers.

tetha 6y ago

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

jcfields 6y ago

As they say, the road to Perl is paved with good intentions. 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.