I just got back from PyCon 2015 as part of the edX delegation (there were 8 of us in total). What follows are my notes and thoughts on many of the talks that I went to.

Friday

I arrived Friday morning on an early (too early) flight, but still only arrived at the end of the keynote by Catherine Bracy about Code For America. I only caught enough to pique my interest, though, and not enough to really write anything more interesting about.

In the first talk I attended, the key takeaways for me were around keyword-only arguments (sadly, a feature not supported by python 2.7 natively), and around checking for whether an iterable is a container (like a list) that can be iterated over more than once, or just a single-use iterator.

All of Brett’s suggestions were spot on. Check out the talk for the leadup, but one thing I’d love to do is take his example for an iterable-container class, and convert it into a reiterable decorator.

Ryan’s talk was about his mashup of PyPy (the JITting python compiler) and Emscripten (an LLVM to Javascript compiler) and how that could provide an onramp towards support for Python in the web-browser. Amazing stuff, including a tracking site where you can track how the progress is going: Are we python yet?.

As you might expect from the original author of namedtuple, Raymond’s talk focused on how you can use python features to write simple, Pythonic code, even over un-Pythonic interfaces, and how simply focusing on PEP8 compliance can leave your code in a suboptimal state. I loved the way he clarified the interface in his examples (and his delivery was excellent).

I had heard of, but never really explored, Rust before this talk. Dan covered the bare basics of the language, and how it approaches memory safety, along with how to use cFFI to execute a Rust function from within Python, and how you can use that to improve the performance of your CPU heavy code. This isn’t a need that we’ve really had yet at edX, but it’s a great tool to have in your bag of tricks if it’s needed.

This talk was excellent, and packed! David walked through bare-bones, socket level implementations of several different concurrency models (single-process multithreading, single-threaded event-loop, event-loop with multi-process pool, event-loop with multi-threading), and demonstrated how each of those models interacted with multiple clients and with the GIL.

Saturday

ducker - A yet-to-be-implemented project to expose python docs to a chatbot

Keynote - Guido van Rossum

Guido’s keynote hit two topics. The first was a call to action towards moving from Python 2 to Python 3, and a rumination about what to do with the ~50000 projects on PyPi that haven’t moved (and perhaps won’t, because they are abandoned). He suggested perhaps emailing the authors of projects that haven’t been updated recently, and suggesting co-ownership for the projects. Later, in the bus on the way to the airport, I talked with a fellow attendee named Jonathan about the possibility of automating forking of abandoned/co-owned projects onto github (that seems perhaps overly aggressive now that I write it down, but perhaps it’s a reasonable option for those projects that are truly abandoned, and which have compatible licenses).

Guido’s second topic was a call for more diversity in the Python community, and to set a goal of having at least two (I think) female core committers by next PyCon.

Guido’s keynote segued nicely into Kate’s talk about how many behaviors that are common in engineering organizations can drive down diversity. Her blog goes much more into depth on all of the topics in her talk, but for me, the big takeaways were:

The thing that excited me most about this talk was having a pattern for defining pylint-style rules in a declarative way, rather than having to write down an imperative AST visitor. If the language proves to be reasonable, then that would significantly lower the barrier for teams to detect their own set of linting violations, and to contribute new linters to the open source community.

Type-Hinting Open Space

This was probably the highlight of PyCon for me. Adam (another edXer) noticed it on the Open Spaces board, and so I was able to sit in and listen as Guido and a number other folks discussed the final details of PEP-484. This included Peter Ludemann and Jukka Lehtosalo, both of whom I was able to talk to later in the hall as well. Jukka is the author of MyPy, which is a static type checker for Python, and the coordinator for typeshed, which provides a place to centralize the type stubs for the Python standard library. Peter is working on pytype, a tool that infers types based on Python 2 usage and generates type hints for those functions.

I’m very excited to follow (and hopefully work on) these projects, so that we can start using them at edX to provide a little more safety for the core of our platform.

Lots of good suggestions in this one, plus a fun story about a bug in glibc inside a subprocess API. I missed the first part of the talk (about system tracing tools), so this is on a short list of mine to re-watch.

This talk covered the basics of the asyncio module, and the basics of a distributed hash table. Both were interesting in their own right, but they also reminded me that we need to make sure that we build in an asynchronous API and allow for concurrency when we’re building the edX common client (so that we guide developers towards writing code that parallelizes as many API calls as it can).

Poster Session

The big takeaway from this one for me was the statement “profiling gives you new hypotheses, but benchmarks are your experiments”. This was in the context of performance profiling and optimization as an application of the scientific method. I know that I’ve been tempted in the past to compare two different runs of a benchmark under profiling, and consider those results to be relevant. But I think Jesse’s point is crucial: code under profiling is being distorted by the profiling itself, so any comparisons between profiling runs is going to reflect that distortion.

This was Guido’s chance to explain the upcoming type hinting to the Python community. He kept mostly to the syntax, and to the reasoning behind the feature. My impression was that the audience reaction was mixed, but for me, it was exciting to see what’s coming.

My name is Calen Pennington. I'm a software developer and lead architect at edX,
father to a two-year old, part-time haskell hacker, board/card/video-gamer. This blog will primarily
focus on the first of those.
Find me on: