PyDev of the Week: Aaron Maxwell

In my life I’ve been a club bouncer, a theoretical physicist, a roofer, an author, a forklift driver, a public speaker, and a software engineer. My degree is in physics (with a heap of extra math classes), and I am really good at starting graduate programs then dropping out of them. Like, I’m great at it! This knack has given me some higher education in biophysics, neuroscience, and computer science.

If a magic genie offers me one superpower, I choose the ability to instantly teleport anywhere – and take anyone with me, simply by holding their hand. That would be soooo much fun!

This matters, because language empowers thought. Code is not just a way to control a machine. It becomes a basic medium in which we express the mental creativity of our craft. A language can hinder or support that expression. A lot of it depends on making good decisions on details of the language.

The 3.x series keeps introducing exciting, richly powerful tools with every release. Three-point-four crossed several important thresholds: many of 3’s initially rough edges have now been smoothed out, unittest got supercharged, asyncio is part of the standard library, pip and virtualenv now ship as included tools… on and on. And it just happened that 3rd-party library support really solidified sometime between the 3.3 and 3.4 release. It’s now rare that I can’t pip install a package I need.

(On that note – there are really soooo many improvements in the Py3k… far more than most people realize. I once gave a talk describing what’s new in Python 3. I talked as fast as I could non-stop for an hour, and I still feel like I barely mentioned a fraction of it all. Some people seem to think only a few things have changed; respectfully to them, that’s very inaccurate.)

After Python, the language I know best is probably C. I keep finding it useful for certain things. I’m amazed C is still as important as it is, and am starting to think it will outlive us all.

Lately, I’ve been liking Java a lot. I can’t believe I just wrote that sentence, but it’s true. I learned it before I started with Python, ignored it for a long time, and recently started needing to use it again. Now that I have more experience maintaining large applications as part of an engineering team, I can see how some of its design decisions (which used to drive me nuts) are in fact valuable in that context.

I know some Lisp and Scheme, but haven’t been practicing them in a while. My mind naturally thinks very functionally (in the sense of functional programming), so they are easy to pick up and re-pickup. Javascript, for the same reasons. (As far as I’m concerned, JS is lisp wrapped in a C-like syntax.)

Go is an interesting language. I love its syntactically cheap concurrency, and the runtime’s solid support for hybrid threading (i.e. goroutines). It’s really hard to implement that well, especially in userspace, and they hit a home run. The lack of generics and (still!!) no built-in set type really drive me nuts, though. There was a time I thought I might switch my primary language from Python to Go; but with Python 3’s relentless onslaught of exciting progress, there’s no chance of that happening now.

I’m the author of an email newsletter, which I call the “Advanced Python Newsletter” – you should subscribe! I’m also about half-way done with a book I am tentatively titling “Advanced Python: A Not-For-Beginners Guide To Leveling Up Your Python Code”. There is a huuuge lack of materials for experienced programmers who already know the basics of Python, and that’s what I’m trying to fill.

Along those lines, I’m also designing some self-paced courses on really impactful topics: expressive code reuse through decorators, mastering the Python logging module, building REST servers, etc. This is where teaching live classes helps a lot – I get to look in their faces as I explain something, and learn how to teach something in a way that the light bulb goes off (instead of baffling them). I can then incorporate the best approaches into the self-paced version.

As you might imagine, with all this, I’m not coding nearly enough this year. After leaving Lyft late last year to teach – the hands-down best engineering team I ever had the privilege to work with! – I no longer am coding full-time, alongside truly excellent engineers. And frankly, I miss it.

I’m in love with asyncio, and Python 3.5’s async/await extensions. This is a big change not just in the library, but the whole Python ecosystem. Excellent libraries like Twisted, gevent, etc. have enabled asynchronous programming for a while; but to have something so solid and well-engineered baked into the standard library is qualitatively different. And on top of that, Python 3’s async support is genuinely breaking new ground.

For third-party, I’m amazed by requests. So much of programming is cognitive – depending on what goes on in the programmer’s mind. A great API can make that orders of magnitude easier. Requests does that better than almost any library I have ever seen.

I use Django and Flask a lot, for two completely different things. For human-facing web applications, Django is my go-to, and has been since version 0.96. (Back in 2007, wow!) For building services that expose their API via HTTPS, Flask works a lot better in my experience; a lot of Django’s killer features become excess baggage in that context, so Flask has less cruft to work around. I am super pumped that Python 3 support is already so solid in both.

For embarrassingly parallel tasks that are truly CPU bound, we can completely bypass the GIL via multiprocessing (see e.g. https://github.com/migrateup/thumper) – or in the rare cases that doesn’t do the job, C extensions. For network and I/O bound tasks,
threading gets you very far… and if you hit its limits, asyncio takes you the rest of the way. I’m actually designing a 2-day course in Python concurrency for one of my client companies, and I may turn that into a self-paced online course at some point.

What Guido has done with 3.4 and 3.5 is just the start of all this, and I can’t wait to see what he does next. He’s one of the greatest software engineers on the face of the earth!

Anyway, that’s my first prediction. The second: I think we’re going to see a mass migration to Python 3 within the next two years. I don’t think it will happen in 2015, but not long after.

The reason is that several changes are converging right now. First, library support is solid. Many libraries have well-tested and reliable support for Python 3; others don’t and never will (usually because they’ve become unmaintained), but there are drop-in Python 3 replacements. This is all true right now – not a “real soon now” thing.

Second, many big hitters in open-source have committed to Python 3. In particular, both Ubuntu and RedHat have very near-term plans to switch to Python 3 being the distribution default. At least in the case of Ubuntu, Python 2 will not even be installed by default, unless some other package requires it.

It also helps that Python 3 safely installs alongside Python 2 on the same system, without stepping on each other’s toes.

With me, the most promising sign of all is what I see happening on github. There is a LOT of activity involving Python 3 projects. In my experience, the best developers are naturally curious and want to do new things, and won’t stay long with a frozen language like Python 2.