Strong types, weakly bound

Reading Strong opinions, somewhat weakly held on Jason Cohen's excellent A Smart Bear blog this morning, I was quoting this excellent soundbite (you really need to simplify it down to "strong opinions, weakly held" to make it work as a soundbite) out loud to Anna and musing about it -- and exactly at the same time she and I chorused about the analogy this has with Python's approach to typing... objects with strong, precise types, but "weakly held" (i.e., weakly bound) via names or slots in containers that might just as well hold objects of other (also strong) types.

This analogy may actually be the least "obvious" thing she and I found ourselves "chorusing" about, though such "choruses" happen more and more often and so it's becoming hard to tell;-). Anyway, I'll be sure to use this next time I need to present Python's typing approach -- now if I can only find a way to work ducks into it, too...

Python tips: pickling it right

Here's an often-seen Python snippet...:

pickle.dump(stuff, open('foo.pik', 'w'))

What's wrong with this? Well, several things, as it turns out...!

1. Use cPickle, not pickle: that will speed things up by 5 or 6 times, effortlessly.


2. The common, sloppy use of open without a corresponding close is theoretically OK in today's cPython, but there's really no good reason to support it. Be neat instead, and write (after a from __future__ import with_statement if you're still using Python 2.5):
   

   
   with open('foo.pik', 'w') as f:
    cPickle.dump(stuff, f)
   



3. Unless there's a very special reason to make you want the pickle dump to be in ASCII (and I've hardly ever seen a good one), don't just use pickle's default, legacy protocol! Rather, explicitly request protocol 2, or better still, unless you need pickle files loadable by older releases of Python, request "the best protocol available".
   

So, the best equivalent of that little sloppy but alas-too-common idiom is:

with open('foo.pik', 'wb') as f:
 cPickle.dump(stuff, f, cPickle.HIGHEST_PROTOCOL)

Don't forget the little b in 'wb', by the way — it won't matter under Linux, OSX, or Solaris, but it will matter in Windows... and, anyway, as we all know, explicit is better than implicit!-)

Python tips: the right way to show errors

I've lost count of how many times I've seen Python code like this...:

logging.error("Unknown user '%s' for '%s'"
             % (username, resourcename))

This error-showing code has two problems:

1. logging.error and other such functions do the formatting for you -- so don't duplicate their work! So, the first level of fixing is to change the call into:
   

   
   logging.error("Unknown user '%s' for '%s'",
                 username, resourcename)
   

   
   


2. any time you're displaying a string that's somehow "in error" (not just in calls to logging functions, but also when instantiating an exception, etc), use %r, not %s! This way, if the problem is that the string contains "invisible" characters, you'll see them clearly displayed as escape sequences, while %s might hide those characters, making debugging much harder. So, the second (and final;-) level of fixing is to further change the call into:
   

   
   logging.error("Unknown user %r for %r",
                 username, resourcename)