[Python-ideas] Method chaining notation

[Chris Angelico]

On Sun, Feb 23, 2014 at 1:25 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> it's a fundamentally bad idea to blur that distinction: you should be
> able to tell *at a glance* whether an operation is mutating an
> existing object or creating a new one...
>
> Compare:
>
>     seq = get_data()
>     seq.sort()
>
>     seq = sorted(get_data())
>
> Now, compare that with the proposed syntax as applied to the first operation:
>
>     seq = []->extend(get_data())->sort()
>
> That *looks* like it should be a data transformation pipeline, but
> it's not - each step in the chain is mutating the original object,
> rather than creating a new one. That's a critical *problem* with the
> idea, not a desirable feature.

Except that it doesn't. The idea of using a different operator is that
it should clearly be mutating the original object. It really IS
obvious, at a glance, that it's going to be returning the existing
object, because that operator means it will always be.

I believe that naming things that don't matter is a bad idea. We don't
write code like this:

five = 5
two = 2
print("ten is",five*two)

because the intermediate values are completely insignificant. It's
much better to leave them unnamed. (Okay, they're trivial here, but
suppose those were function calls.) In a GTK-based layout, you'll end
up creating a whole lot of invisible widgets whose sole purpose is to
control the layout of other widgets. In a complex window, you might
easily have dozens of those. (Same happens in Tkinter, from what I
gather, but I haven't much looked into that.) Naming those widgets
doesn't improve readability - in fact, it damages it, because you're
left wondering which insignificant box is which. Leaving them unnamed
and just part of a single expression emphasizes their insignificance.

ChrisA