Different formatting depending number of argument to a function
I noticed, that with version 0.6.2, when a the first parameter for a function (here: other_function) does not take arguments, yapf prints what I would expect:
$ echo 'something = a_function(other_function(), some_more_long_arguments, and_more_long_args)' | yapf
something = a_function(other_function(), some_more_long_arguments,
and_more_long_args)
However, if other_function has an argument, something strange happens:
$ echo 'something = a_function(other_function(a), some_more_long_arguments, and_more_long_args)' | yapf
something = a_function(
other_function(a), some_more_long_arguments, and_more_long_args)
Is it a bug, or a feature?
Some code formatted in October (that is: some earlier version of yapf) was formatted as the first fragment, even though it used other_function(a) like construct.
This seems related to #216 Is it possible to control how this works?
Sorry for the late response. I didn't see this until now.
Yes, this is a conscious decision. The issue yapf is avoiding is something like this:
something = a_function(another_function(
argument1, argument2, argument3),
a_function_arg_2,
a_function_arg_3)
Oddly enough, this is "valid" according to Python linters. So what we do is split before the another_function call when it has arguments. Restricting it to splitting when another_function has more than one argument wouldn't really work well, because it may be required to place its argument on a separate line...
I have a patch I'll be pushing up for PR that will allow the above snippet to format as
something = a_function(another_function(argument1,
argument2,
argument3),
a_function_arg_2,
a_function_arg_3)
which is what I want (and what I think the original poster also wanted).