Planet Python

Last update: August 25, 2026 07:48 PM UTC

August 25, 2026

---

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

---

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'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

---

Python Software Foundation

The PSF D&I Workgroup is Starting Office Hours in July!

Starting Tuesday 28 July, 2026, the PSF Diversity & Inclusion (D&I) Workgroup is opening its virtual doors once a month on Discord. Come chat with workgroup members from all over the world!

Doing diversity and inclusion work in tech can feel isolating sometimes. You might be organizing a meetup, writing a code of conduct, trying to get funding for your community, or helping people feel welcome, often in your spare time, and wondering if anyone else is wrestling with the same things.

They are. We are! And we would love to get all of us in the same room.

This July, the PSF D&I Workgroup will be hosting monthly office hours within Discord. These will be open, text-based conversations where we encourage you to ask questions, sha
re what you are working on, and connect with other people who care about making the Python community more welcoming.

The details

The PSF D&I Office Hours will be on the last Tuesday of every month. Because our community is spread across the globe, we will alternate between two times so we can cover as many time zones as possible:

• 1 PM UTC / 9 AM US Eastern

• 9 PM UTC / 5 PM US Eastern

Our first session will be on Tuesday, 28 July 2026 at 1 PM UTC. Here is roughly what that looks like around the world:

Region	Local time on 28 July
US Pacific, Los Angeles – (UTC-7h)	6:00 AM
US Eastern, New York – (UTC-4h)	9:00 AM
Brazil, São Paulo – (UTC-3h)	10:00 AM
UTC	1:00 PM
West Africa, Lagos – (UTC+1h)	2:00 PM
Central Europe, Amsterdam / Berlin / Madrid – (UTC+2h)	3:00 PM
East Africa, Nairobi – (UTC+3h)	4:00 PM
Iran, Tehran – (UTC+3:30h)	4:30 PM
India, New Delhi – (UTC+5:30h)	6:30 PM
China, Beijing – (UTC+8h)	9:00 PM
Japan, Tokyo – (UTC+9h)	10:00 PM
Australia, Sydney – (UTC+10h)	11:00 PM

If 6 AM in Los Angeles or 11 PM in Sydney made you wince, do not worry. The August session will be at 9 PM UTC, and we will keep alternating from there.

You will find us in the #psf-diversity channel on the PSF Discord. If you’re new to Discord, check out some Discord Basics to help you get started. 

What will we talk about

Honestly? Whatever is on your mind related to Python, your communities, and D&I.

Since our workgroup exists to advise the PSF on diversity and inclusion, some conversations we are especially hoping to have include:

• Ideas for policies, initiatives, and grant proposals to diversify the PSF missions. Feedback from the community about these topics will help the PSF D&I Workgroup provide recommendations to the PSF Board of Directors.

• Your feedback, plain and simple. We want to understand how the PSF can better serve and grow a diverse membership, and we cannot do that without hearing from the community itself.

• How things are actually going. Part of our job is measuring and sharing the PSF’s progress on its diversity initiatives, and we would rather do that in conversation with you than in a report nobody reads. We also want to understand and learn about the current state of Python communities around the world.

No camera, no mic, no pressure

Office hours are text chat only.

Show up in your pajamas, join from the bus, lurk quietly for the first twenty minutes. It is all fine.

And if you cannot make it at all, the conversation stays in the channel, so you can catch up later when it suits you. If something in the chat sparks a thought you would like to share with us directly, you are always welcome to email the workgroup at diversity-inclusion-wg@python.org.

Bring your own language

Because we are the D&I Workgroup, our members come from around the world! Alongside the main conversation, we will open threads in other languages where possible. Depending on the presence of our members, we would be happy to chat in Spanish, Portuguese, Chinese, Hindi, French or even Persian! Let us know during the office hour if you have a specific language you hope to converse in, or jump in with whichever language thread feels like home.

See you on the 28th!

The first office hour session is on Tuesday, 28 July 2026 at 1 PM UTC, in #psf-diversity on Discord.

Come say hi, even if it is just to tell us what you are working on with Python. We are really looking forward to meeting you!

August 24, 2026 11:23 AM UTC

---

Python Insider

RISC-V is now officially supported by CPython!

I’m happy to announce that RISC-V platforms are now officially supported by CPython. 🎉 🚀

August 24, 2026 12:00 AM UTC

---

Armin Ronacher

Anger, Anxiety and Agency

Sean Goedecke wrote a post arguing that you should never be angry at work — a post with which I strongly agree. Anger can be a useful signal, but being angry at work rarely improves the situation. More often, it makes life worse for the people around you, many of whom have no more power over the source of your anger than you do. I did learn that lesson, but it did not come naturally. One thing in particular that I learned is that in a company there is a shared vision, and if you don’t agree with it and are not in a position to change it, you should not start a mutiny, not even a small-scale one. Nothing good comes from that.

In the discussion around that topic, one of the most upvoted comments on the Lobsters thread asked a question I had to think about quite a bit:

How can you work in tech right now and not be angry?

In the context of the thread, this was clearly also about AI and agents. For me, the emotions I would expect in tech vis-a-vis these new developments are disorientation and anxiety, but not anger.

Anxiety as an emotion does not require someone to blame. Right now, I find it reasonable to feel anxious about an uncertain future. Who knows what our professions will turn into and what kind of world my kids will find themselves in when they enter the workplace? And if you’ve been in the industry for a long time, will the skills you’ve spent years acquiring still matter?

But anger is different from anxiety because anger needs to be directed somewhere. The feeling of anger suggests that somebody or something is doing something to you.

Who are you going to be angry at and why are you angry in the first place? One narrative that is pretty pervasive is that if AI will usher in productivity gains, those gains are going to benefit companies rather than employees. And well at least someone at Meta wants that. Yet I also find that plenty of people in leadership positions express doubt about AI. They see that an increasing share of their costs is being funneled directly to some large AI labs. They express worries about what will happen to their data and whether these large companies will step into their space instead of being partners.

My answer to the question of how you can not be angry in tech is that it’s by no way the most only possible feeling. First of all, instead of being angry, you can simply be unsure. The feeling of uncertainty is a much more productive emotional state because it can lead to curiosity. Even if you don’t find what’s happening right now exciting, you can at least find it interesting. We have access to magic machines, and we can poke at them and see what happens. The second way is to feel genuine excitement. Once you move beyond curiosity, you can come away with a newfound feeling of power and freedom. A lot of the gains from AI aren’t turning into productivity gains that are reflected in company profits but they’re showing up instead in the number of side projects shipped by everybody not on their company’s time.

The fact that this is happening shows us that owners and founders don’t necessarily know what will happen. Ownership comes with agency, but it does not provide foresight, and this change is disorienting for everybody. I engage with plenty of people who project confidence in public and are much less certain in private. Many of them are placing bets, but they are talking with confidence about those bets, trying to keep their business afloat while the ground moves under them. They experience that uncertainty from a position where they can act on it, and they are often standing somewhere with a megaphone to get others on their side to improve their odds.

I feel that contradiction myself: I am simultaneously tremendously excited, but I am also unsure what will happen next. I do not know what it will mean to be a programmer in the future, and, as the owner of a company, I am also not sure where the high ground will be when this all settles. Much of what I learned over the years is changing rapidly, including ideas I considered fundamental to my craft and business. Some days that feels liberating, but on others I wake up feeling like the ground is crumbling beneath me.

Anxiety is an uncomfortable emotion because it acknowledges that you do not know what will happen and might not be able to stop it. On the other hand, anger can feel more actionable because, instead of saying “I don’t know,” you already have someone to blame. It turns a loss of control into a comforting story with a villain. But I feel that particularly when it comes to AI, it’s easy to pick the wrong villain because of how disruptive the change is for everyone. Your engineering manager or leadership team might themselves feel uncertain about their future and just try to bolster their own confidence by projecting clarity and certainty.

That does not mean there are no villains. When this all plays out, some will profit and many will not. I’m afraid we’re completely ignoring the impact this has on society at large, the climate, and the balance of the world as a whole. As excited as I am about the technology, I worry about Europe’s lack of ambition and growing dependence on other countries. I have a lot of complex thoughts about what we’re doing as an industry right now.

I don’t know what the future of this industry will look like, and I don’t know who will benefit from it and I don’t think I’m alone with that. However I can only urge anyone who feels anger and looks for a villain right to instead remain curious instead. To be curious enough to understand what is changing, excited enough to experiment with it. And then, from what we learn, earn the right to decide when resistance is warranted and where to direct it.

August 24, 2026 12:00 AM UTC

August 23, 2026

---

Kay Hayen

Nuitka Release 4.2

This is to inform you about the new stable release of Nuitka. It is the extremely compatible Python compiler, “download now”.

This release adds many new features and corrections with a focus on Python 3.14 official support, new installers for Windows and Linux (macOS already had one), and initial, experimental support for Python 3.15.

Bug Fixes

• Python3: Fix, nested generators did not make the exception being handled in the delegating generator visible to the code they delegate to, so sys.exc_info() gave wrong results there. (Fixed in 4.1.1 already.)

  import sys
  
  
  def inner():
      print(sys.exc_info()[0])  # 4.1: None (bug), 4.1.1: KeyError (correct)
      yield 1
  
  
  def outer():
      try:
          raise KeyError("caught")
      except KeyError:
          yield from inner()
  
  
  next(outer())
  

• Python 3.10+: Fix, compiled coroutines left the result of their send slot uninitialized when they finished by raising, so callers like asyncio could observe garbage values. (Fixed in 4.1.1 already.)

• Python 3.14: Fix, debug builds in module mode needed handling for the reference tracing runtime access, and adapted headers are no longer used for MSVC, where the compiler and runtime layouts match. (Fixed in 4.1.1 already.)

• Python 3.11/3.12: Fix, optimized class calls bypassing object_new did not initialize the managed dict inline values, so the first attribute assignment fell back to a separately allocated dictionary, which was non-optimal and caused incompatibility in corner cases. (Fixed in 4.1.2 already.)

• Python 3.11+: Fix, compiled frame locals were not stored in the interpreter frame localsplus slots, making them invisible to CPython frame introspection. (Fixed in 4.1.2 already.)

• Python 3.12+: Fix, the __type_params__ attribute of generic functions was always empty. (Fixed in 4.1.2 already.)

• Python 3.14: Fix, frame locals were cleared too late in the deallocator, after the code object and extra locals were already released, which could cause crashes. (Fixed in 4.1.2 already.)

• Python 3.14: Fix, type complaint exception messages now use the __qualname__ of the offending type, as CPython does. (Fixed in 4.1.2 already.)

• Python 3.14: Fix, the ctypes dependency configuration did not work in flavors where _ctypes is a built-in module rather than an extension module. (Fixed in 4.1.3 already.)

• Python 3.12+: Fix, the has_builtin_module helper of Nuitka package configuration did not return a boolean value, which could break conditional configuration. (Fixed in 4.1.3 already.)

• Standalone: Fix, standard library path detection for the “Python Build Standalone” flavor now considers symlinks in directory components. (Fixed in 4.1.2 already.)

• Plugins: Fix, mypyc runtime detection didn’t happen for submodules of a package, which affected at least the chardet module. (Fixed in 4.1.1 already.)

• Windows: Enables UTF-8 mode for attached consoles, since otherwise the CRT runtime could hang or corrupt outputs and inputs. (Fixed in 4.1.1 already.)

• Windows: Fix, multiprocessing was not fully working in onefile DLL mode, since spawning needs to point to the outer binary, not the DLL. (Fixed in 4.1.1 already.)

• Windows: Fix, memory issue for 32 bit Python onefile compression, where parallel zstandard compression ran into memory issues for even small files when using multiple threads. (Fixed in 4.1.1 already.)

• Windows: Fix, console attaching did not work for onefile DLL mode with runtime DLLs included, since the DLL uses a separate CRT instance with uninitialized stdio streams, so Python level output and input were not working. (Fixed in 4.1.3 already.)

• Windows: Fix, relative paths for the onefile temp directory specification did not work in onefile DLL mode. (Fixed in 4.1.3 already.)

• Windows: Fix, DLL dependency scanning failed when it encountered folders without read permission, these are now ignored. (Fixed in 4.1.3 already.)

• macOS: Fix, header padding is now also possible for --mode=dll, since otherwise install_name_tool cannot rewrite the load paths of the output. (Fixed in 4.1.1 already.)

• macOS: Fix, existing signatures of frameworks were no longer copied, as they became invalid after relocation and broke re-signing of the binaries. (Fixed in 4.1.1 already.)

• macOS: Fix, now handles another form of self dependency from absolute paths. (Fixed in 4.1.1 already.)

• macOS: Fix, detection of statically linked libraries did not work, since the file command output was not used yet, so they were treated like dynamic ones, leading to errors. (Fixed in 4.1.2 already.)

• macOS: Fix, now detects another variation of self dependencies, where a less-versioned binary depends on its more versioned self. (Fixed in 4.1.2 already.)

• Debian: Fix, --disable-ccache did not work when the compiler binary was a symlink, e.g. from the Debian ccache package. (Fixed in 4.1.2 already.)

• Linux: Fix, large constant blobs could cause linker errors on the x86_64 architecture, since the default small code model limits code and data to 2GB, now the medium code model is used in that case. (Fixed in 4.1.3 already.)

• AIX: Fix, potential memory leak in the dladdr helper. (Fixed in 4.1.3 already.)

• Fix, no longer depended on os.__file__ for detecting the standard library path, since that is not a usable path when Nuitka itself is compiled in accelerated mode, now types.__file__ is used instead.

• Fix, trimming the importlib bootstrap frames off the traceback on error exit now handles missing tracebacks, since very early failures can have no traceback at all.

• Fix, when creating generator, coroutine, and asyncgen objects, the assignment of closure variables was not checked for exceptions, so such assignments could be wrongly optimized away.

  def make(flag):
      if flag:
          raise ValueError
  
      x = 1
  
      def gen():
          yield x  # x is a closure variable
  
      return gen()
  
  make(True)  # must raise ValueError here
  

• Fix, when running a package main module with --python-flag=-m, the __spec__ value was None, breaking code that uses it, e.g. importlib.resources.files(), now a proper ModuleSpec is set.

  # package_main/__main__.py
  import importlib.resources
  
  # Running as "python -m package_main", this needs __spec__.
  print(importlib.resources.files("package_main"))
  

• Fix, for fixed import modules, accessing a missing import name used the attribute lookup and raised AttributeError, now it raises ImportError as CPython does.

• Fix, fixed imports that failed at runtime could segfault, now the failure is handled properly.

• Fix, the hard import modules site, pkg_resources, and importlib_resources are now treated as possibly raising, since they can be broken in broken installs.

• Fix, file listing no longer crashes on case-insensitive filesystems when a directory that needs to be ignored differs in actual case.

• Fix, the optimization was not fully deterministic, since iterating over the set of escapable variables had unstable ordering, causing behavior differences between otherwise identical builds.

• Fix, decoding of localized filenames only copied the bytes, so multi-byte characters in paths were not decoded at all. On Linux the environment locale is now respected with a UTF-8 fallback, and FreeBSD and NetBSD use the macOS UTF-8 handling.

• Python 2: Fix, when Nuitka itself was compiled by Nuitka, executing Scons could race on the import lock, since subprocess.Popen(close_fds=True) imports the resource module late, which is now pre-loaded.

• Python 2.6: Fix, re.sub(flags=...) does not work there, now a wrapper is used when flags argument is needed.

• Python 3.5: Fix, now uses PyImport_CreateModuleFromInitfunc for the meta path loader.

• Python 3.7+: Fix, the outermost iterator of an async comprehension was wrongly awaited, since whether the qualifier is async was not checked before wrapping, causing a TypeError at runtime.

  import asyncio
  
  async def source():
      yield 1
      yield 2
  
  async def main():
      # The outermost iterator of an async comprehension must be
      # a plain iterable, it must not be awaited.
      return [i for x in [1] async for i in source()]
  
  print(asyncio.run(main()))  # [1, 2], not TypeError
  

• Python 3.8+: Fix, when anext() or aclose() failed with “asynchronous generator is already running”, the asend and athrow wrappers were left unclosed, so using them again could misbehave.

• Python 3.9+: Fix, generic aliases did not release their values when being released, now they do.

• Python 3.11+: Fix, a __class_getitem__ set to None or a non-callable now makes the type non-subscriptable with TypeError correctly.

• Python 3.12.4+: Fix, throwing an exception into the asend or athrow wrappers of an already running async generator was not rejected, which could run the generator body concurrently.

• Python 3.13+: Fix, was rejecting clearing of suspended frames in general, now only generator-owned suspended frames are rejected, as CPython does.

• Python 3.13+: Fix, when adapting header files, an assertion in pycore_long.h referenced a stripped macro, causing link errors in debug builds.

• Python 3.14: Fix, now follows the CPython changes in async/await error messages and the with statement attribute lookup order.

• Python 3.14: Fix, reference count leaked the __annotate__ functions, now they are properly released.

• Python 3.14.7+: Fix, the error message for source files with encoding issues matches CPython 3.14.7 changes, where the byte position is reported relative to the seek point after the encoding declaration.

• Python 3.15: Fix, follow __cached__ module attribute removal.

• Python 3.15: Fix, follow the TypeVarTuple object changes.

• Python 3.15: Fix, follow the changes in duplicate parameter and encoding error messages.

• Python 3.15: Fix, follow the complex call argument error message changes.

• Python 3.15: Fix, the _math_integer extension module reports its __name__ wrongly as math.integer, which is now worked around as well.

• Compatibility: Fix, the __builtins__ value of compiled functions is not always a module, but can already be a dict, e.g. for functions created with exec, so accessing __builtins__ failed in those cases.

  import builtins
  
  namespace = {"__builtins__": vars(builtins)}
  
  exec(
      """
  def f():
      return 42
  """,
      namespace,
  )
  
  f = namespace["f"]
  print(f.__builtins__ is vars(builtins))  # must be True
  

• Plugins: Fix, permission errors during DLL and data file scans now give a clear error message pointing at the unreadable directory and its likely cause, instead of crashing outright.

• Plugins: Fix, replacements_re were not really working newline neutral.

• Plugins: Fix, now splits comma-separated --noinclude-qt-plugins just like --include-qt-plugins.

• Windows: Fix, the length check for generated C source filenames only considered the basename, so long build directory paths could exceed the path length limit, now the full path is budgeted and a hashed name is used when needed.

• Windows: Fix, removing an environment variable during startup did not clear the underlying process environment, so unset variables could still be visible to child processes, causing issues with PGO at times.

• Windows: Fix, prevented a file handle leak in the pefile-based DLL dependency detection, which is used for ARM64 or with --experimental=force-dependencies-pefile, since the PE file was not closed after use.

• MSYS2: Fix, DLL configuration paths were not normalized, which turned them into illegal paths errors during compilation.

• macOS: Fix, now checks for the create-dmg tool availability early during options processing.

• macOS: Fix, dependency scans no longer run into permission issues.

• macOS: Fix, no longer crashes at runtime on Chinese app names.

• macOS: Fix, now unlocks the keychain more robustly for CI and ssh contexts.

• Linux: Fix, onefile mode now links pthread explicitly, which older Linux versions require, since there pthread is not yet part of libc.

• Distutils: Fix, for --project the tool.nuitka options were not used.

• Distutils: Fix, using --project with a project that has no name set now gives a clear error message telling where to set it, instead of failing later in confusing ways.

• Distutils: Fix, the entry point options now pass the project name through, so --main-entry-point builds derive their output name from the project, and the misnamed --project-requires option was renamed.

• PGO: Fix, the Python PGO output is now initialized before the meta path loader, since probes during loader setup otherwise wrote to an uninitialized file handle and crashed.

• PGO: Fix, executing the compiled binary during Python PGO did not work for uninstalled Python, where the execution environment setup was missing. It is now executed via a script if necessary, and internal NUITKA_* environment variables are no longer passed to it, since they could cause the created binary to fail at runtime.

• Onefile: Fix, memory issues with parallel zstandard compression are now avoided on 32 bit Python in general, since the check is based on the Python itself rather than the x86 architecture, and Android 32/64 bit detection was corrected.

• Onefile: Fix, manually sent signals were not forwarded to the Python process in onefile mode, and on non-Windows the child process was not terminated on them at all. It now distinguishes signals from the terminal, forwarding only manually sent ones, terminates the child process on non-Windows, and suppresses duplicated SIGINT delivery to the child.

• Report: Fix, could crash when writing the report before the build directory was created.

• Zig: Fix, need to use the newest zig on macOS.

• Zig: Fix, produced binaries for the native CPU architecture of the compilation machine by default, making them not portable to older machines. Nuitka now creates machine portable binaries by default, with the new --target-arch option allowing to select a higher baseline ISA for speed.

• NoGil: Fix, frame objects are now owned by the frame object rather than the generator.

• NoGil: Fix, clearing list objects now stores the item pointer atomically and frees with shared-aware allocation in GIL-disabled builds.

• NoGil: Now tracks more connections in our tp_traverse methods of compiled types.

• UI: Fix, no longer emits a false missing-file warning for --include-data-files-external.

• AIX: Added COFF dump based DLL dependency detection, with various fixes to the parsing, e.g. ignoring hex values and exp archive members, column based parsing, more error checks, and listing only the native architecture.

• AIX: The Python DLL locating code is now more general, and a wrong structure entry for the dladdr helper was corrected.

Package Support

• Standalone: Added support for the pyDOE3 package. (Added in 4.1.1 already.)

• Standalone: Added support for the mssql_python package. (Added in 4.1.1 already.)

• Standalone: No longer proposes to recompile the charset_normalizer extension module. (Added in 4.1.1 already.)

• Standalone: Added support for the emoji package. (Added in 4.1.2 already.)

• Standalone: Added support for the mitmproxy package. (Added in 4.1.2 already.)

• Plugins: Fix, PyQt5 markdown data files caused errors on Linux, they are now excluded. (Fixed in 4.1.1 already.)

• Plugins: Added support for newer pkg_resources versions, where the EggProvider was removed. (Added in 4.1.1 already.)

• Plugins: Fix, build artifacts with .a, .prl, and .la suffixes in QML directories were no longer included, now they are included again. (Fixed in 4.1.2 already.)

• Standalone: Added automatic detection of cffi dependencies.

• Standalone: Added support for newer scipy.

• Standalone: Added support for newer sqlfluff.

• Standalone: Added support for newer datasets.

• Standalone: Added support for newest toga.

• Standalone: Added a workaround for deep recursion in the univers.maven package, where its list2tuple function was replaced with a non-recursive version.

• Standalone: Fix, platform specific gi modules are now included as well.

• Plugins: Fix, added the missing webview.platforms.win32 dependency for newer pywebview, and fixed accidental assignments instead of comparisons that caused too many modules to be included when Qt was used.

• Plugins: Detects Qt plugin XML and webview modules automatically.

• Plugins: Fix, avoided a warning when the gi module is not usable.

• Plugins: Added support for Tcl and Tk from zip files.

• Plugins: Fix, object files on Windows are now also ignored for PySide6.

• macOS: No longer needs the onefile workaround for PySide2.

• macOS: Added a workaround for a PySide6 packaging issue.

• macOS: Added a non-deployment handler for urllib.request, catching the common case where certifi is not used.

New Features

• Python 3.14: Pronounced Python 3.14 as officially supported.

• Python 3.14: Made deferred annotations the default mode.

• Python 3.14: Added support for module-level deferred annotations, and Python source generation for __annotate__ functions.

• Python 3.14: Added support for __annotate__ for classes, and delaying class level annotations when the --experimental=deferred-annotations flag is given. With 4.2, this is the default mode. (Added in 4.1.1 already.)

• Python 3.14: Added the --experimental=no-bytecode-to-compiled-fallback flag for requiring bytecode code generation to succeed.

• Python 3.15: Added initial support for compiling with Python 3.15.

• Python 3.7+: Added support for importlib.resources.contents and importlib.resources.is_resource, which had been overlooked so far. (Added in 4.1.3 already.)

• Python 3.12+: Added support for the no-argument form of importlib.resources.files() as well.

• Linux: Added support for app mode, creating a .desktop file for the compiled result, usable with standalone and onefile.

• Installer: Added an installer for Windows via NSIS with --windows-create-installer, and relocated the macOS DMG creation into the installer as --macos-create-installer.

• Installer: Added support for a Linux installer via AppImage with --linux-create-installer, using appimagetool from PATH or a cached download.

• OS400: Detects IBMi Python as a flavor.

• Plugins: Added the ability to resolve variable references to compile-time constants during tree building, used for pyqtgraph to resolve QT_LIB, enabling dead code elimination of unused Qt binding branches. (Added in 4.1.3 already.)

• Plugins: Added the onMetaPathLoaderEntryTemplate plugin method, allowing plugins to modify the template arguments used to generate the meta path loader entries for modules.

• Plugins: Added the ability to set defines differently for onefile builds and backend builds.

• UI: Added the --update-check option to check if a newer Nuitka version is available.

• macOS: Added the --macos-app-macos-min-version option for the minimum app version, and now sets CFBundleVersion.

• macOS: Added the --macos-app-category-type option to set the app category for the app store.

• PGO: Added the --pgo-python-error-exit option to control error-exit handling.

• Reports: Added totals for C compilation and linking as well, reporting the accumulated user and system CPU time and module count of compilation, and the CPU time of linking, next to the existing code generation totals.

Optimization

• Python 3.14: Added _zstd and _remote_debugging to the standard library modules known to never raise on import, allowing their imports to be optimized accordingly. (Fixed in 4.1.2 already.)

• Replaced our uses of PyCallable_Check with a direct tp_call NULL check, which avoids the expensive __call__ attribute lookup fallback that PyCallable_Check does.

• Runtime isinstance checks now use our own implementation with the faster type checking helpers, instead of the generic PyObject_IsInstance.

• Made the new style code objects the default. These are treated as constant objects now and remove the need for a special path to generate them. It reduces the generated code volume by a lot.

• Loop value traces for the same loop are now considered the same, regardless of being complete or incomplete, enabling more merging of optimization traces.

• The constant blob is now always created as an object file, removing the special Windows resource mode, and the blob creation code was made generic.

• Loader tables no longer need a NULL terminator, since the entry count is now passed into the using code, making them more compact.

• The shape of iter results is now always known, enabling more optimizations in general. As a consequence, os.uname()[0], the OS name, is now known at compile time, allowing platform checks based on it to be statically optimized.

• Added enumerate and zip built-in nodes, in preparation of full optimization for them.

• Expanded dual type operations with previously missing sub helpers, and fixed mistakes for existing ones.

Anti-Bloat

• Avoided more tkinter dependencies from PIL. (Fixed in 4.1.1 already.)

• Avoided including matplotlib due to pandas plotting. (Fixed in 4.1.1 already.)

• Avoided including setuptools_scm when using shtab. (Fixed in 4.1.3 already.)

• Avoided including setuptools when using vcs_versioning. (Fixed in 4.1.3 already.)

• Avoided using click when using httpx.

• Avoided a toga cleanup error during program shutdown on Windows.

Organizational

• Actions: Introduced an “integration” branch as an intermediate step before develop, for PRs that are not considered fully merge-safe, or that may hit a hotfix release instead.

• Project: Corrected a few mistakes done when changing the license, referencing the runtime exception everywhere and using a proper link to the correct version of the license file on the web. (Fixed in 4.1.1 already.)

• Debian: Made builds work inside containers that have the x-bit stripped from the install file, by making it an executable script. (Fixed in 4.1.1 already.)

• Release: Fix, the inline copy of atomicwrites was still needed for Python 2. (Fixed in 4.1.1 already.)

• UI: Fix, duplicate data file targets were not detected, which now warns and uses the first variant. (Fixed in 4.1.1 already.)

• RPM: Fix, the inline copy of atomicwrites was still needed for the update check, and is no longer executed during RPM builds. (Fixed in 4.1.3 already.)

• Release: Better error message for build failures in the PyPI release script.

• Zed: Added autoformatting on save for source files and Nuitka Package Configuration files.

• AI: Added the --assume-yes-for-downloads flag to autoformat commands.

• AI: Expanded agent guidance with a verification matrix, skill index, and syntax restrictions.

• AI: Made it clear that the issue template is to be followed strictly by AI assistants, and that issues ignoring it will be closed as invalid.

• AI: Disallowed local imports unless necessary.

• AI: Pointed to the CMD files for repo tools on Windows.

• AI: Modernized the agent config, removing cursor compatibility, splitting rules into multiple files, and dropping OpenAI and Gemini specific files.

• Visual Code: Also generated a clangd config for the OS/Python combination.

• Visual Code: No longer started the pylint check automatically.

• Modules: Merged upstream enhancements into the inline stubgen copy, improving the generated type stubs.

• Actions: Enabled Python 3.14 in CI.

• Actions: Dropped an unneeded requirements file installation in CI.

• Docs: Updated the man pages with the new CodeMeter plugin options.

• Plugins: Added separate plugin-warning and plugin-error levels for plugin messages in package configuration, allowing plugins to report errors.

• UI: Added {PYTHON_VERSION} and {PYTHON_VERSION_FULL} variables for project expansion, expanding to e.g. 3.10 and 3.10.11 respectively.

• Debugging: Added the --devel-no-bytecode-to-compiled-fallback option to check coverage.

• Quality: Added checker tools for pyright, basedpyright, ruff, and clangd, plus initial cleanups for fewer linter errors.

• Quality: Added --assume-yes-for-downloads support to the checker tools.

• Quality: Use PyLint from the private pip space.

• Quality: Autoformat now removes empty module configurations from the YAML package configuration, which had accumulated when config features were removed.

• Quality: The autoformat tool now outputs the diff when generated files would change with the --check option.

• Quality: Autoformat converts em-dashes to regular dashes in C files.

• Quality: Autoformat removes the spaces between words in spell-checker: ignore lines.

• Quality: The repo ruff configuration no longer formats, since our own autoformat is used, and more unwanted warnings were disabled.

• Quality: Autoformat now respects the exclusion of certain areas for JSON files and image files too, which it previously formatted and optimized regardless.

• Quality: The git pre-push hook no longer fails on submodules that are not checked out, skipping the missing files.

• Quality: The YAML checker no longer outputs traces on success, only reporting problems, and the autoformat progress bar total was improved.

Tests

• Disabled parts of the pkgutil_usage test with newer pkg_resources versions that lost some features. (Fixed in 4.1.1 already.)

• Ignored clang download warnings in output comparisons as well. (Fixed in 4.1.1 already.)

• Ignored differences from messages about Qt font usage in output comparisons. (Fixed in 4.1.1 already.)

• Rejected using --all and --pattern at the same time in the test runner. (Fixed in 4.1.1 already.)

• macOS: Ignored the libffi-trampolines.dylib system library used by Python 3.14 in test comparisons. (Fixed in 4.1.1 already.)

• Debugging: Fix, deep hashing checks failed with active exceptions, which was relatively easy to trigger, e.g. with SystemExit being set. (Fixed in 4.1.1 already.)

• Added support for compiled-only and uncompiled-only exclusive output lines to the output comparison tool, allowing tests of Nuitka-exclusive features while still comparing the rest of the output.

• Allowed file accesses under system library paths in tests for the Debian Python flavor, since its Python relies on system-packaged libraries.

• No longer update resume information for “only” search mode runs.

• Python 3.11+: Normalized traceback comparison by dropping the PEP 657 caret lines from CPython’s output, which Nuitka does not produce, and stripping blank lines between frames.

• Added --no-debug-immortal-assumptions to PySide tests.

• Linux: Allowed reading the /usr/share/zoneinfo directory itself in test file access checks, not just paths below it, since the system time zone info lives there.

• Added app bundle mode and signature verification to the comparison test tool, where the signature is verified before running, since some programs like Qt WebEngine modify themselves on launch.

• Python 3.15: Added support for running tests with it.

• Added a wait_for condition for test cases of nuitka-watch, where a case is skipped until the condition is met, used e.g. to wait for pip installs to start working.

Cleanups

• Fixed pylint warnings in the coverage rendering tool. (Fixed in 4.1.1 already.)

• Quality: Enforced the required versions for the private pipspace packages used for YAML formatting. (Fixed in 4.1.2 already.)

• Fixed the styling of links in informational messages, as the underline of the link was not reset and leaked into the following text. (Fixed in 4.1.3 already.)

• Quality: Updated to the latest ruamel.yaml package and stopped using its private interface. (Fixed in 4.1.3 already.)

• Generated internal class names in the node code now start with an underscore, so it is obvious they must not be used directly, and the stable alias names should be used instead.

• Cleaned up the pylint watching code.

• Watch: The nuitka-watch tool retries git operations on all platforms.

• Watch: The nuitka-watch tool outputs which pip update failed.

• Watch: The nuitka-watch tool writes XML reports like ElementTree does.

• Watch: Improved the automatic staging of changes of nuitka-watch.

• The warning about a missing clang-format binary now uses the shared once-per-warning mechanism, instead of a hand-coded flag.

• Completed the finalization of dead trailing statements, so that removed dead statements free their nodes properly when optimization removes them.

• Nuitka’s internal value hashing is now stable for dict values, with sorted items, where previously the insertion order was used. Since dicts with the same contents can have different insertion orders, equal dicts could hash differently, which matters for reproducible builds and caching, preparing this for future use.

• The Jinja2 inline copy no longer imports the pkg_resources inline copy unless PackageLoader is used.

• Windows: pdb files included as data files are now properly traced, avoiding warnings in onefile mode, and allowing manual copying of such files to be rejected in the future.

Summary

This release makes Python 3.14 officially supported, with deferred annotations becoming the default there, adds new installers for Windows and Linux AppImage and Linux app mode for desktop integration, and provides initial, experimental Python 3.15 support.

The Python source generation for __annotate__ functions might lead the way to better package support where source code is required elsewhere.

The new style code objects became the default, greatly reducing the generated code volume, and constant blobs are now always object files, removing the special Windows resource mode. Optimization work continues with faster type checks, more merging of optimization traces, and statically known shapes of iter results, making e.g. the OS name from os.uname() a compile time constant.

New enumerate and zip built-in nodes prepare for inline optimized re-formulations of them in future releases, promising exciting performance improvements, but for now the gains are not that much yet.

Python 3.15 support is experimental at best (with that version not being final yet), and merely initial, more work will be needed to get there.

August 23, 2026 10:00 PM UTC

---

LernerPython blog, from Reuven Lerner

AI seminars — just one of the big changes at LernerPython

July and August are often when people take a break or go on vacation. But for me, this summer has been super busy, full of writing and improving LernerPython based on feedback I’ve gotten from people around the world.

And so, I’m here with some big changes I’m making at LernerPython World Headquarters:

1. AI is so big, just keeping up with it feels like a full-time job. It’s also a technology that all developers need to know to get jobs and to be effective. That’s why I’m adding a monthly AI seminar to my LernerPython membership, with a lecture, practice session, and/or demo every month. The first one is tomorrow (Monday, August 24th) at 12 noon Eastern, and will talk about using Claude Code as a super shell, rather than for coding.

The AI seminars are part of a LernerPython membership — join here and you’re in for tomorrow’s session. (And if you’re already a member? Get Zoom info at https://lernerpython.com/event/august-2026-ai-session-claude-code-as-a-supershell/.)

2. My AI-based Socratic tutor is now live on LernerPython.com — trained on 30 years of my exercises, columns, and newsletters, so it teaches the way I teach. Ask it anything, whenever you’re stuck, in your native language (You’re still welcome to ask me questions at office hours and in Discord, of course!) Try a free sample at https://practice.lernerpython.com/classroom/540d7ab1a1/

3. Writing https://BambooWeekly.com continues to be one of my favorite activities, analyzing public data sets that have to do with current events. By definition, that means that older issues are less “current.” Moreover, there’s a real lack of good Pandas practice problems out there. For this reason, all BW issues are now completely free, once they’re two years old. Each issue contains 5-7 exercises, which means you now have access to hundreds of data-analysis exercises.

4. Until now, the first mention of a Pandas method in Bamboo Weekly linked to the official Pandas documentation. But that documentation is often a bit theoretical, and doesn’t point to the problems I see in class. I’ve added documentation for the Pandas methods I use in Bamboo Weekly, including (a) examples from past BW issues, (b) common mistakes, and (c) links to my YouTube videos (as appropriate). (And yes, you can even use it if you aren’t a Bamboo Weekly subscriber!) Check it out, at https://www.bambooweekly.com/pandas-methods/ .

5. Want to know what topics will I address in office hours this month? Or find a video from a previous month? The full calendar, as well as all recorded sessions from the past, are now available at https://lernerpython.com/event/.

The post AI seminars — just one of the big changes at LernerPython appeared first on LernerPython.

August 23, 2026 02:22 PM UTC

August 22, 2026

---

Ned Batchelder

Micro language implementation: Calcium

I wrote a tiny language implementation: Calcium. It’s meant as a demonstration of how languages like Python are implemented. It has a tokenizer, a parser, an AST, a compiler, bytecodes, and an execution engine, all in about 300 lines of code.

I did it because I often see the question: isn’t Python interpreted? Why do people say it’s compiled? (BTW, I also answered this in an earlier blog post: Is Python interpreted or compiled? Yes.) It can be hard to explain that your Python program never becomes an explicit sequence of native CPU instructions, which is what people often think “compiled” means.

So I coded up Calcium to have on hand the next time it comes up. I think it will help to be able to show the execution engine code reading bytecodes and doing what they say.

It could also be an interesting starting point for people wanting to play with a language implementation. It has almost nothing, so there’s lots of simple things (comments?) to add.

August 22, 2026 07:53 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