Dynamic Code Patterns: Extending Your Applications with Plugins

My second presentation from PyCon 2013 is available online:

Python makes loading code dynamically easy, allowing you to
configure and extend your application by discovering and loading
extensions at runtime. This presentation will discuss the techniques
for dynamic code loading used in several well-known applications and
weigh the pros and cons of each approach.

And the video:

New Year’s Python Meme

  1. What is the coolest Python application, framework, or library you
    have discovered in 2011?

    We use PyFilesystem to access WebDAV and S3 storage as though it
    was part of the local file system.

  2. What new programming technique did you learn in 2011?

    It’s not a technique, per se, but I learned a lot about the
    internals of Sphinx while preparing the manuscript for my book. I
    will be summarizing what I learned in a presentation at PyCon

  3. What’s the name of the open source project you contributed the
    most in 2011? What did you do?

    For non-coding contributions, that would be the Python Software
    . The PSF Communications team set up Python Insider,
    a blog for the Python core development team. Posts written in
    English are translated into 10 different languages by members of
    the Communications team.

    For code-related contributions, it would probably be a tie between
    virtualenvwrapper and sphinxcontrib.spelling

  4. What was the Python blog or website you read the most in 2011?

    Definitely the Planet Python feed.

  5. What are the three top things you want to learn in 2012?

  6. What are the top software, app, or lib you wish someone would
    write in 2012?

    I like Tarek’s idea for a mobile wine label recognition app, but I
    would settle for a decent wine log/journal app for iOS.

    Other than that, I can’t think of anything I want to see that I’m
    not planning to build myself, but none of those projects are far
    enough along to talk about yet.

Tarek started this series with these instructions:

  • copy-paste the questions and answer to them in your blog
  • tweet it with the #2012pythonmeme hashtag

How I Review a PyCon Talk Proposal

As the submission period for PyCon 2012 comes to a close and we
transition to reviewing the proposals from potential speakers, I
thought I would talk about the criteria I use for evaluating the
submissions. I am only one member of the Program Committee, and others
may use different criteria, so please take that into account while
reading this article.

I approach conference talk proposals in much the same way that I
approached submissions for Python Magazine. Just as the magazine had a
limited amount of space for articles each month, there are a limited
number of speaking slots at PyCon. The Program Committee’s job is to
choose the talks that maximize the benefit to the entire conference
audience, within the space and time constraints given. While reviewing
a proposal, I keep in mind that, as one person among 1,500, my opinion
only goes so far toward the makeup of the conference audience. While
my own enthusiasm and interest in a subject do matter, I try to
consider the rest of the audience first. The main question I keep in
my mind is, will the audience seeing this talk receive enough value to
make it worth bumping another talk? A lot of factors go into that
decision, and balancing them all can be a challenge.

Will the audience seeing this talk receive enough value to make it
worth bumping another talk?

The Abstract

The first step to reviewing the proposal is to read it. That seems
fairly obvious, but occasionally a title comes along that is so
compelling that I have to remind myself to keep reading before voting
+1 and moving on to the next talk. It isn’t enough for a proposal to
cover an interesting topic. It has to indicate that the talk will be
interesting, too. While I am reading, I look for several factors.

Is it clear, complete, and compelling?

First, is the abstract clear? The speaker should describe the topic
they plan to talk about in terms I can understand, even if I don’t
know anything about that subject area. The audience for PyCon is
diverse in experience and background, and so are the speakers. A
clearly written abstract, without a lot of domain-specific jargon,
tells me the speaker will be able to communicate with the audience.
If I can’t understand the proposal, I assume the audience won’t
understand the talk either.

Next, is the abstract complete? An incomplete proposal is the
largest negative factor I consider. If a proposal is incomplete, I
can’t really say what the speaker will talk about, or even if they
know the subject matter for their talk. If a proposal does not have a
detailed summary or outline, I as the submitter to provide more

Finally, I consider whether the abstract is compelling. Without
regard to the actual subject, is the abstract written in a way to
attract an audience? Is it full of boring clichés, vaguely worded
assertions about the superiority of one tool over another, cute
metaphors, or hand waving? I look for an abstract that shows the
speaker is excited about the topic, and that they will be conveying
that same excitement to the audience.

The Topic

For some people, the subject matter of a talk is the most important,
or only, aspect taken into consideration when voting. I have seen
presentations on topics I thought would be boring, but which were
delivered with such enthusiasm that I enjoyed them more than talks I
thought would be interesting from the outset. In my mind, the topic is
an important factor, but not necessarily the most important, to be

How relevant, niche, immediately useful, and novel is the topic?

I look first at whether the topic is relevant to the conference
attendees. For PyCon, that largely means users of the Python
programming language. Attendees will have a range of experience
levels, interests, and backgrounds, though, so not every talk needs to
include examples of Python code showing how to code around a
problem. I have seen successful talks covering user interface
standards compliance, community building, Java-based testing tools,
and a host of other non-coding topics.

Although we want a broad set of topics, we do need to be careful to
avoid talks that are too narrowly focused on a niche. PyCon has
grown large enough that we run five tracks of talks
simultaneously. That means each talk is usually competing with four
others, and when the start and stop times don’t align it can be more
than that. Each talk needs to attract enough of that audience to
justify being included in the program instead of another of the many
rejected talks. There are no formal metrics for that criteria, because
we cannot know in advance how each talk will be attended. Talks that
are unlikely to attract a significant audience at a large conference
such as PyCon may find a better fit at a regional or subject-matter
based conference. Examples of niche talks are those on topics that
require deep technical knowledge of a scientific field, unpopular
hardware platform, or industry. This is also why I tend to down-vote
talks on brand new libraries or tools, usually with an admonition to
resubmit the proposal when the project has matured and the community
around it has grown. Now that PyCon includes a poster session, I often
recommend that new projects which show a lot of promise convert their
talk proposal into a poster proposal.

As a counterpoint to considering whether a topic is too niche, I also
try to take into account whether the audience will take away something
immediately useful. The members of the Python community blend open
source and closed source solutions. Presentations on a closed source
application or service are less interesting, unless the techniques
presented can be applied elsewhere. Talks on open source projects are
more likely to involve reusable code, just by their nature. However,
new and incomplete projects don’t meet that standard.

The final criteria I consider for the proposal’s topic is whether it
is novel. Although the PyCon has a significant amount of turnover in
the audience year to year, I don’t want the program to be made up of
the same topics over and over. The same goes for subjects that have
appeared on blog posts, articles, and books. I am unlikely to up-vote
an introductory talk for a project with excellent documentation unless
the talk presents material in a new and interesting way.

The Presenter

Foremost in my mind when thinking about the presenter is the question
of whether or not they will be successful at delivering their proposed
talk. That question covers a lot of ground, so I break it up into
several aspects and take each in turn.

How skilled, knowledgeable, and experienced is the speaker?

First, how skilled is the speaker? The PyCon audience deserves
speakers who take their task seriously by preparing and practicing.
Evaluating the presentation skills of an unknown speaker can be
challenging. I have not had the opportunity to attend a lot of other
conferences or user group meetings in person, so unless they have
spoken at PyCon in the recent past I am unlikely to know much about
their style or skill. Restricting myself to events I have attended
means I may tend to favor a small group of “usual suspects.” To avoid
that bias, I look for cases where they have spoken at user group
meetings, regional conferences, or other events. Having access to
videos of past presentations helps, and I try to review at least a few
minutes of video for a speaker, when it is available.

I also want to see an indication that the speaker understands the
subject well enough to speak at length about it. A good speaker does
not need to be a domain expert, but some knowledge and experience is
required. It is not necessary for every presentation on a tool to be
delivered by the tool’s developer. Users and other community members
with good public speaking skills can present

Finally, does the speaker have enough experience speaking to know
their limits? There are two main limits: venue and time. PyCon is
typically held in large hotel ballrooms and that type of venue
presents a couple of challenges. The average audience for any given
talk is 1/4 to 1/5 of the 1,500 conference attendees. Due to the
structure of the venue, interactive sessions tend to flow less well
than more the standard talk-followed-by-questions. Presentations that
rely on showing code battle with the deep room layout, so fonts have
to be large enough that big blocks of code don’t fit on a single
slide. All of these issues can be overcome, but a presenter has to
know that they can’t just slap up their text editor together with a
terminal window using a low-contrast color scheme and expect the
audience to follow along during a live demo. Previous speaking
experience at smaller events shows me that a speaker is likely to
understand these issues.

The time issue is more difficult to balance. I want to see a talk with
enough depth that it shows something interesting, but reaching that
depth may require a time-consuming introduction. Setting the audience
level of the talk is one approach for avoiding this problem, because
the audience for an Intermediate or Experienced talk will not expect
as much of an introduction as someone in a Novice talk. On the other
hand, assuming too much knowledge may mean even an Experience attendee
does not understand the main point of a presentation. Speakers can
reclaim time by removing redundant examples, tightening their focus,
and trimming some of the commentary, so I usually try to point out
material I think can be cut to give the speaker more time.

It is less common for an outline to seem too short to fill the space
given, but it does happen. In this case, I look for information the
presenter may need to add, suggest they work in extra examples, or
simply tell them it looks too short. If a talk can’t fill a 30 minute
slot, but is still important or interesting, I may propose they
convert their proposal into a poster, instead.

Voting Versus Steering

One point frequently lost in the heat of the reviewing process is that
the Program Committee is not just supposed to judge the
proposals. Our responsibility is to make the PyCon program
better. That mission includes guiding the speakers to improve their
talks by refining the original proposals.

I have already mentioned a some of the common suggestions I make
during the course of a review. After considering all of the other
factors, I pause and pretend that the proposal I am reviewing is for
the only talk I will be able to see at the conference. Then I think of
ways the presentation could be improved, and engage with the speaker
to discuss them. I try to provide guidance based on past experience to
help newer speakers understand how their talk might be improved to fit
into PyCon better.

I also tend to ask a lot of questions, especially if I or other
reviewers have a negative impression of the proposal. Asking for
clarification or more detail is an important part of the process.
Sometimes the interaction with the speaker helps me decide whether to
champion a talk, or merely vote +0 or -0.


As I said at the outset, other reviewers may use different criteria
when evaluating a proposal. We want a big enough Program Committee
that we have a range of experience and input into the selection
process. But these are the criteria I use, so if I end up reviewing
your proposal, you know how I went about it.

  1. Is the abstract clear?
  2. Is the abstract complete?
  3. Is the abstract compelling?
  4. Is the topic relevant?
  5. Is the topic too niche?
  6. Is the material immediately useful?
  7. Is the presentation novel?
  8. Is the speaker skilled?
  9. Is the speaker knowledgeable?
  10. Is the speaker experience?
  11. How can the proposal/talk be improved?

See also

Choose Your Own (PyCon) Adventure

PyCon is a “community driven” conference. That means we depend on
members of the Python community to organize all aspects of the event,
from site selection to menu planning. It also means we depend on
community members to provide the content for all of the presentations,
posters, and tutorials. There’s no corporate marketing agenda or
“pay-for-play” system for arranging for speakers. Instead, the program
committee finds volunteers to talk about interesting work they are
doing and provide training on topics of interest to the community.

This is normally the point at which a post about PyCon implores you to
submit a proposal about one of your own projects. Not this time.

The Personal Touch

One of the hardest things I had to do as Editor of Python Magazine was
find people to write articles for us. I thought that would be a simple
task (geeks usually love to talk about their work, after all, and we
did pay for articles). I was surprised at just how challenging that
aspect of the job turned out to be. I sent message after message to
mailing lists for projects, user groups, and authors asking for anyone
to tell me about their work. I received almost no responses, and I was
killing myself to put together enough material to make a full issue
every month.

In desperation, I changed tactics and began crafting more specific
requests addressed to individuals. In the short term, it was more
work. I had to research the projects myself by lurking on mailing
lists, watching the PyPI RSS feed for new releases, and scanning the
schedules for every conference I could find with presentations using
Python. But as a result of that work, instead of a generic “tell me
about something you are doing” message, I was able to ask project
leads and library authors to write a more directed article. I could
suggest a few topics, along with reasons I thought what they had to
say would be interesting to my readers.

The results were startling. That seemingly small shift in tactics made
an enormous difference in the responses to my requests. Within a few
weeks, I had more articles than I could edit and I had filled my
production schedule for the next several months. As a result, I was
able to slow down acquisitions and concentrate on other aspects of
being Editor.

I learned that a direct personal request made more of an impression
than a general call for participation. People who may not have
considered themselves authors, or who thought they had nothing
interesting to say, could be swayed by a personal appeal.

You Are PyCon

We can apply the same direct-approach tactics I used with the magazine
to create the PyCon talk schedule, but we need your help to do it.
You all know an interesting story, even if it isn’t yours to tell. We
need you to help us find those stories, and convince their owners to
tell them.

I am not asking you to take an hour this week to write a proposal for
your own talk. Instead, I want you to take 15 minutes to encourage
someone else to write a proposal.

Send a short email to the author of the library that made your
difficult tasks easy and tell them that more people need to know about
the tool they have created.

Write to the lead of a project where Python plays a quiet supporting
role and ask them to share their case study.

Contact a trainer who engaged with their students and made class fun
to make sure they know about the tutorials at PyCon.

Ask a blogger with outstanding technical insight to share the benefits
of their experience.

Suggest that a member of your local user group polish their
presentation about using Python in their job.

Encourage a speaker from another conference to present their talk at

Be specific. Suggest a topic they are qualified to talk about. Tell
them why you think they have an interesting presentation, tutorial, or
poster. Tell them you want them to participate.

The application deadline for proposals for PyCon 2012 is October
12, 2011. Take 15 minutes, right now, and send an email to help make
PyCon a conference you want to attend.

Hidden Treasures of the Standard Library

The slides from my PyCon 2011 presentation are on slideshare now.

Book Galleys

My publisher arranged to send physical copies of *The Python Standard
Library By Example*
so I could bring them to PyCon. Some of them are
going into the door prize pool, and there will be at least one copy in
the bookstore for anyone who wants to look it over before committing to
buying. Although, the Safari edition is probably more convenient for
perusing. This book isn’t going to be exactly light reading:


python-authors mailing list

At PyCon this year, a group of authors and editors met to start
building the writing sub-community for people interested in
Python-related topics appearing online and in print. One of the
suggestions that came out of the meeting was to establish a new SIG
mailing list, hosted on python.org. I’m pleased to announce that the
python-authors list has been established and is ready to host

If you have any experience or interest in writing, editing, or
reviewing technical writing such as blog posts, magazine articles, or
books, this list is for you. We’ll be trading tips, looking for
collaborators for new projects, and just generally talking shop.

I hope you’ll join us!

Updated 5 June 2009: Unfortunately I’ve had to set the list
subscription to moderated to avoid spammers. The list itself is still
unmoderated, and I will try to approve requests for new subscriptions as
quickly as possible.

“Writing About Python” at PyCon

The Python writing community has never been stronger. From blogs to
magazines to a slew of recent releases from O’Reilly, Packt,
Manning, Apress, and other publishers there a more opportunities
than ever before for anyone wanting to write about Python in some

Of course, authoring is only one aspect of producing high quality
professional writing. As an editor, it’s no surprise that I think all
authors can benefit from having someone else read their work. Even an
informal review can help identify gaps in an explanation or problems
with flow, not to mention typos.

Writers, reviewers, and editors can all benefit from sharing tips,
offering advice on tricky problem passages, or just chatting about
ongoing projects. That list sounds just like the sorts of things we talk
about when discussing programming, doesn’t it?

I’d like to bring people together in person for a group discussion and
a chance to network. To kick things off, I’m working on organizing a
“meetup” as an open space session at PyCon in March. If you are a
blogger, published writer, reviewer, or editor – or aspire to be – I
want you to come and participate. No prior experience is necessary,
everyone is welcome.

Let’s connect people interested in doing technical reviews with
authors and editors. Let’s introduce potential writers to the editors
and publishers. Let’s learn from one another and improve our prose, the
same way we improve our code.

We’ll have to wait to schedule a precise time until the conference,
but right now I’m thinking about late Saturday morning or early
afternoon. If you are interested in attending, please post a comment so
I can gauge the size of the room we’ll need. If you have a preference
for the time, make sure to include that information. And if you have
ideas for things we should talk about, let’s hear them.

Update: Although I was thinking of “print” writing, other forms of
publishing like podcasting are welcome, too. We need more good Python

Update 2: See the wiki page for updates as we develop these