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?
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. Providing the Command Extension The first step is to provide the command functionality in a class that derives from “setuptools.Command” in a separate module of the package, which, in my case, was called “coverage_analysis.py”, located in the “test/support” subdirectory of the DendroPy package
I added the following to my ~/.bashrc and I am loving it! ## Up Arrow: search and complete from previous history bind '"\eOA": history-search-backward' ## alternate, if the above does not work for you: #bind '"\e[A":history-search-backward' ## Down Arrow: search and complete from next history bind '"\eOB": history-search-forward' ## alternate, if the above does not work for you: #bind '"\e[B":history-search-forward' (see the comments below for explanation of the alternate codes) The first command rebinds the up arrow from “previous-history”, which unconditionally selects the immediately preceding command from your command history, with “history-search-backward”, which selects the previous command in your history that begins with the characters you have already typed in.
Vim continues to surprise me with its wonders. Sometimes (many times, in fact) things do not make sense, and I am perplexed as to the reasoning behind them. Then, one day, I grokked it. And from that day on, I can never imagine any other way of doing it. An example of this was my confusion over the apparent redundancy of two fundamental commands. In normal mode Vim, “s“ (mnemonic: “substitute”) and “c” (mnemonic: “change”) are both ways to remove some existing text and then go into insert mode.
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.
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.
The Sorceror color scheme for Vim:
The mayansmoke color scheme for Vim:
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!