[Python-ideas] Method chaining notation

[Andrew Barnert]

On Feb 23, 2014, at 23:00, Chris Angelico <rosuav at gmail.com> wrote:

> On Mon, Feb 24, 2014 at 5:49 PM, Andrew Barnert <abarnert at yahoo.com> wrote:
>> But remember that there is an advantage to Gtk, Qt, etc. having their own language-agnostic idioms. They have a hard enough time documenting the whole thing as it is; if they had to write completely different documentation for C, C++, Vala, Python, .NET, etc., we just wouldn't get any documentation.
> 
> Point to note: When I'm trying to pin down an issue that relates to
> GTK on Windows, I'll sometimes switch between Pike and Python, since
> my installations of them embed different GTK versions. (I discovered a
> GTK bug that way.) Being able to translate my code from one language
> to another is extremely useful. And when I'm looking for docs and
> (especially) examples, it's really common to get them for some
> completely different language - it's easier to translate back from
> (say) Perl than to hunt down an example in the language I'm actually
> using.
> 
> A more Pythonic wrapper around object creation would pretty much look
> like what I was saying, except that it would take specific coding
> work. Actually, probably all it'd take is a module that imports all
> the PyGTK classes and wraps them in Steven's chain() function.

But that would be _less_ Pythonic, not more.

The fact that mutating methods return None--and, more generally, the strong divide between mutation and transformation and between statements and expressions--is one of the major ways in which Python is idiomatically different from languages that are specifically meant to be fluent (like Smalltalk or C#) or that just never considered the design issue (like perl or JavaScript).

You don't have to agree with Guido that method chaining is bad. But he's designed his language and stdlib to discourage it, and therefore anything you do in the opposite direction is fighting against the grain of the language and its standard idioms.