Idea Machine PSEUDO-RANDOM THOUGHTS OF A WEB DEVELOPER AND DESIGNER

Nested code is ugly. It’s not just ugly, it is also bad for your health. Imagine having to deal with dozes of binary if blocks nested into each other. It can drive you crazy just imagining it. But there is hope. Using short-circuiting, you can flatten your nested blocks, and write some very nice code.

Here’s a simplified example:

if x > 1:
    if y < 5:
        return a
    else: return c
else:
    return None

We exploit the fact that return ejects you out of the block, so:

if x <= 1:
    return None

if y >= 5:
    return c

return a

This is what I call ‘short-circuiting’ (and correct me if I’m wrong about the name, but I thought it was fitting). We basically trap the executing by if clauses breaking out of the block if it’s a match. For example, if x is indeed less or equal 1, we don’t even worry about the rest of the code. We’ve effectively ‘short-circuited’. On the other hand, we don’t need any specific test for the cases when x is greater than 1 because if it weren’t, we wouldn’t even reach the next line.

You now have beautifully readable code, and still get the same effect. It’s much easier to maintain because it’s far less intimidating.

You may have encountered the get method available to all dict instances before. Here’s an example:

>>> d = {'a' = 1}
>>> d.get('a')
1

That’s the same as d['a'], but it also provides an alternative value (None by default) if there is no such key. I’ve just discovered that there is another way to do this, and that’s the setdefault. In addition to returning the default value, it also sets it, adding the requested key to the dictionary. Here’s a session that demonstrates the difference:

>>> d = {'a': 1}
>>> d.get('a')
1
>>> d.get('b')
>>> d
{'a': 1}
>>> d.setdefault('a')
1
>>> d.setdefault('b')
>>> d
{'a': 1, 'b': None}

In Python, assert does a bit more than it looks like it would do, but it’s basic function is to make sure a condition is met. In defensive programmnig, we try to make sure every bit of input is carefully filtered and verified, and allow our software to function even if input is broken. Although you can detect broken input, and correct it or replace it, assert allows you to add a safety net that will catch anything we might have overlooked.

Here’s a simple example:

>>> def sum_up(int_list):
...     result = 0
...     for i in int_list:
...         result += i
...     return result
...
>>> l = [1, 2, 3]
>>> sum_up(l)
6

The above function returns the sum of all integers in a supplied list. We simply assume that the input will be a list of integer values, but we can’t be sure, can we? Someone might do something silly like this:

>>> sum_up(12)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in sum_up
TypeError: 'int' object is not iterable

Let’s defend against this potential bug. Let’s make sure we are getting a list and a list of integers at that.

>>> def sum_up(int_list):
...     if not hasattr(int_list, '__iter__'):
...         return 0
...     result = 0
...     for i in int_list:
...         try:
...             result += int(i)
...         except (ValueError, TypeError):
...             pass
...     return result
...

Important thing to remember is that we’re making sure that our function can withstand all kinds of faulty output that you might imagine someone shoving into it. The above code is still not perfect, but we’ll get there. Not that we’re testing to see if the int_list is an iterable, rather than a list. The reason we do this is that the code will work even with such things as strings and tuples, as long as they can be iterated. This is called duck typing, and we employ it to maximize the chance of our code surviving malformed input by requesting only minimal requirements for correct operation.

>>> sum_up([1,2,3])
6
>>> sum_up([1, '2', 3])
6
>>> sum_up([1, 'a', 3])
4
>>> sum_up('abc')
0

Not only does it work when you pass it an occasional integer, but it tries to convert it into a string. Also, if you pass it a non-iterable, it returns 0. This may be desirable or not, but it’s your choice. Sometimes it can make the code more robust, when you expect a lot of abuse.

Now, let’s handle one more case. When the input is not iterable, we can still try to return its value as a sum:

>>> def sum_up(int_list):
...     if not hasattr(int_list, '__iter__'):
...         try:
...             int_list = int(int_list)
...             return int_list
...         except (ValueError, TypeError):
...             return 0
...     result = 0
...     for i in int_list:
...         try:
...             result += int(i)
...         except (ValueError, TypeError):
...             pass
...     return result
...

Now all safety nets are in place, and our code will pass most inputs we can think of. The only case left is when there is no input at all. Provided you even want to allow no input, we can simply assign a default value, and we’re done.

>>> def sum_up(int_list=[]):
...     if not hasattr(int_list, '__iter__'):
...         try:
...             int_list = int(int_list)
...             return int_list
...         except (ValueError, TypeError):
...             return 0
...     result = 0
...     for i in int_list:
...         try:
...             result += int(i)
...         except (ValueError, TypeError):
...             pass
...     return result
...

Let’s briefly test our code:

>>> sum_up([1, 2, 3])
6
>>> sum_up(['d', '3', 2, 'abc', 5.4])
10
>>> sum_up('bogus')
0
>>> sum_up('12')
12
>>> sum_up(12)
12
>>> sum_up(None)
0
>>> sum_up()
0
>>>

Finally, in case we’ve missed something, we can use assert to make sure make sure we’ve covered all the angles.

>>> def sum_up(int_list=[]):
...     if not hasattr(int_list, '__iter__'):
...         try:
...             int_list = int(int_list)
...             return int_list
...         except (ValueError, TypeError):
...             return 0
...     assert hasattr(int_list, '__iter__')
...     assert hasattr(int_list.__iter__(), 'next')
...     result = 0
...     for i in int_list:
...         try:
...             result += int(i)
...         except (ValueError, TypeError):
...             pass
...     return result
...

The two assert lines check that (a) we’ve got an iterator-looking input, and (b) that the iterator object returned by actually calling the __iter__() method has the next attribute. Of course, we might agree that the tests are not definitive and there might still be some edge cases where the next attribute can be something other than we expect, but this is, I think, more than enough as an illustration.