PyDev of the Week: Patrick Maupin

I rotate through a few hobbies -- bicycling, sailing, playing tuba in a community band. The tuba is actually something I re-started just a few years ago. I wound up dropping out of school when my lung collapsed when I was playing tuba with the UT Longhorn Band. Fortunately, my lung was repaired later...

I had been pursuing a degree in electrical engineering, because playing with electrons was my passion ever since I can remember. When I dropped out of school, I couldn't find a job doing electrical stuff, but I did find one programming, and then worked myself into positions where I was doing both hardware and software. I have mostly worked near the hardware -- drivers, embedded stuff, modem firmware, or on the hardware -- board design, Verilog blocks for chips, etc., or on tools that help to use and test the hardware -- schematic checkers, JTAG programmers, etc.

For the last 20 years, I've only worked for chip companies, and helping to design chips suits me, because successful chip companies are committed to practices that lead to working products -- a failed tapeout can cost hundreds of thousands, or even millions of dollars, plus the lost opportunity costs of waiting one to three months for your first chips to come back so you can even test them. A product that fails in the field on a customer board can be unimaginably costly, as well, so chip manufacturers usually don't just give lip-service to words like "testing" and "quality."

I've worked at the same place for the last nine years, but we've been acquired a couple of times. The name on the door now says Microsemi, and it's a great place to work.

A quick google search will show you that opinions vary widely on what computer language syntax and core language features should be, but I have to say that Python matches the way I think and work much better than most high-level language. I'm always amused and bemused by assertions from aficionados of other language about Python's supposed shortcomings -- some of those I consider features, and some really are shortcomings, but usually nowhere near bad enough to seriously consider using whichever language is being touted at the time.

The first time I remember using Python for work was in 1999. My boss had been working on a hardware block (as his main full-time task) for 6 weeks, and just couldn't get it to work. He finally asked for my help, and I wrote a Python program in about five hours that wrote some perfectly working Verilog code for him. He wasn't very happy about that.

Using Python to write code has been a recurring theme in my career, and in general, I like the syntax so much that I even sometimes write some simple translators, which is why I contribute to projects like astor.

I always liked assembly language, and I really liked Modula-2 at the time, but when C acquired all the ANSI extensions and the compilers got really good at warning you about your stupid mistakes, C became "good enough" and took over the world.

I have dabbled in several other languages, but with Python and C in my toolbelt (and these days, Cython does a great job of merging them if ctypes isn't fast enough), I just haven't happened to have a project where any of the others are compelling yet.

In fact, my C may be getting a bit rusty -- computers are fast enough that I probably only break it out once every couple of years. These days, if I'm typing stuff on an keyboard, it's probably either Python or Verilog, and that works out well -- Verilog satisfies the urge to write something tiny and polished at a really low level, and Python satisfies the urge to write something tiny and polished at a really high level (as well as the necessity to bang out some ugly throw-away code for a task that somebody needs immediately). What else is there?

I don't know where I first heard it, but I often echo the sentiment that "C is the new assembly language and Python is the new C." But I'm not sure how true that really is any more -- for in-browser stuff, it appears that javascript is rapidly becoming the new assembly language.

The fact that "start" is a bit field in the "ctl" register of the "timer1" block is maintained in a file that is also parsed by a Python script (via rsonlite) to produce Verilog, include files, and documentation (via rst2pdf).

I also use Python for several other tasks, ranging from checking schematic netlists to writing scripts to help out with CAD and production tests.

In my spare time, I'm busy trying to clean up a lot of my old stuff and port it to Python 3 (if it didn't already support it) and move it off googlecode to github. I started with pdfrw, and released a 0.2 with support for Python 3 as well as 2, and a few bug fixes and enhancements. I am actually fairly happy with how github works, and am working on a few more enhancements (and documentation -- need to do a better job of that!)

Maybe 0.3 will come out soon -- pdfrw is actually my most popular project. Although not as popular or full-featured as PyPDF2, it has some nice niche features. The core started off as some personal scripts to do page imposition for a neighborhood newsletter my wife used to edit, and then I released it as open-source when I started using and contributing to rst2pdf and realized that none of the available tools for reusing vector content with that package were very good --either they rasterized the source, or had bugs and some things didn't display properly. It turns out that one PDF feature -- form XObjects -- lets you reuse pieces of existing PDFs as if they were images, so you can use something like inkscape to convert your SVG file into a PDF, and then use pdfrw with reportlab (either directly or via rst2pdf) to add any sort of preexisting PDF content (including those converted SVG images) in a new PDF.

After I'm happy with pdfrw, I'll probably clean up and move rson to github next. rson is another package that was born to work with rst2pdf. Actually, I had some other use-cases for it as well, but its initial usage was with rst2pdf stylesheets. Those were originally in JSON, and when I converted them to YAML, the rst2pdf test time went up by something stupid. I don't remember exactly, but it was in the hundreds of percent. To parse stylesheets. Anyway, I read the YAML spec, downloaded and tested several implementations in different languages, realized that none of the implementations agreed on the multitude of corner cases, and was appalled, so I wrote something that was simpler than YAML and more readable than JSON.

I think one of your previous interviewees, Brian Curtin, said something like "anything by Raymond Hettinger" and that's a great answer -- personally, I use itertools a lot, and collections would also be a great module even if the only thing in it was the defaultdict.

For interfacing to the world, ctypes and re are both indispensible. Finally, binascii is a great sleeper module -- for some tasks it's much faster than using ctypes or struct.

Obviously the core developers are committed to 3, and with some of the later versions of 3 and some of the backports to 2.7, it's not nearly as painful to transition as it seemed it would be for awhile.

I don't know where it goes after this -- I'm just hoping for a bit of breathing room, to where I can reliably get back to looking forward to the next release of Python with unbridled anticipation. I'm starting to get there -- for example, I think 3.5 will have some killer features, and now I'm engaged enough with Python 3 to care -- but that hasn't been the case for a long time.

Overall, I think there are a lot of positive things going on in the community with new packaging, etc. I think the next few years have the potential to be quite exciting. On the one hand, it sometimes seems that, despite things like pyjs and kivy, Python isn't really going to participate in the web/mobile transition. But on the other hand, iPython/jupyter has some fantastic technology, and if they keep improving their security model, who knows where that could lead?

We just started a couple of "hack nights" to try to recapture the spirit of the early days of the meetup, and even there, the response has been phenomenal -- the downtown one probably had 40 people show up, and the one I set up in the coffee shop around the corner from my house had over 20. It's energizing to be able to walk around the corner and engage in relevant technical discussions, so if you don't have any meetup like that in your neighborhood, you should go talk to a coffee shop owner and maybe slip them a few bucks to reserve a room, and then go to meetup.com and let everybody know about it.

That's something I wish I figured out many years earlier.

Another thing in that category is this: if you have a project, it doesn't have to be perfect. Before I understood this, I shelved a few things that I actually had working code for, simply because I didn't think they were good enough (and frankly, some of that was due to negative reactions from people I admired). If you have something that works well for you, even in just one use case, put it out there, and if you get some feedback and make a few mods, pretty soon you might have a core group of users.

On a related note, if you're working for a company that won't ever let you contribute anything you do at work back to the wider community, whether that's because they think that every single thing they do is a sooper-sekret competitive advantage, or because they don't want anybody finding out about you, you're
probably working for the wrong people -- in the first case, they are completely deluded, and in the second case, they're probably not paying you enough.