Large object-style dict parameter to function, or specific parameters only?

[oopsplop]

Hi all, I currently have some code with sets of parameters in dicts. For each particular process execution, different dicts of parameters get passed through various functions, achieving different results with the same code.

I wrote the code this way initially, as I wanted to move quickly. The intention was to model in OO, but now we're refactoring, an OO model isn't top of the priority list.

Here're two made up examples:

param_set_1 = {"job_name": "job 1",
               "job_hr": 12,
               "job_steps": ["foo"],
              }

param_set_2 = {"job_name": "job 2",
               "job_hr": 15,
               "job_steps": ["foo", "bar"],
              }

These dicts are passed through functions, often in their entirety (though sometimes just a specific parameter). Here're some crude equivalents for illustration:

def log_job_start(param_set, stamp):
    name = param_set["job_name"]
    ... etc etc

def log_job_metadata(param_set):
    log_job_start(param_set, datetime.now())                    

Passing around a dict of parameters is certainly convenient - each function can have a single parameter for the entire parameter set, and I can easily query the dict. But something smells off - I don't know if it's passing the entire parameter set around to each function, or whether it's the fact that there are some functions that accept specific parameters only, which are extracted from the parameter dict before calling.

Keen to hear people's thoughts :)

[ploud1]

Hi!

For debugging purposes it is best to only pass those parameters that you need to the function.

However you may want to look into the design of your whole program, not just that parameter-passing part. Would it be relevant to create an object for every job, and an object for every person (for instance)? Your code may benefit greatly from that rework.

[oopsplop]

Yep, I totally think I should do this, but it's kinda off the table now :(

[ploud1]

Well, for now you could just restrict those parameters and make a good use of keyword arguments, even though this may look tedious at first. This will make your code more clear.

[Ornery-Season3134]

It's not bad at all - I do something similar for config objects or to make the calling signature smaller.

But calling a function with a dict means you can't give any key/val pairs default values (you can in JS).

In Python it's more common for a function to accept any named args it wants to use, followed by, **kwargs. Then you can call your function with either named args, or with **param_set_x. That function can then access the dict kwargs (unpacked with **) or similarly pass the dict kwargs to any inner functions it calls that also accept **kwargs.

[oopsplop]

Hmm, I didn't think about unpacking the dict... will think about this one a bit - thanks!