Pycon was wonderful this year. It was held at the Portland convention center which I like, and there were about 40% women at the conference; my perception was that around the same percentage of women were speaking. I credit Guido Van Rossum with requesting that the conference and the community become more inclusive (his goal is 50%). This is an amazing accomplishment in our field; my usual experience is in the low single digits. It has been shown that diverse companies make more money, and I think that the Python community will grow and become more successful because of this goal.

It seemed to me that the women felt comfortable enough to talk about what it is actually like to be a woman in this field. My take: it’s easy to think things have gotten better, and perhaps they have, but the situation is still pretty miserable and we have a long way to go (concerning diversity in general). This situation is holding the whole field back and I’m proud that the Python community is leading the way.

I’ve gone to many Pycons, including giving two keynotes in past years and speaking at Pycons in other countries. But this year I wanted to expand my experience by doing things that I haven’t before.

This included volunteering. I stumbled into bag-stuffing the first day. I did this once years ago, and the process was completely different. I think this is because volunteering is often more self-organized. In this case, it had evolved from people stuffing a bag one at a time to people cycling around holding their bag open and others dropping items into the open bag. It seemed much more efficient to me, and I found it very interesting to see how it had evolved.

I also signed up ahead of time to work at the registration desk and the green room (where speakers get ready to go to their rooms). Apparently the registration software is improved every year, to make it easier for inexperienced people (like me) to quickly become functional. Years ago, when I worked with the now-defunct Software Development conference (which couldn’t adapt to the Internet), one of the big, expensive problems they always had was registration. It was interesting to see how the open-source solution (at least, I think it was open source) had improved things, and will no doubt continue to do so.

In the green room, it turned out that one of the hosts for one of the speaking rooms had not shown up, and the green-room manager handed me a radio and said “you’re it.” (The radios were awkward and unfamiliar and I wish we could have just texted instead, or even better, used some kind of app that maintained status on a big board in the green room).

There are runners that walk people from the green room to the room where they speak. This seems like a simple job, but it’s very useful because speakers can then focus on mentally preparing themselves rather than worrying about (and potentially becoming flustered) finding their room. The runner also talks to the speaker and I think this can be calming. Pycon often has first-time speakers so this is an important role.

The room manager role which I was doing is for three consecutive talks in a single room. I introduced each speaker and then held up signs for 15, 10, 5 minutes and one for stopping. Each sign was held up 5 minutes before the actual time. I didn’t find out how this time-shifting practice had evolved but apparently it works. All three speakers finished with enough time for questions, at which point I ran around with a microphone. Often this is a problem when people start asking their question before the mike arrives, but for each talk I reminded people that this was being recorded and that folks watching on YouTube want to hear the question. I was also watching for the next questioner while the current question was being asked, and bringing the microphone to the new questioner during that time. That might have helped as well, but I think the biggest effect was simply reminding the audience about home viewers.

I enjoyed all three presentations, and also being involved with the production.

In the last year I’ve started to watch, as part of my research, presentations on YouTube, Vimeo, etc. It’s been a huge addition to the way I learn. I also realize what a big effect this must be starting to have on the rest of the world. Anyone with Internet can have the benefits of conference presentations. Pycon has always been a leader in this area (and they get the presentations up very quickly), and I was quite aware this year that I can see any presentation on YouTube. For that reason I decided to try to only do things that were not recorded, and to take advantage of physical presence.

Considering that I hold all open-spaces conferences, and that the first open-spaces (and lightning talks) I ever saw was at Pycon, it surprised me that I wasn’t more attuned to them. I attended three this year: One on freelancing, one on conference organization (where I was able to contribute from my experiences), and one called “Random Storytelling.” I attended this last one because my friend (and book designer) Daniel Will-Harris has invented a technique for creating stories—in fact, he’s in China right now setting up a system to teach it to drama students there. I thought I should look into this in case there were some ideas for him.

It turned out to be telling stories from your life. For me, it felt like I had suddenly stepped out of Pycon and into Burning Man, and I ended up telling a story about the first time I went to Burning Man. The session was a very connecting experience, and a group of us ended up going out to dinner.

The group included Audrey and Daniel Roy Greenfeld (second and third from left, and flanked by the ReadTheDocs guys), who met at Pycon and got married. Audrey created the Cookiecutter project which I spent some time with during sprints and created a basic introduction. Also at that dinner were the guys who do ReadTheDocs.org, which I also sprinted on.

For the first time at Pycon, I held two openspaces sessions, the first about Teal organizations and how we might start them, and the second to gather feedback for a book on Python concurrency, which looks very likely to be my next project.

The book session was extremely helpful. Kevin Quick came, who works at GoDaddy and helped create the Thespian Python actor system. This is in active use at GoDaddy and seems a likely candidate to demonstrate actors in the book.

My intent with the book is to expect Python proficiency but not to assume the reader knows anything about concurrency. This seemed to appeal to the group.

We also talked about print books vs. ebooks. I have been pushing for ebook-only publication, but this conversation set me back. Everyone in the group declared that, although they like ebooks well enough for “regular” books, for a programming book in particular, a print book is essential. One thing that impressed me was the description, which I have heard several times subsequently, of having a mental model of the physical book including where certain topics are located.

Wednesday night I had dinner with Guido Van Rossum and a group from Dropbox, also to discuss the book. Guido was the first person I told when I got the idea, to ask him if he thought it filled a need, and he was quite positive and said that just within Dropbox it would be good to have some way to educate people.

This group also declared they wanted a print version of the book. Both groups also expressed interest when I floated the idea of holding an openspaces conference (like the Winter Tech Forum) around Python concurrency, starting next summer.

After hearing this feedback and spending time during the Sprints with the ReadTheDocs group, I’ve started visualizing a scenario of publishing the book as it’s being developed (much as I did with the original version of Thinking in Java) on ReadTheDocs, then creating a print version for sale. If indeed people really want a print book, this model should produce enough income to pay for the project. If I enjoy it enough to create a seminar, then that would certainly make it worthwhile (I got rather burned out after giving C++ and Java seminars, but Python concurrency might be fun; in addition I’ve learned a lot of tricks over time that make seminars more enjoyable for both me and the participants).

ReadTheDocs provides different download formats (as well as just using it online), including HTML, PDF and Epub. During my time sprinting with them, we discussed the possibility of creating a process to produce a camera-ready PDF that could go directly to a print-on-demand service like LightningSource (which I use; they also make it effortless to switch to a press run and are owned by Ingram, which will handle distribution for you if you want). This process might become a business model to support ReadTheDocs: if you want to go to print, they could have several levels of paid help: basic (turn your docs into camera-ready PDF), self-publish (hand-hold you through the process but you remain the publisher) or ReadTheDocs might even become your publisher, recieving a portion of sales.

Sprinting

Finally, for the first time in all my Pycons I stayed for the sprints. This is one of those life experiences where learning something new can lead to regret that you haven’t been doing it all along, but oh well. And Guido pointed out that this might not be true, because I participated in what might have been the very first sprint after a Pycon in Washington DC, when a group of us went to the Zope Corporation in Virginia and were coached by Jim Fulton — Guido said this is the moment when Jim invented the sprint. But I probably wasn’t ready for it then.

People at the conference seem hesistant to join in, I think because they imagine that to sprint you have to understand the project and be good at something. My own experience disproves this. Indeed, much of the time my strength was my ignorance. I think the initial contact and onboarding experience is very important; if it’s not easy and positive it can turn people away. So if you are clueless about a project, just sit down at a sprint and declare that you’re going through the newbie install process—any project that I know of will be quite happy to have their onboarding checked, because they know it all too well to discover the missing parts.

Apparently the normal pattern is that about a quarter of the conference remains for the sprints (then trickles away over the days). The afternoon of the last day of the conference includes different projects giving tiny descriptions of what they are doing, followed by sprint coaching for new folks.

There is pre-sprint coaching, but you really can just show up and wander around and find some projects. You learn a ton regardless of whether you’re able contribute something, and it’s likely you can help in some way. If a project isn’t working for you, use the same “Law of Two Feet” as we have in open spaces and find another project.

ReadTheDocs

This was my first sprint. I’ve read a lot of documentation hosted on ReadTheDocs.org, but I didn’t know how it worked. I started by following the installation directions for those wanting to build documentation on ReadTheDocs. I learned a lot by doing this and by being able to ask questions of the creators (see the conversation about publishing earlier in this post). The place I helped was discovering a configuration problem that, as it turns out, had been plaguing them and wasting a lot of time, so they were elated to be able to fix it. This is what I mean—anyone can be helpful, even if it’s just by bumbling around and tripping over a problem.

On top of that, I feel like I have enough of a grasp of ReadTheDocs that I can start using it for my own projects.

Invoke

Build tools have always been a kind of hobby horse for me; at one point in the distant past I was pushing make to its limits, enough to see that its creators had given up in despair upon realizing that what they were really doing is creating a programming language.

Once you know that, you realize that the best solution is to start with an existing programming language, especially one like Python which is really good at manipulating everything. And Python decorators are perfect for annotating things to be tasks/targets.

I’ve made a couple of attempts to create a decorator-based build system but I’d much rather use something that someone else has spent a lot of time making. Invoke (Docs here and the github repository is here) by Jeff Forcier seems like it might be that tool. It’s quite thorough but it doesn’t yet do timestamp dependencies like make does. Although I couldn’t get close to making those changes myself, I was able to find a directed-acyclic-graph library that Jeff might be able to use for the task. As it was Python 2 and Jeff wants to use Python 2 and 3 libraries, I modified it to produce Pythondagger23 that works with both versions. I’m hoping it will be a step towards a more powerful Invoke.

Cookiecutter

When I found out what Cookiecutter does I decided it could be very important to me. I made a very introductory overview of the tool so others could quickly understand its value. They decided to use this as their official first introduction.

MicroBit Python

The MicroPython project had BBC MicroBits devices and asked us to create new demonstration examples.

My goal was just to get one working and to program something on the 5 by 5 grid of LEDs on the back, just as a kind of baseline test.

I went down a few wrong paths at first, probably because other parts of the project required creating a full set of build tools and flashing the MicroPython image onto the device. Fortunately I had help from (sorry I forgot your name) who coached me across installing parts of the system until he realized I just wanted to play with the LEDs, at which time he flashed my device from his system and we found that the MU Editor was the thing to get. We didn’t establish whether MU took care of everything necessary to make the connection to the device, or if some driver we had incidentally installed during our explorations was also necessary.

Here’s the code we ended up creating:

from microbit import *
import random

pixX = random.randint(0, 4)
pixY = random.randint(0, 4)

def step(n):
    r = n + random.randint(-1, 1)
    if r < 0:
        return 0
    if r > 4:
        return 4
    return r

while True:
    display.clear()
    display.set_pixel(pixX, pixY, 6)
    pixX = step(pixX)
    pixY = step(pixY)
    sleep(300)

This makes a dot that wanders around the 5x5 matrix and bumps into walls and corners. We didn’t submit it because it seemed too simple compared to the other examples, but if the project still wants to use it, feel free.

The final night for me was Saturday, and I went to dinner with Barry Warsaw and the MailMan sprinters, so Barry and I were able to catch up. He’s still very happy working with Canonical. We figured out that we had both worked on the Gnu Emacs C++ mode. I created the mode way back when I was working at the University of Washington School of Oceanography with Tom Keffer (who later used our work to start Rogue Wave, supplier of C++ libraries). However, I didn’t do very much with it; just got the basic mode working. Sometime later Barry came along and spent a lot of time making it useful, especially the very tricky reformatting, which I remember taking a shot at but then discovering what a big job it was. This all happened years before we met each other during the (relatively) early days of Python, but he remembers my name at the top of the authors list. It was fun to see how our paths had crossed so long ago without either of us knowing it.