win32typelibs - Generic Python Scripting for Engineers

Background

For most of my career I have been working as a mechanical engineer on medical device projects for for big players in the respiratory, diagnostics and pharmeceuticals segments of the industry.

The unfortunate reality of the industry is that most of the effort put into a project goes into managing risk documentation, product lifecycle management, engineering verification and validation - not quite the ‘fast-paced and dynamic’ environment usually advertised.

Over serveral years, more and more of my energy was being spent managing documentation, triple-checking that my formatting and document links were correct. This reached a point several times where I would spend weeks at a time staring at CAD drawings, Excel tables, and Word documents to pull together ISO 13485 and ISO 14971 compliant documentation.

Frankly, I always felt that this approach was inefficient. I was frustrated that businesses were spending hundreds of engineering hours checking, fixing and re-checking mundane, objective facts, rather than reviewing complex and nuanced engineering decisions which make products what they are. Offloading these tasks to software always seemed like it had the potential for major improvements in the industry.

The Solution

After playing around with Python to automate parts of my job I saw a lot of potential for a scripting language to supercharge many of the day-to-day tasks of engineers worldwide.

From extracting dimensional data from Solidworks drawings, automating Minitab analyses, to generating Excel reports, Python’s pywin32 package showed a lot of promise to pull the engineer away from wrestling proprietary software, into bespoke applications which could specialise in the simple but time-consuming tasks that every business has. For those unaware, the win32com package lets you bring the complete VBA API of an application into Python - letting you mix arbitrary Python code with VBA function calls.

While pywin32 and win32com are great, a major missing piece into turning Python into a scripting language for engineers was the lack of language server (LSP) support.

win32typelibs was my way to integrate the win32com approach into a modern development workflow with full type support for IDEs like VSCode or Neovim. It is essentially a Python type-generator for applications which I will call ‘VBA-enabled’. The effect is that we can import a type library of our favourite applications.

from win32com.client import Dispatch
from win32typelibs import excel, word, solidworks

wdapp:word.Application = Dispatch("Word.Application")
xlapp:excel.Application = Dispatch("Excel.Application")
swapp:solidworks._Application = Dispatch("SldWorks.Application")

# Types and interfaces for each COM object are now known in your IDE
# and the below code can auto-complete.

wddoc = wdapp.ActiveDocument  # type: Word.Document
xlsht = xlapp.ActiveSheet     # type: Excel.WorkSheet
swdoc = swapp.ActiveDoc       # type: SldWorks.Document

Closing Thoughts

In many ways, I think that the modern engineering workflow is crippled by its dominant software: Windows, MS Office, CAD packages, etc., all of which tend to cater their interfaces to the average user. As engineers, I think if we are going to spend 1000+ hours per year behind a screen, each of us should strive to increase their productivity on a computer.

At this point I don’t think the main challenge of software automation in this space is at all technical - many industries have already heavily integrated software into their core processes to eliminate human error and improve robustness, such as finance and software. I don’t see why another knowledge-based industry such as engineering wouldn’t be capable of doing the same (especially given the advancements in AI models recently).

While I understand most processes do not deserve a bespoke automation, I think the real challenge here is convincing upper management that computers are capable of solving the niche problems costing their engineers hours every week, and affecting the business’ bottom line.

Further Development

While I haven’t needed this project for around two years due to some career changes, the recent integration of Python in Excel has shown that even the OEM, Microsoft, is aware that Windows power-users are shifting away from VBA into a modern language like Python. This win32typelibs project since spun out into another: ‘xlpro’ - A self-hosted system I designed for dynamic, arbitrary Python execution in Excel.

---

Comments

I am yet to publish the code for this project publicly because the foundational scripting on pywin32 is perfectly capable without it for those with the right knowledge. However this will always be something I am proud to share when I run into keen individuals looking to take initiative and automate their workflows.