How to Be More Effective with Functions - Brett Slatkin

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.

# Brett's example
class LoadCities(object):
    def __init__(self, path):
        self.path = path

    def __iter__(self):
        with open(self.path) as handle:
            for line in handle:
                cit, count = line.split()
                yield city, int(count)


# A re-usable decorator

def _Reiterable(object):
    def __init__(self, fn, args, kwargs):
        self.fn = fn
        self.args = args
        self.kwargs = kwargs

    def __iter__(self):
        return self.fn(*args, **kwargs)

def reiterable(fn):
    @functools.wraps(fn)
    def wrapper(*args, **kwargs):
        return _Reiterable(fn, args, kwargs)

@reiterable
def load_cities(path):
    with open(self.path) as handle:
        for line in handle:
            cit, count = line.split()
            yield city, int(count)

PyPy.js - Ryan Kelly

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?.

Beyond PEP8 - Raymond Hettinger

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).

How to make your code Python 2/3 compatible - Brett Cannon

My takeaways from Brett’s talk were:

1. there are lots of tools to help with the mechanical transformations (futurize and modernize).

2. six can help us build libraries that work in both Python 2 and 3.

3. You still have to think about how your strings are used (are they text? or are they bytes?).

4. We (edX) should be making a push towards running on Python 3 (and we’re not that far away: https://caniusepython3.com/check/a48ab687-f601-40d1-a12d-b4c91bca717b).

My Python’s a little Rust-y - Dan Callahan

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.

Python Concurrency From the Ground Up: LIVE! - David Beazley

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.

Evening Lightning Talks

Highlights:

• Waterbutler - streaming file updload/downloads
• ipython-sql - Nicely formatted sql output in an ipython notebook
• rdbms-subsetter - Get a consistent subset of a sql database with a target size
• pgcli (and mysqlcli) - Better colors and autocompletion in a sql client on the commandline
• modular-odm - Perhaps a way to build the next version of XBlock fields?

Morning Lightning Talks

Highlights:

• 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.

How our engineering environments are killing diversity (and how we can fix it) - Kate Heddleston

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:

1. Focus on making suggestions, rather than providing critical feedback
2. Work to improve our onboarding documentation and process
3. Work to document undocumented processes

Learning from other’s mistakes: Data-driven analysis of Python code - Andreas Dewes

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.

Techniques for Debugging Hard Problems - Alex Gaynor

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.

Lessons Learned with asyncio (“Look ma, I wrote a distributed hash table!”) - Nicholas Tollervey

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).

Evening Lightning Talks

Highlights:

• pStatsViewer - iPython Notebook-based viewer for pStats data
• - CSS layout debugging
• lazy_python - truly lazy python objects (down to the bytecode)

Morning Lightning Talks

Highlights:

• effect - effect isolation for python

Poster Session

Highlights:

• pulp - A repository manager (perhaps as a local PyPI)
• ClusterRunner - A test-parallelization framework

Python Performance Profiling: The Guts And The Glory - A. Jesse Jiryu Davis

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.

Type Hints - Guido van Rossum

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.