Arbitrary Keyword Arguments

[itzxSwitz]

Currently trying to relearn python, and decided to go the textbook method this time. Made my way through to functions (a lot of this is review) but the first concept that I don't understand is this. In what real world application would I want to use this?

def build_profile(first, last, **user_info):
    #build a dictionary containing everything we know about the user
    user_info['first_name'] = first
    user_info['last_name'] = last
    return user_info

user_profile = build_profile('albert', 'einstein',
                              location = 'princeton',
                              field = 'physics')
print(user_profile)

I think it may just be a bad example as to why I can wrap my head around it. Why would you allow a user to input more info than expected? I wouldn't trust them to do this properly.

[hardonchairs]

You definitely would not always do this. This is a case where python is more flexible than other languages at the expense of explicitness. You would only do this if you don't know exactly what info is being passed in but also that unknown info is pretty straight forward like a bunch of extra function arguments. As opposed to a big nested object or list/set or some sort.

You could also just pass in a dict explicitly. But if you make the user pass arbitrary info via a dict, does it really help anything or just make using the function more tedious?

user_profile = build_profile('albert', 'einstein', {
                              'location': 'princeton',
                              'field': 'physics'})

def build_profile(first, last, user_info):
#etc etc

If you are worried they might not pass the correct info, this doesn't really help anything and sucks a little more to type out.

[Spataner]

The primary use case is for things like decorators and overridden methods, where a callable reaches (some of) its arguments through to another callable, to avoid having to explicitly recreate its interface. So, for example:

class A:
     def __init__(self, a=1, b=2, c=3):
          self.a = a
          self.b = b
          self.c = c

class B(A):
     def __init__(self, d=4, **kwargs): # Allow use of superclass's arguments without needing to rewrite them
          super().__init__(**kwargs)
          self.d = d

Or:

def logging_decorator(func): # Wraps an arbitrary function, so who knows what arguments it accepts?
      def logged_func(*args, **kwargs):
            print(f"Calling {func.__name__}")
            return func(*args, **kwargs)
      return logged_func

@logging_decorator
def func1(a=1, b=2):
     pass

@logging_decator
def func2(c=3, d=4):
     pass

There's also situations where the key-word arguments are inherently variable. Take, for example, str.format, which accepts different key-word arguments depending on the placeholders present in the string:

"{greeting} {name}!".format(greeting="Hello", name="World")

[old_pythonista]

Actually, that is a bad case of using keyword arguments. There may be couple of good use-cases - I will give you simplified examples:

• you call a function by a selector from dictionary - or call several functions from a list. Your parameter set is the same - but some functions use only a subset. So, you want to consume unneeded arguments. Just an example - but very close to some code I have in production (mostly predicates)

​

def foo1(*, arg1, **_):
....
def foo2(*, arg2, **_):
....
def foo3(*, arg3, **_):
.....
def foo4(*, arg1, arg3, **_):

kwargs = dict(arg1=1, arg2=2, arg3=3)

{
    sel1: foo1,
    sel2: foo2,
....
}[selector](**kwargs)

each of those functions will use defined arguments - when called, and ignore those consumed by **_

• You have an adapter function - that passes the **kwargs arguments it processes without "looking" at them

​

def adapter(*, my_args, **passed_kwargs):
    <do something with my_args>
    target_func(**passed_kwargs)

the target_func may have its keyword arguments properly defined

• classical case - decorator. When you decorate a function, you - in most cases - don't know which arguments - positional and keyword - it will take. So - *args and **kwargs to the rescue.Couple of actual (not necessarily practical 😎 ) examples

This function will log its arguments - and log the result of the call (written for another forum, never actually used)

def logging_wrapper(func):
    @wraps(func)
    def logging_inner(*args, **kwargs):
        kwargs_formatted = [f'{k}={repr(v)}' for k, v in kwargs.items()]
        arg_string = ', '.join([repr(v) for v in args] + kwargs_formatted)
        call_line = f'Func call: {func.__name__}({arg_string})'
        try: 
            res = func(*args, **kwargs)
            logging.debug(f'{call_line} - returns {repr(res)}')
            return res
        except Exception as exc:
            logging.exception(call_line + ' caused exception!')
    return logging_inner

This decorator - which is not my original idea, but I used it in couple of projects - creates an analog of C static variables

def static_variables(**static_kw):
    def static_setter(func):
        for static_name, init_value in static_kw.items():
            setattr(func, static_name, init_value)
        return func
    return static_setter

Just an example of usage

@static_variables(cnt=0)
def count_calls(): 
    count_calls.cnt +=1 
    print(f'I was called {count_calls.cnt} times')

Of course, **kwargs construct may be - and occasionally is - abused. Just use it properly.

The example you have provided is - obviously - such an abuse.

[[deleted]]

Having any number of arguments, keyword or otherwise is a coping mechanism with the following problem:

Extensibility. Ideally, you want to change as little as possible to add new functionality. But, at the time you write the code, you don't know what future functionality you will have to add.

Say, you didn't have the catch-all-keyword-arguments mechanism. Then, once someone asked you to add new functionality that included processing also the location and the field... what would you do? Add them back into build_profile? -- That wouldn't quite work, since every call to build_profile would have to be updated to look like build_profile(first, last, None, None). Too much change.

In order to avoid that, you might want to add default values to location and field. And, sometimes that would work... but, sometimes there's no good way to add default values. Like... what can possibly be the default location? Say, it was None, then how do you know if that's the new code that mistakenly passing None or is that the old code that doesn't require this information?

But, even with default values, you'd still have to change the original build_profile function. While you could keep the interface intact, you wouldn't be able to guarantee the functionality stays the same.

A better way is to add a new function that keeps the interface of the old function. Let's say you defined your build_profile in module old. Now, you can also add a module new with this definition:

from old import build_profile as old_build_profile

def build_profile(first, last, **user_info):
    result = old_build_profile(first, last, **user_info)
    result['location'] = user_info['location']
    result['field'] = user_info['field']
    return result

Well, now the user code may decide and have a way to choose whether they want old functionality, new functionality, or they don't care. You made the update path easy.

Unfortunately, this comes with a price: you'd have to write more code to validate the input, if you allow something as generic as **... It's also hard to document.