CODEWITHSUNDEEP
pythonpython-3.x
Migwell
Migwell

Reputation: 20137

**kwargs.pop(x) versus defining x as a function parameter

Lets say you're writing a child class that has a constructor that passes its unused kwargs up to the parent constructor, but your class has the argument x that it needs to store that shouldn't be passed to the parent.

I have seen two different approaches to this:

def __init__(self, **kwargs):
    self.x = kwargs.pop('x', 'default')
    super().__init__(**kwargs)

and

def __init__(self, x='default', **kwargs):
    self.x = x
    super().__init__(**kwargs)

Is there every any functional difference between these two constructors? Is there any reason to use one over the other?

The only difference I can see is that the second form, which defines x in the signature, allows the user to better see it as a possible argument, or an IDE to offer it as an autocomplete option. Or in Python 3.5+, you could add a type annotation to x. Does that make the first form objectively worse?

Upvotes: 2

Views: 564

Answers (2)

bruno desthuilliers
bruno desthuilliers

Reputation: 77912

As already mentionned by Giacomo Alzetta in a comment, the second version allow to pass x as a positional argument when the first only allow named arguments, IOW with the second form you can use both Child(x=2) AND Child(2), while the first only supports Child(x=2).

Also, when using inspection to check the method's signature, the second form will clearly mention the existance of the x param, while the first won't.

And finally, the second version will yield a slightly clearer exception if x is not passed.

And that's for the functional differences.

Is there any reason to use one over the other?

Well... As a general rule, it's cleaner (best practice) to use explicit arguments whenever possible, even if only for readability, and from experience it does usually make maintenance easier indeed. So from this point of view, the second form can be seen as "objectively better" than the first.

This being said, when the parent method has dozens of mostly optional and rarely used arguments (django.forms.Form, I'm lookig at you) AND you also want to preserve positional arguments order, it can be convenient to just use the generic *args, **kwargs signature for the child and force the additional param(s) to be passed as kwargs. Assuming you clearly document this in the docstring, it's still explicit enough (as far as I'm concerned, YMMV), and also avoids a lot of clutter (you can have a look at django.forms.Form for a concrete example of what I mean here).

So as always with "best practices" and other golden rules, you have to understand and weight the pros and cons wrt/ the concrete case at hand.

PS: just to make things clear, django's Form class signature makes perfect sense so I'm not ranting here - it's just one of those cases where there's no "beautiful" solution to the problem, period.

Upvotes: 3

Dalen
Dalen

Reputation: 4236

Aside obvious differences in code clarity, there might be a little difference in speed of calling the function, in this case method init().

If you can, define all necessary arguments with default values if you have some, in both methods, and pass them classically, and exclude ones you do not wish. In this way you make the code clear and speed of calls stays the same.

If you need some micro-optimization, then use timeit to check what works faster. I expect that one with the "x" added as an argument will perhaps be a winner. Because getting to its value directly from local variables will be faster and kwargs dict() is smaller.

When you use "normal" arguments, they are automatically inserted into the functions local variables dictionary.

When you use *args and/or **kwargs they are additional tuple() and/or dict() added as new local variables. They are first created from the arguments you passed into the function call. When you are passing them to a next function, they are extracted to match that function's call signature. In both operations you lose a tiny bit of speed. If you add removing something from the kwargs dictionary, ( x = kwargs.pop("x") ), you also lose some speed.

By observing both codes, it seems that their call speed would be equal. But you should check. If you do not need an extra 0.000001 seconds when initializing your instances, then both options are fine and just choose what you like most.

But again, if you are free to do it, and if it will not greatly impair the code's maintenance, define all arguments and their default values and pass them on one-by-one.

Upvotes: 0

Related Questions