Black: Consider rule for fluent interface / method chaining

[max-sixty]

Particularly in py-data, we often use long method chains - aka fluent programming

The 'best' approach to grouping items in a chained statement is by method, including any arguments that method takes. By 'best', I mean groups of items which are self-contained - i.e. the items within a group influence other items in their group, but don't influence items outside of their group

But at the moment black is splitting methods _from_ their arguments, while grouping methods where possible. Take a case:

     result = (
-        data_set
-        .round(0)
-        .isin([0])
-        .sel(dim2=0, dim3='a')
-        .isel(dim1=[0, 1])
-        .drop(['time', 'dim3', 'dim2', 'numbers'])
-        .squeeze()
+        data_set.round(0).isin([0]).sel(dim2=0, dim3='a').isel(
+            dim1=[0, 1]
+        ).drop(
+            ['time', 'dim3', 'dim2', 'numbers']
+        ).squeeze()
     )

Here, .isel(dim1=[0, 1]) is a self-contained group of information; you can see that and know what's happening. dim1=[0, 1] is not - you need to know the method that it's being applied to

I realize this would probably be a branching in black's logic, since often splitting on args is reasonable. But I'm also fairly confident that black does not handle this specific case well.
Is there a synthesis here that adds this without complication?

FWIW I've recently starting using Rust, and rustfmt does this well.

Operating system:MacOS
Python version:3.6.4
Black version:black, version 18.3a4
Does also happen on master:Y

[ambv]

This was discussed in #67 and I still think this is a rather foreign syntax to Python where with significant indentation this form isn't even valid unless additional parentheses are used.

Since this comes up again and again, I recognize that a large population probably wants it so I'll reopen the initial issue.