Yapf: Line break of function/method declaration with args and keyword-args

[MagSec-Arts]

I don't know if this is an issue or a newer feature which I missed.

I have the following code:

class Test(object):
    def __init__(self, argument1, argument2, argument3, argument4=None, argument5=None, argument6=None):
        pass

.. and would expect to get a result looking like this:

class Test(object):
    def __init__(self, argument1, argument2, argument3, argument4=None, 
                 argument5=None, argument6=None):
        pass

But instead yapf produces the following:

class Test(object):
    def __init__(self,
                 argument1,
                 argument2,
                 argument3,
                 argument4=None,
                 argument5=None,
                 argument6=None):
        pass

This only happens when keyword-arguments are used.
Is there a way to turn off this behavior, or is it a bug?

This formatting is against our internal Python guidline.

I only had time to test this on a Windows machine with yapf 0.16.0.

[gwelymernans]

If you set SPLIT_BEFORE_NAMED_ASSIGNS to False, then it should do what you want. It's going to turn it off in all situations, though. So it's a bit of a heavy hammer if you like this for, say, function calls.

[MagSec-Arts]

OK thanks, but I also discovered, that the knob DEDENT_CLOSING_BRACKETS causes a method/function definition to look like:

def __init__(
    self, argument1, argument2, argument3, argument4=None, 
    rgument5=None, argument6=None
):

Which is not what I want, but I still want this behavior for variable definition or funtion calls with keyword arguments.

Is it possible to strip out function/method declarations to be influenced by this knob?

[pengzhenghao]

Is there some way to use DEDENT_CLOSING_BRACKETS for all brackets expression that applicable EXCEPT the function definition?

I got something like

def build_reward_function_change_goal(
    config, input_length, transition_length, max_track_pos, lanes
):            <--- This line is what I don't want

which is not what I wanted.

But I still like the format in other case:

        raise NotImplementedError(
            "We don't prepare the build function <{}>, \n"
            "we only have {} here.".format(
                build_reward_function_full_name,
                get_all_reward_function_names()
            )
        )

which, if disable the DEDENT_CLOSING_BRACKETS would become:

        raise NotImplementedError(
            "We don't prepare the build function <{}>, \n"
            "we only have {} here.".format(
                build_reward_function_full_name,
                get_all_reward_function_names()))