However, clever oneliners also make life difficult for the developer of the code while the code is being written. The reason is, again, that they obscure the thing the code is actually trying to accomplish. Consider this real life example:

my $unprocessedRecords = [$data->{'records'}] unless (ref($data->{'records'}) eq 'ARRAY');

What should happen here is that a reference to the contents of a data element called “records” goes into a variable called $unprocessedRecords. Owing to a quirk of the mechanism that created $data, however, $data->{’records’} may be either a reference to an array of records or to a single record, which is a hash. The developer, correctly, decided to make life easier for himself by ensuring $unprocessedRecords would always be a reference to an array, and since the developer in question (not me, though it could easily have been), wrote this oneliner to accomplish this.

What happened, therefore, was that several steps further on in the code, $unprocessedRecords turned out to contain no records at all and it took the developer almost half an hour worth of debugging for him to find and correct this mistake.

Now there is, of course, no shame, in producing bugs and taking a long time to find them. However, this particular bug (only if $data contained exactly one record would $unprocessedRecords contain records) would have easily been avoided had the developer written the code to explicitly match his intentions, like so:

my $unprocessedRecords = $data->{'records'};
$unprocessedRecords = [$unprocessedRecords] unless (ref($unprocessedRecords) eq 'ARRAY');

The lesson here is that your code should always match your intentions, even if it takes up more vertical space.

(*) except when they don’t

Ouch.

Searching Google, I found nothing useful except for this thread on the Apple support forums where amongst the dozens of rightfully irate screamers there were two that suggested gzip compression on the web server was to blame (well, not really to blame, of course. every single browser in the world is absolutely fine with gzip compression except for Safari, so by rights it’s Safari that’s to blame and not the compression, but you get the point). And luckily the mediawiki site in question was running on my own server, so I could disable the offending gzip compression quite easily. Of course I couldn’t remember ever having turned on gzip compression, but after some grepping I managed to unearth the following foul, foul line in in includes/DefaultSettings.php:

$wgDisableOutputCompression = false;

Added a line to LocalSettings.php that explicitly set it to “true” and presto, Safari displayed the website without any problems at all and I was once again the happy and fulfilled little tinkerer I usually am.

The question, of course, is why Apple thinks it can pass off a browser as “just working” that chokes so violently on something as common as server side gzip encoding. Especially in the mobile browsing market that they’re so interested in acquiring a substantial share of and where megabytes transferred are quite literally worth their weight in gold.

Make the connection:

  connection = MySQLdb.connect(host = dbhost, user=dbuser, passwd=dbpass, db=dbname)

And before you do anything else, run a query that forces MySQL to output UTF-8 from now on:

  cursor = connection.cursor(MySQLdb.cursors.DictCursor) # or some other cursor type
  cursor.execute('SET character_set_results="utf8"')

Once you’ve done this, all your subsequent queries will return your data in proper UTF-8 encoding.

The fact that you have to run a query suggests that it’s not Python or MySQLdb that’s to blame, by the way. Not that I particularly care, of course. I just want it to work.

  import db
  dbObj = db.DB(type='mysql', someparameters)

to return an instantiation of the DB class in the package db.engines.mysql.

After reading through the documentation and some Googling, I figured out how to do it. Let’s say we have the following files:

In db/__init__.py :

  class DB(object):
    __init__(self, dbtype, config):
      module_name = 'db.engines.' + dbtype
      # before python 2.5, __import__ had no named parameters. the non-empty list (fromlist) ensures we
      # actually get the mysql engine object, not the db object
      module_obj = __import__(module_name, globals(), locals(), [1])
      class_obj = getattr(module_obj, 'DBEngine')
      dbobject = class_obj(config)
      self.dbobject = dbobject
      # do whatever else you need to do to initialize a generic DB object

And in db/engines/mysql.py :

  class DBEngine(object):

      def __init__(self, config):
        # do whatever you need to do to initialize a mysql db engine object
        pass

In other words, you need to use the __import__ function to dynamically load the module you’re after (in this case db.engines.mysql.py) and then the getattr function to dynamically load a specific class from that module. Easy as pie, actually.

That’s it.

To really make it work well, however, you’ll want to register at the site. This allows you to set a decent sub domain name (the automatically generated ones are less than fantastic – mine was http://matthijs_auiyk.posterous.com/ , for example) but, even better, it also allows you to receive replies to your blog posts in your mail. If you reply to these, the results will automatically turn into new blog posts. This way you can have a conversation online using a tool you’re already using anyway (your email program).

An idea so simple it is, even though I personally have no need for a service like this, genius.