About the site

Curious Efficiency is the intermittently updated personal website of Nicholas Coghlan, CPython core developer, PSF Fellow, software development toolsmith, cognitive science dabbler, and cynical idealist.

The main portion of the site is generated via Nikola, hosted on GitHub Pages, and under source control on BitBucket.

Python specific technical writing tends to end up on the ReadTheDocs powered Python Notes subsite.

About the name

Curious Efficiency is actually a reframing of my original blog title, Boredom & Laziness - the original boredomandlaziness.org URLs now redirect here. The original site blurb on Boredom & Laziness read as follows:

There are a couple of very, very scary things in this world.

The first is a bored human. Bored humans have time to indulge their curiosity, with potentially amazing results.

The second is a lazy human. Lazy humans can be quite inventive when it comes to figuring out how to do less work.

So, here's to boredom & laziness - two of the prime movers in human progress!

"Curious Efficiency" is really just a nicer way of referring to the same concept.

This post goes into some additional detail on the concepts that inspired the naming, both the original form, and the current more conventionally acceptable phrasing.

About the author


Nick is a CPython core developer, a Fellow of the Python Software Foundation, and the founder of the PyCon Australia Education Seminar.

He is the author or co-author of several accepted Python Enhancement Proposals (including PEP 453, which saw the pip installer bundled with Python 3.4+, PEP 466, which saw several key Python 3 network security enhancements backported to the Python 2.7 series, and PEP 538, which updated CPython to coerce the legacy ASCII-based C locale to a suitable UTF-8 based locale when one is available), and has also accepted a number of PEPs on Guido van Rossum's behalf as BDFL-Delegate.

Nick is currently the BDFL-Delegate for most packaging related PEPs, serving as the primary liaison between the CPython core development team and the Python Packaging Authority. His own efforts in the packaging space are focused primarily on the Python Packaging User Guide, and the pipenv application dependency management project.

At the PyCon US 2013 language summit, Nick successfully argued for updates to the Python Enhancement Proposal process (described in PEP 1) that allowed BDFL-Delegates to approve PEPs that don't affect the language definition or the standard library directly on the relevant mailing lists (without needing to rehash the discussions on python-dev).

In addition to CPython, the PSF, the PyPA, and the PSF's Packaging Working Group, other projects & programs of particular current interest include:

  • Kubernetes: a Google created open source application deployment platform, designed to ease adoption for folks accustomed to managing their own Linux servers directly, and supported across all major public clouds. I'm interested in this as I believe it addresses many of the vendor lock-in concerns otherwise raised against public cloud adoption (and unlike previous efforts in that space, it has support from the major public cloud vendors themselves).
  • OpenShift: Red Hat's fully open source Kubernetes-based Platform-as-a-Service offering that provides tools to handle automatic updates of deployed images when either application code or the underlying base image changes. I'm interested in this as Red Hat are veterans at selling to the legacy infrastructure crowd, and many of the "But what about..." objections raised against plain Kubernetes already have solutions built in to OpenShift.
  • Zappa: a toolkit for running Python WSGI applications in AWS Lambda behind AWS API Gateway. I'm interested in this as I think it's the level of "Don't bother me with irrelevant infrastructure details" that Kubernetes et al should be aspiring to, but they're not there yet.
  • Software Collections: a Red Hat supported approach to deploying platform components (such as language runtimes, database engines and web servers) on Linux, such that end user applications can use newer versions without interfering with the versions integrated directly into the underlying operating system distribution. I'm interested in this as "We have to use the system Python in some ancient RHEL version and aren't allowed to install packages from PyPI" is one of the largest drags on innovation in the Python ecosystem, and Software Collections are the main mechanism that Red Hat uses to offer newer Python runtimes to their customers.
  • Zappa: a toolkit for running Python WSGI applications in AWS Lambda behind AWS API Gateway. I'm interested in this as I think it's the level of "Don't bother me with irrelevant infrastructure details" that Kubernetes et al should be aspiring to, but they're not there yet.
  • Conda: a cross-platform environment manager created initially for the Python data science community. Its language independent design means it can not only manage the installation of Python packages, but also manage the Python runtime itself, external binary dependencies written in C/C++/FORTRAN/etc, and data analysis components written in other languages entirely (such as R and Julia).
  • Fedora Scientific: a KDE-based Fedora desktop distribution with a range of science and data analysis applications pre-installed, including IPython Notebook.

Selected articles, presentations and interviews

Selected Python Enhancement Proposals:

Selected Python related presentations (video links):

Selected Python related articles and presentation reviews:

Selected software design, development and deployment related presentations and articles:

Selected community management related articles and interviews:

Podcast appearances (in reverse chronological order):

  • Free as in Freedom (with hosts Karen Sandler & Bradley M. Kuhn, recorded January 2015)
  • Pragmatic (with host John Chidgey, recorded August 2014)
  • From Python Import Podcast (with hosts Mike Pirnat & Dave Noyes and fellow guest Alex Gaynor, recorded March 2014)
    • Historical note of potential interest: I consider this discussion between Alex and myself to be one of the key events on the road to PEP 466's backport of Python 3 network security features to the Python 2.7 series, and PEP 476's switch to verifying HTTPS certificates by default in Python 2.7.9+ and 3.4.3+
  • Radio Free Python (with host Larry Hastings, recorded February 2012)