
Seriously, what is the obsession with putting things on one line here?
There is no obsession. It is more of a consideration of balance between operation complexity vs its verbosity.
If it's because "it works better when there is a long list of such assignments" then unless you actually show a real-world example, it's hard to discuss the *actual* trade-offs.
First library that comes to mind, which has a high level constructor: https://github.com/pydata/xarray/blob/main/xarray/core/dataarray.py#L437 <https://github.com/pydata/xarray/blob/main/xarray/core/dataarray.py#L437>
It's often an anti-pattern to have a function with that many arguments in the first place, so refactoring the code may be a better option). It often is, but at the same time unavoidable in some cases, i.e. high level APIs. Few examples, CLIs (e.g. poetry), constructors of high level objects.
I think what would be nice to have is a set of dimensions that are deemed to be of importance when deciding on a language constructs. plot(dim1, dim2, dim3) dim1 - number of lines dim2 - number of terms dim3 - number of operations dim4 - frequency of usage dim5 - ... Of course, not all dimensions can be quantified. And to quantify some of them certain definitions would have to be decided on, e.g. what is an operation. Also, I do not know what those dimensions should be, they would ideally be decided by those who have a very good sense of python’s long-term vision. Such information could be helpful in having productive discussions regarding such considerations and proposals. In this case I am concerned with a balance of brevity vs complexity of python constructs, which is a core building block in a space of constantly increasing number of abstraction layers. —Nothing ever dies, just enters the state of deferred evaluation— DG