Planet Python

Last update: August 26, 2026 09:48 PM UTC

August 26, 2026

---

Talk Python to Me

#560: Building a Research OS: From Django to 30,000 Samples

In 2020, a gastroenterologist in Glasgow did the math on his new research study and came up with 30,000 samples, arriving over two years from three cities and a dozen hospitals. He asked around about how researchers keep track of that. The answer was Microsoft Excel. Shaun Chuah had written some HTML by hand in Notepad back in high school and that was about the whole of his programming experience, so he opened the Django tutorial and started reading. Six years later that app is Foundry120, holding 10 terabytes of clinical and genomics data with an agentic AI running on top of it.<br/> <br/> <strong>Episode sponsors</strong><br/> <br/> <a href='https://talkpython.fm/sentry'>Sentry Error Monitoring, Code talkpython26</a><br> <a href='https://talkpython.fm/course-certifications'>Talk Python Courses</a><br> <a href='https://talkpython.fm/training'>Talk Python Courses</a><br/> <br/> <h2 class="links-heading mb-4">Links from the show</h2> <div><strong>Guest</strong><br/> <strong>Shaun Chuah</strong>: <a href="https://github.com/shaunchuah?featured_on=talkpython" target="_blank" >github.com</a><br/> <br/> <strong>Up and Running with Rust Course</strong>: <a href="https://training.talkpython.fm/courses/up-and-running-with-rust" target="_blank" >talkpython.fm</a><br/> <br/> <strong>Foundry120</strong>: <a href="https://www.foundry120.com/?featured_on=talkpython" target="_blank" >www.foundry120.com</a><br/> <strong>Designing Data Intensive Applications</strong>: <a href="https://www.oreilly.com/library/view/designing-data-intensive-applications/9781491903063/?featured_on=talkpython" target="_blank" >www.oreilly.com</a><br/> <strong>Microsoft Foundry</strong>: <a href="https://ai.azure.com/home?featured_on=talkpython" target="_blank" >ai.azure.com</a><br/> <strong>ChatIBD</strong>: <a href="https://www.chatibd.com/?featured_on=talkpython" target="_blank" >www.chatibd.com</a><br/> <strong>Blog</strong>: <a href="https://shaunchuah.github.io/?featured_on=talkpython" target="_blank" >shaunchuah.github.io</a><br/> <strong>@drshaunchuah</strong>: <a href="https://x.com/drshaunchuah?featured_on=talkpython" target="_blank" >x.com</a><br/> <strong>github.com/shaunchuah</strong>: <a href="http://github.com/shaunchuah?featured_on=talkpython" target="_blank" >github.com</a><br/> <br/> <strong>Watch this episode on YouTube</strong>: <a href="https://www.youtube.com/watch?v=zwL1-VQMUo0" target="_blank" >youtube.com</a><br/> <strong>Episode #560 deep-dive</strong>: <a href="https://talkpython.fm/episodes/show/560/building-a-research-os-from-django-to-30-000-samples#takeaways-anchor" target="_blank" >talkpython.fm/560</a><br/> <strong>Episode transcripts</strong>: <a href="https://talkpython.fm/episodes/transcript/560/building-a-research-os-from-django-to-30-000-samples" target="_blank" >talkpython.fm</a><br/> <br/> <strong>Theme Song: Developer Rap</strong><br/> <strong>🥁 Served in a Flask 🎸</strong>: <a href="https://talkpython.fm/flasksong" target="_blank" >talkpython.fm/flasksong</a><br/> <br/> <strong>---== Don't be a stranger ==---</strong><br/> <strong>YouTube</strong>: <a href="https://talkpython.fm/youtube" target="_blank" ><i class="fa-brands fa-youtube"></i> youtube.com/@talkpython</a><br/> <br/> <strong>Bluesky</strong>: <a href="https://bsky.app/profile/talkpython.fm" target="_blank" >@talkpython.fm</a><br/> <strong>Mastodon</strong>: <a href="https://fosstodon.org/web/@talkpython" target="_blank" ><i class="fa-brands fa-mastodon"></i> @talkpython@fosstodon.org</a><br/> <strong>X.com</strong>: <a href="https://x.com/talkpython" target="_blank" ><i class="fa-brands fa-twitter"></i> @talkpython</a><br/> <br/> <strong>Michael on Bluesky</strong>: <a href="https://bsky.app/profile/mkennedy.codes?featured_on=talkpython" target="_blank" >@mkennedy.codes</a><br/> <strong>Michael on Mastodon</strong>: <a href="https://fosstodon.org/web/@mkennedy" target="_blank" ><i class="fa-brands fa-mastodon"></i> @mkennedy@fosstodon.org</a><br/> <strong>Michael on X.com</strong>: <a href="https://x.com/mkennedy?featured_on=talkpython" target="_blank" ><i class="fa-brands fa-twitter"></i> @mkennedy</a><br/></div>

August 26, 2026 08:04 PM UTC

---

Rodrigo Girão Serrão

Why OOP exists

Learn the fundamental principles behind OOP and how they connect to the syntax of Python.

Introduction

Welcome! This article will teach you the core ideas behind object-oriented programming, commonly known as OOP. This is the article I wish I read many years ago, when I was first learning about OOP in Python.

If you're new to OOP, this article will explain why OOP exists, how it works, and how to work with OOP in Python. If you think you already know OOP, this article will change the way you think about programming and Python.

Code is about real-world things

Let me tell you about a programming project I had to do in college where you had to write a library management service. We were expected to work in pairs and I was paired with my good friend Tito.

Tito and I sat down and started going through the problem statement, figuring out what we needed to implement. We got to a point where Tito turned to me and said:

“It's not obvious to me what's the best way to represent a book in our program. Maybe you can start implementing the search functionality and I'll think about this for a while.”

The search functionality was a set of functions that the problem statement required us to implement:

• find_by_title(catalog, search_term): returns a sublist with the books whose title contains the given search term
• find_by_genre(catalog, genre): returns a sublist with the books of the given genre
• find_by_author(catalog, author): returns a sublist with the books written by the given author

I nodded, but then I thought about it for a second. If I don't know anything about how to work with books, there's no way I can implement these three functions. Tito agreed with me and told me he'd provide me with these functions:

• book_title(book): returns the title of the given book
• book_genre(book): returns the genre of the given book
• book_author(book): returns the author of the given book

He told me to think of these functions as auxiliary functions that he would implement. I didn't have them yet, but I could write my search functions trusting he'd implement them correctly.

Now, think about it for a second. Can you implement the functions find_by_title, find_by_genre, and find_by_author, using the auxiliary functions that Tito will implement? How would you go about it?

I worked on it for a bit, and eventually used a list comprehension to define the function find_by_title:

def find_by_title(catalog, search_term):
    search_term = search_term.casefold()
    return [
        book
        for book in catalog
        if search_term in book_title(book).casefold()
    ]

The function find_by_title goes through the list of books called catalog with a loop and uses the auxiliary function book_title to retrieve the title. It then uses casefold to perform a case-insensitive search.

Something worth...

August 26, 2026 02:01 PM UTC

---

LernerPython blog, from Reuven Lerner

MIT just called for an educational revolution

As someone who teaches Python programming for a living, I’ve spent the last few years wrestling with the educational implications of AI. I’m changing everything I do to adjust to our new AI reality, experimenting with new ideas, including my AI-based Socratic tutor (https://practice.lernerpython.com/). I keep what works, throw away what doesn’t, and then try the next thing. I’ve never been more challenged as a business owner. And yet, I’ve never been more excited about being an instructor.

What about universities? I’ve said for a while that they’ll also need to change, but that they cannot do so nearly as quickly as I can. They’re big and bureaucratic, and have to answer to donors, staff members, students, parents, and governments. It’ll take years for them to figure out what they want to do, and how to do it.

And then, last night, I received e-mail from Sally Kornbluth, the president of MIT, with a message addressed to all MIT students, faculty, staff, and alumni. The subject, “AI and education: A watershed moment for MIT,” was quite the understatement.

Kornbluth announced a report from an ad-hoc committee on AI in education (https://aiandeducation.mit.edu/report/). It’s the clearest, deepest, and most profound take I’ve yet read on the subject. It doesn’t hold back, spelling out the good and the bad. I’m still absorbing the full impact of what they wrote — and they wrote a lot. But the report — which I expect will be given formal backing in the near future — has, more or less, called for a complete revolution in how instruction works. And they’re willing to take the lead in trying new approaches, technologies, and assessments, both for their own future and for the future of university education.

Maybe a university can’t change as quickly as my one-person business. But the report sounds urgent and focused, and I think we should expect MIT to change as quickly as any large organization can. The report even recognizes the slow pace at which curricular changes are normally made, and encourages departments to allow for curricular experimentation without onerous bureaucracy.

Among the many smart, important points they make:

• Classes are going to change. Instructors will need to re-assess what people need to get out of a course, and think about how AI can be integrated into it. Whether that means developing new course-specific tools or having students use AI to advance their knowledge and understanding will depend on the course and the instructor. But they are actively encouraging instructors to think deeply about what they are really trying to teach, and what tools might help them to achieve that more easily.
• Embracing apprenticeship. You could argue that graduate school (and to a lesser degree, undergraduate studies) are already an apprenticeship program, in which aspiring researchers learn from their more experienced professors and peers. AI threatens this model to some degree, enticing researchers to use agents to accomplish a task, rather than bringing on someone who might take longer or make mistakes. As they say in their report, “Using research as an opportunity for learning-by-doing may produce seeming ‘inefficiencies,’ but that’s a feature, not a bug.” Struggling and working through problems is an inherent part of the learning process.
• Education is about the process of learning. I keep meeting people (students and professionals) who say that they ask AI to write papers and essays for them, because they “know it anyway,” and this is just a faster way of producing the same text they would have written on their own. This is, of course, nonsense — as the saying goes, “writing is thinking,” and anyone who writes knows that as you struggle over how best to make your argument, you’re learning more than any classroom could teach. As the report says: “Getting the right answer from a chatbot can create the illusion of learning – but it can also trigger ‘cognitive surrender’, where students fall back on AI at the first hint of struggle.” They similarly say, “All of us who teach at MIT will need to be prepared to help students understand both that the process of education is necessarily a productive struggle, and that the most important product of their education is not a GPA or a diploma but themselves: their personal growth and intellectual maturity and the development of their own imagination, insight, and judgment.”
• Assessment will need to change. The report says, “MIT should take this opportunity to consider what role grades play in our overall system, and if the current approach could be improved.” The old standards of homework assignments and exams might not be the best ways to know whether a student has really mastered the material. I’ve been saying for a while that it might be time to bring back oral exams, either alone or alongside project-based learning. The report discourages the use of AI detectors, which have a history of being unreliable and discriminatory. Plus, “stepping up ‘policing’ around AI use builds an adversarial atmosphere of distrust between instructors and students, which understandably hurts students’ motivation and morale.”
• Constructionism has its moment? I feel like all of the educators who spoke of project-based, constructivist, and constructionist approaches for decades might finally have their moment in the sun. The report points to the potential for individualized attention and instruction that AI can uniquely provide — and which would go hand-in-hand with the project-based approach. Seymour Papert developed constructionism at MIT, calling for a revolution in education around personalized, project-based, technological learning. I’m an MIT alumnus, a constructionist at heart, and I did my PhD in learning sciences under one of Papert’s students. So watching Papert’s own institution consider a revamp of education around his principles is, for me, delicious.
• Ethics are crucial. We’re now in an era where anyone can generate a decent-sounding article within minutes. The report emphasizes that a culture of transparency around the use of AI is and will continue to play a critical role. This is true not just for students, but also for instructors and researchers, who will be expected to clearly state where and how they used AI in their work. The report says, and I believe rightly so, that using AI is just fine — but you need to be specific about how you use it, and what you did with it. They also point to the need for equitable access to AI, ensuring that all members of the MIT community can use this technology, not just those who can most easily afford it.

The report also emphasizes, repeatedly, the importance of human interactions in all of this. AI, more even than phones and the Internet, has a tendency to push people to hole up by themselves, rather than interact with others. (The report points to fewer in-person study groups, and a drop in the number of students coming to office hours.) And it is those interactions that are not only at the heart of research, science, and learning, but of human existence. They stress the need for incorporating “social learning” into projects, and to encourage people to work together. As they say, “Instructors should intentionally structure such interactions to achieve desired learning objectives and maintain quality, even in large classes.”

This report isn’t the last word on AI and education, and it isn’t meant to be. A year from now, we’ll probably see parts that were prescient, and other parts that were misguided (if well meaning). But it’s the first time I’ve seen a major university announce a plan to reshape the entire university’s educational approach around our new reality. This is an ad-hoc committee, and thus doesn’t have any official standing. But the fact that MIT’s president sent it out to every member of the MIT community tells me that this is way beyond a simple committee. I expect that MIT will put serious effort (and money) behind the changes needed to see these things through.

If you’re an educator, then you owe it to yourself, and to your students, to read this report. And then to re-assess what you do, starting with the principles that MIT is using to evaluate itself, as the first stage of what’ll likely be a revolutionary transformation.

The post MIT just called for an educational revolution appeared first on LernerPython.

August 26, 2026 12:14 PM UTC

---

Python Bytes

#493 CalVer and LTS

<strong>Topics covered in this episode:</strong><br> <ul> <li><strong><a href="https://github.com/chr0nzz/traefik-manager?featured_on=pythonbytes">Web UIs for your reverse proxy</a></strong></li> <li><strong>Wagtail 8.0 is hot off the presses</strong></li> <li><strong>RISC-V is now officially supported by CPython</strong></li> <li><strong><a href="https://www.djangoproject.com/weblog/2026/aug/10/annual-release-cycle?featured_on=pythonbytes">Django’s annual releases make every version an LTS</a></strong></li> <li><strong>Extras</strong></li> <li><strong>Joke</strong></li> </ul><a href='https://www.youtube.com/watch?v=_hmos9eMyDY' style='font-weight: bold;'data-umami-event="Livestream-Past" data-umami-event-episode="493">Watch on YouTube</a><br> <p><strong>About the show</strong></p> <p>Sponsored by <strong>Logfire from Pydantic</strong>: <a href="https://pythonbytes.fm/logfire">pythonbytes.fm/logfire</a> <strong>Connect with the hosts</strong></p> <ul> <li>Michael: <a href="https://fosstodon.org/@mkennedy">Mastodon</a> / <a href="https://bsky.app/profile/mkennedy.codes?featured_on=pythonbytes">BlueSky</a> / <a href="https://x.com/mkennedy?featured_on=pythonbytes">X</a> / <a href="https://www.linkedin.com/in/mkennedy/?featured_on=pythonbytes">LinkedIn</a></li> <li>Calvin: <a href="https://sixfeetup.social/@calvin?featured_on=pythonbytes">Mastodon</a> / <a href="https://bsky.app/profile/calvinhp.com?featured_on=pythonbytes">BlueSky</a> / <a href="https://x.com/calvinhp?featured_on=pythonbytes">X</a> / <a href="https://www.linkedin.com/in/calvinhp/?featured_on=pythonbytes">LinkedIn</a></li> <li>Show: <a href="https://fosstodon.org/@pythonbytes">Mastodon</a> / <a href="https://bsky.app/profile/pythonbytes.fm">BlueSky</a> / <a href="https://x.com/PythonBytes?featured_on=pythonbytes">X</a> Join us on YouTube at <a href="https://pythonbytes.fm/stream/live"><strong>pythonbytes.fm/live</strong></a> to be part of the audience. Usually <strong>Tuesday at 7am PT</strong>. Older video versions available there too. Finally, if you want an artisanal, hand-crafted digest of every week of the show notes in email form? Add your name and email to <a href="https://pythonbytes.fm/friends-of-the-show">our friends of the show list</a>, we'll never share it.</li> </ul> <p><strong>Michael #1: <a href="https://github.com/chr0nzz/traefik-manager?featured_on=pythonbytes">Web UIs for your reverse proxy</a></strong></p> <p>Traefik, nginx, and Caddy all sit in front of a lot of self-hosted infrastructure, and all three are configured by hand-editing files. Three active projects put a control plane on top: <a href="https://github.com/chr0nzz/traefik-manager?featured_on=pythonbytes">Traefik Manager</a> (Python + Flask), <a href="https://github.com/0xJacky/nginx-ui?featured_on=pythonbytes">Nginx UI</a> (Go + Vue), and <a href="https://github.com/zackwag/caddy-ui?featured_on=pythonbytes">caddy/ui</a> (React + Node). All three are additive rather than replacements - none of them take ownership of your config away from you - which is the part that matters when the thing has write access to production routing.</p> <ul> <li><strong>Traefik Manager</strong> is the Python one: Flask 3.1 and Gunicorn for the control plane, a lightweight Go agent for remote instances, currently v1.10.0 with an Android companion app.</li> <li><strong>Nginx UI</strong> is a single Go binary at 11.3k stars, with a block-style config editor, an Ace editor doing LLM completion on nginx syntax, and an MCP server so agents can drive it.</li> <li><strong>caddy/ui</strong> runs as two containers next to your existing Caddy, reads and writes your Caddyfile directly, and uses Caddy's <code>/adapt</code> API to validate before reload - no Docker socket required.</li> <li>Each one edits the config the underlying server already reads, so your files stay the source of truth and you can drop the UI without unwinding anything.</li> <li>Undo is a first-class feature across all three - timestamped backups with optional Git history, config version compare and restore, Caddyfile snapshots with one-click rollback.</li> <li>Observability is where they diverge: Traefik Manager does CrowdSec and a visual route map, Nginx UI does server metrics, caddy/ui streams access logs over SSE and pulls p50/p95/p99 off Caddy's Prometheus endpoint.</li> <li>Maturity spread is wide - Nginx UI has 11.3k stars, caddy/ui has 4 and was built in a single Claude session - and caddy/ui ships with auth off by default, so set <code>CADDY_UI_USER</code> and <code>JWT_SECRET</code> before it goes anywhere near a public interface.</li> </ul> <p><strong>Calvin #2: Wagtail 8.0 is hot off the presses</strong></p> <p>Link: https://github.com/wagtail/wagtail/releases/tag/v8.0</p> <ul> <li>Custom base page models are now supported, so projects aren't locked into subclassing Wagtail's Page as shipped (Matt Westcott).</li> <li>New v3 REST API handles both read and write CMS operations, a first for Wagtail's API.</li> <li>A global registry for permission policies, plus full customizability for the remaining page views via PageViewSet.</li> <li>AVIF and WebP images are no longer auto-converted to PNG by default, a real behavior change to watch on upgrade.</li> <li>Five security fixes: page admin API restrictions, document identification by SHA1 hash, descendant collections in the Documents/Images API, snippet copy permissions, and the page translation endpoint.</li> <li>Formalized Django 6.1 support, and CI now runs on uv with a lockfile.</li> </ul> <p><strong>Sponsor</strong>: <a href="https://pythonbytes.fm/logfire">Logfire from Pydantic</a></p> <p>Your AI agent failed at 2am. Was it the model? A tool call? The database? Most observability tools can't tell you, because they only see part of your stack. Pydantic Logfire sees all of it. One trace across your agents, LLMs, APIs, and database. Down to the infrastructure: services, Kubernetes, and hosts. It's built on OpenTelemetry, with SDKs for Python, TypeScript, and Rust, and it works with any OTel-compatible language. Every prompt, token count, and cost, right next to your vector searches and API calls. You query everything with Postgres-compatible SQL. And so can your coding agent, through the Logfire MCP server. Stop guessing. Read the trace. Pydantic Logfire. AI, it's still just engineering. Visit <a href="http://pythonbytes.fm/logfire">pythonbytes.fm/logfire</a> today and sign up today. Get 10M records free every month, no card required. You can even click “Onboard with your coding agent” to copy a prompt to have claude or codex integrate Logfire into your app. Thanks to Pydantic for supporting the show.</p> <p><strong>Calvin #3: RISC-V is now officially supported by CPython</strong></p> <p>Link: https://blog.python.org/2026/08/riscv-now-officially-supported/</p> <ul> <li>CPython added RISC-V as a tier 3 platform under PEP 11, specifically the 64-bit Linux target riscv64-unknown-linux-gnu.</li> <li>RISC-V is an open ISA anyone can implement, unlike x86 and ARM, and its market is projected to quadruple by 2032.</li> <li>The RISE Project donated real RISC-V machines for buildbots; the author's work was funded by a Sovereign Tech Agency fellowship.</li> <li>What changes: the port is now a maintained compatibility target, so CPython changes are less likely to quietly break it. What doesn't: no <a href="http://python.org/?featured_on=pythonbytes">python.org</a> installers, no binary wheel parity for native extensions.</li> <li>Next up: RISC-V runners in CPython CI for pre-merge feedback, then a push toward tier 2, plus architecture-specific optimizations.</li> <li>The ask is testing. If you have RISC-V hardware, build CPython, run your test suite, file what breaks. Tier 3 is the weakest support tier. PEP 11 tier 3 requires a core developer contact and a buildbot, but failures on tier 3 platforms explicitly do not block a release. Saying "ongoing CI/testing expectations" oversells it. The honest bit is "someone is now on the hook for it, and breakage gets noticed," not "it's guaranteed working." Worth the caveat that this is Linux SBCs, not microcontrollers. A VisionFive 2 counts, an ESP32-C6 or Pico 2 does not. Those are 32-bit non-Linux parts where MicroPython is still the answer.</li> </ul> <p><strong>Michael #4: <a href="https://www.djangoproject.com/weblog/2026/aug/10/annual-release-cycle?featured_on=pythonbytes">Django’s annual releases make every version an LTS</a></strong></p> <p>Starting with Django 2028, Django will move to one January feature release per year, adopt calendar-based version numbers, and support every release for three years. The old distinction between standard and LTS releases disappears, giving teams a predictable annual upgrade path that aligns more closely with Python’s own release and support cadence.</p> <ul> <li>Every Django release becomes the safe, long-supported choice, so teams no longer need to wait for a specially designated LTS version or absorb two years of changes at once.</li> <li>Each release gets one year of mainstream bug fixes followed by two years of security and data-loss fixes.</li> <li>New releases support the three latest Python versions and add the next Python release during their first year.</li> <li>Calendar versioning begins with Django 2028, followed by Django 2029 and so on.</li> <li>Three Django versions will be supported at any time, giving third-party packages a clearer rolling target.</li> <li>Nothing changes before 2028, and existing commitments for Django 5.2 LTS and 6.2 LTS remain in place.</li> </ul> <p><strong>Extras</strong></p> <p>Calvin:</p> <ul> <li>The Python docs now document the time complexity of built-in types https://docs.python.org/3.16/library/time-complexity.html</li> <li>Thinking in Python - Bruce Eckel's free book https://thinkinginpython.com/ Michael:</li> <li><a href="https://gist.github.com/mikeckennedy/2f45134b3281b3ccf2729e3a7c21ea4f?featured_on=pythonbytes">prune_uv_pythons.py</a> - Prune uv-managed Python installs, keeping only the newest patch per minor version <ul> <li>Runs automatically in my system “upgrade” script: <a href="https://blobs.pythonbytes.fm/upgrade-output-2026.png?cache_id=96100e">upgrade-output-2026.png</a></li> </ul></li> <li>Started using <a href="https://ollama.com/search?c=cloud&featured_on=pythonbytes">Ollama cloud models</a> for my Hermes assistant. Thanks to Jeff Triplett I learned they are not just local models.</li> </ul> <p><strong>Joke: <a href="https://www.talisman.org/tao/?featured_on=pythonbytes">The Tao of Programming</a> -</strong> Book Seven: Corporate Wisdom</p>

August 26, 2026 01:07 AM UTC

August 25, 2026

---

Django Weblog

PyCharm &amp; Django Fall Fundraiser

We are back with our friends at JetBrains for the second of the two "Buy PyCharm, Support Django" fundraisers we run together each year. Our spring campaign was the first. It remains one of the most impactful ways the community can support the Django Software Foundation.

Your support of this campaign helps fund key initiatives such as:

• A Django Executive Director: Funding our first Executive Director, who will lead fundraising, operations, and community coordination for the Foundation.
• Django Fellows: Ensuring the rapid development and maintenance of Django.
• Django Girls: Making the Django community accessible to programming beginners around the world.
• International events and conferences: Supporting DjangoCons, one-day events, meetups, and other community gatherings around the world.
• Djangonaut Space: Onboarding new contributors to the Django project.

The Executive Director role is new, which is why this campaign matters more than usual. The DSF raises around $300,000 a year today. Reaching $500,000 is what makes a full-time Executive Director sustainable, and campaigns like this one are how we close that gap. If leading that work sounds like you, applications are open until September 14, 2026.

How the campaign works

The campaign runs until September 7, 2026. When you buy a new PyCharm license or renew an existing one at a 30% discount through our special campaign link, JetBrains will donate an equal amount to the Django Software Foundation. You get a professional IDE that is trusted by Django developers worldwide, and the DSF receives a matched contribution.

Get 30% off PyCharm, Support Django

Thank you, JetBrains

Beyond this campaign, JetBrains contributes to the Django ecosystem in ways that are easy to overlook but hard to overstate. The 2026 Django Developers Survey was published earlier this summer, and along with the Python Developers Survey, it gives the entire community a clearer picture of where Django and Python are heading each year.

"JetBrains is one of our most generous fundraising partners year after year, helping us sustain and grow the Django ecosystem. We deeply appreciate their commitment, leadership, and collaboration."

Jeff Triplett, President, Django Software Foundation

Thank you to JetBrains for another year of partnership, and thank you to everyone who participates in this campaign. Together, we can ensure the continued success and growth of the framework we all rely on.

Other ways to donate

If you would like to donate in another way, especially if you are already a PyCharm customer, here are other ways to donate to the DSF:

• On our website via credit card
• Via GitHub Sponsors
• Benevity Workplace Giving Program - If your employer participates, you can make donations to the DSF via payroll deduction.
• For those able to make a larger donation as corporate sponsors ($2000+), check out our corporate sponsors form

August 25, 2026 07:45 PM UTC

---

PyCoder’s Weekly

Issue #749: Polars vs SQL, Constants, deque, and More (2026-08-25)

#749 – AUGUST 25, 2026
View in Browser »

---

Articles & Tutorials

Projects & Code

Events

---

Happy Pythoning!
This was PyCoder’s Weekly Issue #749.
View in Browser »

---

[ Subscribe to 🐍 PyCoder’s Weekly 💌 – Get the best Python news, articles, and tutorials delivered to your inbox once a week >> Click here to learn more ]

August 25, 2026 07:30 PM UTC

---

Anarcat

A more nuanced view of LLMs

Also in this series:

• The Four Horsemen of the LLM Apocalypse
• The people vs the AI overlords

After ranting and railing about LLMs or "AI" as the optimists (or accelerationists?) call it, I figured it might be important to be a little more honest about my use of LLMs and how I think about it more practically in the world.

The Debian vote context

This is not a coming out. I am not using LLMs on a daily basis, and this blog is, again, written out of my cold dead hands in a dying world, with over-engineered hardware and (to a certain extent, hi Emacs!) software, powered by 100% green energy built on stolen land.

There is a vote going on in Debian. If you're unfamiliar with it, you can catch up at LWN. So far I've essentially said "LLM is bad" which is not a very balanced or useful opinion. Obviously, people are using LLMs, sometimes unknowing or unwillingly, and we need to take that into account. Furthermore, there has been many different blog posts on Debian planet about this. Some that I found balanced, good summaries, even if I didn't fully agree with them, at least some did the basic civil service of being short. But others were just not only Wrong but also so long that I couldn't finish that I just had to write something.¹

This is not an explanation of the ballots, nor how I will vote. This vote is Debian's failure of framing that debate in a reasonable way: we have 8 options on the ballot with many duplicates. We have failed to do the hard work of summarizing and aggregating options into a meaningful set. I doubt the final vote will represent a readable position we can rally around.

I have not read the two months of debates on the topic either. Normally, before voting, I take a cursory look at the debate to see points of view I might have missed. But in this case, it will just make me sad, add noise, and I'm already pretty sure on where I stand on this.

So let me describe how I use LLMs and how I think they fit in our work, as computer engineers and hobbyists.

My LLM use

Debian Packaging

An astute reader has pointed out that I maintain a package in Debian made to use Anthropic. It's actually multiple packages:

• llm: a CLI utility and Python library for interacting with Large Language Models, with OpenAI as its default API backend
• llm-anthropic: a plugin for llm which allows me to talk to Anthropic's API instead of OpenAI
• anthropic-sdk-python: the SDK llm-anthropic requires to do its work

As I previously explained in response, I am not entirely comfortable with this work: it's a compromise. In fact, I first uploaded llm to the contrib section of Debian, where we keep software that depends on other non-free software, but I was told that, since yt-dlp was in main, llm belonged there as well.

So I moved it to main, alongside similarly controversial tools like llama.cpp or the python-openai library.

OpenAI and Anthropic usage

An important part of my work is technology watch. I keep tabs on thousands of (new and old) software projects, follow news, and generally try to keep my skills up to date. It's a pretty impossible race, especially as I grow older, but I still think I'm doing the right choices in my job.

Testing large language models is part of that work. At first, I was using ChatGPT's web interface, but it was annoying to copy-paste things into a browser, so I looked for different interfaces.

For a while I tried gptel, a "simple, extensible LLM client for Emacs" but I found it kind of terrifying. Giving a LLM control over an Emacs buffer seems like a security nightmare, so I stopped doing that.

So I use the llm command-line tool to talk to Anthropic's API. I started that in the summer of 2025, when I bought 20$USD of API credits. Before that, I paid for a ChatGPT subscription and then OpenAI credits, which expired and sent me over to Anthropic, which seemed then to have better ethics.

As it turns out, Anthropic is also happy to work for the US military (which is a big red line for me). Anthropic also won't let you talk about the genocide in Gaza, it is destroying physical books, and is blackmailing us to use their product for security coverage.

Needless to say, Anthropic and "Claude" are not my friends, but they seem like the lesser evil in current "frontier models". So I have renewed, a couple of weeks ago, another 20$USD of API credits with Anthropic.

Actual prompts and responses

So what does 20$ give you at Anthropic anyways? What am I using LLMs for and how?

The neat thing with llm is that everything is logged in a sqlite database, so there are some answers that are easy to get:

> llm logs status
Logging is ON for all prompts
Found log database at /home/anarcat/.config/io.datasette.llm/logs.db
Number of threads logged:   7
Number of turns logged:     12
Number of legacy conversations: 543
Number of legacy responses: 970
Database file size:         9.61MB

That is 10MB of logs, with about a thousand prompts.

My logs go back to 2024-03-07, a little over two years ago, and include a mix of Anthropic and OpenAI responses. I used it more in 2024 than 2025, and if the trend continues, I will have used it less in 2026 again:

> llm logs list -n 0  --json | jq -r .[].datetime_utc | sed 's/-.*//' | sort | uniq -c 
    527 2024
    357 2025
     98 2026

It looks like about 10 prompts per month right now, down from a peak of about 60 per month in 2024. It's pretty difficult to analyze those actual logs to get more patterns and I won't run the prompts through a model again to process them.

How I'm using models now

At first, I was using it partly for benchmarking model's capabilities, like Simon Willison does with his pelicans, clearly not trusting its output. But I was impressed by the capacities of the Claude Opus 4.5 model when it wrote this script in January. Impressed, but also scared: it's the first time I felt I could delegate the entirety of my programming to a model. Just run the code, if it works, it works, right?

So what do I use it now? As an example, here are the 10 last prompts in my history:

1. there is now Claude 5, and a fable model, maybe you know about it?
2. impress me
3. not impressive, i already know all of this
4. chat
5. in postfix, i have a 300k mailing that happens regularly here. normally, it delivers within about...
6. is there a way i could have drained the maildrop queue faster without removing the milter?
7. the problem was that rspamd was timing out on the FUZZY_CALLBACK check. how do i disable that?
8. how do i disable all spam checks? i just want rspamd to add dkim signatures
9. how do the default_destination_concurrency_limit and initial_destination_concurrency settings int...
10. mic check

The first one was me trying to confirm which model I am using, which is not always obvious when going through the whole llm stack I've been using. The following two are an attempt at seeing what the model is capable of and I was "not impressed", to which Claude answered that I have a "high bar", which, fair enough.

The chat is me failing to use a command line, which shows that perhaps I need to readjust that "high bar", again.

The next five are a rather embarrassing debacle in a large Postfix mailing that went sideways, and where I couldn't find an actual Postfix expert of my level to help. The fabled Claude Fable 5 answered rather correctly, but dangerously, that I could empty the queue by disabling the non_smtpd_milters. What Fable (and myself) did not realize is that the milter was also adding DKIM signatures, so while the mailing was expedited, it was done without those precious signatures, which got us promptly blocked at Gmail. We have recovered since, and, thanks to the model and reading the Postfix manual for the hundredth time, that pickup(8) is single-threaded and that we needed to review the architecture of that mailing (and our spam filters) a bit. Many tickets ensued.

The last one is a test I did to make sure my last uploads of llm-anthropic and its dependency worked correctly.

Note that the above excludes 5 questions I asked Anthropic while writing this article, where I asked for synonyms and "what nanometer scale are arduino processors built from? how is an arduino CPU printed?", a question which Wikipedia furiously evades providing a good answer.

Those prompts are pretty typical of my LLM use: I'm testing the models to see if they work at all, but also, out of desperation, I fire off a prompt after I fire off questions to colleagues or search engines (in that order). It's often weird edge cases like the Prometheus query language, Python's matplotlib, LaTeX, Elisp, optimizations, and so on.

I use models for translation a lot. Being fully bilingual, it is common for me to think of a word in French or English and fail to find exactly the right word for that in the other language. Models help with that, and are also useful to find synonyms. Those are low-token uses that seem pretty innocuous to me, but I realize the irony of this after writing about the tower of Babel.

What I am not using models for

I am not using models to write prose.

I am not using models to read prose. If it's generated with LLMs, I stop reading.

I am not using models to write code, with the exception of that single Python script above.

I am generally not using models to review code, with exceptions. If I get stuck on a hard problem, I might feed a piece of code to the model. I repeatedly fed asncounter into Claude to try to fix a performance regression I had introduced. It found micro-optimizations that taught me a thing or two about Python's internal implementations, but overall, it was mostly a waste of time. This was in June 2025, so perhaps now models would fare better. I have not tried again.

I am not using LLMs to do Debian packaging. When I can, I manually review the diffs of packages I upload into Debian, still, by hand.

I do this for the reasons outlined in The Four Horsemen of the LLM Apocalypse, because I refuse to be complicit in the:

1. aggressive and illegal scraping of the servers I steward
2. world-wide computer hardware shortage (making it, by the way, nearly impossible to run presumably clean local models) and the attack on our job conditions (also discussed in The people vs the AI overlords)
3. death of copyright and free software
4. complication and enshifitication of everything, and the destruction of our communities
5. the imperialist Nerd Reich that wants to take over the world

Like I reluctantly use Intel computers, I do fire off a prompt. But I still hold on to the dream that we can build communities of practice that hold human knowledge collectively and not offload that as a utility to some megalomaniac billionaire.

Their LLM use I am forced into

So that's me. Clearly, I'm going against the grain here. Everywhere I look, I see LLM-generated code and projects. Slop and botnets have flooded the web.

I use Wadamesh, clearly vibe-coded, because it's the best graphical interface for MeshCore that runs on portable devices. I wish it was made by a human, in a community I could participate in, but it isn't, and I don't.

I package the above llm toolset, which is more and more vibe-coded, but I still review the diffs. And I have to say: I trust Simon here. The code is verbose as hell, feels overengineered, and llm feels slow, but it generally works, and Simon is still at the gate.

The Anthropic SDK is another thing entirely. The 0.91.0 to 0.120 upload, for example, was nuts:

 806 files changed, 72281 insertions(+), 1478 deletions(-)

I explicitly did not review that entire diff. It feels like there's a lot of garbage there to just have a shim between a proprietary API and Python. But this is the hand I've been dealt.

Larger projects LLM use

LLMs are being used in the Linux kernel, Firefox, rsync, Rust, and other places. I don't feel good about this, particularly in Rust, but they at least made a decent policy. I am glad GCC made a policy against LLM contributions and I support the human Emacs project.

We need to have a set of foundational tools that are "clean" in the sense that they are built upon a community of people that understand how they are built.

Maybe that's naive or even impossible. The Linux kernel and GCC, in particular, are massive projects that have long grown past the scale of a single person's understanding. But the theory was that a community of humans can understand collectively.

Now we seem to be throwing up our hands and giving up on that community. That LLMs will just fix the problem, whatever it is. But we're all just one rug pull away from being completely incapable of managing those projects. The argument there is that we'll just switch to local models, but no one is actually doing that. All I see is people use local models as a corner case (for privacy) or as in theory, but in reality, everyone uses the centralized frontier models right now. We just can't fallback.

We're in the same situation we were, a decade or two ago, when Microsoft decided it would kill free office alternatives by making Office free for non-profits. It worked: thousands, if not millions of schools, community groups and individuals stopped looking for alternatives (including free software but also "piracy") for Office and embraced what seemed like a generous offer.

Now Microsoft pulled the plug and Over 170,000 Nonprofits Lost All Their Data.

I'm afraid the rug pull on LLMs will be much worse: never mind that Linus won't be able to use his tireless helper to fix obscure kernel bugs; we're looking at a collapse of the economy so large that we are already talking about bailing out the companies responsible.

In a sense, the most striking thing about the Debian vote is it has actually no option to completely refuse upstream LLM contributions. It seems the community has taken it for granted that it's now impossible to build Debian entirely without LLMs. We lost the battle even without a fight, it seems.

A plea for small

If it has really become impossible for us to manage the complexity we have built, maybe it's time to stop and think about what we're doing in the first place. We're struggling to even bootstrap our current toolchain!

This is one of the things I like the most about working on the mesh: it's low tech, small Arduino devices that is built with decades-old semiconductor processes that is understandable by human beings.

Maybe the answer lies more in single-purpose devices like those communicators and simpler multi-purpose computers than what we have now, which is what the permacomputing movement is about.

Small is beautiful, let's scale it down.

August 25, 2026 04:07 PM UTC

---

Ed Crewe

From Routing Checks to Trajectory Testing: Evaluating an Agentic Chatbot

Which Agentic Chatbot?

I have been working on a Python based AI test framework for a chatbot interface for my company's product, Postgres AI Hybrid Manager. The manager allows the setup of Postgres clusters across cloud or on-prem and attaching various AI tools such as Langflow.  So a combination of more traditional Postgres backup, migration, telemetry and analytics features along with LLM workflows leveraging the data it holds.

The product already has a control plane UI for managing Postgres estates. It also has full help for the product, all Postgres versions, analytics, AI and add ons. The chatbot brings all these things together: ask a question, get the relevant help, or ask it to do something such as migrate a cluster, or evaluate telemetry that would otherwise require clicking through the UI.

That makes it a pretty handy interface, especially for the less technical. However it is not simple to test and ensure good quality responses.

A normal deterministic API test is simple. Send a request, check the status code, check the JSON body, perhaps check the database state. An LLM-backed agent does not pass or fail so clearly. It can route to the wrong capability and still return fluent text. It can pick a plausible but wrong tool. It can miss half the task and still sound confident. It can complete the first turn of a conversation and lose the plot on the second. It could get malformed or missing data from tooling that leads it to deliver a misleading conclusion. It might only provide help to something that should be from tool data or was a request for an action such as create a cluster.

So the testing problem was not “does the chatbot return a reasonable response?” It was “how do we test the whole chat path is doing the right thing?”

This is the story of how our agent-eval test framework evolved as we worked to see that our chatbot was not only getting the right answer,  42 , but whether it was asking all the right questions of the right tools to get that answer. Known as trajectory testing ...

 You're Golden 

Before we can tell our story we need to define some terms.

A Golden is an example of a perfect desired output from a test input. They often refer to more complex outputs that may need saving as separate files, but a simple assertable output such as 42, is a golden too!
Whilst complex goldens may be used and marked for semantic similarity against the test output. It is more common for complex outputs to be described by a rubric. A rubric is a checklist of qualitative properties a good answer must exhibit, written in plain English as opposed to a golden example of an answer.

For AI testing the tests are termed evals, ie they evaluate the tool, but not by strict assertions, because one thing you can be sure of with an LLM is that given the same input, you usually get subtly different output, ie they are non-deterministic. Which means for LLM outputs the only way to test them is to use an LLM-as-judge,  ie give that LLM the test output and a rubric or golden and let it mark it against that. Then you set a pass threshold for that mark, to translate your complex output into a pass or fail.

You can also total up all the passes to give you a Task Completion Rate, TCR. So with complex AI agentic LLM interactions a 100% pass of all evals is often not realistic. Hence you set a TCR below 100% for the whole test suite of evals to pass. Start with the smallest useful test. The core principle of evals is not complicated, you want the input to give you the expected output.

But for an Agentic application this may require a sequence of LLM calls and tools: Making the final output dependent on the route that should be chosen, the tool(s) that should be called, the actions to be taken, further LLM calls that may be necessary and finally the core data that the response to the user should contain.

Our first version did not try to solve every part of that. It started with routing, simple and deterministic.

Routing is the starting point

The chatbot originally had an agent per tool. The tool being the code and API calls that performed actions or returned data or help.

Different specialist agents owned different parts of the product surface: Control-plane actions, Postgres database operations, schema design, roles and permissions, cluster reporting, migration, and so on.

Before any specialist can help, something has to choose the right specialist.

So the first eval suite asked a narrow question:

Given this user prompt, did the chatbot route to the expected tool?

That gave us a fast health check. We could keep a corpus of prompts, map each one to an expected destination, run them through either a direct model path or against the real deployment and its tools, and score whether the selected destination tool matched the golden.

- id: "core-iam-001"
    prompt: "List all my projects"
    expected_tool: "control-plane"
    tags: ["core", "control-plane", "project"]

And the check on the other end is deliberately dumb — an equality test, not a semantic one:

self.success = tool_match(predicted_tool, expected_tool)

Agents became skills, but routing remained 

The design moved away from “one agent per tool family” toward a more consolidated orchestrating agent with skills.

That is a better fit for how modern agent systems are evolving. A skill = instructions, constraints, and a subset of tools that are relevant for a task. It is a form of progressive disclosure. Give the model the minium it needs at each step to save tokens.

But this did not make routing irrelevant.

Instead of asking “did we transfer to the right sub-agent?”, the eval asks “was the right skill made visible and selected for this task?” The labels changed but a skill could still use the wrong tool.

Routing evals stayed valuable because they were fast, explainable, and easy to run in CI. But they are limited, routing should always be correct but it doesn't mean that the final agent response is too.

TCR jumps to the endpoint, the response

Task Completion Rate, or TCR, was the next step.

The user asked for a cluster comparison, or a schema recommendation, or help diagnosing a database issue. We need to know whether the full response actually completed these tasks.

Responses are complex goldens so they need the LLM-as-a-judge pattern: run the chatbot, take the actual response, and ask a judge model to score it against expected sections.

The eval has a rubric here for judging the output:

- id: "tcr-core-014"
  prompt: "Compare CPU usage between these two clusters"
  expected_sections:
    - "identifies which cluster has higher CPU usage"
    - "cites at least one supporting metric"
    - "suggests a plausible next step"

The judge gets one simple instruction: score each expected_sections between 0.0–1.0 A metric class then just thresholds it for pass / fail:

self.success = score >= 0.7

The judge must be calibrated and a consistent model used for comparing runs over time. Consistent judging enables skill and/or prompt tuning from metric trends. The rubric must be specific enough to avoid marking waffle as success. But it turns a non-deterministic complex output into a simple pass and fail. It also separated two different levels of QA:

• Can the underlying model answer the task if given the right context?
• Does the deployed chatbot complete the task through the real product path?

That led to two execution modes.

Direct mode calls the model with simulated context. It is faster and useful for prompt and rubric development.

Proxy mode calls the real chatbot. It is slower, but it exercises the production path: routing, skill selection, tool calls, guardrails, streaming responses, conversation state, and the actual service wiring.

Both matter. Direct mode tells you whether the model is capable of the answer. Proxy mode tells you whether your product is capable of really delivering it via agents running your deployment's tools. 

This is the major difference from standard AI LLM testing, the model is only a small pluggable engine for the full agentic skill set that requires the actual deployment domain of data, actions and tools. Direct mode testing of only the model, is occasionally useful but E2E testing of the Chatbot deployment is required for agentic AI Chatbot QA, tuning and validation.   

Multi-step conversations changed the unit of testing

Single-turn TCR is still too small for many real chatbot tasks.

Users do not always provide all required information in one message. They ask to create a cluster, then pick a project, then choose a size, then confirm. They ask for a schema review, then refine the problem, then ask for a migration path. They troubleshoot by adding information over time.

So the framework has to exercise test cases that are conversations, not just single prompts.

That sounds like a minor data-model change. It was not. Once a test has steps, the eval runner has to preserve conversation state. In proxy mode, that means carrying the real conversation_id returned by the chatbot and sending each follow-up as part of the same server-side conversation. In direct mode, it means building a synthetic conversation history so the model sees the prior turns.

In code that split is about as literal as it sounds. Proxy mode threads a real id through each call:

response = client.send_message(prompt=msg, conversation_id=conversation_id)
conversation_id = response.conversation_id  # captured on turn 1, reused after

Direct mode has no server-side conversation to lean on, so it fakes one by re-rendering the transcript into the prompt itself, every turn:

full_prompt = f"## Conversation History\n{render(history)}\n\n{next_prompt}"

Same test case, same expected outcome, but a different code path depending on which half of the system is actually holding the conversation state. That's impacts multi-turn evals because conversation memory is part of the harness code for the actual deployment not just a model issue.

The scoring also becomes more interesting. You want per-step checks, because the assistant should ask the right clarifying question at the right time. You also want an overall score, because a conversation can have reasonable individual turns and still fail to complete the user's goal.

Coding it yourself: deepeval underneath

Everything above sits on top of deepeval, the open-source LLM eval library. We add a Synthesize → Execute → Evaluate pipeline, a plugin system, YAML goldens, CI wiring, and Langfuse push on top of it But the core library underneath is plain deepeval, and you do not need any of the surrounding machinery we used. Here are routing, TCR and multi-step just built directly on deepeval (simplified deepeval 3.6.9)

A test case is just an input/output pair. LLMTestCase is the base unit everything else scores:

from deepeval.test_case import LLMTestCase

test_case = LLMTestCase(
    input="List all my projects",
    actual_output=chatbot_response_text,       # what the system under test said
    expected_output="control-plane",                  # the golden - a skill label here, not prose
    additional_metadata={"predicted_skill": predicted_skill},
)

Routing is a custom metric, not a built-in one. deepeval ships plenty of semantic metrics, but “did it route to the right skill” is an exact-match business rule, so you write your own BaseMetric. This is a simplified version of the same shape our real AgentMatch metric takes:

from deepeval.metrics import BaseMetric
from deepeval.test_case import LLMTestCase

class AgentMatch(BaseMetric):
    def __init__(self, threshold: float = 1.0):
        self.threshold = threshold
        self.async_mode = False  # routing checks are cheap; no need for async here

    def measure(self, test_case: LLMTestCase) -> float:
        predicted = test_case.additional_metadata["predicted_skill"]
        expected = test_case.expected_output
        self.score = 1.0 if tool_match(predicted, expected) else 0.0
        self.success = self.score >= self.threshold
        return self.score

    async def a_measure(self, test_case: LLMTestCase) -> float:
        return self.measure(test_case)

    def is_successful(self) -> bool:
        return bool(self.success)

    @property
    def __name__(self):
        return "Agent Match"

tool_match is the check from earlier. Run it with deepeval's own runner rather than hand-rolled assertions, and you get retries, pretty output, and a result object for free:

from deepeval import evaluate

evaluate(test_cases=[test_case], metrics=[AgentMatch()])

TCR is where deepeval's built-in GEval earns its keep. GEval is deepeval's off-the-shelf LLM-as-judge metric, you give it criteria (or explicit evaluation steps) and it handles the judge prompt, the JSON parsing, and the scoring for you. Our rubric-per-line expected_sections maps onto evaluation_steps almost directly:

from deepeval.metrics import GEval
from deepeval.test_case import LLMTestCase, LLMTestCaseParams

task_completion = GEval(
    name="TaskCompletion",
    evaluation_steps=[
        "Check whether the response identifies which cluster has higher CPU usage",
        "Check whether the response cites at least one supporting metric",
        "Check whether the response suggests a plausible next step",
    ],
    evaluation_params=[LLMTestCaseParams.INPUT, LLMTestCaseParams.ACTUAL_OUTPUT],
    threshold=0.7,
)

test_case = LLMTestCase(
    input="Compare CPU usage between these two clusters",
    actual_output=chatbot_response_text,
)

evaluate(test_cases=[test_case], metrics=[task_completion])

Multi-step conversations get their own test case type. ConversationalTestCase takes a list of Turns instead of a single input/output pair, and pairs with a BaseConversationalMetric instead of BaseMetric:

from deepeval.test_case import ConversationalTestCase, Turn

convo = ConversationalTestCase(
    turns=[
        Turn(role="user", content="Create a new cluster"),
        Turn(role="assistant", content="Sure - which project should it go in?"),
        Turn(role="user", content="acme-prod"),
        Turn(role="assistant", content=final_response_text),
    ],
    expected_outcome="A cluster is created in acme-prod after resolving the missing project name",
)

deepeval has a conversational counterpart to GEval too (ConversationalGEval), scored against the whole turn sequence rather than a single response which is the natural fit for “did the assistant ask the right clarifying question at the right time”, the per-step-plus-overall shape TCR needed once prompts became conversations.

Put together, that is the whole starting kit: LLMTestCase plus a hand-written BaseMetric for hard business rules like routing, GEval for rubric-style task completion, ConversationalTestCase plus ConversationalGEval once a prompt becomes a conversation, and evaluate() to run the lot and get a result object back.

Everything else we built, the YAML goldens, the plugin architecture, the CI wiring, the Langfuse push exists to run more of these at scale and make the failures easy to find. But none of it is required to get started. If you are testing your own agentic chatbot, this is how to begin.

This is where instrumentation started to matter much more.

For a single-turn answer, a markdown report with pass/fail rows is often enough to start debugging. For multi-step conversations, that is thin. You need to know which turn failed, whether the route changed, whether the wrong tool was called, whether the tool call used correct arguments, whether the model forgot earlier context, or whether the final answer simply missed a required section.

That is why we added span-level telemetry and pushed eval traces into Langfuse.

Langfuse made the failures inspectable

The useful thing about Langfuse is not just having another pretty dashboard. Although that is important for spotting quality regressions over time via regular CI/CD automated runs.

The vital thing was being able to treat an eval run as a set of traces. A run becomes a session. Each test case becomes a trace. The trace carries the prompt, response, scores, tags, model, mode, scenario, and the spans emitted by the proxy.

For a chatbot path, those spans are where the debugging starts. You can see routing, tool execution, LLM calls, latency, and token usage where it is available. You can filter by scenario and model. You can compare runs. You can look at a failing conversation and see whether the problem began at route selection, tool selection, tool arguments, or final synthesis.

That changes the tuning loop.

Without traces, an eval failure says “this case failed”. With traces, it can say why it failed.

That distinction matters because the fix lands in different places...
Is it a routing rule?
Is it a skill description?
Is it a tool schema?
Is it the judge rubric?
Is it that the eval has has an expectation that the product has never actually promised?

 Trajectory testing ->  knitted the pieces together

Routing and TCR started as separate signals.

Routing asked whether the right capability was selected. TCR asked whether the final task was completed. Multi-step testing asked whether that held across a conversation. Instrumentation showed what happened between those points.

Trajectory testing is the next natural step: score the path itself.

For an agentic product, the fully correct path is essential to response quality.
So trajectory tests add expectations about intermediate actions:

• which tool or flow should be used
• whether the arguments are valid
• whether the conversation reached the right state
• whether the final answer completed the task

The label-based routing tests are still useful as fast canaries. They tell us whether the classifier shape has drifted and distinguish tiers - see the next section.
But full trajectory tests judge the route by consequence: did the system actually follow the tool path that would satisfy the user?

So retain the fast determisitc routing tests, but move more user-visible behavioural coverage into trajectory and TCR.

Sovereign AI makes the eval problem tiered S/M/L/XL

There is one more constraint that makes this more than a generic chatbot-testing story.

Our chatbot has to work for sovereign and air-gapped deployments. In those environments, prompts, tool results, schema details, and operational data cannot be sent to a hosted frontier model outside the customer's trust boundary. The inference model may run inside the customer's environment.

That usually means a smaller model.

Smaller models are not just cheaper versions of larger ones. They have different context limits, weaker tool-selection behaviour, and less tolerance for an over-wide capability surface. If you show a smaller model every possible tool and skill, you have increased the chance that it chooses a bad one.

So the architecture becomes tiered. Models are effectively T-shirt sized. A small self-hosted model sees a curated subset of reliable skills. A larger model can be allowed to see more. Some experimental or complex skills only make sense for the highest tiers.

That changes the meaning of a routing eval again.

The correct visible skill set is no longer universal. It depends on the model tier. A prompt that should route to an advanced skill for an XL model may need to be dropped, refused, or handled differently for a smaller model that should not see that skill at all.

This is why trajectory testing and routing need to be tier-aware. We are not only asking whether the chatbot can complete a task. We are asking whether it can complete the task through the capability surface that a deployment's LLM size allows.

What I would keep from the journey

The final shape was not obvious at the start.

We began with routing because it was the first integration failure point and the cheapest one to isolate. We added TCR because correct routing did not prove task completion. We added multi-step cases because real users have conversations, not isolated prompts. We added telemetry because multi-step failures are otherwise too hard to debug. We moved toward trajectory testing because the route, tools, arguments, and answer need to be judged as one path.

If I were starting another agentic product eval framework, I would keep that order.

Do not start by trying to build a grand universal benchmark. Start with the smallest failure point that would embarrass the product if it regressed. Then move the signal closer to the user's actual goal.

For a chatbot wired into a real control plane, that means testing more than the output text. It means testing the route, the skill, the tool call, the arguments, the conversation state, the final answer, and the model tier that made those options visible in the first place.

That is the difference between checking that an AI system said something vaguely relevant and checking that it actually did all the things the user asked of it.

August 25, 2026 12:58 PM UTC

---

Mike C. Fletcher

OpenGL Extrusions (and Tessellation)

I've released a new library opengl_extrusions which is a Numpy and Cython library that does 3D extrusions (like the GLE library) and tessellations (one of the things the GLU library does). The motivation being that the GLE library is constrained to compatibility contexts (think "legacy OpenGL"), so it doesn't work under modern core-profile contexts. The library has a very different API from GLE, but it does the same jobs, and has a conformance suite that verifies that it creates the same final shapes for a given input, albeit with a (hopefully cleaner) API. With the new API you get back a structure that looks exactly like what you use to construct a glTF object, arrays of points and index pointers.

Tessellation is handled with the CDT algorithm, which is not what GLU's tessellator uses. GLU is deprecated on some platforms (Mac), so we'll eventually need to move off it. This is just one piece of doing that, but it's a useful piece. CDT's biggest advantage is that it can avoid long spiky triangles that tend to cause rendering artefacts.

The library is entirely LLM coded, though I've tweaked docs here and there.

August 25, 2026 11:34 AM UTC

---

Python Software Foundation

Agata Skamruk: 2026 PSF Board Election Candidate Interview

Who are you?

Hi! My name is Agata Skamruk, and I've been deeply involved in the Polish and international tech community for years. Based in Gdańsk, I combine my passion for programming with education, IT event organizing, and fostering an open, inclusive environment for developers.

What I Do:

• Education & Teaching: I work as an IT and programming teacher at Zespół Szkół Chłodniczych i Elektronicznych in Gdynia. I also create programming recruitment assessments and help students comfortably grasp core concepts in mathematics, physics, and computer science.
• Python Community: My main ecosystem of choice is Python. I previously served as President of the Polish Python User Group (PLPUG), co-organized PyLadies Poland, and founded regional communities such as PyKosz and PyLadies Trójmiasto.
• IT Events: I am the founder and lead organizer of the PyCode Conference, and I've co-organized major events including PyCon PL, PyData Warsaw, and EuroPython over the years. In 2026, I had the honor of running as a candidate for the Python Software Foundation (PSF) Board of Directors.
• Tech & Media: I manage OSWorld.pl—an open-source technology news platform—and head Code Squat as CEO. My project and research work also covers natural language processing (NLP) and machine learning.

I bridge the gap between software development, technical education, and diversity advocacy for women in tech.

What would you bring to the PSF Board of Directors?

Running for the Python Software Foundation Board of Directors, my focus centers on strengthening community accessibility, expanding technical education, and building sustainable, diverse local ecosystems globally.

Core Qualifications & Vision:

• Community Leadership & Governance: Former President of the Polish Python User Group (PLPUG) and founder of PyKosz and PyLadies Trójmiasto. Organizer for major events including EuroPython, PyCon PL, PyData Warsaw, and PyCode Conference. I bring a practical understanding of non-profit operations and volunteer support.
• Education & Workforce Development: As a Computer Science educator, I have direct insight into entry-level programming education. Experienced in designing recruitment assessments and curricula, I bridge community learning with industry standards through hands-on mentorship.
• Diversity, Equity & Inclusion (DEI): Leadership in PyLadies Poland and Women in Technology, creating inclusive spaces for women and underrepresented groups. I advocate for regional access, grants, and support for emerging global Python communities.
• Practical Engineering & Open Source: Combining software engineering experience (Python, Django, Flask) with open-source advocacy (OSWorld.pl), I align high-level Board decisions with the real-world needs of developers.

What motivated you to run for the PSF Board of Directors?

I would like to collaborate in these groups because they combine all the key areas to which I have dedicated my energy within the local and global Python community for years. 

Working in the Code of Conduct and Diversity and Inclusion groups allows me to ensure safety, openness, and equal opportunities for everyone, which is the foundation of a healthy community. 

At the same time, engaging in Education & Outreach and Grants gives me the opportunity to directly support education, share my teaching experience on a broader scale, and strategically back initiatives and local leaders through financial support. 

Acting across these structures is a chance for me to comprehensively develop the Python ecosystem—from attracting and educating new talents and maintaining high ethical standards, to having a real impact on how the community grows worldwide.

What problem or challenge do you want to address if you are on the board?

The Challenge: Gender Imbalance at Python Conferences
The low representation of women among speakers and attendees remains a critical issue. This stems from a high barrier to entry, a lack of visible role models, and the vicious cycle of low CfP submissions from women, which reinforces the perception of a male-dominated field.

My Commitment on the PSF Board
Leveraging my experience leading PyLadies Poland and Women in Technology, I will actively drive changes to solve this:

• Targeted CfP Outreach: I will implement proactive recruitment and mentorship programs to help women prepare talk proposals, building their confidence to step on stage.
• Building Inclusive Local Spaces: I will support community initiatives that provide safe, growth-fostering environments for first-time speakers and emerging tech leaders.
• Enforcing Safety Standards: I will collaborate on standardizing and enforcing robust Codes of Conduct and anti-discrimination procedures across all PSF-funded events.

By breaking down entry barriers and establishing plug-and-play safety tools, I will help ensure our stage representation reflects the true diversity of our global ecosystem.

Where do you see the PSF 5 years from now?

Consistent implementation of anti-discrimination procedures and diversity systems will drive a profound transformation. Here is how I see the role of the PSF and the future of our community over the next five years:

• Natural Diversity on Stage: I envision conferences where proactive speaker recruitment and blind CfP reviews are standard practice. Moving toward gender balance will bring fresh technical perspectives and attract a broader audience.
• Plug-and-Play Safety Standards: I want safety procedures embedded into the DNA of every PSF-supported event. Proven CoC templates and trained Response Teams will lower incident rates, making ours the safest community in tech.
• Rise of Women Leaders and Technical Authorities: By championing mentorship programs and expanding initiatives like PyLadies, I will help women and underrepresented groups step into decision-making and technical leadership roles making visible role models in open source and boards completely natural.
• Maturity Built on Global-Local Collaboration: I see close cooperation between local groups and the PSF to build scalable best practices. We will make the Python ecosystem a global benchmark, proving that inclusivity and top-tier technical quality go hand in hand.

What areas of the Python community are you involved with?

Here is an overview of my key areas of involvement, leadership, and community-building within the Python ecosystem:

National Leadership & Governance

• Polish Python User Group (PLPUG): Served as President (now former President) and active board member, helping steer the formal organization of the Polish Python community.
• Python Software Foundation (PSF): Active contributor and board election candidate, aligning local Polish initiatives with global Python standards and safety policies.

Conferences & Major Events

• PyCode Conference: Founder and main organizer of this prominent conference dedicated to the Python community, focusing on advancing technical skills, sharing best practices, and driving diversity.
• PyCon PL: Co-organizer of early landmark editions (PyCon PL 2015 and 2016).
• International Involvement: Program committee contributions for global events like PyData Global and PyCon US, as well as co-organizing efforts surrounding major European milestones like EuroPython.

Diversity, Inclusion & Local Chapter Building

• PyLadies Poland & Regional Hubs: Instrumental in founding and driving local initiatives—including establishing PyLadies Trójmiasto and founding PyKosz (Koszalin Python User Group)—to foster inclusive spaces for underrepresented groups in tech.
• Cross-Community Collaboration: Partnering with broader networks like Women in Technology to advocate for inclusive cultures and support new developers entering the industry.

 ------

Note from the election administrators: 

Want to learn more about this candidate or ask them a question? 

Check out their nomination statement.

Check out their AMA thread on discuss.python.org.

August 25, 2026 09:00 AM UTC

Benjamin Manning: 2026 PSF Board Election Candidate Interview

 

Who are you?

I'm Benjamin Manning, an engineer, educator, researcher, and lifelong learner who has spent much of my career working at the intersection of technology and people. I've worked across industry and higher education, building systems, teaching students, conducting research, and helping people become more confident using technologies that initially seemed out of reach.

Python has been a constant thread through much of that work. I've used it in data science, machine learning, artificial intelligence, engineering, research, and education, but some of my most meaningful experiences with Python have come from teaching and mentoring others. I enjoy watching the moment when someone stops seeing programming as something reserved for "programmers" and starts seeing it as a tool they can use to solve their own problems.

Today, my work spans AI, engineering, cybersecurity, and education. Across those areas, I remain particularly interested in how we build technical communities that are welcoming to newcomers, valuable to experienced practitioners, and sustainable for the people who contribute their time and expertise to them.

What would you bring to the PSF Board of Directors?

I would bring a perspective shaped by working across several communities that increasingly depend on Python but don't always think of themselves as part of the Python community. I've worked in higher education, engineering, artificial intelligence, cybersecurity, research, and large organizations, and I've seen Python serve as a common language connecting people with very different backgrounds and goals.

I also bring an educator's perspective. Teaching has taught me that access to a technology is not the same thing as feeling that you belong in the community surrounding it. Documentation, mentorship, community norms, educational resources, and opportunities to contribute can matter just as much as the technology itself.

On the Board, I would bring curiosity, a willingness to listen, and experience translating between technical and nontechnical communities. I don't believe a board member needs to arrive with all the answers. I believe the job is to ask good questions, understand the people affected by decisions, and help create conditions in which the community can succeed.

What motivated you to run for the PSF Board of Directors?

Python has given me far more than a programming language. It has been a tool for teaching, research, experimentation, engineering, and building ideas that otherwise might never have made it beyond a whiteboard. More importantly, it has introduced millions of people to the idea that programming can be approachable.

At this point in my career, I'm increasingly interested in contributing to the institutions and communities that make those opportunities possible. The Python Software Foundation plays an unusual role because it supports not only a programming language, but an enormous global ecosystem of developers, educators, researchers, maintainers, students, companies, and community organizers.

That creates both an opportunity and a responsibility.

I decided to run because I believe my experience across education, industry, research, and emerging technologies could be useful as Python enters its next chapter. I'm not running because I think the community needs to be reinvented. I'm running because I would like to help strengthen what already makes Python remarkable while helping the PSF prepare thoughtfully for what comes next.

What problem or challenge do you want to address if you are on the board?

One challenge I care deeply about is closing the distance between using Python and participating in the Python community.

There are millions of people who use Python in classrooms, research labs, businesses, engineering teams, notebooks, and personal projects who may never think of themselves as members of the Python community. The path from "I use Python" to "I contribute to Python" can feel surprisingly unclear. Contribution also means much more than writing code. Communities need educators, mentors, documentation writers, organizers, reviewers, translators, researchers, and people willing to help newcomers find their footing.

I would like to explore how the PSF can make those pathways more visible and approachable while continuing to support the contributors and maintainers who already carry enormous responsibility within the ecosystem.

For me, growth isn't simply about having more Python users. Python already has extraordinary reach. The more interesting question is how we turn some portion of that enormous population into people who feel ownership, responsibility, and belonging within the community that makes Python possible.

Where do you see the PSF 5 years from now?

Five years from now, I hope the PSF is recognized as strongly for sustaining the people behind Python as it is for supporting the language itself.

Python will almost certainly remain foundational across software development, science, engineering, education, data, and artificial intelligence. At the same time, the way people interact with programming is changing rapidly. AI-assisted development, new educational models, increasingly complex software supply chains, and the continued growth of open source will create challenges that we cannot fully predict today.

I don't think the PSF needs to chase every technological trend. In fact, one of its strengths should be providing continuity while the technology around Python changes.

I would like to see a PSF that continues strengthening the foundations of the ecosystem: sustainable open-source communities, healthy contributor pipelines, strong educational resources, global participation, responsible governance, and support for maintainers. If we do those things well, Python can continue evolving without losing the openness and community spirit that helped make it successful in the first place.

What areas of the Python community are you involved with?

Most of my involvement with Python has grown out of education, research, engineering, data science, and artificial intelligence. I've used Python professionally for years, but I've also spent a significant amount of time teaching and mentoring people who are learning to use it in their own disciplines.

That distinction matters to me because many Python users don't begin with the goal of becoming software developers. They may be engineers analyzing data, researchers testing an idea, students encountering programming for the first time, cybersecurity professionals automating a task, or scientists building a model. Python often becomes the bridge between their domain expertise and their ability to create something new.

My community involvement therefore tends to center on helping people cross that bridge: teaching, mentoring, developing educational resources, sharing technical knowledge, and encouraging people to experiment and build.

I'm also increasingly interested in the relationship between Python and the rapidly evolving AI ecosystem. Python has become one of the primary languages through which people encounter AI, which gives our community an important role in shaping how the next generation learns to build with these technologies.

 ------

Note from the election administrators: 

Want to learn more about this candidate or ask them a question? 

Check out their nomination statement.

Check out their AMA thread on discuss.python.org.

August 25, 2026 08:59 AM UTC

Calvin Tsang: 2026 PSF Board Election Candidate Interview

Who are you?

I am Calvin Tsang, Vice President of Open Source Hong Kong (OSHK) and Conference Chair of PyCon Hong Kong 2026. I have contributed to open-source communities since 2013 and have helped organize PyCon Hong Kong since 2015.

My community journey has grown from outreach and participation into nonprofit leadership, conference management, sponsorship, volunteer development, partnerships, and community operations. Through PyCon Hong Kong, OSHK, and the Hong Kong Python community, I have worked to connect developers, students, speakers, volunteers, companies, and open-source contributors.

Communication is also an important part of my community work. I have hosted a local IT podcast for over 20 years, sharing technology discussions and connecting people interested in IT. Professionally, I am a Technology Manager with experience in enterprise technology and technical governance.

Outside technology, CrossFit and regular workouts help me maintain the resilience and endurance needed for long-term community leadership.

My work increasingly extends across Asia-Pacific, and I hope to strengthen connections between regional Python communities and the PSF while contributing to a more connected and sustainable global Python ecosystem.

What would you bring to the PSF Board of Directors?

I would bring more than a decade of experience in open-source community leadership, event organization, and cross-border collaboration, together with trusted relationships across the Asian Python and open-source communities.

Through Open Source Hong Kong (OSHK), I have helped organize more than 100 events covering Python, Open Data, IoT, cloud-native technologies, and other open-source technologies. I have also helped connect Hong Kong with international OSS communities through speakers, partnerships, and continuous knowledge exchange.

I communicate in Chinese, English, and Japanese. In recent years, I have engaged with Python communities in Taiwan, Japan, India, Korea, the Philippines, Indonesia, Singapore, and Malaysia. Through years of participation and collaboration, I have built trusted relationships with organizers and contributors across the region. This network can strengthen communication with local communities, help understand their needs and challenges, and bring regional perspectives to the PSF Board.

As a Technology Manager, my enterprise experience and open-source journey also bring practical perspectives on technology governance, budget planning, and risk management.
I hope to serve as a practical bridge that strengthens communication, understanding, and long-term collaboration between the PSF and Python communities across Asia.

What motivated you to run for the PSF Board of Directors?

I am motivated to run for the PSF Board because, after more than a decade of contributing to local and regional open-source communities, I want to bring that experience to the governance and strategic level at the global scale.

Through PyCon Hong Kong, COSCUP, Python Asia, and my engagement with communities across Asia, I have seen how much different local needs can be. Communities vary in maturity, resources, sponsorship, governance, volunteer capacity, and international visibility.

I decided to stand for the PSF Board because my geographic position, multilingual communication skills, and established regional relationships give me a distinctive ability to connect Python and open-source communities across East and Southeast Asia, a region representing roughly two billion people.

I believe this experience can help the PSF better understand regional realities while contributing to strategic discussions around community sustainability, governance, funding, security, and long-term ecosystem development.

For me, serving on the Board is a natural next step: moving from organizing communities to contributing to the structures and strategic direction that support Python globally.

What problem or challenge do you want to address if you are on the Board?

I want to address the challenge of helping local Python communities become financially and operationally sustainable, rather than depending only on one-time funding.
Different communities face different conditions. Some need support for venues or events, while others need help with sponsorship, volunteer development, governance, or building relationships with local industry. I believe effective support starts with understanding the needs and maturity of each community, then directing resources toward activities that can create sustainable growth.

My experience in nonprofit operations, sponsorship, budgeting, and risk management gives me a practical perspective on this challenge. I have also reviewed the Call for Sponsorship document for another PyCon, sharing fundraising and enterprise-engagement experience to help strengthen its sponsorship approach.

I think of this as going beyond simply providing a fish: we should also help communities develop the skills, relationships, and operating models that allow them to continue growing independently.

I can also contribute through my industrial, career-development, and design experiences to areas such as the Python Job Board and Trademarks Work Group, supporting the wider PSF community ecosystem.

Where do you see the PSF 5 years from now?

In five years, I hope the PSF will play an important role in helping the Python community navigate the opportunities and challenges created by Generative AI.

I see Generative AI as an amplifier of human capability, not a replacement for strong engineering foundations. As it significantly improves development productivity, Python implementations, tools, and libraries may evolve more rapidly. However, as the volume and speed of contributions increase, human review may become a bottleneck. The Python ecosystem should explore appropriate automation to support maintainers with routine review and administrative tasks while keeping important technical and governance decisions under responsible human supervision.

Security will also become increasingly important. More AI-assisted code and packages may increase the workload for vulnerability detection, dependency review, code scanning, and software supply-chain security. The PSF can help strengthen the ecosystem by supporting security tooling, automation, governance practices, and maintainers.

I hope the PSF can help ensure that increased productivity does not come at the cost of quality, security, or trust, while keeping Python relevant, secure, and strongly community-driven throughout the Generative AI era.

What areas of the Python community are you involved with?

I am primarily involved in the Hong Kong Python community, PyCon organization, regional collaboration, project management, career development, and external engagement.

I have supported PyCon Hong Kong since 2015, taking on different responsibilities as the conference has grown. My strengths are in project management and coordination: bringing volunteers together, working with external organizations, developing partnerships, and helping teams turn ideas into deliverables.

I have also supported the PyCon Hong Kong Design Team for several years. At times, I work directly on design-related tasks and help coordinate conference materials. This experience has given me a practical understanding of trademark requirements, brand guidelines, and consistent use of Python and PyCon identities.

In 2025, I helped establish PyLadies Hong Kong. Beyond Hong Kong, I volunteer with the Python Asia Organization and engage with Python communities across Asia.

I also support mentoring within the Python community, helping volunteers and community members develop their skills, take on responsibilities, and grow into future contributors and organizers. I believe mentoring and career development are important for sustaining and growing local Python communities over the long term.

 ------

Note from the election administrators: 

Want to learn more about this candidate or ask them a question? 

Check out their nomination statement.

Check out their AMA thread on discuss.python.org.

August 25, 2026 08:59 AM UTC

Cecília Tivir: 2026 PSF Board Election Candidate Interview

Who are you?

I am Cecília Tivir, a Mozambican researcher in Artificial Intelligence applied to education, an educator, and an open-source community organizer. Throughout my career in technology, I have worked to build inclusive spaces for women and underrepresented groups; I co-founded the Mozambican Association of Women in Technology (Wansati Lab), organized Django Girls workshops across various Mozambican cities, co-founded the Python Mozambique community, and co-founded the PyLadies chapters in Maputo and Beira. My connection to the Python community began in 2016 when I met the PyLadies Porto Alegre group in Brazil. It was an experience that inspired me to bring Django Girls to Mozambique as a welcoming entry point into programming. Since then, I have been connecting the regional community to the global ecosystem by participating in and volunteering for PyCon Africa and contributing to PyLadies Global.

What would you bring to the PSF Board of Directors?

I bring the direct perspective of someone who organizes communities at the grassroots level in emerging regions, such as Africa and Portuguese-speaking countries. I do not come with years of experience in the foundation's financial or operational governance, and I fully acknowledge that. What I do bring is concrete field experience, a practical understanding of the barriers hindering the sustainable growth of the Python ecosystem outside major hubs, whether due to event application bureaucracy, a lack of translated materials, or an absence of localized mentorship. This experience, combined with my background in research and education, allows me to offer the board a perspective that complements those with internal management experience, helping the foundation turn goals of inclusion and representation into processes that truly work for local organizers.

What motivated you to run for the PSF Board of Directors?

What motivated me to run was realizing that the sustainable growth of emerging ecosystems, particularly in Africa and CPLP nations, requires dedicated governance, intentional representation, and direct access to resources. After years of organizing the community, seeing firsthand the efforts and limitations of those who lead locally, I understood that it was time to bring these regional voices into the foundation's decision-making process, and not just continue asking the foundation to listen to us from the outside.

What problem or challenge do you want to address if you are on the board?

The issue I aim to address if elected to the board is the barrier to access and participation faced by organizers and educators in emerging regions. This translates into three concrete areas of action. First, simplifying application procedures to reduce the administrative friction encountered by community leaders organizing local PyCons, meetups, and PyLadies or Django Girls gatherings in Africa and other emerging regions. Second, fostering cross-border collaboration among chapters in Portuguese-speaking countries and across Africa through shared educational materials, translation initiatives, and localized mentorship frameworks. Third, expanding PSF and PyLadies mentorship structures to equip local community leaders with practical handbooks covering legal, financial, and operational aspects, thereby ensuring the long-term stability of these chapters.

Where do you see the PSF 5 years from now?

Over the next five years, I envision the PSF making concrete progress toward the goals the council itself has already put up for public discussion—particularly regarding regional community self-sufficiency and integrating inclusion into every decision rather than treating it as a standalone project. The foundation’s strategic plan emphasizes strengthening partnerships with community groups across the open-source ecosystem and supporting Python communities in building their own capacity through collaboration and shared resources. This is precisely where I want to contribute. I envision a PSF that translates these goals into tangible processes for organizers—whether they are running a Django Girls event in Maputo or a PyLadies meetup in Beira—by offering streamlined applications, translated materials, and structured mentorship. At the same time, the PSF would responsibly sustain critical Python infrastructure like PyPI and CPython, ensuring these efforts align with the foundation's actual funding and staffing capabilities. I see a PSF that is more transparent in its decision-making and fosters stronger connections between regional communities and central governance, ensuring that language and geographic distance no longer act as barriers to contributing to or leading in the open-source world.

What areas of the Python community are you involved with?

I am primarily involved with the PyLadies community, serving as a co-founder of the Maputo chapter and a mentor for the Beira chapter. I am also active in PyCon Africa, having participated as both a volunteer and a speaker. I have been a regular volunteer for PyLadiesCon since 2023 and co-organize workshops for beginners in Python, Data Science, and AI. I was honored with the Outstanding PyLady award in 2025 and have been an individual member of the Django Software Foundation since 2024, reflecting my ongoing commitment to education, diversity, and community organizing within and around the Python ecosystem.

 ------

Note from the election administrators: 

Want to learn more about this candidate or ask them a question? 

Check out their nomination statement.

Check out their AMA thread on discuss.python.org.

August 25, 2026 08:58 AM UTC

Christopher Neugebauer: 2026 PSF Board Election Candidate Interview

Who are you?

I'm an Australian software engineer, currently living in Petaluma, in the San Francisco Bay Area in California. I'm a long-time user and advocate of Python, I currently work as a Senior Software Engineer. 

What would you bring to the PSF Board of Directors?

This would be my third term on the board – I previously served from 2018-2021, and my second term started in 2023. In that time, I've been an advocate for growing, re-establishing, and re-growing the Grants program. I want to see the Grants program get back to full strength, but in a way that is sustainable for the long term. Our global community has come to rely on the PSF as a partner over the years, and the unpredictability of the grants program has been unfortunate. I've also got experience as a US-based conference organiser, and I want to continue stewarding PyCon US, so that it can return to being a contributor to the PSF's finances, rather than a break-even prospect.

I'm also the current board's go-to person for working on the administrative side of the Foundation, I understand our by-laws like the back of my hand (after amending them a number of times over the last few years), and help the board understand how to do the important work of uplifting the global Python community while still fulfilling the obligations of being a US-based non-profit.

What motivated you to run for the PSF Board of Directors?

I'm excited to continue the work I've been doing for the last few years, and want to continue serving as a source of institutional memory for the board. I'm also super excited to have adopted the foundation's 5-year Strategic Plan, and I want to be able to help the foundation put the new plan into effect. I want us to have a sustainable financial backing that lets us make the best decisions we can for a global community. independent of corporate or government influence. Python has done a great job of being in the right place at the right time over decades, and often that means taking a longer term view. I want us to continue being able to do that!

What areas of the Python community are you involved with?

I've been involved in the Python community in a number of countries for the last couple of decades. I ran PyCon Australia for a couple of years, and when I moved over to the US, I started the North Bay Python conference, here in Petaluma. I'm also a long-term volunteer at PyCon US – I helped run the lightning talks this year and last. Most of my volunteer time these days is spent on the board: it's a job that demands a lot of time, and I try to do that job well. You might also have seen me speaking at various Python conferences throughout the world.

 ------

Note from the election administrators: 

Want to learn more about this candidate? Check out their nomination statement.

August 25, 2026 08:58 AM UTC

Ee Durbin: 2026 PSF Board Election Candidate Interview

Who are you?

Hi, I'm Ee Durbin. I am a volunteer PyPI Administrator, contributor to the PSF Infrastructure, PSF Fellow, past PSF Staff member, and Previous PyCon US Chair. I live in Philadelphia and volunteer with Philly Bike Action to advocate for safer cycling infrastructure. I'm currently working on open-source high performance developer tooling on the Astral team, which recently joined OpenAI. 

What would you bring to the PSF Board of Directors?

Throughout the past thirteen years, I have taken on many roles and responsibilities across the PSF and have an appreciation for the way that the foundation and community interact from many perspectives. I hope to bring my understanding of the foundation's operations as well as its past challenges to service on the board.

What motivated you to run for the PSF Board of Directors?

I'm motivated to run for the board because I have attended _most_ board meetings from 2018-2025 and have interacted with the board in many ways as both a volunteer, staff member, and friend. I see the impact that the board can have to grow and sustain the organization. The Python community and PSF are important to me, and I want to contribute in ways that create new growth and sustainability.

What problem or challenge do you want to address if you are on the board?

The PSF has done a lot to meet the challenges of the past six years, specifically as it relates to the impact on PyCon US of increased contract costs and geopolitics. At the same time, immense shifts in the landscape of software security and the rise of LLMs have created new opportunities and challenges for the organization. Seeing these challenges through and coming out of them as a foundation that is durable to inevitable new challenges is a priority in my eyes.

Where do you see the PSF 5 years from now?

Pie in the sky, I dream of a PSF that is ever increasingly community focused and community supported. It is impossible to say what will come of the next 5 years, but I have much more certainty in the community who make up the PSF. I would like to see the PSF's core financial sustainability based on membership and individual donations, solidifying the organization's track record of accountability to the community above all else.

What areas of the Python community are you involved with?

My main involvement as of late has primarily been as a volunteer PyPI admin and I am focusing more recently on contributions to Python packaging tools and standards.

 ------

Note from the election administrators: 

Want to learn more about this candidate or ask them a question? 

Check out their nomination statement.

Check out their AMA thread on discuss.python.org.

August 25, 2026 08:57 AM UTC

Elaine Wong: 2026 PSF Board Election Candidate Interview

Who are you?

Hello, I’m Elaine! A Canadian who likes solving problems, building things, and bringing people together.

I grew up tinkering with computers, but I spent the majority of my career in journalism, doing everything from interviewing guests to directing live TV news programs. My journey into Python began in 2016 thanks to a PyLadies Travel Grant and someone telling me that Python could do magical things with Natural Language Processing.

Since then, I’ve been an active volunteer in the Python community. I’ve helped run local meetups like PyLadies and Python Toronto, organized regional events like PyCon Canada, and taught beginner-friendly intro to coding workshops through The Carpentries and NICAR to help folks from non-traditional backgrounds get into coding. Recently, you may have seen me serving as Chair of PyCon US, which gave me firsthand experience working closely with PSF staff, volunteers, sponsors, speakers, and community members across the entire ecosystem.

What would you bring to the PSF Board of Directors?

I bring a fresh perspective alongside more than a decade of community organizing experience, practical knowledge of how the PSF operates, and a viewpoint that bridges community, governance, operations, and technology.

During my time as PyCon US Chair, I learned a lot about how this non-profit works, where volunteers struggle, and how seemingly small organizational decisions can have huge consequences for the people doing the work. My journalism background also shapes how I approach governance: true transparency means explaining why decisions are made, not simply announcing what was decided. I’ll bring curiosity, clear communication, thoughtful problem-solving, and a commitment to asking how choices affect our broader community before we make them.

What motivated you to run for the PSF Board of Directors?

I’m running because I believe Python’s future depends on investing in people as seriously as we invest in infrastructure. I want to help build a PSF that supports its volunteers, strengthens regional communities, communicates clearly, uses its resources responsibly, and makes it easy for someone discovering Python today to become a contributor or community leader tomorrow.

What problem or challenge do you want to address if you are on the board?

One major challenge I want to address is the sustainability of our volunteer-driven community.

Python benefits from an extraordinary amount of volunteer energy, but passion isn't an infinite resource. Too often, critical knowledge lives with a small number of people, experienced organizers burn out, and new volunteers face unclear pathways into leadership.

I want the PSF to make community work easier rather than adding to its burden. That means:

• Better documentation and tools for local event organizers.
• Intentional mentorship and knowledge transfer.
• Clearer pathways for new contributors.
• Practical fundraising and operational guidance for regional groups globally.

Having spent years in the trenches as a volunteer, I understand both how rewarding this work is and how exhausting it can get. We need systems that allow people to contribute sustainably and hand off their work smoothly to the next generation of leaders.

Where do you see the PSF 5 years from now?

In five years, I see the PSF as a more sustainable, globally connected organization that continues to support Python as both critical technical infrastructure and an extraordinary human community.

I want regional Python communities everywhere to have access to resources, mentorship, funding guidance, and shared knowledge without needing to reinvent the wheel. I want contributors to see clear pathways from learning Python to contributing, speaking, mentoring, organizing, and leading.

I also want PyCon US to remain a financially sustainable, community-driven flagship conference while the PSF continues expanding investments in Python communities beyond the United States. Most importantly, I hope we preserve what made Python special in the first place: a truly welcoming community where someone can arrive from an unconventional background, find people eager to welcome and teach them, and eventually pass that experience on to someone else.

What areas of the Python community are you involved with?

My involvement spans conference organizing, global community building, local events, AV support, and education:

• PyCon US: Served as Co-Chair in 2024 and Chair in 2025 and 2026, working closely with PSF staff and volunteer teams.
• Regional & Global Conferences: Chaired PyCon Canada in 2018 (Co-Chair in 2019, organizer since 2016). Core organizer for csv,conf since 2015, helping run events in Germany, the U.S., Mexico, Argentina, Italy, and online. Volunteered with PyLadiesCon, and provided AV support for events like FlaskCon, PyCascades, PyBeach, and PyOhio.
• Local Communities: Involved with PyLadies Toronto and Python Toronto. 
• Education & Advocacy: Instructor with The Carpentries and instructor at PyCAR (NICAR's Python bootcamp for journalists). In 2026, I also spoke on the Women+ in Open Source panel at UN Open Source Week about building welcoming pathways into open source.

------

Note from the election administrators: 

Want to learn more about this candidate or ask them a question? 

Check out their nomination statement.

Check out their AMA thread on discuss.python.org.

August 25, 2026 08:57 AM UTC

Georgi Ker: 2026 PSF Board Election Candidate Interview

Who are you?

Hi, I’m Georgi, an independent entrepreneur, open source community organiser, and leader. I’m also a PSF Fellow and a recipient of the PSF Community Service Award.

Although I currently live in Amsterdam, I am proud to represent communities across Asia. I have served on the PSF Board since 2023. I also helped design PyCon US branding and websites since 2022 and for other open source community events and projects as well.

My contributions to the Python community span over many years, beginning mainly in Asia and becoming more international over time. Much of my work sits where people, governance, and community meet.

I care especially about the people doing the quiet work that keeps open source communities alive. They may not always be on the main stage, but the community would not exist without them.

What would you bring to the PSF Board of Directors?

Three years on the Board have taught me where the PSF is strong, where it is fragile, and where good intentions are not becoming results. 

As a former Treasurer, I raised concerns about the lack of a clear financial runway and pushed for stronger budgeting and regular financial planning. Through the Executive Committee, I have also participated in staff discussions, document reviews, difficult organisational decisions, and helped finalize the PSF’s long-delayed strategic planning process with the board.

My perspective is also strongly shaped by communities around the world. The work began from Asia and now includes PyLadiesCon, EuroPython, and regular discussions with global community leaders through the PSF Diversity and Inclusion Workgroup. Global representation at the PSF has improved, but it still remains incomplete.

I would bring institutional knowledge, experience in financial oversight and a global community perspective. And yes, I am willing to do the unglamorous work. 

I know more now than when I joined. I know what I am signing up for and how much work remains.

What motivated you to run for the PSF Board of Directors?

I am running because the past three years have shown me much more clearly what the PSF needs next. I’ve seen where the Foundation works well. I’ve also seen outdated financial assumptions, limited organisational capacity, unclear responsibilities, and decisions that could not be implemented because the necessary systems or that expertise were missing.

These are not exciting campaign topics but unfortunately, they matter.

Python is now part of the world’s infrastructure. Companies, governments, researchers, schools, and millions of developers depend on it. The organisation responsible for protecting Python must be able to plan beyond the next conference or sponsorship cycle.

I would like to continue helping the PSF build a more realistic base, improve its financial planning, strengthen its internal systems, and communicate more honestly with the community.

The next few years matter. That is why I am running again.

What problem or challenge do you want to address if you are on the Board?

The problem I most want to address is the PSF’s financial sustainability.

For years, PyCon US was a reliable source of income for the Foundation. After COVID, the economics and risks of large conferences changed. PyCon US should remain an important community event, but one conference should not be expected to carry the financial future of the organisation protecting Python.

The PSF needs realistic budgets and financial projections. The Board needs to understand the Foundation’s runway, commitments, risks, and future operating costs. Hope is useful in open source but less useful in accounting.

We also need to build sponsorship around Python itself. Companies benefit from Python every day, not only when their logo appears at a conference. Their support should help fund Python’s infrastructure, security, legal protection, trademarks, and global community.

This requires a serious review of the PSF’s business model. It also requires the right staff capacity and expertise to turn Board decisions into results.

I would like the PSF to professionalise the support around the community without professionalising the community out of Python. That distinction really matters. Volunteers and local organisers are not a cheap workforce. They are the reason Python has a community in the first place. 

Where do you see the PSF 5 years from now?

In five years, I would like to see the PSF be an organisation that plans with evidence instead of habit.

The PSF should be better equipped to protect Python’s trademarks, copyright, infrastructure, and identity. As Python becomes more important, this will require greater legal, financial, security, and organisational expertise. Goodwill alone cannot do all that work.

It should have a clear financial runway, realistic budgets, and dependable sources of income. PyCon US should continue bringing people together, but its financial performance should not decide whether the Foundation can support Python properly.

I would also like a more transparent PSF. The community should understand what the Board is working on, what the Foundation can afford, why major decisions were made, and what progress followed. 

Finally, the PSF should remain global and human. It should develop new leaders, support communities outside North America and Europe, and recognise capable people who may not be famous conference speakers. In fact, the board should consider reserving a few board seats for appointed directors with expertise that the Foundation needs.

The PSF should become more professional in how it operates without becoming corporate in how it treats people. Python’s community is not a side project. It is one of its greatest strengths and part of its unique model. 

What areas of the Python community are you involved with?

I have served on the PSF Board since 2023, including as Treasurer and currently as Vice Chair.

I currently chair the PSF Diversity and Inclusion Workgroup. I am also one of the organisers of PyLadiesCon and a member of the EuroPython Code of Conduct team. My earlier involvement included PyCon Thailand, PyCon APAC, founding PyLadies Bangkok, and other regional communities. I am also involved with the podcast PyPodcats featuring underrepresented Pythonistas.

Apart from that, I am developing Open Community Leadership through the fellowship with the Sovereign Tech Agency. The project focuses on mentorship, succession planning, sustainability, and helping communities prepare their next generation of leaders.

 ------

Note from the election administrators: 

Want to learn more about this candidate? Check out their nomination statement.

August 25, 2026 08:56 AM UTC

Jeremy Tanner: 2026 PSF Board Election Candidate Interview

Who are you? 

I'm Jeremy Tanner, an organizer, speaker, sponsor, Python developer, and community member. I'm based in North America, though many of my favorite people, places, and events are not. I've spent much of my career in the open Python ecosystem; packaging infrastructure, developer tooling, and the supply chains that get Python into the hands of pythonistas building everything imaginable. I believe the Python community should look like the world, not just the English-speaking, North American corner of it, and that sustainable finances are what make that vision achievable. I'm running for the PSF Board to do both: raise sustainable funds and resources, and make sure they reach everywhere.

What would you bring to the PSF Board of Directors?

Sponsorship for Python Foundations, Events, Organizations: I have direct experience securing corporate partnerships and sponsorships for the Python ecosystem, including navigating the internal processes of large companies to provide support to open source projects, infrastructure, and community gatherings. I’ve been on the organizing side as well, responsible for fundraising, programming, and attendee experience.

What motivated you to run for the PSF Board of Directors?

I wouldn't be here if it weren't for Python.

The PSF is the organizational backbone of the most important programming language in the world, and it is perpetually underfunded relative to its mission. Companies and the community benefit enormously from the PSF's work sustaining PyPI, funding sprints, and keeping the ecosystem healthy. Many are interested and capable of supporting further, but unsure how. I want to change that, and I want the resources generated to flow toward a Python community that genuinely reflects the mission's diverse and global users.

What problem or challenge do you want to address if you are on the board?

Build a sustainable corporate partnership program

The PSF has sponsorship tiers, but lacks a structured program for engaging companies at the scale their Python dependency warrants. I’m interested in working with PSF staff to design and execute a partnership program that makes it easier, and compelling, for companies, and others to contribute meaningfully. I've done this work both from the corporate side, and the position of organizer as well. I know what makes it succeed.

Invest in regional and international events

PyCon US has been the largest gathering, but is no longer running profitably. Python is spoken in Lagos, São Paulo, Jakarta, Warsaw, and the events, meetups, and communities in those places are where most of the world's Python developers live. The PSF grants program is the primary lever for supporting these communities, and it is chronically under-resourced. I’ll advocate for dedicated, predictable funding for regional and international events, not one-off grants that organizers have to re-apply for every year, but structural support that lets community leaders plan, grow, and mentor the next generation of organizers in their own languages and time zones. A Python community that looks like the world requires the PSF to invest across the globe.

Connect packaging infrastructure investment to the PSF's mission

PyPI is critical infrastructure, and its funding has historically been precarious. My background in packaging and distribution gives me the context to make the case, both to the board and to corporate partners, for why sustained investment in Python's packaging ecosystem is a strategic priority, not an afterthought. I want the PSF to be a more confident and articulate advocate for the infrastructure that millions of developers depend on daily.

Where do you see the PSF 5 years from now?

Celebrating Python's 40th anniversary. Strong, sustainable, with a growing staff & membership. Not a member yet? Please consider joining the PSF as a Supporting Member

What areas of the Python community are you involved with?

I've spoken at, sponsored, or participated in PyCon US, as well as PyLadies, PyCarribean, PyTexas, PyGotham, SciPy, PyData (Texas, London, New York, Seattle), North Bay Python, and meetups, have kept me grounded in what pythonistas across the community are building, struggling with, and asking for.

Packaging: Working with package maintainers and partners in order to see that all pythonistas are able to get the software they need. 

 ------

Note from the election administrators: 

Want to learn more about this candidate? Check out their nomination statement.

August 25, 2026 08:56 AM UTC

Kalyan Prasad: 2026 PSF Board Election Candidate Interview

Who are you? 

Hi, I’m Kalyan Prasad. My journey has been unconventional and shaped by persistence, self-learning, and community. I started working at a young age while continuing my studies, including delivering newspapers and milk. I later began my professional career in the financial services industry, working across operations and related roles.

Over time, I became increasingly curious about data and technology and decided to make a career transition. Coming from a non-technical background, I had a lot to learn. Through self-learning, continuous practice, and the support of communities, I moved into data science, later took on data and AI leadership roles, and today work as an AI and Data Science Practice Lead.

Python has been an important part of both my professional and community journey. I became involved with the Python community in 2019, starting as a room monitor at PyConf Hyderabad. Since then, I have grown from being a volunteer to organizing conferences, mentoring others, contributing to program committees and working groups, and taking on community leadership responsibilities.

For me, Python is much more than a programming language. It is a community that has helped me learn, grow, contribute, and build meaningful relationships. That experience continues to shape how I think about technology, opportunity, and community service.

What would you bring to the PSF Board of Directors?

I would bring the perspective of someone who has worked both inside community organizing and inside professional technology leadership. My Python community involvement began at the volunteer level and grew into organizing responsibilities across programs, sponsorship, logistics, speakers, volunteers, operations, and Code of Conduct work. That experience has helped me understand not only the visible parts of community events, but also the unseen work required to make them sustainable, inclusive, and valuable for participants.

Professionally, I bring more than a decade of experience across operations, data, technology, and AI transformation. In my current role as an AI and Data Science Practice Lead, I work with technical and business stakeholders, mentor teams, and contribute to strategic decisions. I have also worked extensively with startups and growing organizations, where I learned how to build teams, processes, and solutions from the ground up while balancing cost, growth, technology choices, and long-term value.

I believe this mix of experience would help me contribute to PSF Board discussions around sustainability, sponsorship, funding, partnerships, and long-term community growth. My work with sponsorship activities and with the NumFOCUS Small Development Grants Working Group has also given me practical experience in building relationships, reviewing proposals, and thinking carefully about how limited resources can create meaningful impact.

Most importantly, I would bring a willingness to listen. The Python community is large and diverse, and no single person’s experience can represent it fully. I would aim to support thoughtful, inclusive decisions that strengthen the PSF, reduce barriers for community organizers, and help Python continue to grow as a welcoming global community.

What motivated you to run for the PSF Board of Directors?

A lot of my motivation comes from my own journey in the Python community. I started as a room monitor at PyConf Hyderabad in 2019. At that time, it was simply an opportunity to volunteer and contribute. Over the years, people trusted me with more responsibilities, and I had opportunities to learn different aspects of organizing communities and conferences.

Today, one of the things I value most is seeing newer volunteers take on responsibilities and grow into visible community roles. In HydPy, I have tried to build this practice intentionally by training newer volunteers, giving them ownership, and gradually creating space for them to become the front-facing organizers of the community.

That has made me think a lot about how communities grow. For me, growth is not only about having more attendees or organizing more events. It is also about giving people opportunities to participate, learn, take ownership, and eventually help others.

That is one of the main reasons I decided to run for the PSF Board. The Python community has created opportunities for me to learn, grow, and contribute, and I would like to help create those opportunities for others. I hope to bring what I have learned through local, national, and international community involvement to a broader level and contribute to the PSF’s work in supporting a more sustainable, inclusive, and welcoming global Python community.

What problem or challenge do you want to address if you are on the board?

One challenge I care deeply about is the long-term sustainability of local and regional Python communities. From my experience organizing communities, I have seen how much work is often carried by a relatively small number of volunteers. When knowledge, relationships, and responsibilities remain with the same people for a long time, communities can become dependent on a few individuals, and it becomes harder to build the next generation of organizers.

At HydPy and PyConf Hyderabad, we have tried to address this by bringing newer volunteers into organizing responsibilities, supporting them as they learn, and gradually giving them ownership. My own journey also started with a very small volunteer role, so I have personally seen how important these opportunities can be.

If I serve on the Board, I would like to explore how the PSF can better support local communities in building stronger teams, sharing knowledge, developing future leaders, and accessing useful resources. This could include better ways to share organizing practices, support volunteer onboarding, connect communities with one another, and help local groups learn from what has worked in different regions.

I do not think there is one solution that will work everywhere. Local communities understand their own circumstances best. But I believe the PSF can play an important role in supporting and connecting them, so that communities become stronger, more sustainable, and less dependent on only a few people over time.

Where do you see the PSF in 5 years from now?

In five years, I would like to see the PSF even more connected with local and regional Python communities, helping more people find meaningful ways to participate in the wider Python ecosystem. Python has communities around the world, and each one operates in its own context. I believe the PSF can continue helping these communities access resources, learn from one another, and build stronger connections across the ecosystem while allowing local communities to decide what works best for them.
I would also like to see clearer pathways for people who want to contribute. Someone may start by attending a meetup or using Python, then become a volunteer, speaker, mentor, organizer, open-source contributor, or community leader. Making those pathways easier to discover and access would help bring more people into the community and support the next generation of contributors and organizers.

I would also like to see the PSF continue strengthening its long-term strategy around funding, partnerships, and resource allocation. As the Python ecosystem grows, careful prioritization will be important to ensure that limited resources are used where they can create meaningful impact, whether that is supporting maintainers, community programs, local events, grants, infrastructure, or new contributors.

Technology will continue to change, including the growing role of AI, but I hope the PSF continues to stay grounded in its community values. In five years, I would like the PSF to be a stronger global connector: supporting Python’s technical ecosystem, helping communities become more sustainable, and creating opportunities for people from different backgrounds, regions, and levels of experience to participate and grow.

What areas of the Python community are you involved with?

Most of my involvement in the Python community has been around community organizing, conferences, program activities, mentoring, community safety, and working group participation.

Locally, I am involved with HydPy and PyConf Hyderabad. I started volunteering with PyConf Hyderabad in 2019 and gradually took on different organizing responsibilities, eventually serving as Co-Chair and later Chair. I also served as Co-Chair of PyCon India in 2023, which gave me the opportunity to contribute to a larger national community effort.

Since 2022, I have also been involved in program and review activities for several conferences, including PyCon US, EuroPython, PyCon JP, PyCon APAC, PyData Global, JupyterCon, and SciPy. I have been part of the PyCon JP Program Team for the last three years and have reviewed SciPy scientific paper submissions for three consecutive years.

Beyond conferences, I am a member of the PSF Diversity & Inclusion Working Group and participate in the NumFOCUS Code of Conduct and Small Development Grants Working Groups. These roles have helped me engage with community safety, inclusion, funding, and support for open source projects from different perspectives.

In 2026, I was honored to receive the Python Software Foundation Q2 Community Service Award. I see this recognition not as a destination, but as encouragement to continue serving the community and taking on greater responsibility where my experience can be useful.

Through these experiences, I have learned from communities beyond my own and gained a broader view of both the strengths and challenges across the Python ecosystem. They have helped me understand how important it is to support communities not only through events, but also through thoughtful programs, safer spaces, funding, mentoring, and shared learning.

------

Note from the election administrators: 

Want to learn more about this candidate or ask them a question? 

Check out their nomination statement.

Check out their AMA thread on discuss.python.org.

August 25, 2026 08:56 AM UTC

Karo Ladino-Puerto: 2026 PSF Board Election Candidate Interview

¡Hola mundo! I'm Karo Ladino-Puerto, though most of the community knows me as Karobot. I'm Colombian, a PSF Fellow since 2020, and I've spent the last eight years building Python community infrastructure in my country alongside a lot of amazing people. I've co-led PyLadies Colombia since 2018, supporting chapters in Bogotá, Medellín, Cali, Bucaramanga, Boyacá and Santa Marta. I co-organized PyCon Colombia from 2020 to 2025, and today I'm one of three women leading Python Colombia, with the objective of reconnecting the Python communities across the whole country. In 2025 I co-founded Fundación Átoma with Carolina Gómez and Nicole Franco, a Colombian non-profit that trains women in programming and helps local organizers keep their tech conferences free.

By trade I'm a project manager, which mostly means I'm the person who notices the task nobody was assigned, asks the awkward question early, and keeps the timeline honest. It's the same skill I use in community work. I over-communicate on purpose, I'm detail-oriented to a degree that occasionally annoys people, and I still believe most good things don't need a big budget, just organization and consistency.

What would you bring to the PSF Board of Directors?

I ran for the Board in 2024. I'm running again because the question in front of the PSF has changed, and I think I can be more useful this time.

In 2024 we were mostly talking about growth. Today the Grants Program is running on a capped budget after last year's pause, PyCon US has run at a loss for three years, and the Foundation is operating with less than twelve months of runway. That isn't a communications problem, and it isn't only a diversity problem. It's a sustainability problem: how do you keep serving a community that keeps growing, with less money than you had previously?

What I'd bring is experience with exactly that. Latin American organizers have never had a big budget. We learned to build events, chapters and workshops with sponsorship money that wouldn't cover a single line item at a larger conference. I'd like the Board to hear that experience from inside the room, from someone whose entire trajectory happened outside the funding centers of the world.

What problem or challenge do you want to address if you are on the board?

It comes down to sustainability, and it has two sides.
 
One is the community side. Most organizers I know work with very little money, or none. How do we help them keep their impact, and grow it, like that?
 
The other is the industry side. Open source holds up the whole industry, the AI boom included, and more of the tooling is becoming closed. The people who keep it running are rarely recognized and almost never paid. The companies profiting from Python need to give something back.
 
Money touches everything. A lot of this gets done for love, but communities still need money for the basics to keep existing.
 
Still, part of what organizers need was never money. The PSF started here with the Community Partner Program, and I'd like to see it grow: introductions, shared infrastructure, organizers helping other organizers.
 
The other part is communication. The PSF has been very open about its finances this year, and the Spanish-speaking community can help spread that. People can't defend what they don't understand. I want PSF updates and calls to action to arrive in Spanish, on time. That helps fundraising too: people give when they understand what is going on.

What areas of the Python community are you involved with?

PyLadies is where I started and where I've stayed. I've co-led PyLadies Colombia since 2018, supporting the chapters in Bogotá, Medellín, Cali, Bucaramanga, Boyacá and Santa Marta with events, workshops, sponsorships and job pipelines.

On the conference side, I co-organized PyCon Colombia from 2020 to 2025 and handed it over in September of that year. I've co-organized Django Girls and Humble Data Workshops in Colombia and Mexico, and PyDays in Cali and Pereira. I've keynoted PyLatam and PyCon Bolivia, and spoken at meetups across the region.

Since December 2025 I've been part of the three-person team leading Python Colombia, whose one job is to reconnect local communities that had drifted apart from each other. It's slow, unfunded work, and a labor of love.

Inside the PSF, I'm part of the Grants and the Diversity & Inclusion Work Groups. And through Fundación Átoma, the non-profit I co-founded in 2025, we've reached more than 5,000 women, supported 10+ communities and built a network of 30+ national partners funding that work.

------

Note from the election administrators: 

Want to learn more about this candidate? Check out their nomination statement.

August 25, 2026 08:55 AM UTC

Keith Murray: 2026 PSF Board Election Candidate Interview

Who are you?

I’m Keith Murray.

I engage with a lot of Python Communities, often with the handle KeithTheEE, and I find that my favorite parts of the many communities are seeing the hobbies people have, and if/how Python intersects them. Hobbies and passion projects (including silly, fun passions) are one of the ways to make code matter, and are one of the things I’ve been falling back to of late to help balance against burnout: particularly when I feel overwhelmed by code ‘engagement’ that feels overly extractive. Discovering hobbies of other Python community members has made engaging feel like a collaborative and supportive experience, even if the code isn’t tied to the hobby at all.

I love (trying) to grow orchids, birding, and making pasta, and while I don’t involve Python in every aspect of it, hearing about how it resonates with others (constructive or destructively), like how some prefer begonias over orchids, never got birding but love their dogs, or the many foods from their home I now need to try--helps me look forward to reading comments on the item at hand. So I’m Keith, I like many things and I love how so many people make the code around me joyful.

What would you bring to the PSF Board of Directors?

My experience would help drive outreach to communities and direct small changes to help navigate the Python ecosystem and communities with an increased awareness of engagement opportunities. A particular interest is tied to PSF membership, and using it as a pathway for communication and building outreach to help inform people about the many ways to get involved and support the Python community. Because I’m interested in the Education and Education Resources side of things, I’m more aimed at the new user experience, and trying to maintain the “exciting new world/what can I do next” feeling new programmers have.

I add perspective on the impact of things like navigating the python.org website, and how it feels to those who are new and not from a programming background. This experience with outreach and newer community member navigation helps shape how I consider relaying information to those I think either want to know about it, or want to share it to those they know want to know. In a Board of Directors role, this perspective helps understand how choices are felt in the wider community, and shapes the way I’d encourage asking for feedback, input, and help with larger goals.

What motivated you to run for the PSF Board of Directors?

I am running for the PSF Board of Directors because I think my experience reaching out to lots of communities, and relaying their events in other spaces has helped me learn a lot about helpful outreach methodologies as well as perceived limitations in many communities. I particularly hope to shape the workflow of becoming a member, to make “being a part of the PSF” feel more meaningful, and to help direct the excitement of wanting to help into things which are impactful, but may not immediately be alluring.

Things like sharing events, commenting on an old issue if it is still present on your machine, operating system, python version, telling community members, “thank you” and that you like the things they did are all ways to help which can alleviate some burden or stress from staff and core team members, and guiding that branch of empowerment is something I think is valuable.

What problem or challenge do you want to address if you are on the board?

Funding the PSF, and ensuring that funding is reliable so long term, structural improvement can be made is the among largest challenges I see PSF currently facing. While improving the PSF Membership workflow might not be the most direct way to addressing overall PSF funding, a wider audience who’s aware of the financial needs of Open Source gives strength to the conversation in every company.

One of my biggest hopes for the next year is a formalized means to nominate individuals for PSF “Contributing Membership”, that way it’s easier to communicate how many people actually qualify for this class of membership. The wording of the membership is a non exhaustive list of ways people qualify, but many people don’t know it exists, or pre-emptively determine their efforts aren’t enough. There are so many who qualify and if they’re invited they’ll highlight all the other amazing community members they know. Building a network of celebration helps communicate a core reason funding the PSF is very important, and makes it easier for more community members to start that conversation within their companies.

Where do you see the PSF 5 years from now?

Because funding is among the biggest challenges, and is one that is unlikely to be resolved quickly, I think “Community Empowerment” will be one of the strongest aspects of the PSF in the years to come. There are many bodies for regional, domain specific, or identity specific Python groups, and I think maintaining and encouraging strong relationships with the larger community will help relay messaging, and help build up diverse leadership skills by having more events like CPython development sprints at various regional events. That wider net helps foster skills, enables local companies to invest in their local community while seeing its direct impact on the growth of Python as a whole, and hopefully provides chances for community engagement in a fashion that alleviates burdens.

Looking at the strength of the PSF Board of Director Nominees as well as Python Packaging Council nominees, it’s clear that there’s a massive amount of talent and each person has amazing experiences which inform the direction they want to help the PSF grow. Each of those is an area that strengthens the whole Python Community, and strong and well defined paths of empowerment and organization resources help ensure these initiatives continue to help Python thrive.

What areas of the Python Community are you involved with?

I’m a part of the PSF Education and Outreach Workgroup, a Director and Community Outreach Lead for the community run Python Discord, and help with PyOhio (As a volunteer this year, prior two years as a Communication Chair). Additionally I moderated the Python Subreddit from mid 2020 through mid 2023.

I do a lot of work focused on the outreach side of things, trying to listen to where communities have needs and connect individuals who have strengths in exactly that domain. There’s a fair amount of times where people just didn’t know something existed, or don’t know where to find a resource, and helping relay that information has been one of the areas I’ve found to be fulfilling. It has the added benefit of getting to meet a ton of cool people and seeing the amazing things they’re doing in Python, and how their hobbies outside of Python shape their code and community.

------

Note from the election administrators: 

Want to learn more about this candidate or ask them a question? 

Check out their nomination statement.

Check out their AMA thread on discuss.python.org.

August 25, 2026 08:55 AM UTC

Nina Zakharenko: 2026 PSF Board Election Candidate Interview

Who are you?

I'm Nina Zakharenko. I went to my first PyCon US in Santa Clara in 2013, and fell in love with the Python community. Since then, I've co-chaired PyCascades, taught Python to hundreds of students, and given talks, workshops, and keynotes at Python events around the world, including the closing keynote at PyCon US 2019. Professionally, I've held roles at Microsoft and Google focused on Python, open source, developer communities, and supply chain security. These days I work for myself, and I'm running as an independent candidate.

I served on the PSF Board of Directors from 2020 to 2023, including as Communications Co-Chair and Co-Vice Chair. After spending time recharging, I'm running again because I believe the Python community is entering a period of significant change, and I'd like to contribute my relevant experience to a community that has been central to my life and career for over a decade. Outside of work, I love to be creative with hobbies like 3D printing, ceramics, and stained glass artwork.

What would you bring to the PSF Board of Directors?

Three years of board experience, along with perspective from working across industry and community. During my previous term, I worked on initiatives around grants and helped introduce a more accessible membership tier. I also learned the less visible side of board work: fundraising, executive oversight, and recruiting new directors. That means I can start contributing quickly, and invest time in helping new directors onboard as well.

I've been involved in Python from many angles: as a software engineer, a conference organizer and speaker, and a teacher. At Microsoft and Google, I focused on open source and software supply chain security, and managed Microsoft's sponsorship and event presence at PyCon US and other Python events for several years. The PSF exists at an intersection of community, education, infrastructure, and sponsorship, and I believe directors with hands-on experience in those areas will help the PSF adapt to new challenges ahead.

What motivated you to run for the PSF Board of Directors?

What's pulling me back in 2026 is the sense that the landscape is changing quickly, both within and around the Python community. How open source is funded, maintained, and secured looks very different than it did a few years ago. So do conference attendance and sponsorship. As an educator and speaker, I'm hyper-aware that AI tools are changing how people learn to program, contribute to projects, submit to conferences, and share their knowledge. I believe the PSF, through its policies, grants, and working groups, has a role to play in how Python is taught in the age of AI, so that a new generation of programmers learns to read, comprehend, and debug code, and make meaningful contributions to open source.

This isn't new territory for me. I've worked on these problems as a contributor, an organizer, a PSF director, and in industry roles focused on open source and security. I'm running because I believe my experience is particularly relevant to the challenges the PSF faces today.

What problem or challenge do you want to address if you are on the board?

One of the biggest challenges is financial sustainability: as a non-profit, the PSF relies on donations to keep operating and provide critical services, like PyPI, that millions depend on.

While we'd like to see companies contribute in proportion to their use of Python, I'd love to help the board find new ways to bring in funds beyond events like PyCon US. After the PSF withdrew from a strings-attached NSF grant in October 2025, supporters donated over $150,000 and 295 new members joined within two weeks. I want to keep that momentum going through small recurring pledges from those with the means to give, and by spreading the word about employer donation matching at large tech companies.

The other side of the coin is how those funds are used: compensating the PSF's small staff fairly, and sustaining the grants and programs that shape the next generation of Python programmers. Those programs should reflect our global community, and continued outreach beyond North America and Europe is paramount. The $25 supporting membership we introduced during my last term opened the door to more people, and I believe there are more opportunities like it to welcome members from all over the world.

------

Note from the election administrators: 

Want to learn more about this candidate or ask them a question? 

Check out their nomination statement.

Check out their AMA thread on discuss.python.org.

August 25, 2026 08:54 AM UTC

Petr Andreev: 2026 PSF Board Election Candidate Interview

Who are you?

I am a Python educator, CPython-internals specialist, community organizer, and international Python speaker.

I teach Advanced Python and CPython internals, from memory management and interpreter architecture to free-threading and performance. My work increasingly focuses on turning technical education into real-world participation: research, open-source contribution, conference speaking, and leadership.

Before focusing on Python, I helped build an educational community of roughly 2,500 participants. I assembled an organizing team, secured external funding, and developed partnerships with companies, an endowment, and other organizations to support courses, competitions, speakers, and community programs.

These experiences shaped the model behind much of my work:
develop developers → develop contributors → develop community leaders.

What would you bring to the PSF Board of Directors?

I would bring experience building organizations and systems around technical communities.

I have worked on both sides of community development: developing individuals through education and mentorship, and building the infrastructure around them through organizing teams, institutional partnerships, external funding, events, and opportunities to lead.

I also bring an unusual combination of technical depth and community-building experience. I can communicate with CPython contributors about implementation-level problems, with educators about developing new talent, and with institutions and companies about partnerships and resources.

My international work across Europe and Asia gives me another useful perspective: the ability to listen across communities, identify problems that repeat across regions, and connect people who have already developed solutions.

What motivated you to run for the PSF Board of Directors?

One of the PSF’s strategic goals resonates particularly strongly with me: Develop the Next Generation of Python Developers.

I have spent years experimenting with this problem on a smaller scale and have seen students progress from learning advanced Python to researching its internals, contributing upstream, and presenting their work publicly.

I now want to work on the system behind that progression.

The PSF is uniquely positioned to connect communities, educational institutions, employers, sponsors, maintainers, and contributors. I am running because I believe these connections can make participation in Python easier to discover and more sustainable over the long term.

What problem or challenge do you want to address if you are on the Board?

Contributor retention.

Python attracts enormous numbers of users, but converting initial interest into years of meaningful contribution is much harder.

Open-source contribution competes with paid work, family, and other demands on people’s time. The question I want to work on is: how can the PSF make sustained contribution easier and more rewarding?

I would explore clearer contributor pathways, mentorship infrastructure, recognition, funded contributor time, and partnerships with employers and educational institutions.
I would also measure whether these mechanisms actually work: repeat contributions, retention, mentorship activity, increasing responsibility, and long-term participation.
The PSF does not govern CPython technically, but it can help create conditions in which contributors and maintainers are more able to stay.

------

Note from the election administrators: 

Want to learn more about this candidate or ask them a question? 

Check out their nomination statement.

Check out their AMA thread on discuss.python.org.

August 25, 2026 08:54 AM UTC

Ramya Ravi: 2026 PSF Board Election Candidate Interview

Who are you?

I'm Ramya Ravi, a Developer Advocate for AI and Open Source at NetApp Instaclustr, based in Connecticut. My day to day is teaching developers how to actually build with open source technology, not just read about it. I write technical tutorials, record videos, and speak at conferences, about things like vector search, retrieval augmented generation, and open source AI infrastructure. Python sits underneath almost everything I work on. The PyTorch and OpenSearch tooling I write about every week both run on it, so in a very real sense I've been a daily Python user for my entire career, even before I thought of myself as part of the Python community in the traditional sense.

Outside of work, I care a lot about lowering the barrier to entry for newer developers. Earlier in my career I built a developer community from zero to over 6,000 members, and watching someone go from lurker to confident contributor is honestly what keeps me doing this kind of work.

What would you bring to the PSF Board of Directors?

I'd bring three things: a track record of building community from nothing, a habit of teaching at scale, and a genuinely outside perspective. I grew a developer community from zero to 6,000+ members earlier in my career, so I know what it actually takes to onboard someone new, keep them engaged, and turn them into someone who helps the next person. I've applied that same instinct to technical education, writing tutorials and producing videos across multiple open source ecosystems with one consistent goal: make the next step easier for whoever is reading.

What I think is most useful, though, is that I come to Python from the outside in. My daily work sits at the intersection of Python, AI/ML, and open source infrastructure, which means I see how people who use Python constantly, but through frameworks built on top of it, experience the ecosystem. That's a growing and increasingly important slice of the Python user base, and I'd bring their perspective directly into board conversations.

What motivated you to run for the PSF Board of Directors?

Python is the layer underneath almost everything I build and teach. Every tutorial I write about PyTorch or OpenSearch is really a tutorial about Python doing something useful under the hood, and I realized at some point that I'd spent years benefiting from this community without ever putting energy directly into it. That felt worth correcting.

I'm also motivated by a specific pattern I keep noticing: a huge number of developers write Python every single day through AI/ML and data tooling, but many of them have never engaged with the PSF, attended a PyCon, or thought about Python as a community they belong to rather than just a language they use. I think that's a real opportunity. I want to help build the bridge between that audience and the PSF, using the same hands on, teaching first approach that's worked for me elsewhere, and turn "I use Python" into "I'm part of this community" for a lot more people.

What problem or challenge do you want to address if you are on the board?

I want to help the PSF reach the enormous number of developers who use Python daily but arrived through a specific framework or tool rather than through Python itself. AI/ML practitioners are a great example. Someone can spend years writing Python through PyTorch, Hugging Face, or OpenSearch tooling and never once engage with the PSF, attend a Python event, or think of themselves as part of this community. That's a missed opportunity in both directions: the PSF loses potential members, volunteers, and advocates, and those developers miss out on a community that could genuinely support their growth.

I'd like to work on lowering that barrier, through education content, event partnerships, and simply making the path into PSF involvement more visible to people who don't think of themselves as core Python developers yet. I think this matters more every year, as more of the fastest growing parts of the Python ecosystem are AI and data focused.

Where do you see the PSF 5 years from now?

I'd love to see the PSF recognized as the natural home not just for traditional Python developers, but for the much larger and still growing population of AI/ML and data practitioners who write Python every day through the tools built on top of it. Five years from now, I hope the PSF has stronger, more visible pathways for that audience: clearer education initiatives, more partnerships with the events and communities where these developers already gather, and a membership base that reflects how broad Python's real world usage has become.

I also hope the PSF continues to grow its global reach, so that community members anywhere in the world feel like there's an obvious way to get involved. Ultimately, I want the PSF five years from now to be an organization where someone who just uses Python for AI work feels just as welcome as someone who's been contributing to CPython for a decade.

------

Note from the election administrators: 

Want to learn more about this candidate? Check out their nomination statement.

August 25, 2026 08:53 AM UTC

August 24, 2026

---

Django Weblog

The Block and Tackle of Django&#x27;s Code of Conduct Working Group

In early 2026, Django's Code of Conduct Working Group adopted Contributor Covenant 3.0 as Django's Code of Conduct. I talked about why at DjangoCon US 2026 (slides here). That talk was mostly the story of how we managed the people side of the process. This post is the technical mechanics of how we managed the change and our work going forward.

Who can change what, and who has to sign off

The Code of Conduct Working Group is established by the DSF board and kept deliberately small. At least three people, per the working group manual, recruited for diversity of geography, background, and lived experience rather than just availability. Membership is volunteer and term-limited. Terms became annual in February 2026, and if a member doesn't respond to the January renewal check-in within a week, they're rolled off. Nobody has to feel guilty about stepping back.

The board isn't a separate, distant approval layer sitting above the working group. The DSF board's president always holds a seat on the working group and acts as its board liaison. Other board members can volunteer alongside them, and two currently do, in addition to the chair. Day to day, the working group operates independently. It only has to go back to the board for three things: spending money, taking a drastic punitive action, or altering the Code of Conduct text itself.

There's a second working group in the mix too. The Online Community Working Group handles routine moderation of Django's day-to-day spaces. It doesn't touch the Code of Conduct Working Group at all until something gets escalated: a formal report, a violation spanning multiple spaces, or an issue neither group can resolve alone. Each group appoints one of its own members as liaison to the other. If the two groups can't reach consensus on something that needs joint handling, either chair can send it to the board.

Inside the working group itself, decisions are made by consensus first. If that doesn't happen, a two-thirds majority of members without a conflict of interest can decide instead. If neither happens in a reasonable timeframe, it goes to the board.

The process for changing the process

Before anyone touched the Code of Conduct's actual text, the working group created a process for how changes get proposed at all. Issue #69, opened January 13, 2026, asked for exactly that. PR #70 answered it the same day by adding updates.md and a structured issue template for proposals.

The rules are plain. Anyone in the Django community can propose a change by opening an issue against that template. It asks what's changing, why, and whether it touches the CoC text itself or just supporting documentation. The working group can skip the full process for genuinely minor edits, things like typos, membership list updates, or FAQ tweaks. Everything else gets discussed at the working group's regular monthly meeting, with input from the wider community pulled in through the forum, Discord, or DSF Slack when a change is significant enough to warrant it.

Approval splits along the same line as the board relationship above. The working group can merge changes to supporting documentation on its own consensus. A change to CODE_OF_CONDUCT.md itself needs the board's sign-off first. That split isn't just written policy, it's enforced mechanically by a two-line CODEOWNERS file:

* @django/coc-committee
CODE_OF_CONDUCT.md @django/coc-committee @django/dsf-board

Every file in the repo requires the working group's review. CODE_OF_CONDUCT.md additionally requires the board's. GitHub won't merge a PR touching that one file without both. If you're setting up something similar, this is worth copying directly: two lines, and your governance policy becomes something GitHub enforces instead of something people are trusted to remember.

Additionally, we require a 30-day public comment period for all PRs that aren't administrative (fixing typos, updating membership lists, changelog updates, etc.). The working group can merge a PR after 30 days even if nobody comments, but if anyone does, the discussion has to be resolved before merging. This is the mechanism that makes the process public and transparent. It doesn't require anyone to read every comment, but it does require the working group to respond to them. You can use our workflow to enforce that for your project as well. There's two settings BYPASS_LABEL and MIN_AGE_DAYS to tweak the behavior, but the defaults are a 30-day wait and an expedited label that lets the working group skip it for administrative changes.

Once something merges, it gets announced on the blog, forum, social, whatever's appropriate for the size of the change, with a summary, the rationale, and links to what actually changed. updates.md even keeps its own tiny changelog at the bottom, tracking edits to the process document itself, separate from changes to the Code of Conduct. The governance model applies to itself.

Turning a rewrite into a project plan

Two weeks after updates.md landed, issue #74, "Adopt Contributor Covenant 3," opened and immediately spawned fifteen sub-issues (#75 through #89). Each one was a discrete deliverable: rewrite the Enforcement Manual, rewrite the Reporting Guidelines, rewrite the FAQs, rewrite the CoC text itself, sync all of it to djangoproject.com, then announce it, separately, on the Django blog, the forum, Discord, DSF Slack, and Reddit. A rewrite this size doesn't happen as one PR. It happens as a checklist of small, assignable, individually reviewable pieces.

The actual pull requests show how messy that still is in practice. PR #90 opened February 10 and closed the same day, unmerged. A first attempt at the policy rewrite that didn't pan out. PR #91, opened minutes later, was the one that actually worked: +1,475/-790 lines, merged five weeks later on March 16. PR #97 closed the loop on April 15 with a comparatively small +217/-90, formally adopting Contributor Covenant 3. Start to finish, from PR #68 (which first brought these docs into git for change tracking, back on January 10) to PR #97 merging, the whole rewrite took about three months. Most of which was us allowing time for the community to read, comment, and ask questions. The actual work was a few days of writing and reviewing.

The paper trail that replaces "trust us"

The same PR that added updates.md also added a GitHub Action that regenerates CHANGELOG.md automatically on merge. It's not a list of diffs. It's a list of decisions, in plain language, with the reasoning attached. One real entry from the April 15 rewrite:

📝 remove weapons policy since we don't host in-person events directly. this makes more sense as guidance for affiliated events so I'll move it there in the process-docs PR

That's a documented reason for a scope decision, sitting in a public file anyone can read without asking. Multiply that by every entry in the changelog and that's the actual mechanism behind "trust us" becoming "here's the commit history." Not a promise, a habit, enforced by a bot that runs on every merge whether anyone remembers to update the changelog by hand or not.

Our GitHub Action expects a script to be at scripts/update_changelog.sh in the repo. View ours at https://github.com/django/code-of-conduct/blob/main/scripts/update_changelog.sh

What happens after a report comes in

The process above covers how the document changes. Reports of actual violations run through a separate mechanism, described in full in the working group manual and the reporting guide.

Every report lands in one inbox, conduct@djangoproject.com, which fans out to the whole working group. The goal is acknowledgment within a day and an initial response within a week, though the manual is upfront that volunteer coordination sometimes takes longer than that. A decision on next steps needs at least two working group members to agree. Anything severe enough to warrant legal advice needs a majority. Outcomes run up the enforcement ladder: private warning, 30 to 90 day suspension, 90-plus day suspension, permanent ban. Lower rungs get skipped when severity calls for it.

The record-keeping is worth copying too. Every case gets a randomly generated code name, things like "home shelf" or "stunned bulb." Every reported person gets their own persistent code name, like "Person A" or "Blue Jay," so the working group can track repeat patterns across cases without a real name ever touching the primary tracking sheet. A second spreadsheet, access-restricted separately from the first, holds the only mapping from code names back to real identities. Most of the working group can discuss a case, even in public, without either of them knowing who it's actually about.

The code name generator

Those code names come from a small Google Apps Script bound to the tracking spreadsheet, not a service or a library where we're sending sensitive data off to a third party. To install it, open the spreadsheet, go to Extensions > Apps Script, paste the script into Code.gs, and save. Reload the spreadsheet and a "Django CoC" menu shows up next to the built-in ones.

To use it, select the cell where you want a code name and click Django CoC > Generate Code Name. It picks one adjective and one noun at random from two 100-word lists, joins them with a hyphen, and drops the result into the active cell (something like amber-anchor). If the cell already has a value, it asks before overwriting.

Record keeping spreadsheets

The record-keeping actually lives across three separate spreadsheets, each with a different level of access.

The Report Tracker is the working record. One row per case, using code names instead of real identities, with columns for status, resolution source, safety risk, and consequences. The code name generator menu lives on this sheet.

The Person Identity Key is a second, more restricted spreadsheet. It's the only place that maps a code name back to a real name, and it tracks report counts and the highest consequence recorded against that person across cases. Access to it can be limited to a smaller subset of the working group than the Report Tracker itself, so members handling a case can look for patterns without necessarily knowing who they're looking at.

The Public Tracker doesn't touch either of those directly. It pulls a single "Annual Stats" tab out of the Report Tracker with IMPORTRANGE, aggregate counts only (reports, people named, warnings, suspensions, bans, and so on), nothing case-level. That's the sheet behind the statistics Django publishes publicly.

Borrow honestly

None of this was invented from scratch, and the working group says so directly. sources.md traces the lineage: the Ada Initiative's anti-harassment policy, through PyCon 2013, into Contributor Covenant. The 2026 rewrite additionally drew on published enforcement materials from the Python Software Foundation, OpenJS Foundation, and Mozilla, each one cited with the specific license it was borrowed under. Django's own materials are released under CC BY 3.0 for the same reason, so the next community doesn't have to start from a blank page either.

Proof it's still running

The process didn't stop being used the moment PR #97 merged. PR #106 added Djangonaut Space as an affiliated program in May. PR #108 added Django Commons in July. Both went through the same lightweight path described in affiliated-programs.md: adopt a complementary CoC, name a point of contact, publish transparency reports at least annually. This wasn't a one-time project. It's infrastructure now, and it's still picking up new communities.

If you want to fork this

Start with updates.md and the issue template it depends on. That's the whole meta-process in about a hundred lines. Copy the CODEOWNERS pattern if you have anything resembling a board or steering committee that should have a harder veto than your day-to-day maintainers. Read the working group manual end to end before you build a report-handling process from scratch, most of the hard judgment calls are already made in there.

And if you want the record-keeping spreadsheets as actual templates instead of a description, here they are, cleaned of real data and history. Each link opens a "Make a copy" prompt instead of our live copy, so you get your own independent version:

1. Report Tracker, the case-by-case log with the code name generator built in
2. Person Identity Key, the restricted sheet mapping code names back to real names
3. Public Tracker, which pulls the Annual Stats tab out of the Report Tracker via IMPORTRANGE for anything you publish externally

Copying doesn't rewire them to each other. The IMPORTRANGE formula in your copy of the Public Tracker will still point at our Report Tracker, not yours, since Sheets copies the formula text as-is. After you copy both, open the Public Tracker, find the IMPORTRANGE formula on the Annual Stats tab, and replace our spreadsheet URL with the URL of your own copy of the Report Tracker. The first time it runs against the new URL, Sheets will show a #REF! error with an "Allow access" link. Click it once and the formula resolves.

A Code of Conduct is an exercise in trust. The processes and mechanics we've put in place are designed to make that trust verifiable, not just assumed. If you want to borrow them, please do. If you have improvements, please share them! We're available on email at conduct@djangoproject.com or open an issue against the working group repo and we'll respond.

August 24, 2026 02:00 PM UTC

• • RSS feed
  • Titles Only
  • Powered by Planet!
• Other Python Planets
  • Python Summer of Code
  • Planet Python Francophone
  • Planet Python Argentina
  • Planet Python Brasil
  • Planet Python Poland
• Python Libraries
  • OLPC
  • PySoy
  • SciPy
  • SymPy
  • Twisted
• Python/Web Planets
  • CherryPy
  • Django Community
  • Plone
  • Turbogears
• Other Languages
  • Haskell
  • Lisp
  • Parrot
  • Perl
  • Ruby
• Databases
  • MySQL
  • PostgreSQL
• Subscriptions
  • [OPML feed]
  • "Menno's Musings"
  • "Michael J.T. O'Kelly"
  • "Michael Kennedy's Thoughts on Technology"
  • "Michiel's Blog"
  • "Morphex's Blogologue"
  • "Speno's Pythonic Avocado"
  • "William's Journal"
  • 2degrees
  • A. Jesse Jiryu Davis
  • ABlog for Sphinx
  • Aahz
  • Abhijeet Pal
  • Abu Ashraf Masnun
  • Adam Pletcher
  • Adrarsh Divakaran
  • Agendaless Consulting
  • Ahmed Bouchefra
  • Al-Ahmadgaid Asaad
  • Alec Munro
  • Alex Grönholm
  • Alex Morozov
  • Alexander Limi
  • Alexandre Conrad
  • Alexandre Vassalotti
  • Alexey Evseev
  • Allison Kaptur
  • Amjith Ramanujam
  • AmvTek
  • Anarcat
  • Anatoly Techtonik
  • Andre Roberge
  • Andrea Grandi
  • Andrew Dalke
  • Andriy Kornatskyy
  • Andy Dustman
  • Andy R. Terrel
  • Anna Martelli Ravenscroft
  • Anthony Baxter
  • Anton Belyaev
  • Anton Bobrov
  • Antonio Cuni
  • Anwesha Das
  • Ari Lamstein
  • Armin Ronacher
  • Artem Golubin
  • Artem Rys
  • Ashish Vidyarthi
  • Astro Code School
  • Audrey M. Roy Greenfeld
  • Automating OSINT
  • Awesome Python Applications
  • Baiju Muthukadan
  • Bajusz Tamás
  • BeDjango
  • Ben Bass
  • Ben Cook
  • Ben Rousch
  • Benjamin Peterson
  • Benji York
  • Bertrand Mathieu
  • Bhavin Gandhi
  • Bhishan Bhandari
  • BioPython News
  • Bit of Cheese
  • Bob Belderbos
  • Bojan Mihelac
  • Brandon Rhodes
  • BreadcrumbsCollector
  • Brendan Scott
  • Brett Cannon
  • Brian Okken
  • Bruno Oliveira
  • Bruno Ponne / Coding The Past
  • Bruno Rocha
  • Caktus Consulting Group
  • Calvin Cheng
  • Calvin Spealman
  • Carl Chenet
  • Carl Düvel
  • Carl Trachte
  • Carlos Eduardo de Paula
  • Casey Duncan
  • Catherine Devlin
  • Ching-Hwa Yu
  • Chris Hager
  • Chris Miles
  • Chris Mitchell
  • Chris Moffitt
  • Chris Rose
  • Chris Warrick
  • Christian Heimes
  • Christian Ledermann
  • Christian Scholz
  • Christoph Schiessl
  • Christoph Zwerschke
  • CodeGrades
  • CodeSnipers
  • CodersLegacy
  • Coding Diet
  • Core Dispatch
  • Corey Gallon
  • Corey Goldberg
  • Cormoran Project
  • Cross-Platform Command Line Tools
  • CubicWeb
  • Curtis Miller
  • DSPIllustrations.com
  • DaPythonista
  • Daily Tech Video (Python)
  • Dallas Fort Worth Pythoneers
  • Dan Crosta
  • Dan Stromberg
  • Dan Yeaw
  • Daniel Bader
  • Daniel Nouri
  • Daniel Roy Greenfeld
  • Data Community DC
  • Data School
  • DataWars.io
  • Dave Beazley
  • David Amos
  • David Caron
  • David Goodger
  • David Lindelof
  • David MacIver
  • David Malcolm
  • David Szotten
  • Davide Moro
  • Davy Mitchell
  • Davy Wybiral
  • Declassed Art
  • Denis Kurov
  • Django Weblog
  • Djangostars
  • Doing Math with Python
  • Doug Hellmann
  • Dougal Matthews
  • Duncan McGreggor
  • Ed Crewe
  • Edward K. Ream
  • Eli Bendersky
  • Eniram Ltd.
  • Eray Özkural (examachine)
  • Erik Marsja
  • Etienne Desautels
  • EuroPython
  • EuroPython Society
  • Evennia
  • Everyday Superpowers
  • Fabio Zadrozny
  • Filip Wasilewski
  • Filipe Saraiva
  • First Institute of Reliable Software
  • Flavio Coelho
  • Flavio Percoco
  • Floris Bruynooghe
  • Frank Wierzbicki
  • François Dion
  • François Marier
  • Frederik Rietdijk
  • From Python Import Podcast
  • Full Stack Python
  • Gaël Varoquaux
  • Georges Dubus
  • Ghaandee on IT
  • Giampaolo Rodola
  • Giulio Fidente
  • Glenn Franxman
  • Glyph Lefkowitz
  • Go Deh
  • Gocept Weblog
  • Godson Gera
  • Graeme Cross
  • Graham Dumpleton
  • Graham Wheeler
  • Grant Baillie
  • Grant Rettke
  • Greg Taylor
  • Grig Gheorghiu
  • Grzegorz Śliwiński
  • Guido van Rossum
  • Gustavo Narea
  • Gustavo Niemeyer
  • Gökhan Sever
  • Hernan Grecco
  • Hilary Mason
  • Holger Peters
  • HoloViz
  • Hugo van Kemenade
  • Humberto Rocha
  • Hynek Schlawack
  • Ian Ozsvald
  • Ilian Iliev
  • Import Python
  • Inspired Python
  • Ionel Cristian Maries
  • IronPython-URLs
  • IslandT
  • Israel Fruchter
  • Itamar Turner Trauring
  • Ivan Velichko
  • J. Pablo Fernández
  • Jack Diederich
  • Jacob Perkins
  • Jahongir Rahmonov
  • Jaime Buelta
  • Jamal Moir
  • James Bennett
  • Janusworx
  • Jarrod Millman
  • Jean-Paul Calderone
  • Jeff Bisbee
  • Jeff Bradberry
  • Jeff Hinrichs
  • Jeff Shell
  • Jeremy Epstein
  • Jeremy Hylton
  • Jim Fulton
  • Joe Abbate
  • Joe Pitz
  • Johan Dahlin
  • John Burns
  • John Cook
  • John Jacobsen
  • John Ludhi/nbshare.io
  • Jon Parise
  • Jonathan Ellis
  • Jonathan Harrington
  • Jonathan Hartley
  • Jonathan Street
  • Jorgen Schäfer
  • Juan Manuel Contreras
  • Julien Danjou
  • Julien Tayon
  • Juri Pakaste
  • Just a little Python
  • Justin Mayer
  • Kai Lautaportti
  • Karim Elghamrawy
  • Kay Hayen
  • Kay Schluehr
  • Kelly Yancey
  • Kevin Renskers
  • Kodnito
  • Kogan Dev
  • Konrad Delong
  • Koodaamo
  • Kristján Valur Jónsson
  • Kriti Godey
  • Kulbir Saini
  • Kumar McMillan
  • Kumar Vipin Yadav
  • Kushal Das
  • Károly Nagy
  • LAAC Technology
  • Laurent Szyster
  • Leigh Honeywell
  • Lennart Regebro
  • Leonhard Vogt
  • LernerPython blog, from Reuven Lerner
  • Lintel Technologies
  • Linux Stans
  • ListenData
  • Logilab
  • Low Kian Seong
  • Luca Botti
  • Lucas Cimon
  • Ludovic Gasc
  • Ludvig Ericson
  • Luke Plant
  • Maciej Fijalkowsk
  • Made With Mu
  • Mahmoud Hashemi
  • Malthe Borch
  • Marc Richter
  • Marc-André Lemburg
  • Marcos Dione
  • Mariatta
  • Marius Gedminas
  • Mark Dufour
  • Mark McLoughlin
  • Mark McMahon
  • Martijn Pieters
  • Martin Fitzpatrick
  • Mats Kindahl
  • Matt Layman
  • Matthew Rocklin
  • Matthew Rollings
  • Matthew Wilson
  • Matthew Wright
  • Mattias Brändström
  • Mauveweb
  • Michael Becker
  • Michael Droettboom
  • Michael Foord
  • Michael Nelson
  • Michal Kwiatkowski
  • Michał Bultrowicz
  • Michele Simionato
  • Michy Alice
  • Mike C. Fletcher
  • Mike Driscoll
  • Mike Müller
  • Mikhail Korobov
  • Mikko Ohtamaa
  • Mirek Długosz
  • Mitchell Garnaat
  • Mitya Sirenef
  • Montreal Python User Group
  • Moshe Zadka
  • Moya Project
  • Mozilla Web Development
  • Muharem Hrnjadovic
  • Mycli
  • Nadav Samet
  • Naomi Ceder
  • Natan Zabkar
  • Ned Batchelder
  • Neil Schemenauer
  • Nick Coghlan
  • Nick Craig-Wood
  • Nick Efford
  • Nick Janetakis
  • Nicola Iarocci
  • Nicolas Dumazet
  • Nicolas Paris
  • Nigel Babu
  • Nikola
  • Nikolaos Diamantis
  • Not Invented Here
  • Nsukami Patrick
  • Obey the Testing Goat
  • Ofosos
  • Omaha Python Users Group
  • Ondřej Čertík
  • Paolo Melchiorre
  • Pathwright
  • Patrice Neff
  • Patrick Altman
  • Patrick Kennedy
  • Patrick Müller
  • Paul Everitt
  • Paul Harrison
  • Paul Redman
  • Paweł Fertyk
  • Pedro Lima
  • Peter Bengtsson
  • Peter Eisentraut
  • Peter Fankhänel
  • Peter Harkins
  • Peter Hoffmann
  • Phil Hassey
  • Philip Jenvey
  • Philipp von Weitershausen
  • Philippe Normand
  • Phillip J. Eby
  • Podcast.__init__
  • Polyglot.Ninja()
  • Possbility and Probability
  • Pradeep Gowda
  • Pranav Pandey
  • Praveen Gollakota
  • Programiz
  • Programming Ideas With Jake
  • Przemysław Kołodziejczyk
  • PyATL Bytecode
  • PyBites
  • PyCharm
  • PyCoder’s Weekly
  • PyCon
  • PyCon Ireland
  • PyPodcats
  • PyPy
  • PyTennessee
  • Python 4 Kids
  • Python 411 Podcast
  • Python Advocacy
  • Python Anywhere
  • Python Bytes
  • Python Celery - Weekly Celery Tutorials and How-tos
  • Python Circle
  • Python Data
  • Python Diary
  • Python Docs Editorial Board
  • Python Does What?!
  • Python Engineering at Microsoft
  • Python GUIs
  • Python Insider
  • Python Koans
  • Python Morsels
  • Python People
  • Python Piedmont Triad User Group
  • Python Pool
  • Python Software Foundation
  • Python Sweetness
  • Python User Groups
  • Python for Beginners
  • Python on Karan
  • Python with Myo
  • Python(x,y) News
  • PythonClub - A Brazilian collaborative blog about Python
  • PythonDebugging.com
  • Pythonicity
  • Pythonology
  • Python⇒Speed
  • Péter Szabó
  • Péter Zsoldos
  • Quansight Labs Blog
  • R David Murray
  • RMOTR
  • Ralph Bean
  • Ram Rachum
  • Randell Benavidez
  • Randle Taylor
  • Randy Zwitch
  • Raymond Hettinger
  • Read the Docs
  • Real Python
  • Red Hat Developers
  • Rene Dudfield
  • Richard Tew
  • Richard Wall
  • Rickard Lindberg
  • Rishi Maker
  • Rob Galanakis
  • Robert Collins
  • Robert Zaremba
  • Robin Parmar
  • Robin Wilson
  • Rodrigo Araúj
  • Rodrigo Girão Serrão
  • RoseHosting Blog
  • Ruslan Spivak
  • Ryan Cox
  • S. Lott
  • S. R. Krishnan
  • SDJournal
  • SPE Weblog
  • STX Next
  • Salim Fadhley
  • Sandipan Dey
  • Sandro Tosi
  • Sean McGrath
  • Sebastian Pölsterl
  • Sebastian Witowski
  • Selena Deckelmann
  • Senthil Kumaran
  • Seth Michael Larson
  • Shannon -jj Behrens
  • ShiningPanda
  • Simeon Franklin
  • Simeon Visser
  • Simon
  • Simon Brunning
  • Simon Wittber
  • Simple is Better Than Complex
  • SoftFormance
  • Speed Matters
  • Spike ekipS
  • Spyder IDE
  • Stack Abuse
  • Stanislas Morbieu
  • Starzel.de
  • Stefan Behnel
  • Stefan Scherfke
  • Stefanie Molin
  • Stein Magnus Jodal
  • Stephen Ferg
  • Steve Holden
  • Steven Klass
  • Stuart Gordon Reid
  • Stéphane Wirtel
  • Sumana Harihareswara - Cogito, Ergo Sumana
  • Suresh Dasari/Tutlane.com
  • Swisscom ICT
  • Talk Python Blog
  • Talk Python to Me
  • Taylor Edmiston
  • TechBeamers Python
  • Techiediaries - Django
  • Terri Oda
  • Terry Jones
  • Test and Code
  • TestDriven.io
  • The Data Scientist
  • The Digital Cat
  • The Lunar Cowboy
  • The No Title® Tech Blog
  • The Occasional Occurrence
  • The Open Sourcerer
  • The Parcon Blog
  • The Python Coding Blog
  • The Python Coding Stack
  • The Python Papers
  • The Python Show
  • The Three of Wands
  • Thibauld Nion
  • ThisHosting.Rocks
  • Thomas Guest
  • Thomas Vander Stichele
  • Tibo Beijen
  • Tim Arnold / reachtim
  • Tim Gilbert
  • Tim Knapp
  • Tim Lesher
  • Tobias Ivarsson
  • Tom Christie
  • Tomasz Ducin
  • Tomaž Muraus
  • Tomer Filiba
  • Tony Breyal
  • Toshio Kuratomi
  • Travis Oliphant
  • Trey Hunner
  • Tryton News
  • Turnkey Linux
  • Twisted Matrix Labs
  • TypeThePipe
  • V.S. Babu
  • Varun Nischal
  • Vasudev Ram
  • Vinay Sajip
  • Vinay Sajip (Logging)
  • Vinayak Mehta
  • Virgil Dupras
  • Vladimir Perić
  • Wayne Witzel
  • Weekly Python Chat
  • Weekly Python StackOverflow Report
  • Wes Mason
  • Wesley Chun
  • Will Kahn-Greene
  • Will McGugan
  • Will Pierce
  • William Minchin
  • William Reade
  • Wing Tips
  • Wingware
  • Wyatt Baldwin
  • Yair Lenga
  • Yaniv Aknin
  • Yann Larrivée
  • Yuval Greenfield
  • Zaki Akhmad
  • Zato Blog
  • Zero to Mastery
  • Zero-with-Dot (Oleg Żero)
  • ZeroDB
  • bottlepy-dev
  • codeboje
  • death and gravity
  • eGenix.com
  • hypothesis.works articles
  • kdev-python
  • meejah.ca
  • nl-project
  • pgcli
  • py.CheckIO
  • pygame
  • pythonwise
  • qutebrowser development blog
  • saaj/recollection
  • scikit-learn
  • testmon
  • tryexceptpass
  • Éric Araujo
  • Łukasz Langa
  • To request addition or removal, open a PR or issue