How Python for the Lab helped the developer of Twingo

The following article is a guest post by Michal Jablonski.

I've always found that experimenting is a great way to learn. However, regardless of the topic, almost always I had to make more experiments than manually possible. Adding the problems with reproducibility, it naturally led me to learn about instrumentation and automation. Experimenting is often about attempting something nobody, or very few people, tried before you. Therefore, it's not surprising that there is no software to support your specific requirements and you're forced to make your own tools. This is how I ended up scripting in Python both for my work as a researcher and for my hobbies at home.

As a researcher, your true goal are the experiment results, and you want to get there fast. Normally, you don't think about programming itself as an end. Python is surprisingly good at supporting exactly that goal. But some months ago, I realized that it would be great to bring my coding skills a level up so I could create simple measurement apps. 

I immediately hit two obstacles:

• No (real practical) clue how to do Object-Oriented Programming
• No clue how to structure a project in Python

While point 1 remains still in power to some extent (anybody with experience can tell by looking at my code), I did have an eureka moment with project structure. Just as I was about to give up trying, lost in a myriad of bugs from edge cases, with a half-baked app that was one huge ugly class with a kaleidoscope of disconnected methods, I found the book Python For The Lab by Aquiles Carattino.

After a couple of minutes looking through the contents, I knew the book was just what I needed.

While going through the pages, I was also spending hours refactoring the monster I had created earlier. I wanted to try to stick to the recommendations from the book as much as possible. Soon, by applying the onion principle and understanding the meaning and power of the MVC pattern, I was able not only to get to a stable, complete app but, low and behold, reduce my shame about the code quality to a point where I dare share it online! (See Twingo on Github).

The book, accompanied by some of the spot-on PFTL blog articles became my true heroes. 

My biggest surprise was that by applying a proper structure to the project and by following the onion principle, I could remove at least half the bugs without having to re-think my application nor abuse the use of try-except statements. I could also throw out big chunks of superfluous logic, making the code simpler, easier to maintain, and much more reusable.

Learning of how to make the code more generic by creating a base class for measurement equipment came to me like a cherry on the cake. Despite initially planning to make Twingo compatible only with National Instruments DAQ cards, I decided to enable the acquisition and generation of signals via the system default sound devices. The MVC pattern allowed me to add pyAudio suport with relative ease and without changes to upstream code. This made my app potentially usable to people who don't own special hardware and it also opened the possibility to support other brands of data acquisition hardware. This was a great addition and the push I needed to make the code open source.

Whether you come from scripting or are new to programming for instrumentation or even completely new to Python altogether, make sure you check out the PFTL book before your first large project. I hope that, as for me, it will save you a lot of time and make you more proud of the end result!

About the author

Michal Jablonski, PhD Electrical Engineering. I work in automotive product development. In my profession, Python helps me save time by automating large data collection and extraction from spreadsheets as well as support instrument control and data collection for Light Emitting Diode bench tests. After hours I’m an audio, electronics, python and science enthusiast (more on my Wodrpress space).