[Python-ideas] Method chaining notation

[Andrew Barnert]

On Feb 22, 2014, at 18:48, Chris Angelico <rosuav at gmail.com> wrote:

> On Sun, Feb 23, 2014 at 1:25 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> 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.

The difference between the look of nested statements and giant expressions in Python is much larger than the difference between the look of . and ->. One structure means you're doing imperative stuff, mutating one value on each line. The other means you're doing declarative stuff, transforming objects into new temporary objects. That distinction is huge, and the fact that it's immediately visible in Python i's one of the strengths of Python over most other "multi-paradigm" languages. 

> 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)

But in real life code, this would be something like rows * columns, and even if rows and columns are constant, they're constants you might want to change in a future version of the code, so you _would_ name them.

And if, as you say, they're actually function calls, not constants, I think most people would write:

rows = consoleobj.getparam('ROWS')
cols = consoleobj.getparam('COLS')
cells = rows * cols

... rather than try to cram it all in one line.

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

All you're arguing here is that PyGtk is badly designed, or that Gtk is not a good match for Python, so you have to write wrappers. There's no reason the wrapper has to be fluent instead of declarative.