Computing Thoughts Bruce Eckel's Programming Blog

Pycon 2017

This year I repeated my strategy of “Don’t go to any recorded sessions,” and also did more volunteering (one of these was at the green room, and again one of the session chairs failed to show up so you’ll see me introducing three of the talks).


In the past I’ve kind of stumbled into dinner groups, but not always. This time I made more of an effort and was rewarded with dinner friends every night. I think, however, that I’d like to make more of an effort to pre-plan these next year somehow, perhaps using some online tool. Admittedly this could reduce the chances for serendipity, but once a core of people are going to dinner it’s not usually hard to add others.

I wonder if there’s already an app for setting up group dinners. One of the hopeful things that happened is that I discovered that someone I have started to know is a web developer and we’ve agreed to do some experiments. I’ve been approached by any number of people over time who want to build web projects, but these are invariably people who have figured out how to configure a technology (often Wordpress, which I’ve come to loathe) and recommend that I use that particular technology. But in this case, I’ve got a real programmer who can adapt to my arcane needs. As a result, I’ve started imagining asking him to create all kinds of new experiments, and one of these could be a dinner planner app for conferences. The possibilities for this and other ideas are very exciting.

Hunting for Self-Guided Tutorials

For years, many people in Crested Butte have expressed to me an interest in learning to program, while declaring they know nothing about it. Perhaps the idea gestated long enough, or some other experience triggered this, but I recently began formulating a free class for new programmers that relies completely on self-guided tutorials. The benefit of this is that people do not get driven away by the class going either too fast or too slow; by its nature it adapts to the learning experience of each individual. In addition, once anyone has solved one of the steps, they can help their classmates solve that step (indeed, they are probably better at it, being closer to “beginner’s mind”).

The site is and might still be rough when you look at it, but the content is basically there, including links to the tutorials.

While at Pycon I talked to various folks who are in education to try to see if there were other, better tutorials and ended up with the ones you see on the site. Of course it’s an experiment so we’ll adjust it depending on how things work and new discoveries.

One of my goals is to create new coaches from the people that attend the class. There are other folks in town who can help and take over if I’m traveling, as well.

Open Spaces

Although I attended more open spaces than the ones described here, these were the ones I found most engaging.


This was convened by a young woman who had a poor experience in a workshop. From the context, I don’t think it was one of the pre-conference tutorials; I think it had happened awhile ago but it had left a mark and she needed to discuss it. Others in the session shared similar experiences.

I have not found these kinds of discussions at other conferences. One of the unique things about Pycon is that it (intentionally) has a very high percentage of women attendees and speakers. Guido’s stated goal is 50% and it seems like that number is fairly close in terms of speakers, and I might guess the women attendees could be as high as 35% or more. Minorities of various kinds are also becoming more represented. I wonder if one reason Python’s popularity keeps rising is its inclusiveness.

What Confuses You About Concurrency?

I held this session to gather more ideas to support the development of Concurrent Python. You can find my notes from this session here by scrolling down to that heading.

Improve Your Writing

This was requested directly to me by one person (who ended up not being able to make the session). I had actually submitted a session proposal for something similar, but it wasn’t accepted. We had about 10 people.

To keep it simple I gave three core ideas I think make the biggest impact on someone’s writing:

  1. Less is More. The more words you have, the more work your reader must do. Shorter sentences are easier to read and understand. Multiple editing passes are usually required to achieve short sentences.

  2. Active Voice. You can find some examples here, although these are rather basic. Perhaps we need another category of “super- active” or “direct” voice, as it’s usually possible to make your sentences even more immediate – although it takes even more work to get there. Active voice helps a lot with point 1, because active sentences are almost always shorter than passive sentences.

  3. Read It Aloud. This is a trick I learned from a friend many years ago. When you read silently, your mind tends to skip and skim. When you read every single word out loud, it forces you to scrutinize your prose. Problems jump out at you and you’re surprised you missed such glaring errors. It takes a lot of time (especially for book chapters) but it pays off.

I tried to keep the description of these points short and take questions. Afterward there was general Q&A and discussion.

Starting Teal Organizations

I never know what’s going to happen when I hold one of these sessions. Usually I get curious folks and it gives me practice in explaining the concepts, which you can find at Reinventing Business.

The turnout was larger than I expected, perhaps 8 folks, and we had a stimulating discussion. At this point I’m trying to discover the details, things not covered in the Reinventing Organizations book, such as bringing people into and out of the organization, payment, investing, and things like that. Frederic Laloux (the author) says these topics are different from one Teal organization to another and chooses not to cover them for that reason. But if you’re starting such an organization, you need those structures, even if you just use them as a starting point. I think I can make an important contribution to this field by discovering, collecting and passing on such information.

While I was in Portland I was able to attend a separate one-day open-spaces event around non-violent communication, and there I also held a “Starting Teal Organizations” session, which produced more good discussion.

Sprint days

Last year was my first experience sprinting (If you don’t include what was arguably the very first sprint, coached by Jim Fulton at Zope Corp in Virginia after one of the D.C. Pycons – but I can’t remember much from that one; I do know he tried to teach us Git). Then I went to many different projects and contributed a little to each one, primarily either documentation or testing their onboarding process, but in a few cases I added code. I learned a great deal through this sampling process, but this year I ended up spending all three days (and wishing I had the fourth) on a single project: Beeware.

I’ve been experimenting with and using a small decorator framework for building command-line applications, much like (for example) Click although mine is much simpler. I have a friend or two who would like some automation, so I’ve been imagining that a command-line system would work for them.

Then a friend pointed out that most people have no idea what the shell is, and are unfamiliar with command-line applications. At Pycon it occurred to me that it might be possible to use the same decorator approach, but instead of producing a command-line option, the decorator would insert a menu item in a windowed program, and thus be easier and more familiar for the vast majority of users, while at the same time making the creation of such a program far easier. I went to the Beeware booth and ask the creator, Russell Keith-Magee (whom I had met and spent time with at PyCarribbean), if he thought this was possible and he said yes.

It turns out his answer was a bit … premature. When you go to the Beeware Site, it can be hard to discover where to start. There’s a reason for that: this is a collection of projects, so you must first (A) Know that and (B) Decide what project fits your needs. And even then, some parts of the project are still more visionary than completely fleshed out, so you won’t always find a tutorial or example of what you’re looking for.

I quite like the vision of BeeWare: make Python work everywhere. I think it will get there. We even had some discussions about funding so Russell (and ideally other programmers) could work on it full time, and get it there faster. But be warned that at this writing the vision is only partly there.

The sub-project that met my needs is called Toga, with Docs here. The first thing I discovered was that there were menus for the Mac and I think Linux, but not for Windows. Thus, my effort was spent on learning the Toga architecture and figuring out how to add menus for Windows apps. This was tremendously educational but I’m still not close to creating my “decorators for menus.” However, I’d rather continue working on Beeware until it gets to the point where I can, rather than building something from scratch. This way I’ll produce results that works across platforms, by taking advantage of the Beeware architecture.

Virtual Environments Revisited

Setting up the virtual environment for this project was one of my learning experiences. When you install a package that you want to modify and test, it turns out you must make it editable using the -e flag, as in pip install -e. Otherwise your changes won’t be used, and only the original installation will ever be seen when you run your program. Without knowing this I experienced some frustration until Russell walked me through it. If I hadn’t been doing this in a sprint, I probably would have given up.

In the process, I ended up making multiple installations and building the virtual environment multiple times. I also realized that I sometimes hesitate to build a virtual environment because I must look up and re-learn the configuration commands, and running the activate script is always a bother. If only we could get the computer to do annoying, repetetive things for us! Here’s a Windows batch file that does the trick (anyone with basic shell skills can create the equivalent for Mac/Linux):

@echo off
rem venv.bat

rem Works if you're outside the starting directory:
if defined VIRTUAL_ENV (
) else (
  rem Only works inside starting directory, otherwise
  rem creates a new virtual environment:
  if exist virtualenv (
  ) else (
    python -m venv virtualenv

I’m choosing to call my virtual environment directory virtualenv, and so can use that directory’s existence to indicate whether there’s an installed virtual environment.

You can place venv.bat somewhere in your Windows PATH and use it anytime you want to create and use virtual environments. Note that for it to work correctly, you must call it from the directory where the virtualenv subdirectory will be created or already exists.

activate.bat sets VIRTUAL_ENV and deactivate.bat clears it, so VIRTUAL_ENV means that the virtual environment has been activated. This way, running venv just turns it on if it’s off, and off if it’s on, so that’s two less commands I need to remember.

If the virtual environment doesn’t exist, it is created and activated. But while working on Toga, I needed the special -e editable installations in that new environment, so I created a local venv.bat and added the following lines after the virtual environment creation and activation:

  cd src\core
  pip install -e .
  cd ..\winforms
  pip install -e .
  cd ..\..
  pip install -e .


The rest of the time I sought out experiences and interactions. And this is a place where the smart phone really has enhanced my life: whenever anyone said something interesting, I pulled out the phone and entered it in a list in Google Keep. I used to write notes and then set them aside and forget them, but entering them in Keep and knowing they will show up on all my other devices seems to really make the key difference.

Here are my notes, in no particular order:

The Concurrent Python Project

I’ve started working on a big, ambitious Python project: a book called Concurrent Python which assumes you know Python but that you don’t know anything about concurrency. I considered writing yet another introductory book, but realized there are already plenty of good ones and that I wouldn’t contribute much there. Concurrency, however, is a topic I’ve struggled with over the years and I know I could add some value to that discussion. It also presents opportunities for much more interesting training, conferences, speaking and consulting (these days I’m far more invested in discovering stimulating experiences, instead of just any experiences).

The first chapter has mostly been taken from the Concurrency chapter in On Java 8, which is now available in beta (as in “nearly finished”) form but still requires a little more work. The Atomic Kotlin book has also inserted itself in my schedule. So don’t expect a lot of progress right now, although I am thinking about it and watching for ideas, tools and libraries which I’m capturing in the file – feel free to make pull requests or add issues if you think something belongs there.