Python

Given a list of strings, how would you iterpolate a multi-character string in front of each element?

For example, given:

    >>> k = ['the quick', 'brown fox', 'jumps over', 'the lazy', 'dog']

    ['-c', 'the quick', '-c', 'brown fox', '-c', 'jumps over', '-c', 'the lazy', '-c', 'dog']

Of course, the naive solution would be to compose a new list by iterate over the original list:

For the past few months, I've been 'defensive coding' wrt to Python 3.x; basically, if there is a construct that:

• will be broken under 3.x

and

• the alternate (which is not broken) is supported under 2.6+

I've been trying to use that instead.

Here is a "3K-ism" got me, that was completely unanticipated. I encountered it when running my Python environment description script under Python 3.x.

I love text editors. Which is a good thing, because I spend the overwhelming majority of my computing time (and, hence, sadly, most of my conscious life) in one text editor or another. For years I have been an Emacs user, only relatively recently moving to BBEdit with my adoption/inheritance of a Mac as a personal machine. Using and often administrating Linux-based systems has necessitated that I use Vi now and then, but I have long held the opinion that the only Vi command one needs to know is: ":q!", perhaps to be followed by "emacs".

This attitude was born out of some unpleasant experiences really early on in my computing history. I distinctly remember a few occassions when I was trapped in an apparently psychotic terminal session that would not accept my typing despite dozens of increasingly-frenzied keystrokes, and then suddenly and inexplicably it started accepting my typing but refused to let me stop typing and exit. This was my introduction to the Vi editor. After once or twice resorting to disconnecting and relogging-in as the only way break out of the grip of this insane editor, I learned how to properly quit it: ":q!". For many years after that, those three keystrokes probably summed up 90-99% of my Vi usage: whenever I inadvertently triggered an editing session with it, I would quit it with alacrity and get on with life. It was a long while before I stopped getting a flash of a "Arrgh! Not again!" semi-panicky feeling whenever I saw a screen with all those tildes running down the left hand side. As far as I was concerned, a Vi session was synonymous with an operating system glitch or failure.

All that has recently radically changed ...

Here I present a script that provides diagnostics about the current Python execution context, or the Python environment of the interpreter passed as an argument. As a Python developer, I have multiple Python versions side-by-side for testing purposes, using scripts that munge my $PATH variable to "import" and "unimport" different versions of Python as I need them. While "which python" is always available, many times I want to know things like, "what is the version of the current default Python?" or "where is the current Python's 'site-packages' directory?". Though all this information is usually one or two commands away, it can be pretty tedious jump through these hoops every time this information is required. Also, often mature systems that have gone through various systems administrators and upgrades have both legacy and current stuff scattered all over the place, and it can be a hassle trying to figure out where the site packages and other components of a particular installation of Python are located.

Python descriptors allow for rather powerful and flexible attribute management with new-style classes. Combined with decorators, they make for some elegant programming.

One useful application of these mechanisms are lazy-loading properties, i.e., properties with values that are computed only when first called, returning cached values on subsequent calls.

The one Python shell to rule them all:

Syntax highlighting, live/dynamic code autocompletion, live/dynamic code hints and display of doc-strings, easy-installable ...

I recently integrated unit test code coverage analysis (using coverage) as a setuptools command extension into the DendroPy phylogenetic computing library, and thought that I would share how this was done.

The following is an example of how to use the "pkg_resources" module (provided by the setuptools project) to compose a list of all available modules in a Python package.

UPDATE Nov 7, 2009: Better parsing of traceback.

UPDATE Nov 4, 2009: Now passing a "-b" flag to the script opens the parsed stack frame references in a BBEdit results browser, inspired by an AppleScript script by Marc Liyanage.

When things go wrong in a Python script, the interpreter dumps a stack trace, which looks something like this: