Python’s Optional Parameters and the Perfidy of the Human Spirit

I wanted to briefly comment on something I’ve observed myself doing that I consider to be an antipattern.

Let’s say I’m knee-deep in that swampy mire known as Someone Else’s Code. I’m working on a search service that has this API:

class SearchService(object):
    def search(self, query):
    # Mega complicated stuff follows.

I need to change this method to be aware of the content-type of the media it returns.

OK, let’s go see how often this thing is used.

~$ ack
<.. SPEW of 86 distinct invocations of this service method>


I pick one of those service calls and crack open open the relevant buffer:

def viewThatHasNoContentTypeInfoWhatsoever(request, query):

Even better — now I have to figure out how I’m going to get the content-type information I need to the service I’m calling here.

And there are 86 more of these to go.

So now I’m sitting here thinking that the job I initially thought was going to take 5 minutes is probably going to take much longer.

So what are my options?

  1. Make content_type a required arg on the search method and just deal with the upstream changes.
  2. Refactor the parameter list to search to take a SearchParams object that encapsulates the parameters that are required for a search.
  3. Create a different, content-type-aware method on SearchService, since this is a conceptually different search, and use that instead.

1 and 2 both require changes to all 86 call sites, but at least 2 is a bit more future-proof. 3 just seems like it’s asking for an explosion in combinatorial complexity on that service interface.

This is generally the point where I begin to consider option 4, which is to make content_type a keyword arg with a reasonable default.

Great, right? This is a “minimally disruptive change” — I’m guaranteed not to break any client code, which is good because our test coverage is low and I’m not confident that I’ve even found all the relevant call sites.

The biggest problem I have with this is that it’s a terrible idea.

If this feature was being designed for the first time right now, I’d probably decide there there is no “reasonable default” for content_type at all, and I’m thus fragmenting the interface to the call at the intersection of version n-1 and version n.

New developers on the team aren’t necessarily going to be aware of the entire release history of the project, and so seeing media_type as an optional parameter will suggest to them that this is just a minor detail of the interface, where it is actually just as important as the querystring itself is.

I wonder — do you ever catch yourself being similarly lazy? I feel like this technique might actually be a good first step in getting hooks into legacy code for some preliminary unit testing before elevating the parameter to first-class status and making the upstream changes, but that’s only valid if you’re committed to making those changes in the first place.

In the meantime, I’ve forced myself to assess my motives carefully each time I add an optional kwarg to a function or method in Python. (Constant vigilance!)

One thought on “Python’s Optional Parameters and the Perfidy of the Human Spirit

  1. Rosita1992

    This post is on 15 spot in google’s search results,
    if you want more visitors, you should build more backlinks to your blog,
    there is one trick to get free, hidden backlinks from authority
    forums, search on youtube; how to get hidden backlinks from forums

Leave a Reply to Rosita1992 Cancel reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>