We attended the Sherlock Seattle Mini-Convention at the Broadway Per­for­mance Hall. It was much more lightly attended than previous previous Sherlock Seattle con­ven­tions.

The final event of the evening was a Mystery Science Theater–style treatment of Sherlock Holmes (2010 film) given by some of the con’s organizers. We had seen Young Sherlock Holmes get the MST3K treatment at last year’s con and the show was quite funny. This show was also funny, but I was appalled at just how bad Sherlock Holmes was. (I suppose that’s the point of getting the MST3K treat­men­t—the movie stinks and deserves to be heckled.) It was totally incoherent and anachro­nis­tic and ineptly made.

Generators decouple iteration from the code that uses the results of the iteration.

—David Beazley, Generators

[Pre­vi­ous­ly published at the now defunct MetaBrite Dev Blog.]

Python generators have a variety of uses. One such is to lazily evaluate sequences. Another is for coroutines. Yet another is to re­cur­sive­ly traverse a tree or a graph, yielding an iterable sequence.

Consider this simple tree of nodes:

node_tree = Node(
    'a', [
        Node('b', [
            Node('e', [
                Node('g')
    

Benjamin Black (the mystery-writing pseudonym of Irish novelist, John Banville) channels Raymond Chandler as he writes a Philip Marlowe novel. Robert Parker wrote a couple of books about a quarter-century ago with the approval of the Chandler estate. Black’s book is also authorized.

The book has all the familiar elements of a Marlowe novel: the femme fatale of the title, the idle rich, ungrateful offspring and murderous staff, cynical cops, the baking heat of California, beatings and booze, Marlowe cracking wise, and the trademark Chan­dleresque similes.

If you like Chandler, you’ll probably like Black’s con­tri­bu­tion to the canon.

Apparently, there’s no standard for writing dates in Canada. I assumed that Canada used the annoying US-style convention of MM/DD/YYYY. I didn’t realize that the British-style DD/MM/YYYY is also widespread. How ex­as­per­at­ing!

Personally, I always write YYYY-MM-DD whenever I can get away with it, as God and ISO 8601 intended. A bill is before the Canadian parliament aiming at stan­dard­iz­ing on year-month-day formats.

I wanted to clean out my local PostgreSQL database today so that I could restore a database dump taken on another system, but every time I ran the psql utility, I got:

psql: could not connect to server: No such file or directory
    Is the server running locally and accepting
    connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

I tried various things, including restarting Postgres several times, but nothing helped. Eventually, I thought to look in /usr/local/var/postgres/server.log, where I saw several error messages indicating that Postgres 9.5 couldn’t read data files created with 9.4. At that point, I realized that during my most recent brew update; …continue.

Today is Martin Luther King Day, a day that honors the legacy of a great American. It’s a Federal Holiday, but only 37% of employers give off Martin Luther King Day. Apparently, 37% is an all-time high for MLK Day and it’s also higher than the other three holidays that most Americans don’t get, Presidents’ Day, Columbus Day [sic], and Veterans’ Day.

I’ve worked in America for a quarter century, but it was only at the first job, when I was a Brown University employee, that I got those secondary Federal holidays off.

Not only is America one of the least-generous countries for vacation days, it’s also one of the least generous for holidays. American …continue.

Have you ever attempted a relative import in a Python script?

$ ./foo/bar/script.py some parameters
Traceback (most recent call last):
  File "foo/bar/script.py", line 16, in <module>
    from .quux import find_vcs
ValueError: Attempted relative import in non-package

I prefer to use absolute imports to minimize ambiguity and confusion, and most of my Python modules begin with:

from __future__ import absolute_import, unicode_literals, print_function

(Using uni­code_lit­er­als and print­_­func­tion makes porting to Python 3 easier.)

I recently read the accepted answer to Python relative imports for the billionth time and the solution to the above ValueError occurred to me: Use python -m package instead:

$ python -m foo.bar.script some parameters

(Assuming that package foo exists.)

We deploy on Ubuntu 14.04, the most recent Long Term Support release. It comes with Python 2.7.6, but we need Python 2.7.9+ to get the some important SSL fixes and work with a recent version of the Requests library.

Felix Krull maintains a Personal Package Archive for Python 2.7 Updates, which makes it straight­for­ward to upgrade to Python 2.7.11 on supported versions of Ubuntu.

sudo apt-add-repository ppa:fkrull/deadsnakes-python2.7
sudo apt-get update
sudo apt-get install python2.7 python2.7-dev

Be sure not to use Felix Krull’s other Python PPA by mistake. I did that on a colleague’s machine yesterday. In our attempts to figure out why we still had Python 2.7.6, we managed to mess up the machine suf­fi­cient­ly that …continue.

We got a new monitor today for one of our pairing work­sta­tions. At 2560x1600, it was higher resolution than its pre­de­ces­sor. I dis­con­nect­ed the DVI cable from the old monitor, leaving it connected to one of the video ports on the computer, and connected it to the new monitor. All I could see was static and noise on the screen. After trying a variety of other things, I eventually thought to use the DVI cable that came with the new monitor. It worked!

I had assumed that all DVI cables were in­ter­change­able. Reading the Wikipedia article, I see that at higher res­o­lu­tions, dual link is needed. I hadn’t known such a thing existed.

When I declare a derived class that inherits from both a base class and some mixins, I am always tempted to write:

class Derived(Base, Mixin1, Mixin2):
    "Some class"

My reasoning is that Derived is a Base with some Mixin1 and Mixin2 goodness sprinkled on. Generally, that’s fine. The exception is when I want one of the mixins to override a method or attribute that’s defined in Base. Because the Method Resolution Order is left-to-right, then Base’s im­ple­men­ta­tion will always be found first.

To get the desired behavior of the mixin overriding the base, Base should always appear last in the in­her­i­tance list.

from __future__ import print_function

class Useful(object):
    def __init__(self, msg):