News for hackers. Stuff that matters.
Re:Bringing the print statement back by mumblemumble on Tuesday July 14, 2020 @04:54PM (#23837722)
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."

Re:Bringing the print statement back by mumblemumble on Tuesday July 14, 2020 @05:25PM (#23838119)
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.

Re:Bringing the print statement back by yuchi on Wednesday July 15, 2020 @06:17AM (#23843273)
This is explicitely explained in the linked article.

To solve the conflict the first parameter cannot start with a paren.

Re:Bringing the print statement back by mumblemumble on Wednesday July 15, 2020 @08:34AM (#23844249)
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.
Re:Bringing the print statement back by riknos314 on Tuesday July 14, 2020 @05:10PM (#23837941)
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.

Re:Bringing the print statement back by jcfields on Tuesday July 14, 2020 @05:54PM (#23838457)
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.

Re:Bringing the print statement back by tetha on Tuesday July 14, 2020 @05:26PM (#23838131)
> 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.

Re:Bringing the print statement back by jacquesm on Tuesday July 14, 2020 @08:28PM (#23839823)
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.
Re:Bringing the print statement back by kevin_thibedeau on Tuesday July 14, 2020 @09:32PM (#23840220)
It was an inconsistent albatross of a special case. The whole point of 3 was to break things that were bad ideas.
Re:Bringing the print statement back by moreaccountspls on Tuesday July 14, 2020 @09:43PM (#23840292)
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.

Re:Bringing the print statement back by kevin_thibedeau on Tuesday July 14, 2020 @11:05PM (#23840758)
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.
Re:Bringing the print statement back by jacquesm on Wednesday July 15, 2020 @02:23AM (#23841972)
Backwards compatibility is something that you only ditch for extremely good reasons, for instance to deal with a security issue that can not be handled in any other way. Breaking it for reasons of aesthetics is just plain dumb. The python ecosystem is still suffering from these major mistakes many years later and python's image as a reliable and trustworthy tool suffered right along with it. Such changes are fine pre 1.0, but once you ask people to base their production systems on it you maintain backwards compatibility at a cost, even if that means holding your nose occasionally. And my suggested fix would at least allow for the old syntax to live happily along with the new one, which given the price (two stupid brackets) could have easily been dealt with. Focusing on purity vs the responsibility towards people maintaining 100's of millions of lines of code in aggregate (if not another order of magnitude more) means you don't have your priorities straight.

Imagine we'd drop HTTPS for a new protocol because it fixes the 'Referrer' spelling error.

Re:Bringing the print statement back by wodenokoto on Wednesday July 15, 2020 @07:40AM (#23843816)
The analogy here is: "Imagine making a new, incompatible protocol and NOT fixing the 'Referrer' spelling error, because the old protocol had that 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.

Re:Bringing the print statement back by D13Fd on Wednesday July 15, 2020 @09:53AM (#23845230)
The backwards compatibility was already ditched. It's over.
Re:Bringing the print statement back by moreaccountspls on Wednesday July 15, 2020 @02:07AM (#23841881)
> 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.

Re:Bringing the print statement back by bregma on Wednesday July 15, 2020 @08:01AM (#23843959)
SO, you're saying that if Python abandoned quality in favour of aggressive sales and marketing in the channel and cut-throat monopolistic practices against competing program languages, then its core programmers would rise to the ranks of American social elites?
Re:Bringing the print statement back by moreaccountspls on Wednesday July 15, 2020 @01:08PM (#23848158)
Alright, I'll bite. Why do you think not breaking users programs is abandoning quality?
Re:Bringing the print statement back by kevin_thibedeau on Wednesday July 15, 2020 @02:40AM (#23842048)
The whole ecosystem had over ten years to import print_function and fix their shit for the eventual flag day.
Re:Bringing the print statement back by PhantomGremlin on Wednesday July 15, 2020 @04:39AM (#23842687)
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.
Re:Bringing the print statement back by jacquesm on Wednesday July 15, 2020 @05:15AM (#23842881)
It survived and thrived because it did not break the canonical example program. If they had broken printf in say 1995 the situation would be entirely different today. Oh, and they did get it right the first time by making it a function.
Re:Bringing the print statement back by raverbashing on Wednesday July 15, 2020 @06:14AM (#23843254)
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

Re:Bringing the print statement back by fomine3 on Wednesday July 15, 2020 @09:11PM (#23854591)
Method call without parenthesis is very useful for making DSL.
Re:Bringing the print statement back by amelius on Wednesday July 15, 2020 @07:48AM (#23843863)
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).
Re:Bringing the print statement back by lmm on Tuesday July 14, 2020 @08:38PM (#23839897)
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.
Re:Bringing the print statement back by Karuhanga on Wednesday July 15, 2020 @12:59AM (#23841513)
> which does not have partial application functools.partial?