LWN: Comments on "The (non-)return of the Python print statement"

The (non-)return of the Python print statement

flussence — Sat, 18 Jul 2020 11:17:30 +0000

Python's solution to the waterbed theory of language design seems to be to nail down the lumps.

The (non-)return of the Python print statement

jezuch — Tue, 14 Jul 2020 05:01:59 +0000

(To me that proposal sounded like "we've created this problem for ourselves so let's wade deeper into the weeds!" Because language design is fun or something?)

The (non-)return of the Python print statement

kenshoen — Tue, 14 Jul 2020 04:48:58 +0000

Is it another deviation from PEP3099?

The parser won't be more complex than LL(1).

The (non-)return of the Python print statement

nix — Sat, 11 Jul 2020 14:21:30 +0000

Quite. As the proposal notes, people have been moving *towards* free functions for the cases considered, not away from them, so there's no way they could be considered anything like deprecated.

The (non-)return of the Python print statement

kokada — Thu, 09 Jul 2020 01:13:50 +0000

Yeah, I know, but having this in the language itself would be great.

The (non-)return of the Python print statement

niner — Mon, 06 Jul 2020 19:24:56 +0000

In Raku you could use the compose function operator:
my &composed = &print ∘ &fn2 ∘ &fn1;
composed(foo);

or directly:
(&print ∘ &fn2 ∘ &fn1)(foo)

Particularily handy in combination with the reduction meta operator [] when you have a list of functions:
my &composed = [∘] @function-list; # i.e. @function-list[0] ∘ @function-list[1] ∘ @function-list[2] ...
composed foo; # because parentheses aren't really needed anyway

The (non-)return of the Python print statement

NAR — Sun, 05 Jul 2020 19:58:53 +0000

Elixir came to my mind as well when I read this article. It's really confusing when parenthesis are omitted, but I think that's what makes some Ecto code look like SQL, e.g. instead of this:

query = from(c in City, select: {c.name, c.population})

one can write

query = from c in City, select: {c.name, c.population}

The (non-)return of the Python print statement

Cyberax — Sun, 05 Jul 2020 19:48:26 +0000

This makes no sense at all. C++ is not Java and free functions are an integral feature. Especially since object methods can behave drastically differently from functions.

The (non-)return of the Python print statement

NAR — Sun, 05 Jul 2020 19:46:32 +0000

Actually that weird C++ idea makes some sense, it's too bad that C-compatibility (existence of free functions) causes problems decades later.

The (non-)return of the Python print statement

quotemstr — Sun, 05 Jul 2020 12:58:47 +0000

Language designers sometimes, late in the evolution of their languages, propose the weirdest mechanisms. Here we have a function call syntax in Python that I couldn't be more against. In C++-land, we have Bjarne Stroustrup's weird idea [1] for a "unified call syntax". Sometimes things are done and should be left alone.

As for Python's PEG parser: I really dislike this trend towards complicated and context-sensitive language grammars. I don't want to have to backtrack across half a megabyte of crap to figure out what a token means. LALR is powerful enough to express anything you might reasonably want in a programming language. For God's sake, let's keep language grammars simple.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n...

The (non-)return of the Python print statement

xi0n — Fri, 03 Jul 2020 16:22:16 +0000

You don’t even need to define partial(), as it’s already present in functools.

The (non-)return of the Python print statement

raoni — Fri, 03 Jul 2020 14:23:42 +0000

I too have this instinct. Bu I think it is a typing mindset that is context dependent, when on shell or REPL you are on a "bash" mindset, that is different than when on an text editor.

The (non-)return of the Python print statement

marcH — Fri, 03 Jul 2020 10:04:00 +0000

> Oh, with those non-parenthetical calls they almost pulled a Perl.

Exactly https://en.wikipedia.org/wiki/There%27s_more_than_one_way...

The (non-)return of the Python print statement

NYKevin — Fri, 03 Jul 2020 05:52:55 +0000

To be fair, GvR means "because we can now." In earlier Python 3.x, this was not possible. See for example this code, which is trying to decide whether or not the syntax error we are about to raise was caused by a 2.x-style print statement.

TL;DR: It's processing the code as a raw string, by hand. No AST, no tokenizer, just raw Unicode. It's mostly equivalent to grep -E '^[[:space:]]*print '. It should be entirely unsurprising that you can't "simply" convert this custom syntax error into a valid parse.

The (non-)return of the Python print statement

ibukanov — Fri, 03 Jul 2020 03:45:53 +0000

Haskell does not have that problem as the language is lazy and functional. So there is no difference between a reference to a function or its result.

The (non-)return of the Python print statement

joey — Fri, 03 Jul 2020 01:34:00 +0000

More like a Haskell really, but the non-tuples gave it away.

The (non-)return of the Python print statement

smitty_one_each — Thu, 02 Jul 2020 13:57:19 +0000

See your Perl; raise you Visual Basic #ForTheWin

The (non-)return of the Python print statement

jafd — Thu, 02 Jul 2020 13:51:51 +0000

Oh. I have a blind spot wherever those four letters are invoked.

The (non-)return of the Python print statement

dskoll — Thu, 02 Jul 2020 13:49:47 +0000

I know. I posted a link to a funny XKCD cartoon.

The (non-)return of the Python print statement

jafd — Thu, 02 Jul 2020 13:43:58 +0000

I'd rather have a demonstration of how one could, for example, create a new type of string — say I want to embed SQL which will get validated all over my codebase before my program even runs.

the_sql = sql"SELECT * FROM foobar WHERE (x = :placeholder)"

And if my little prerun hook is not present, the string is being treated as just string.

Or make it HTML, or whatever else code or markup that you'd like to throw over the fence at another system.

But for all gods' sake, let the print statement burn already. You Python people were putting it down for 12 years already, and it saddens me to no end that some people still can't let go of it.

The (non-)return of the Python print statement

jafd — Thu, 02 Jul 2020 13:34:05 +0000

In Perl, parentheses in function calls are optional.

To pass an actual subroutine reference somewhere, you need to specify it as \&foo.

The (non-)return of the Python print statement

dskoll — Thu, 02 Jul 2020 11:10:44 +0000

What's that about Perl?

The (non-)return of the Python print statement

rschroev — Thu, 02 Jul 2020 10:55:03 +0000

Please no. Explicit is better than implicit. Python now makes a very clear distinction between just referring to a function (no parentheses), and calling a function (parentheses), unlike some other languages. I would hate to loose that.

Just because you can do something, doesn't mean you should..

The (non-)return of the Python print statement

mina86 — Thu, 02 Jul 2020 10:11:15 +0000

First formatted strings, now attempt to allow function calls without parenthesises. It’s like they’re trying to tell us Perl was right all along. ;)

The (non-)return of the Python print statement

ragnar — Thu, 02 Jul 2020 09:25:31 +0000

You could do something like this:

def apply(first_arg, *args):
    res = first_arg
    for item in args:
        res = item(res)
    return res

def partial(fn, *args):
    def _inner(*inner_args):
        return fn(*(args + inner_args))
    return _inner

apply('foo', len, partial(operator.mul, 7), print)

The (non-)return of the Python print statement

dw — Thu, 02 Jul 2020 09:02:48 +0000

Eventually the kindest thing you can do for any old horse is to take it out back and shoot it.

The (non-)return of the Python print statement

NYKevin — Thu, 02 Jul 2020 02:24:17 +0000

Haskell does that, but Haskell also automatically curries everything. Since Python has always had a strong difference between foo(bar, baz) and foo(bar)(baz), I doubt it would be a Good Idea.

The (non-)return of the Python print statement

ncm — Thu, 02 Jul 2020 01:04:18 +0000

If the print function were to return itself, then we could have (had)

>>> print (2+2) 42
4 42

but no one would ever have wanted that.

The (non-)return of the Python print statement

kokada — Thu, 02 Jul 2020 01:03:24 +0000

Glad this proposal didn't gain track. Most languages that I know that allow calling functions without parenthesis (Ruby, Elixir) are either ambiguous causing unnecessary confusion (Ruby) or this is discouraged by the language users even if possible (Elixir).

One case that I think having function without parenthesis helps is when you're calling multiple functions, something like:

print fn1(fn2(foo))

But in this case, I really prefer thread macros instead:

(-> foo fn2 fn1 print)

I would love if Python introduced something like above instead.

The (non-)return of the Python print statement

maney — Thu, 02 Jul 2020 00:48:05 +0000

My first thought was along the lines of another comment here: we just got done with that conversion! But there is in fact one place that my fingers persist in wishing print statements were still a thing: when doing discovery/experimentation in the REPL. The things that were real warts (yeah >>filething, yuck) are non-issues there.

Or maybe my fingers are just lazy - they keep trying to leave the parens off of dir, too. :-)

The (non-)return of the Python print statement

roc — Thu, 02 Jul 2020 00:02:25 +0000

Reintroducing print statements just after everyone had to finish converting their print statements to print functions is just rubbing salt in the wound.

The (non-)return of the Python print statement

kjp — Wed, 01 Jul 2020 23:34:53 +0000

> Van Rossum said there was an element of "because we can" to the idea;

There is a whole lot of venting I could post in response to this right now, but I'm done. I'm just done.

The (non-)return of the Python print statement

jafd — Wed, 01 Jul 2020 22:57:54 +0000

Oh, with those non-parenthetical calls they almost pulled a Perl.

If the proposal got accepted, though, I'm wondering if there wouldn't be an ambiguity if a function call was without arguments: is this a reference to the function itself or to its result? Or should we specify &foo for the former, like, again, Perl?

The (non-)return of the Python print statement

benhoyt — Wed, 01 Jul 2020 22:18:23 +0000

I'm very glad this change didn't get any traction. Print being a statement (well, really being special) was an annoyance in Python 2, and makes much more sense as a plain old function in Python 3. It'd be weird to have two different ways to print stuff (with parens and without), and avoids the whole "is it a tuple or are these function args?". I so much prefer "print('foo', file=sys.stderr)" over "print >>sys.stderr, 'foo'". And "len 'abc'" ... that's just crazy talk. :-)