PyDev of the Week: Glyph Lefkowitz

I work on a lot of open source software, both for work – I maintain Twisted, and a ton of associated ecosystem projects, for Rackspace – and personally.

My hobbies mainly revolve around computers. For example, I’m an avid video game fan. I’ve also dabbled in graphic design, 3D rendering, and computer-generated music; although nothing really good enough to share. As time allows, I’m also a really big reader, particularly of science fiction and fantasy.

I was working on a video game, “Twisted Reality”, that was originally written in Java.

Twisted Reality was designed to have authors doing content creation in-engine and online, possibly with players watching them do it. This meant that a lot of behavior had to be dynamic and run-time modifiable, which meant that objects had lots of collection data structures to map item names and verbs to various simulation objects and actions.

I had a summer job writing a calendaring system in Perl, and as I was increasingly having problems with the JVM, I was casting around for other languages I might use. One of the major problems I had with the JVM was that the UIs just behaved incorrectly and were visibly laggy and slow (remember; this was 1999 or so) no matter how much I tweaked them. I started re-writing the client software in C, for Linux, to make native use of the GTK. I believe I originally discovered Python because one of the other developers pointed out that it was possible to write GTK UIs using a much higher-level language, so the first thing I wrote was a PyGTK client for our game server.

One of the things I noticed when writing the client is that many of the high-level dynamic behavior constructs that I had cobbled together by hand in Java were built right in to Python – like the ability to dynamically add an attribute to an object. The others which I used frequently, like hash tables, involved radically less typing; ‘x = {}’ rather than ‘import java.util.Hashtable; Hashtable x = new Hashtable();’.

Beyond that though, one of the nice things about my research role at Rackspace is that I have the flexibility to experiment with new projects. Sometimes this means some contributing upstream to maintenance of other libraries, and sometimes it means experimental new side-projects. One such side-project is my state-machine library Automat, which allows for easy expression of formal state machines. Another is Horsephrase which is a simple password generator designed to apply a bit more information-theoretical rigor to the process of generating pronounceable, communicable passwords.

One of the things that makes Python so appealing is its generality. It’s the second-best language for everything; if you want the absolute best language for the web, for example, in terms of availability of libraries and developers and time to market, Ruby – due to Rails – might be a better bet. If you want the best language for enterprise computing or distributed systems, Java, or at least, something in the JVM ecosystem, might be better than Python. If you want to do statistics, R or MATLAB might have more functionality available.

But, if you want to write some numerical analysis that is hooked up to a web app which needs to do reporting from an enterprise database, Python will beat any of these languages hands down.

So, as a community, I think we have two choices before us. Either we are going to keep pushing boundaries, keep making Python more general – make it run in the browser, for example, make it run better on mobile devices – or we are going to be complacent about the places where it’s already doing well.

Right now, it’s possible to run Python almost anywhere, for almost any application. But that doesn’t mean it’s practical, or accepted. If you go to do front-end stuff, there’s a strong expectation you’ll be using a JavaScript framework like React. That’s why I think issues like this one are so important. Back in the old days, Python was competing against really horrible alternatives, which it could beat handily: giant piles of closed-source C++, for example. Now, the competition is much more intense: ECMAScript 7 with React in the browser, for example, and Clojure with advanced features like JMX on the back end.

Right now I’m concerned about front-end stuff, because that seems to be the area where Python is the weakest and also the area where there is the most potential for another breakout success. (And frankly because I want to write cool front-end stuff and I don’t have a huge amount of time to invest.)

However, one thing I think it’s important to speak out about – and since you’ve given me a space here explicitly to speak out on something I think is important, I should do so – is that we absolutely can’t stop here. We still need to be welcoming.

An easy way to do this is to work on friendliness and openness to beginners and unfamiliar people in your open source communities. Thank every contributor for their patches – even if the patches are terrible, they still dedicated time to learning enough about your project to submit one, and that investment of time is a vote of confidence in your work! This goes the other way, too – sometimes the users have more status and power than the maintainers. Be sure to thank maintainers for their efforts, especially if they’re volunteers.

But just doing the easy stuff isn’t good enough. Leaders in open source communities need to participate in outreach programs. Managers in software companies need to actively work to remove bias and unfairness (which are not necessarily the same thing!) from their hiring processes.