Beginning Python for Bioinformatics

I posted about a week ago that Packt Publishing had invited me to review Python Testing Beginner’s Guide by Daniel Arbuckle. Having finished reading the book (I must admit that I haven’t tried all the code in it), I can say that I have an excellent initial impression of the book.

PTBG is not a long book and the topic is divided in 10 chapters and one appendix. One of the first things that I liked about the book is that there’s no introduction (or something similar) to Python. It just goes straight to the point assuming that you have some good understanding of the language and everything that surrounds it. In the past I was frustrated with some “Introduction to X with Python” that wasted precious space talking over and over about a topic, learning Python, better covered in many other books. PTBG does not waste time and space introducing its main topic which is testing, and in my opinion that’s the best approach, even though it might look a little bit abrupt by some.

The language and text in the book is clear and very pleasant. PTBG is a very well written book and I really enjoyed its style. The first chapters of the book cover Python testing using doctests. For someone like me that didn’t write so many tests in the normal software development workflow (I know I should write more tests), this section seems like a really nice introduction to the topic, with well thought real-life like examples and a good flow on the explanation of the different features. One small complain that I have is that for a beginner sometimes the code listed in the examples might seem a little bit confusing, and maybe the addition of line numbers might have helped a bit here. But at the same I understand that this is normal style of some Packt books.

After the doctests section, PTBG gets into more advanced techniques, covering a little bit mock objects with Mocker, then moving into unittest and nose. The latter is a Python tool that allows for managing, running and automating tests. Also covered is Twill, another third-party library that allows for testing of web applications.

One full chapter is devoted to test-driven development, with a complete walkthrough of this approach. This gives a wrap-up of most of the techniques and modules covered in the book, but there’s still space for another chapter that shows how beautifully doctests, unittest and nose can be fully integrated and help the development of applications using the test-driven approach.

Overall, I really enjoyed PTBG. As I mentioned, test driven development was never a high priority in the application I usually developed with Python. But certainly this book can be a good starting point for some Python test beginners to incorporate these techniques in their usual development workflow. Scientific software is also a perfect niche for this type of approach and we should do what is possible in order to avoid the nightmares of the past.

Via Bioinformatics Zen:

As mentioned on the last post I am moving the current repository, an html page, to an actual Git repository on github.com. The link to the repository is

http://github.com/nuin/beginning-python-for-bioinformatics/tree/master

and it can be accessed by anyone. There are only a handful of scripts there but I am slowly adding more comments to the scripts and moving them to github. The web interface at github is pretty nice and the code can be viewed on the website with a nice code highlighting, for example. Also there is an RSS feed to receive updates, commits, etc.

How to create a local copy

Git is very easy to use and it is very simple to create a local copy of the repository on your local machine. Git is available on most systems as a command-line utility (there is a gui but I haven’t used yet) and to have an updated copy of the Beginning Python for Bioinformatics, two commands are needed.

- first you have to clone the repository

$ git clone git://github.com/nuin/beginning-python-for-bioinformatics.git

that will create a beginning-python-for-bioinformatics directory wherever you run git (this only needs to be done once)

and to keep the clone updated

$ git pull

from inside the clone directory.

Any questions please let me know.

I had problems installing Google’s AppEngine in Vista. I had Python 2.5.1 installed in my machine but every time I tried to install the msi package it failed, claiming that Python was not present, even though C:\Python25 was in the path. AppEngine issues site did not help much either, the “solution” listed there was to make sure Python was in the path.

So, I decided to start over. I removed Python (and ActiveState Python, which I installed before to see if AppEngine would work) and re-installed it, or tried to. Strangely, Python’s msi package was installing it in the C drive root, not under Python25. For half an hour I tested all possible combinations, versions and tricks to have it installed in the proper directory/folder. Then I remembered msiexec, a command line tool that runs msi packages. Running msiexec with no parameters shows a window with options, but basically /i is the the only required. /i tells msiexec the input package, while ‘code>/qb make the installation quiet and with a basic interface. msiexec worked flawlessly and then Python was in its right place.

msiexec /i python-2.5.2.msi TARGETDIR="C:\Python25" /qb

Then the same "trick" was used with AppEngine, but without a TARGETDIR. Bingo, it installed perfectly (I am assuming that).

Now, I just have to wait for my AppEngine account.

import sys
for i in file:
    print i

Just for fun, let’s see if there is any advantage (apart from generating a smaller code) in using either of the approaches to create an unique list. A list of 741 gene IDs and another one with 1322 (that contained all the 741 IDs from the first) were used. Instead of hard coding the lists in the script, normal I/O was used and the files were read automatically. Using a for loop the scripts were run 10 times and the final time averaged.

Here are the results

Using dictionaries 0.08540
Using sets 0.15890

Almost twice as fast for the dictionaries. Why? One thing, and one thing only: Python version. My system’s box default Python is 2.3.4, which has one of the first implementations of set. I have a “personal” Python version 2.5 so the test was redone with the newer Python

Using dictionaries 0.04520
Using sets 0.03770

Ok. That shows a little bit of advantage for sets what is expected. But it shows us that different versions of Python have a huge difference between them. This is a rather crude and simple test, with a small list of entries, but there is a huge gain from version 2.3 to versio 2.5, either in dicts or sets.

For a more comprehensive test and more functions with a similar objective check this page.

This is a blog devoted to basic Python, but I could not refrain myself of suggesting the new Python Magazine, that has its first issue free online.

Enjoy.

A new feature has been add to the blog: ratings. As I don’t receive many comments on the posts but there is a steady stream of viewers of the website, I decided to add the possibility of rating a post. So, if you feel the post was useful for you, well or badly written, just click the rate you feel the post deserves. It is an Ajax-like feature so there is no reloads or any other intrusion on your normal browsing.

A suggestion: whenever you are coding or leaning a new language it is always opportune to have at hand some code to compare, check and learn. One of the good tools to do code search is Krugle, where you can extensively search code based on language, project name, among other variables.

One example: I searched for IUPAC entries on Krugle and found a lot of results, in different computer languages and could see the projects that they were linked to. It is a way to check if your approach is the ideal or if there is a way to improve your code.

Due to the lack of updates in the past weeks (yup, a lot of work), I decided to add some features to the website, for the time being. The first one is the code repository, that can be accessed on the menu bar above.

I will try to include all the relevant code presented in the posts with extra comments.

I will probably be back with a regular post at the end of May.

See you then.