Python

It is past 4 am, and the bug hunt is over. It was a weird one. One that I'll remember. It led me on a wild exhausting chase through dark nooks and crannies of a horribly-written nightmare of a code base. What made it weird was that, with the same random number seed, I got different behavior depending on whether there were some (debugging-related) print statements in some parts of code. Even if these statements were in parts of the code that were entirely separate from where the failure was happening.

The Problem

No amount of autotools-fu could get either Python 2.4 or 2.5 satisfactory built for Mark Holder and myself on Snow Leopard. Setting a slew of environmental variables, hacking the ./configure script, the ./configure.in, or the generated Make file all yielded some manner of progress, but all ultimately ended in failure.

Here is what we initially tried and the results ...

I am afraid that in practice I have always ended up going the simple "litter the code with print statements" route when debugging my Python. Without the compilation step, the cost of inserting and then removing these lines from the source code is relatively cheap, and has served me well enough so far. Thus, as sanctioned under the "if it is not broken, don't fix it" clause, I have not felt the need to look any further, or look into learning how to use pdb.

The Python 2 and 3 standard library documentation can be installed as Vim help files through installation of the following:

• Python 2.x: http://www.vim.org/scripts/script.php?script_id=3277
• Python 3.x: http://www.vim.org/scripts/script.php?script_id=3278

Installation:

The Great Controversy

A standard dictum amongst experienced Vim users is not to use the arrow keys to move around your document. This dictum is often repeated again and again, in tones that range from the taken-for-granted to hysterical-zeal. The most common reason given for this is that using the arrow keys takes your hands away from the home row of your keyboard, and thus is wasteful both in terms of time and energy, whereas the standard Vim movement keys --- `h`, `j`, `k`, and `l` --- keep your hands on the home row, and therefore is far more efficient. Here is what I have discovered: this anti-arrow key argument is wrong!

This package looks promising:

PyMC: Bayesian Stochastic Modelling in 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.