I’m a PhD student in physics, working on experimental quantum computing with superconducting qubits. So as you might guess, data acquisition and analysis make up a big part of my daily work. To state an example, my current experiment requires me to control 15 different measurement devices such as microwave generators, voltage sources, arbitrary waveform generators, oscilloscopes, spectrum analyzers and fast data acquisition cards. All of this equipment needs to be properly interfaced and in order to perform an actual measurement it is necessary to perform many individual parameter changes and data transfer steps. Furthermore, huge amounts of numerical and binary data often need to be analyzed, aggregated and fed-back as parameters into the measurement system. In order to do all this, the software used in my group when I started my PhD was National Instrument’s “Labview”. Labview is an easy-to-use and quite powerful tool for building measurement and automation applications. In fact, when I first got in touch with it I was quite amazed of how easy it actually was to interface measurement devices and to build simple graphical user interfaces. Some of the features of Labview which I probably liked most were

• the ability to easily create rich user interfaces with diagrams, tables and data graphs.
• the ease of use of the graphical programming interface, which provides many pre-build libraries and instrument drivers.
• the very high execution speed of Labview scripts.

However, as I started to build more complex experiments it became increasingly hard to come up with good solutions for interfacing them through Labview. For example, some limitations which quickly started to annoy me were

• the lack of a text-based programming language. Labview uses a graphical programming language called "G", which makes it easy to “write” but hard to copy and read code.
• the dataflow programming model of Labview, which makes it very hard to reuse individual parts of programs and to make use of object-oriented programming techniques. 

So after all, I wasn’t fully happy with using Labview for controlling my experiments since I felt that I would be somehow limited in the extension of my measurement system. Luckily, one day a post-doc working in our group told me that in his former lab a programming language called Python was used to control and interface most of their measurement equipment. Up to that day I only briefly heard of this language and I didn’t have the slightest experience with it. Nevertheless, I became very curious and I wanted to learn more about it. And as it turned out, I found Python to be a great tool for my work: It was flexible, easy to learn and it had many useful libraries that I could use for my data acquisition and processing needs. In fact, as of today Python seems to become more and more the standard scientific programming language, often replacing older and more inconvenient languages such as C/C++ and Fortran. So, being a physicist and a computer geek I was immediately convinced and started to use it on a daily basis. As of today, I have completely rewritten our whole measurement and data acquisition system in Python, with very satisfying results. Unfortunately, during this work I also learned that Python has some shortcomings of its own that can make it complicated to use it in a scientific environment. For me, some of the most troubling (but solvable) issues included

• the Global Interpreter Lock (GIL): The Python interpreter cannot simultaneously execute code in different threads. This makes it quite hard to make full use of a  multi-processor architecture.
• the fact that Python code runs relatively slow: Numerical operations and the manipulation of large amounts of data (e.g. binary strings, lists and numbers), which are very common tasks in a measurement environment, run much slower than e.g. in Labview or C/C++.
• the lack of an easy-to-use (for a scientist, not for a programmer) toolkit for building graphical user interfaces: Although there are several very good toolkits available that make it relatively easy to build a graphical user interface with Python (e.g. PyQt or Tkinter), all of them require some considerable learning effort and a large amount of programming.

Fortunately it turned out that all of these problems can be somehow fixed or circumvented. In the following blog posts I will describe in detail how I resolved these issues and what I think is a good way to build a measurement system with Python.

Please feel free to comment on this article and to share your thoughts and experiences concerning the use of Python in a scientific environment.