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. #! /usr/bin/env python import sys try: import pkg_resources except ImportError: sys.stderr.write("'pkg_resources' could not be imported: setuptools installation required\n") sys.exit(1) def list_package_modules(package_name): """ Returns list of module names for package `package_name`. """ try: contents = pkg_resources.resource_listdir(package_name, "") except ImportError: return  module_names =  for entry in contents: if pkg_resources.
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. An implementation of this concept (based on this post) is: class lazy_property(object): """ Lazy-loading read-only property descriptor. Value is computed and stored in owner class object's dictionary on first access.
There are a number of solutions for executing Python code in your active buffer in Vim. All of these expect the buffer lines to be well-formatted Python code, with correct indentation. Many times, however, I am working on program or other documentation (in, for example reStructuredTex or Markdown format), and the code fragments that I want to execute have extra indentation or line leaders. For example, a reStructuredText buffer might look like:
The following script takes a space separated list of GenBank numbers as input, and then uses BioPython to download the corresponding sequences from GenBank, strips off all non-coding nucleotides, gives the sequences sensible names, and assembles them into a FASTA file. It is pretty basic, and does not do a lot of fancy error checking, and is probably a little too specific to be useful for most people. I can imagine extending it in a number of ways that would make it much more useful in a number of different contexts.
R R is like a microwave oven. It is capable of handling a wide range of pre-packaged tasks, but can be frustrating or inappropriate when trying to do even simple things that are outside of its (admittedly vast) library of functions. Ever tried to make toast in a microwave? There has been a push to start using R for simulations and phylogenetic analysis, and I am actually rather ambiguous about how I feel about this.
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