This week we welcome Patrick Maupin as our PyDev of the Week. Let's spend some time getting to know Patrick a bit better.
Can you tell us a little about yourself (hobbies, education, etc):
I was born in San Antonio, Texas and raised in Austin. I spent several months working in England, and met and married a wonderful English lady and brought her home. We've lived in Austin for the last 30 years, except for one year we spent in Toronto. We have two great girls -- one is in medical school, and the other is a budding composer/author.
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.
I've sort of worked myself into a position where the hardware guys think I'm a software guy, and the software guys think I'm a hardware guy. That probably means I don't do either one very well.
Why did you start using Python?
I was trying to teach myself a bit about encryption and hashing, back in 1996, and I found Python's long number support, combined with its automatic memory management, quite compelling.
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'd like to do a hardware language with Python. There are a few efforts in that direction, but I don't find any of them compelling. Some of the building blocks that people are making that could help out with this, like mython, seem interesting.
What other programming languages do you know and which is your favorite?
I have made money programming in FORTRAN, Z-80 assembly, X86 assembly, 68000 assembly, TI DSP assembly, Pascal, Modula-2, C, and Verilog. Interestingly, I have never "made money" programming in Python, in the sense that it has never been in my job description like those other languages have, but in general, people at work don't bother me when I'm using it rather than a "real" language, and often seek me out for basic scripts that they can tweak.
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?
Anyway, for most general computing tasks, Python has to be my overall favorite by a large margin.
What projects are you working on now?
At work, I'm working on emulation for a new test chip. I use Python for many of the tests, with a setup where the device is represented by a class instance on the computer, and when you do something like "dut.timer1.ctl.start = True" it will actually go out over USB and provoke the dut (aka "device under test") and do a read/modify/write to timer 1's control register, setting the start bit high. Put py.test and jenkins on top of that, and you have really simple
reporting that even a manger will love.
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.
Obviously, the world doesn't agree with me (or maybe YAML has been cleaned up?) because YAML seems to be the in-thing these days.
Which Python libraries are your favorite (core or 3rd party)?
When it comes to the core, that's a very difficult question. The core is so balanced that I use a lot of libraries -- subprocess, hashlib, shutil, time, bisect, textwrap, array, glob, atexit, wave, gc, ast, elementtree -- the list goes on and on.
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.
When it comes to external modules, obviously I have a fondness for things I've written or worked on, but honestly, the overall winner is not in either of those categories -- xlrd is the hands-down winner, because it helps to keep me sane. I don't use Windows, much less Excel, but I have come to accept that, for many users, Excel is a productive data entry tool. xlrd lets me accept data from those guys, get it into a text form that can be version-controlled, and then have my way with it.
Where do you see Python going as a programming language?
Psychologically, I'm still recovering from the 2-to-3 transition, which created a huge chicken-and-egg situation in the community. I know, I'm a Luddite, but for a few years there, I wasn't really interested in doing anything with Python 3, and didn't feel that other people would be all that interested in my Python 2 stuff.
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?
Maybe I can have my own iPython notebook at my bank that knows all about my accounts and presents the data the way I want to see it, and a notebook at my brokerage that helps to handle my trades for me, and a notebook at amazon that helps to buy stuff for me.
Is there anything else youâ€™d like to say?
One thing I've noticed since I started re-engaging with the Python community a few months ago is how huge it's gotten in Austin. There are apparently a zillion companies in downtown Austin using Python heavily, and sometimes over 100 people show up at the monthly meetup.
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.
Finally, I think your blog in general, and this interview series in particular, are both awesome, and I'd like to thank you for doing this!
Copyright © 2022 Mouse Vs Python | Powered by Pythonlibrary