In the last couple of months I’ve worked on a system that is supposed to be used to drive testing equipment in an industrial environment. The client demanded the system be implemented in Python. Now, while I’ve always had a soft spot for Python, I was a bit wary about that, since my experiences with scripting languages in these kinds of environments – so far – have not exactly been overwhelmingly positive. This, coupled with the fact, that every inch of the posed problem seemed to scream “static checks!” at me, made for a very skeptical start of the project given the nature of Pythons typesystem. At last, there was the performance question. On a productionline, that is expected to churn out close to half a billion (yes, that is 500.000.000) parts per year, we have to face huge economies of scale, where even a tiny drop in performance will translate to millions of parts that will be produced less, which in turn means lost revenue for the customer. With the existing system being controlled by a C++ application and having very tight timing constraints, using a language that is – at best – an order of magnitude slower, than the existing, tightly optimized solution, at least seemed, like a recipe for desaster.
The Good
Python has a tremendous ecosystem of libraries that helped us to hit the ground running. The language itself is easy to pick up, so the teammembers with no Python experience got up to speed fairly quickly. All in all we had a prototype system running in about eight weeks. One of the very notable libaries, that made our lives a lot easier, is SQLAlchemy. Using a quality ORM improved productivity a lot and SQLAlchemy really shines here, with a simple interface and a powerful programing model that made interacting with our database a breeze. The same goes for “pluggy” which provides nearly trivial means for adding plugin functionality to an application.
The Bad
The ecosystem does come with a lot of half-baked libraries, where the user (i.e. the developer using the lib) will have to figure out if a given library is worth using. Sadly this – more often than not – will require digging through library code if said library misbehaves. Also, the virtual environment system is a mess, which has caused countless headaches (especially with our parallel CI setup).
The Ugly
It’s a scripting language with an utterly useless typesystem that basically forces 100% test coverage if one wants to be halfway sure, that the program does not crash due to a typing error. Having dabbled mostly with Rust in the last year this is an excercise in frustration.
TL;DR
The project is still running, so I can’t say if the choice to use Python will bite us in the end. However, I am pretty sure, that using a language with static typing would have been cheaper, as we spent an awful lot of time figuring out type erors that are usually raised by the compiler. This goes hand in hand with a tremendous testing effort since a relevant part of the project consists of a UI application written with pyqt where – quite frankly – the inbuilt testhelpers are not really up to snuff.