De Morgan’s and (un)Pythonic code


The term “Pythonic” is a subjective and ambiguous one. There are plenty of sites on the internet that try to explain what it means. Some of the better sties will even tell you why one way of doing something is better than another. I am adding my scrollingtext to the latter list.

I believe that one of the key requirements for writing pythonic code is readability, as briefly mentioned in “The Zen of Python” by Tim Peters. I also believe that this little poem (I use that term loosely here) gives some pretty good hints on how to write pythonic code. (This is for more of the thought process outside the general coding style stuff defined in PEP-8). Here is the Zen of Python:

“Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!”

Since this post is about pythonic code, I want to take a quick moment to show you what I mean, saving you a google search or two in the process. Here is a class method that I would consider non-pythonic code:

  1. def inNodeExistInPool(self, poolName, nodeName):
  2. try:
  3. currentNodes = self.__getNodesInPool(poolName)
  4. if currentNodes:
  5. for n in currentNodes:
  6. if n == nodeName:
  7. return True
  8. return False
  9. except Exception, e:
  10. raise Exception('Exception in isNodeExistInPool: ' + poolName +
  11. ', Node: ' + nodeName + ', Error: ' + str(e))

Now here is a more pythonic version of the same code:

  1. def isNodeExistInPool(self, poolName, nodeName):
  2. try:
  3. if nodeName in self.__getNodesInPool(poolName):
  4. return True
  5. else:
  6. return False
  7. except Exception, e:
  8. raise Exception('Exception in isNodeExistInPool: %s, Node: %s, Error: ' %
  9. (poolName, nodeName, str(e)))

While the first version of the code above is not wrong and would probably be the correct way to do this in other programming languages, it’s not the best way to do it in python. (I also expect to see quite a few comments on how other python programmers might improve the first or second versions of these functions.)

Now that we have that little example out of the way, let me share with you the motivation for this blog post. At work one day I saw some code that looked like this:

  1. # ‘a’ being an instance of a class
  2. if not a.att1 and not a.att2 and not a.att3 and not a.att4:
  3. # more code down here

oddly enough, I remembered De Morgan’s Law from my formal logic courses, so I used it to simplify the expression. Here is the proof (in formal logic notation because it’s quicker):

  • ~P ^ ~Q ^ ~R ^ ~S
  • (~P ^ ~Q) ^ (~R ^ ~S)
  • ~(P v Q) ^ ~(R v S)
  • (~(P v Q) ^ ~(R v S))
  • ~((P v Q) v (R v S))
  • ~(P v Q v R v S)

After the logic juggling above I renamed the variables and then modified the code to resemble the ending result:

  1. if not (a.att1 or a.att2 or a.att3 or a.att4):
  2. # still more code down here

After the change we can immediately see that I’ve reduced number of not calls. While I’m sure there is some performance improvement, I seriously doubt that it’s something that might be noticed by a human being, so we’ll just discount this as any form of optimization. I believe I’ve also made the code easier to read. The line itself is smaller, so a maintainer would have less “things” to juggle in their head to verify that the expression should pass or fail. Thus this code change has fulfilled some of the ideas in the “Zen of Python,” particularly the parts about “Simple is better than complex,” and “Readability counts.” However, in the final product I’ve had to add some parentheses in order for the logic to be correct, and this is where my ultimate question lies. In a lot of “pythonic” code examples on the web, one doesn’t really see “if” statements written like this one. So a somewhat self-conscious part of me thinks that I even though I have gone through the trouble of trying to make the code cleaner, I still haven’t gotten the code to be “pythonic”.

After thinking about it a little more, I decided that my version is pythonic. While I did add some clutter by adding parentheses, I also removed 3 “not calls” and made the line easier to understand. I believe this follows the spirit of pythonic code, even if it does not follow the the code to the letter.

Top photo credit goes to: mromtz

PEP-8 helps fast code recognition through familiarity

What about PEP-8, Section "Prescriptive: Naming Conventions" ?
Different conventions are like different accents for a language.
The problem is that if you travel too far south (or north) you could find difficult to understand local people.

Hardware folks like me are

Hardware folks like me are now saying: "No duh."

Alternatively...

You could do something like:

  1. if not any(a.att1, a.att2, a.att3, a.att4):
  2. # more code here

Which I like even better.

Of course, you need Python 2.5+ to do this, but that's pretty common these days.

K, I didn't think about using

K, I didn't think about using any for that. But I do think that's a good use for it and thus a good reduction. I will have to remember that.

Replace if nodeName in

Replace

  1. if nodeName in self.__getNodesInPool(poolName):
  2. return True
  3. else:
  4. return False

with
  1. return nodeName in self.__getNodesInPool(poolName)

?

Gary, I think that is a great

Gary, I think that is a great reduction. But I think to keep up with the expected return values I believe that you'd want to put those into a bool like this:

return bool(nodeName in self.__getNodesInPool(poolName))

The bool() is unnecessary

The bool() is unnecessary (and adds overhead) - the in operator always returns True or False.

Also, catching the exception and raising another is almost certainly *very* unhelpful, because you lose the location of the actual exception and the stack trace you would have got otherwise. The only thing it does is include the information about the node, but that can be found by a decent debugger or a stracktrace that prints local variable information.

So, I would reduce this method to a single line:

  1. def isNodeExistInPool(self, poolName):
  2. return nodeName in self.__getNodesInPool(poolName)

gone!

agreed. so now in fact, perhaps the method isn't needed at all. You just have to consider if its acceptable to make the getNodesInPool method public. I believe get_nodes_in_pool() would be more "pythonic" by pep8.

Even better -- make

Even better -- make self.pools public and just access directly, wrapping with properties if necessary; this allows you to get rid of inNodeExistInPool() entirely and just do

  1. if poolName in self.pools:
  2. self.pools[poolName].do_whatever()

or
  1. try:
  2. self.pools[poolName].do_whatever()
  3. except KeyError:
  4. self.handle_error(poolName)

Luke, you are correct. I

Luke, you are correct. I thought about it a little bit and came to the same realization regarding the boolean casting. I just went to bed instead of writing another comment.

Greg, you're also correct that get_nodes_in_pool would be more PEP-8 compliant name. The code in question is actually used in "production" where I work, so while I'm happy to update and lightly optimize the code, I'm reluctant to change the method name. Hopefully one day I can tweak the code enough that I will be able to remove it, but one can only dream at this point.

Thank you both for the comments.

If you made it this far down into the article, hopefully you liked it enough to share it with your friends. Thanks if you do, I appreciate it.

Bookmark and Share