The Zen of Python

2025-10-10

This is a daily report personally published by PyCon JP 2025 Chair @nishimotz.

PyCon JP 2025 was held September 26–28 at Hiroshima International Conference Center. Thank you for your participation and support.

Why the Zen of Python matters

I frequently returned to the Zen of Python when making decisions and running the team. It is a compact set of aphorisms you can see with python -m this, and it is also quoted in the official documentation. Below is the original text, followed by how I applied it to event operations.

The Zen of Python (original / Tim Peters)

The Zen of Python, by Tim Peters

Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren’t special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one– and preferably only one –obvious way to do it. Although that way may not be obvious at first unless you’re Dutch. Now is better than never. Although never is often better than right now. If the implementation is hard to explain, it’s a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea – let’s do more of those!

How it helped operations

Beautiful is better than ugly

We were able to care about the beauty of the logo and website, which was a happy outcome.
We could have insisted on “beauty” in more places.

Explicit is better than implicit

Over‑communicating explicitly matters. I asked the team to do so repeatedly, and I myself was also asked to do the same at times.
In a meeting just before the event, we asked core members to disclose their anxiety levels on an 11‑point scale. Interestingly, the more experienced the member, the lower the anxiety.
You cannot provide too much explicit information to participants and speakers.

Simple is better than complex

Some processes (participant management, venue usage) were not as simple as they could have been.

Complex is better than complicated

To reduce MC workload, we aligned rooms for the English track—accepting some complexity without making operations tangled.

Flat is better than nested

The team structure could have been flatter.
We intended to run mostly on the B2 floor, but staff often got confused about the relationship with B1 and the first floor.
In early preparation it is difficult to gather many organizers; in that case, staying flat longer was a viable option. I hesitated and lacked confidence, so I followed precedent and stood up the teams about six months before the event.

Sparse is better than dense

Because the number of participants was not too high, the venue felt spacious. Participants with baby strollers left a strong impression.
The party venue became somewhat dense.

Readability counts

We did some things well, but there were confusing points—for example, the hashtag for the Dahlia 1 room appeared as “…2” in places.
A participant with visual impairment told us they could prepare a lot in advance by reading the website, which was great to hear.
We worked on English information, but Japanese information and content may actually have been lacking.
The “No Photo” strap was not easily distinguishable from the regular strap—a point of reflection.

Special cases aren’t special enough to break the rules

Without going into detail, we had internal discussions to minimize exceptions, which should have contributed to transparency.

Although practicality beats purity

Constraints in budget and manpower inevitably existed, and some “pure” wishes could not be realized.

Errors should never pass silently

Triage of inquiries/tickets/emails did not go smoothly. Thanks to everyone’s efforts and support, we managed to get through it.
I tried to grasp situations where organizers were not functioning well, and tried to avoid dissatisfaction or regret even if things did not work out.
The existence of a chair team that supported the chair’s own difficulties was significant.

Unless explicitly silenced

Concerns about CoC violations among organizers were addressed promptly.
I am grateful that no major problems occurred within the team or the wider community.

In the face of ambiguity, refuse the temptation to guess

We received a request for information regarding a wheat allergy. We were not sure if the person would attend the official party, but we confirmed at the venue and provided information (we could not accommodate the food itself).
For accommodations such as meals, we did not provide information when there were no prior requests (we gave up on ad‑hoc adjustments).

There should be one—and preferably only one—obvious way to do it

We unified the basic flows for registration, inquiries, and payments.
In hindsight, we made some people (e.g., invited speakers) take unnecessary steps.
For organizers’ work, especially payments, we asked everyone to follow a unified manual (this continues post‑event).

Although that way may not be obvious at first unless you’re Dutch

Explanations of how organizers should work, and information for newcomers, could have been more concrete.

Now is better than never

We aimed to publish drafts early and invite feedback.

Although never is often better than right now

We repeatedly emphasized to organizers that actions related to the Code of Conduct needed to be taken with care.

If the implementation is hard to explain, it’s a bad idea

When “hard to explain” was detected in meetings or reviews, we redesigned.
It did take time to shape the fuzziness that inexperienced organizers felt.

If the implementation is easy to explain, it may be a good idea

We prioritized proposals where consensus quickly emerged from a simple explanation.

Namespaces are one honking great idea — let’s do more of those!

We basically followed the established practice in PyCon JP for Google Docs and Slack.
Communication in English with organizers was a persistent challenge; we eventually created prj-international, an English‑only channel.
Instead of the long‑used random channel, we intentionally created 2025-random, and ultimately positioned it for “ongoing introductions”.
Not exactly a namespace issue, but inconsistent display names across Slack, Jira, Zoom, and connpass made coordination hard from the chair’s perspective. PyCon JP Slack has a “name++” kudos culture, but because accounts were hard to match, I refrained from using it actively.

Closing

I realized that the Zen of Python is wisdom for “Python community‑ness” beyond software development. That was one of my learnings as chair.

References: The Zen of Python (import this, or see the Python official documentation)

Update History

2025-10-10: First published