Greg Ward

Volunteering

For some reason it never occurred to me to volunteer at a conference before. Especially considering that PyCon is almost entirely run by volunteers, I now have to wonder: what was I thinking? This year I noticed some tweets and emails encouraging people to volunteer, so I did it. Turns out that volunteering at PyCon is how you peek behind the curtain and nudge closer to the inner circle without having to do all that much. It's a brilliant scam, but it seems to work because there are a lot of people willing to do a bit, and some people willing to do a lot.

The fun part was helping at the registration desk. I literally got off the plane, took a taxi to the conference centre (with a gaggle of other Montrealers who happened to be on the same plane), registered and got my badge, and went right behind the desk to register other people. Oh yeah, there was a 5-minute training session in there somewhere, so I had a vague idea what I was doing.

The work part was being a session runner. This involves being in the Green Room well before a given talk starts, making sure the speaker is there, finding them if not, making sure their slides are saved, making sure they can hook their laptop up to the projector, getting them to the right room at the right time, and then leaving their interesting talk halfway through to start the process again for the next talk. I managed to be late for my first session because I just plain forgot, which was a minor panic. Then, because irony exists as an actual physical force in the universe, I was late for my second session because I was enjoying a leisurely lunchtime chat with Mathieu Leduc-Hamel and Yannick Gingras about how great it is to volunteer at PyCon. Argghh. Ah well, it all came together in the end.

Good talks

As usual, there was way too much interesting stuff on hand to see everything I wanted to see. Really, something must be done about that next year. Or we'll just have to stick with recording everything so you can catch what you missed later on at home.

Here are the talks that I saw in person and recommend:

• Brandon Rhodes - The Naming of Ducks: Where Dynamic Types Meet Smart Conventions
• Augie Fackler, Nathaniel Manista - The End Of Object Inheritance & The Beginning Of A New Modularity
• Luke Sneeringer - Logical Failures
• Larry Hastings - All-Singing All-Dancing Python Bytecode
• Allen Short - Worry-Free Parsers with Parsley
• Taavi Burns - Server Log Analysis with Pandas

There are a bunch more on my list of talks to watch on my laptop when too tired for programming but not tired enough to completely collapse:

• Brett Cannon - How Import Works
• Laurens Van Houtven - Crypto 101
• David Malcolm - Death by a thousand leaks: what statically-analysing 370 Python extensions looks like
• Doug Hellmann - Dynamic Code Patterns: Extending Your Applications with Plugins
• Daniel Lindsley - How (Not) To Build An OSS Community
• Raymond Hettinger - Python's Class Development Toolkit
• Lynn Root - Sink or swim: 5 life jackets to throw to New Coders
• Glyph - So Easy You Can Even Do It in JavaScript: Event-Driven Architecture for Regular Programmers
• Chris McDonough - API Design for Library Authors

... and I just got tired of copying and pasting, despite being only halfway through the list. You get the picture: there were way more interesting-sounding talks than any one person could attend in person. (And if you view a talk from home that turns out to be boring, you can walk away without hurting anyone's feelings!)

Packaging

I mentioned that there was a secret hidden connection between my first International Python Conference in 1998, and PyCon 2013: packaging. Well, really, I should say build and packaging tools, since the problem back in 1998 was building, but the problem today is packaging.

The whole story is a bit long, so I'll write it up in a separate post. TL;DR: the basic design of distutils came out of the 1998 conference, and I wrote most of the code from late 1998 to late 2000. Standard build tool for Python libraries: problem solved!

But we punted on a couple of key issues, specifically dependencies and packaging. My opinion at the time (1999) was that packaging was a solved problem: it's called Debian, or Red Hat if you prefer. Both have excellent packaging systems that already worked fine, and I felt it was silly to reinvent that wheel for one particular programming language. If you need library X in your production environment, then you build a package of it using distutils. When Harry Gebel contributed the bdist_rpm command to build a simple RPM from information in your setup script, that was a key step. We just made sure it was possible to build only the .spec file, because of course you would often need to tweak that manually. Then I waited for someone to contribute bdist_deb, but it didn't happen.

It turns out, unfortunately, that people persist in using deficient operating systems with no built-in packaging system. More importantly, programmers like to use the latest and greatest version of library X, which is incompatible with OS vendors wanting to stick with stable known versions. And building OS packages is a pain, especially when you're in development and playing around with libraries.

Unfortunately, I burned out and lost the energy to keep working on distutils before any of this became apparent. So over the years, various people have tried to address these problems in various incompatible ways. I've pretty much ignored things, because after all packaging was a solved problem for me (use OS packages, or build your own).

Anyways, it appears that 2013 is the year the Python community has decided that enough is enough, and we need One True Packaging Solution. As a result, there were a couple of packaging-related sessions at PyCon this year. Probably the most important development is that Nick Coghlan has volunteered (was volunteered?) to be the czar of all things packaging. I wish him well. Heck, maybe I'll even contribute!

Hallway track

I chatted with a number of people, some long-time acquaintances and some total strangers. I mentioned to several of them that I had been using Go for a couple of months, and every single one of them was quite curious about it. So I definitely need to write up this Python hacker's view of Go. (Nutshell version: largely positive, but I miss exceptions.)

I was also fairly shameless about looking for a job, which I've been in the midst of for the past week or two. One piece of advice: PyCon is an excellent place for programmers to look for work; the job fair reminded me of a two-way feeding frenzy. Another piece of advice: don't fire off a bunch of job application emails right before going to a conference. You'll spend way too much time hunched over your smartphone trying to type professional-sounding but still short email messages explaining that you can't really talk right now, but next week would be great. Maybe I should have bought one of those spiffy ultra-light laptops so that whipping a real computer out for processing email isn't so painful. Oh well.

Open spaces & sprints

I scheduled two open spaces: a Mercurial clinic and a place to debate the wisdom of extendding vs. embedding.

I was late for the Mercurial clinic because of another really interesting open space; many thanks to Augie Fackler for showing up on time and fielding most of the questions. Oooops. We fielded some basic questions like, "do I really have to merge this often?", explaining why it works that way, what the alternatives are, and so forth. The usual stuff for someone new to DVCS.

Augie also explained changeset evolution to a couple of people. Evolution is a very cool feature Mercurial has been growing slowly over the past couple of releases to allow safe mutable history. As of Mercurial 2.5, it's good enough that Mercurial's developers are eating their own dogfood and using it to develop Mercurial. I've also been using it heavily on personal projects. Hopefully it will be solid enough by 2.6 that enthusiastic power users can start to use it instead of MQ.

After the Mercurial Clinic, Augie and I popped into the Python 3 Porting Clinic organized by Barry Warsaw. That's when the real fun began. Augie has been plugging bravely away at porting Mercurial to Python 3, and all is not well. Barry opened issue 17445 as a result of Augie's first showstopper bug, and I've been working on a patch. No doubt more showstoppers will follow. I stayed for the first day of sprinting, and spent the day alternating between fixing that bug and whining to people about the various unpleasant ways of fixing it. I got to meet several thoroughly decent people in the process: Richard Jones, Nick Coghlan, Toshio Kuratomi, and Buck ... umm, sorry Buck, I didn't catch your last name.

My other open space was intended to spark a little debate about extending vs. embedding. I've been working on a build tool that revolves around embedding "real" languages like Python, and suffered a minor crisis of confidence when I stumbled across Glyph Lefkowitz's anti-embedding rant from 2003. So I was hoping this session would clear the air a bit. It didn't. I guess I should have invited Glyph personally. My personal suspicion is that there do exist valid use cases for embedding, but you had better make damn sure it's the right choice. "When in doubt, choose extending" is not as strong as Glyph's stance, but there you go. It's my opinion today.

Wrap up

Everybody knows that the language is great, and that the library is (mostly) great too. Likewise, the collection of modules on PyPI is a good thing (if a bit overwhelming).

But honestly, it's the people that make hacking in/on/with Python so fun and rewarding. I know there is a stereotype of programmers as anti-social, maladjusted, unpleasant people, but that stereotype just vanishes at PyCon. Whether chatting with total strangers who I'll probably never meet again, or reconnecting with former colleagues, or meeting people who I've only "known" online before, PyCon is just about the friendliest and most welcoming environment I've ever been in. That's just as true with 2,500 people in 2013 as it was with 250 in 1998.