PyDev of the Week: Brian Skinn

Sure! My background is in chemical engineering–I have a B.S. from Case Western Reserve University and a Ph.D. from MIT. For the last ten years, I’ve worked at a small business in the Dayton, OH area doing electrochemical process R&D, though I recently made the jump over to the Python world in the form of a developer and services partner relations position at OpenTeams. I’m really excited to start working more directly with Python and open source generally.

For fun, I like to read fiction, play music and board games, and hack on my side projects. I’m a big Dresden Files fan, just finished Scalzi’s Kaiju Protection Society, and have been working my way through Jane Austen’s novels. I play clarinet, piano and guitar, and sing tenor in a men’s quartet.

I’ve been programming in various languages since high school (TI-BASIC, a bit of C++ and Java, and a lot of Excel VBA), and I also picked up an interest in quantum chemistry in grad school. Around 2014, I decided that I wanted to try implementing one of the quantum chemical methods I’d been reading about. However, I only really knew Excel VBA well enough to build something substantial, so that’s what I started with. It … was pretty terrible. VBA can do object-oriented programming, technically, but it’s awkward and difficult. After a thousand or so lines of code, I realized that I *had* to find something else. I’d been aware of Python through my experience with Linux, so I read up on it a bit, decided it seemed like a promising option, started learning… and have never looked back.

VBA in its various flavors is definitely the other language I know best, and it’s been invaluable throughout the engineering portion of my career — automating all of the boring stuff in Excel, Word and Outlook has been a huge productivity gain. Other than that, I know just enough Javascript, Java and C to be dangerous, but not to build anything substantial with them.

In open-source land, I’m most actively working on my tool for inspecting/manipulating Sphinx objects.inv files, sphobjinv. Short-term, there are some aspects of the CLI that need improvement; medium-term, I want to look into multiprocessing to speed up a handful of key spots in the internals; long-term, I need to revamp the exceptions model and I want to try to improve the user experience around the core Inventory API.

In terms of other projects, I just cut a first release of jupyter-tempvars, a Jupyter extension that provides easy temporary variables management. I have some tweaks to make to that, some freshening to do on the underlying tempvars library, and I want to (a) package it for conda-forge and (b) adapt it for JupyterLab. I also want to completely overhaul the parser construction model for pent, which extracts structured data (e.g., numerical arrays) from long-form string text.

I use pathlib and argparse from the standard library a lot. I recently found pprint (pretty printing) and calendar, and they’re hugely helpful. itertools (and the 3rd-party more-itertools) is fantastic for writing concise, readable, functional code.

In terms of 3rd-party packages, I use attrs for most of my projects, even after the introduction of dataclasses — I like the flexibility of the conversion, validation, etc. features. I’ve recently picked up BeautifulSoup (beautifulsoup4) and sqlalchemy and am really liking them. The scientific stack (numpy, scipy, pandas, etc.) is key, of course.

For tooling, I heavily use Sphinx, pytest, tox, coverage, and flake8, and I’ve recently started adding pre-commit to my projects. I build packages using setuptools.

If you’ve ever thought about contributing to an open-source project, but haven’t done it yet — go for it! It’s definitely intimidating at first, because there’s a lot to learn about the tooling, the processes, the etiquette, and so on. But, most maintainers are very welcoming to new contributors, and are happy to guide them through everything. I would recommend looking into making your first contributions to small- to medium-sized projects, though, and ones with at least a measure of visibility (a dozen or more Github stars, say). This will hopefully guide you toward projects with engaged maintainer(s) that will have bandwidth to engage with you in some detail. (I will note, a larger project may still work for this; you can monitor the flow of issues/PRs on the repo, and if new issues and PRs are getting steady engagement from maintainers, then it might work well.)  Be aware that your first contribution doesn’t necessarily need to involve code — clarifying something in the documentation, fixing a typo in the README or contributor’s guide, and other buffs to a project are quite valuable, too!