Planet Python

Last update: October 13, 2026 07:49 PM UTC

October 13, 2026

PyCoder’s Weekly

Issue #756: 3.15 Released For Real This Time, Muse, and More (2026-10-13)

#756 – OCTOBER 13, 2026
View in Browser »

CodeAF: 2x OpenCode’s and 4x Claude Code’s solves, same model

On DeepSWE, CodeAF solved 2× as many real GitHub issues as OpenCode and nearly 4× as many as Claude Code on the same open model, at up to 4.8× less per solved issue. A new open-source coding harness built for open models like DeepSeek, Qwen, GLM and Kimi, and it works with closed models too. Try CodeAF on GitHub
AGENTFIELD sponsor

Articles & Tutorials

Projects & Code

Events

Happy Pythoning!
This was PyCoder’s Weekly Issue #756.
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 ]

October 13, 2026 07:30 PM UTC

PyCharm

Two things are true about Python: It’s the most popular programming language in the world, and it’s the most common companion language for Go developers. How do we know that? From the Developer Ecosystem 2026 survey by JetBrains.

But we also know a lot more about the developers who use these two languages – both from quantitative data from different surveys, as well as qualitative data from our interviews with professionals who switched from Python to Go.

In this article, we share findings from these sources, going well beyond the simple syntax comparisons you will usually find. We will look at how the two languages differ, what the surveys tell us about the people who use them, and what our interviews say about the trade-offs between Python and Go, so that if you’re considering making the leap, you don’t have to dive in blind.

TL;DR

• The article compares Python and Go across language design, performance, tooling, developer profiles, and migration experiences.
• Python favors expressive code and rapid iteration; Go favors explicit, standardized code that is easy to maintain across teams.
• Go excels in raw performance and concurrency, and is widely used in cloud infrastructure. Python remains stronger for machine learning, data science, and scientific computing.
• Go developers are typically more infrastructure-focused and more senior. Go is rarely someone’s first language, whereas Python is very beginner-friendly.
• Python leads in building AI models, yet Go developers create AI integrations at nearly the same rate: 46% vs 44%.
• Moving to Go rarely means abandoning Python. Most teams use both, with Go for services and infrastructure and Python for AI and data workloads.

A note about the data

Unless stated otherwise, all survey figures come from the JetBrains Developer Ecosystem Survey 2026 (28,945 responses, fielded May–July 2026). We compare two groups: developers who selected Go among their primary languages (1,836) and developers who selected Python (11,298). The groups overlap, with 619 respondents selecting both languages. Therefore, every gap below is a conservative estimate of the real difference. Some questions were shown to only a part of each group, so bases are provided for reference. The qualitative material comes from interviews with developers who moved production workloads from Python to Go. We conducted the interviews between April and May 2026 and included seven participants who began using Go within the past year.

Python vs Go – languages compared

Core philosophy

On paper, Python and Go sound like they’d get along. Python lays out the core principles in the Zen of Python: Simple is better than complex, readability counts, there should be one obvious way to do it, etc. Go, as per Effective Go, “focuses on simplicity, reliability, and efficiency”, and is “specifically designed to make it easy to build software at scale”.

In practice, Python often optimizes for the person writing the code, offering multiple ways to say the same thing. Go optimizes for the person (or, nowadays, possibly the agent) reading someone else’s code two years later, so it picks one way to say most things and makes you spell it out. The goal is for all Go code to look like other Go code.

We point this out right at the beginning, because however similar these two philosophies look, this difference in approach underlies almost all the other language design differences that follow.

Ease of use and learning curve

Python is arguably one of the easiest programming languages to learn among those widely used in production. The syntax resembles natural language, the core set of constructs is small, and beginners can focus on programming ideas instead of language mechanics, leading to less frustration and faster results. Surveys consistently show Python to be one of the most popular programming languages (if not the most popular). In 2026, 10% of Python developers have been coding for less than a year, 23% are students or working students, and 19% hold junior positions, showing the language has a strong early-stage user base.

Python’s popularity among early learners is almost self-perpetuating. Initially, the language was well-suited to introductory courses and learning materials largely because it lets beginners print “Hello, world” with little ceremony, bypassing much boring theory in favor of real outputs. It also has the added benefit of being a generalist language that can handle a variety of use cases. Later, the sheer number of introductory courses and learning materials made it a natural choice for anyone who wanted to pick up programming but didn’t know where to start.

It’s not the same case with Go. In fact, you would be hard-pressed to find courses that teach you programming through Go. There are two reasons for that. First, Go 1.0 was released in 2012, long after Python had already become firmly embedded in CS curricula. The other is that Go solves problems that beginners don’t have. Explicit error handling, static types, and interfaces, which we’ll discuss later, all pay off across a large codebase maintained by a team over years. Go also has a much narrower set of implementations than Python, which makes it even less appealing for beginners.

That said, Go was also designed to be easy to learn, but for a different reason: Any large team should be able to onboard a new engineer quickly. Many Go developers will say that if you already know general programming concepts, you can become productive in Go in a matter of days or weeks. Developers we talked to said that Go “feels as easy to write as Python” and that it “strikes a good balance between Python’s simplicity and Java’s explicit nature”.

Syntax and readability

When you read Python, you can often follow it even without programming experience, because it reads relatively close to English. Python is dynamically typed, so type declarations are optional, though in practice, many companies and large codebases now write Python with type hints throughout, checked by tools like mypy or Pyright. Most of the ecosystem follows the formatting conventions set out in PEP 8, but they are still optional, and so some teams diverge from them.

Go, by contrast, is explicit and deliberately limited, which contributes to the cross-team readability we mentioned. It is statically typed, which makes it noticeably more verbose than Python. That was the main syntactic complaint raised by the developers we interviewed. Formatting in Go is not a matter of preference: gofmt will shape your code into the canonical form, whether you like the conventions or not.

One syntactic difference that developers consistently pointed out as a big adjustment when moving from Python to Go was error handling. Python lets you push failure handling to the edges of a function with try / except. Experienced Go developers clutch their pearls at the sight of that.

# Python: handle failure where it is convenient
try:
    profile = get_user(user_id)
except UserNotFound:
    return render_404()

// Go: handle failure where it happens
profile, err := getUser(userID)
if err != nil {
    if errors.Is(err, ErrUserNotFound) {
        return render404(w)
    }
    return fmt.Errorf("get user %s: %w", userID, err)
}

The Go version is longer, and in a large handler, developers will find themselves writing the if err != nil boilerplate ad nauseam. In return, they get control flow with no invisible jumps: Every path a value can take is explicit. Both approaches come with trade-offs.

Type system

Python’s dynamic typing checks types at runtime. This gives developers flexibility in writing and can speed up iteration, but it also means some type errors only show up when the code runs. The flexibility extends to the object model, which relies on duck typing: The code cares less about what an object is than what it can do. The developers we interviewed said they sorely missed duck typing, as it makes testing and mocking more difficult in Go.

Go checks types before the program runs. This results in fewer type-related failures reaching production and makes refactoring safer, but also causes code verbosity, as we touched on earlier.

Object model and polymorphism

Python is object-oriented in the way that most developers first learn the term. Everything is an object, and classes inherit from other classes (several at once, if you insist). Polymorphism works in two ways: down the class hierarchy when a subclass overrides its parent’s method, and sideways through duck typing, where anything with a read() method can be handed to code that expects a file.

Go has none of that hierarchy. There are no classes, no inheritance, and no way to declare that one type is a subtype of another. Instead, structs have methods attached to them, as well as interfaces that types satisfy implicitly without ever naming them.

# Python: the implementation announces its role
class Store(ABC):
    @abstractmethod
    def get(self, key: str) -> bytes: ...

class RedisStore(Store):
    def get(self, key: str) -> bytes:
        ...

// Go: the consumer declares what it needs; RedisStore never mentions Getter
type Getter interface {
    Get(key string) ([]byte, error)
}

func handleRead(g Getter, key string) ([]byte, error) {
    return g.Get(key)
}

Notice how the dependency runs. In Python, RedisStore inherits from Store, so the abstraction sits with the implementation. In Go, handleRead declares the one method it actually calls, and RedisStore never learns that Getter exists. That’s why Go developers say to “accept interfaces, return structs”, and that’s why interfaces stay small – io.Reader and io.Writer have a single method each.

Performance and speed

Go follows a traditional compilation model, producing a native binary. Python, on the other hand, takes a hybrid approach: Source code is compiled to bytecode, which the interpreter then executes.

As most compiled languages do, Go wins in terms of raw speed. You can compare the patterns across latency, throughput, and startup time on The Computer Language Benchmarks Game. Microbenchmarks like these don’t really translate directly to real workloads, and we wouldn’t be surprised if you made nothing of them. Our interviewees told us what the difference meant in production for them: One team migrated to Go after cold starts on AWS Lambda in Python exceeded 10 seconds; another measured a tenfold improvement in request times after rewriting their Python service in Go.

But raw language speed matters only when your service is actually compute-bound or latency-sensitive, and plenty of services are neither. Equally importantly, the Python interpreter is not slow where it counts most for one of its largest user bases. In machine learning, data work, and numerical computing, libraries like NumPy and PyTorch offload expensive operations to optimized native code, making interpreter overhead much less relevant. When we asked migrating developers where they decided to keep Python code, they confidently listed all AI and ML workflows – LLMs, chatbots, RAGs, and model training.

Memory management

Memory management is another important part of the performance discussion. Both languages manage memory for you, but differently: Go uses a tracing garbage collector, while CPython uses reference counting alongside a cyclic garbage collector. This affects what developers can fine-tune and what they need to design around.

Go’s GC runs concurrently with the program and is designed to minimize stop-the-world pauses. Developers can tune this behavior: GOGC and GOMEMLIMIT set the pacing, and the memory profile (heap and allocs) tells you when a service allocates too hard.

In CPython, an object is typically freed the moment its last reference disappears. Memory use is predictable, and pauses are rarely worth measuring, but the cost is spread across every operation, and there’s little to room tune it.   

Concurrency and parallelism

Even though both languages support concurrency, developers we talked to cited better concurrency as the reason why they switched from Python to Go.

Goroutines are central to Go’s design. They are lightweight threads managed by the runtime. They are cheap to create, carry little overhead, and scale to thousands of concurrent operations. The runtime handles the scheduling, which makes the model simpler than in Python – there is no separate async/await syntax, so a function is just a function. However, if you start to spawn goroutines without controlling their lifecycle, you’d better be ready to deal with race conditions, leaks, and deadlocks before long.

The other half of the concurrency model in Go are channels – typed conduits that pass values between goroutines and synchronize them. Instead of guarding shared state with a lock, Go can pass the value to whichever needs it next. A select statement waits on several channels at once, which is how Go expresses timeouts, cancellation, and fan-in using built-in language constructs. These very same primitives also produce common Go bugs: goroutine leaks and more deadlocks. 

Meanwhile, Python relies on standard libraries, single-threaded event loops, and sub-processes to work around interpreter constraints. It offers threading, but in CPython, the global interpreter lock (GIL) has historically prevented threads from running Python bytecode simultaneously, making it ineffective for CPU-bound parallelism. For I/O-bound concurrency, there is asyncio, and for real parallelism there is multiprocessing, but that adds memory overhead and requires inter-process communication.

It’s worth noting that the GIL itself is no longer a necessity – starting with Python 3.13, PEP 703 introduced an officially supported free-threaded build, and 3.14 continues that work. Most production code still runs with the GIL in place, but with each new release, the claim that “Python can’t do real threading” is becoming less true.

# Python: async/await, and the coloring that comes with it
async def fetch_all(urls):
    return await asyncio.gather(*(fetch(u) for u in urls))

// Go: ordinary functions run concurrently
var wg sync.WaitGroup
for _, u := range urls {
    wg.Add(1)
    go func() {
        defer wg.Done()
        fetch(u)
    }()
}
wg.Wait()

The approach to concurrency gives Go much of its practical advantage in high-throughput services, and having experienced both, our interviewees praised Go for being “async by default” and better suited for high-concurrency components, and they described it as having a superior concurrency model that’s highly performant and appealing for real-world use cases.

Libraries, frameworks, and IDEs

Go’s self-contained ecosystem

Go was never built as just a programming language, but as an ecosystem. As the Go team puts it, the goal was “an end-to-end platform with tooling all around the software development lifecycle” (Google for Developers), with formatters, test frameworks, dependency management, and security tools included in the toolchain, alongside a standard library that’s comprehensive enough to make external frameworks optional, if not irrelevant.

The Developer Ecosystem 2026 survey shows how successful the Go team has been in achieving that goal. For example, among Gophers, the standard html/template and text/template library packages are used by 31% and 22% of developers respectively, whereas the only other significant alternative – templ – is used by 11%.

Almost half of Gophers either don’t write unit tests or don’t use testing frameworks: 14% don’t write unit tests at all, and 35% don’t use frameworks for testing – the testing package provides everything they need in that regard. Others may also reach for tools such as Testify (31%) or GoMock (25%). The remaining libraries are far less popular.

For web development, 46% of developers use the standard net/http library, compared to 48% who use Gin. This proves that where a third-party framework exists, it doesn’t compete with the many other frameworks, but only with the standard library. Oftentimes, it loses.

Python’s broad ecosystem

Python’s ecosystem works the other way around. The Python Package Index (PyPI) is vast and mature, and where the standard library stops, several strong alternatives tend to compete.

Take web frameworks, for example. Half of Python developers use FastAPI, and Django (31%) competes closely with Flask (30%). The data science landscape is more fragmented, and developers use those libraries simultaneously: 69% use NumPy, 68% use pandas, 50% use PyTorch, 49% use Matplotlib, etc. With Python, there’s often no clear leader, and choosing the right framework or library is part of the job.

IDEs & editors

When it comes to editors, we see a similar pattern unfold. Go has an excellent language server, which makes general-purpose editors a viable alternative to a Go-specific IDE. When asked which IDEs or editors they use for Go development, 49% reported using GoLand, while 48% reported using VS Code. 

One reason is how much of Go’s surrounding ecosystem developers can access without having to assemble it themselves. GoLand installs with a test runner, debugger, coverage, and profilers wired into the toolchain. The analysis runs across the whole project, rather than only the open file. Interprocedural nil checks and unhandled-error inspections can catch the mistakes a Python developer might otherwise only see at runtime. Suffice it to say, Alan Donovan of the Go team has also described traditional IDEs like ours as setting “the gold standard” for refactoring because of their tight integration between the analysis logic and the user interface.

The Python side is more fragmented and has more Python-specific options, such as Jupyter Notebook and, of course, PyCharm. The latter is used by 30% of Python developers (PyCharm – 22%, PyCharm Pro – 8%), with VS Code at 41%. Notebooks explain much of the fragmentation, since data and service work don’t necessarily require the same toolset. Whatever you build in Python, PyCharm has first-class support for your stack, your frameworks, and your workflow – for web, data, and ML workflows – with notebooks running alongside a debugger and type checker. It parses your code and resolves usages, types, and dependencies throughout your entire project. So you always know exactly what your code does and what will break if it changes, for you and your agents alike.

If you use both Go and Python – as a quarter of Gophers do – it’s worth noting that both GoLand and PyCharm are built on the same platform, so keymaps, shortcuts, and settings sync between them. GoLand also supports Python functionalities through the Python Community Edition plugin.

Python vs Go – broader landscapes

The language itself is one thing, but many other factors go into deciding which language you choose to work with. Developers consider what the languages are used for, who uses them, and how they’re maintained. In this section, we’ll provide insights on the factors that shape the broader landscapes of Python and Go.

Go developers are more senior

Across all questions about age, experience, and seniority in the Developer Ecosystem 2026 survey, Gophers tend to be further along in their career than Python developers.

On overall professional coding experience (not just experience in their main programming language), 20% of Go devs report 16 years or more, compared to 12% among Python developers. At the other end, 9% of Gophers have 1–2 years of experience, compared to 20% of Python developers.

Most Go professionals have senior roles, at 60%, with only 2% being trainees and 10% juniors. Meanwhile, 42% of Python professionals are seniors; trainees (6%) and juniors (19%) make up a quarter of the cohort.

72% of Go developers are employed full-time, compared to 51% of Python developers. Students and working students make up 8% of Gophers, compared to 23% of the Python population.

Finally, by age, the largest group of Go developers is aged 30–34 (23%), compared to Python’s largest group, aged 21–24 (22%).

These differences align with the point we made earlier: Python is a very popular first language for learners, while Go is almost never chosen as a first language and instead is picked up by more experienced developers later in their careers.

It’s important to keep this in mind as you read the following sections on developer demographics, because a lot of these numbers may look like differences between two languages, where in reality, they’re just differences between a senior population vs a general one that you would see regardless of what ecosystems you compare.

Salary follows seniority

Salary bands clearly show how experience affects other demographic data. Go developers are better represented in the top bracket: 9% report earning more than $180,000 a year, compared to 6% of Python programmers. Meanwhile, Python users cluster more in the lowest brackets.

However, if we look only at full-time developers, the differences are no longer statistically significant. The premium is attached to the seniority and employment status, not the primary language. In other words, learning Go itself will not guarantee you a higher salary, but the roles that require Go generally pay better.

What they build

The Developer Ecosystem survey also asks people what functionality their code implements.

Go developers more frequently reported:

• 69% – providing APIs and services (Python – 41%)
• 63% – integrating with APIs and services (Python – 47%)
• 51% – application logic and workflows (Python – 37%)
• 47% – user interface (Python – 41%)
• 35% – libraries and frameworks (Python – 26%)

Meanwhile, Python developers reported higher rates for:

• 38% – data processing and analytics (Go – 30%)
• 36% – artificial intelligence and machine learning (Go – 20%)
• 32% – data science and data analytics (Go – 15%)

The question of where their code is executed adds more context: A vast majority of Go developers target server, infrastructure, or cloud environments (74% compared to 57% of Python developers. On the other hand, 66% of Python developers target the desktop (Go – 47%).

Python is clearly a general-purpose language with a stronghold in AI, ML, and data work that favors local execution, while Go is heavily oriented towards networked services and infrastructure.

There is, however, a particularly interesting line item in the set: integration with AI. While AI development per se is a Python domain, integrations are not. 46% of Go developers report implementing AI integrations, against Python’s 44%, almost equal numbers. Asked about the types of development they do at work, 51% of Python developers reported working with AI and AI tools, compared to Go’s 48%. Go engineers may not train the models, but they are building AI-powered products at roughly the same rate as Python developers.

DevOps: Same job, different toolbox

One other point of convergence between Python and Go developers that deserves its own section is DevOps. Both groups are involved in that area, though Python developers (31%) somewhat less than Gophers (45%). The two groups also tend to use different tools.

• For orchestration, Go developers are more likely to use tooling overall, and especially Kubernetes. Only 8% of Go developers don’t use container orchestration tools (compared to 17% for Python); 58% use Kubernetes (compared to 39%). The engineers we talked to cited Go’s deep integration with Kubernetes as one of the reasons they migrate entire services from Python to Go.
• For configuration management, Terraform leads both groups. However, Python developers lean more toward cloud-native IaC tools (29% for Python, 23% for Go) or use nothing (21% for Python, 15% for Go), while Go developers choose GitOps more often (27% for Go, 21% for Python).
• When it comes to DevOps practices, Go developers report using them more often overall, with one exception: AI-driven operations (12% of Go developers and 18% of Python developers). Python developers are also more likely to use no DevOps practices at all (6% for Python, 2% for Go).

So even if you move from Python to Go in the same type of role, the toolset change might be as big an adjustment as the language change itself.

Operating systems

A curious difference surfaced when we asked developers about the operating system they use for their development environment. Go developers work on macOS (70%) and Linux (57%) significantly more than on Windows (44%). Meanwhile, Python developers use Windows first (66%), then split almost evenly between macOS (54%) and Linux (52%).

For developers planning to migrate to Go, sticking with Windows doesn’t have to complicate deployment, even when the target is a Linux server. For pure Go, building a Linux binary from any of the three operating systems takes no more than two environment variables, while a Python deployment still has to find a matching interpreter and native packages, wherever it ends up.

Two different approaches to AI

We’ve already discussed using Python and Go for AI development, but what about using AI for Go and Python development? Both groups use AI heavily at work, but there’s a difference in how and what they use it for.

Go developers report using AI daily for tasks such as editing code across multiple files (60% vs 52%), agentic development of features or programs (51% vs 41%),  generating commit messages (51% vs 36%) and tests (47% vs 34%), or performing code reviews (39% vs 34%).

Meanwhile, Python developers lead on one task: learning new things about coding and software development (38% of Python developers vs 31% of Go developers), which is consistent with earlier data showing a larger early-career population among Python developers.

There is, however, a long list of tasks where the two groups are indistinguishable: refactoring, debugging, checking code for potential issues, asking general questions, or generating boilerplate – even though you’d expect Go developers to jump on the last one much more, considering the verbosity of the language.

So AI-assisted coding is common in both ecosystems. Go developers have simply wired it into the production chores of a maintenance-heavy codebase: commits, tests, reviews, and multi-file edits.

The groups also tend to use different tools. Go developers are more likely to use terminal and agentic tools like Claude Code (45% vs 40%), OpenAI Codex (24% vs 17%), Cursor (17% vs 12%), and OpenCode (12% vs 6%). Python developers, in turn, reach more for general-purpose assistants and Google or Microsoft surfaces like ChatGPT (20% vs 16%), Google Antigravity (9% vs 5%), and Microsoft 365 Copilot (4% vs 1%).

One number that has to change

Software development remains a heavily male-dominated field, and the gap is particularly pronounced in Go, which – as it’s typically people’s second language – inherits whatever the pipeline hands it and exacerbates it further. In our sample, only 1.8% of Go developers identify as female, compared to 5.8% of Python developers.

Transitioning from Python to Go

One-way path well traveled

You may ask why we’re focusing on transitioning from Python to Go, not the other way around. The data leaves little doubt about the path developers are taking. Python is already the most common second language among Go developers – 35% of Gophers declare it as their other primary language. But most Go developers (70%) say they have no intention of adopting another language in the next 12 months, and if they do, they name Rust (16%), rather than Python (2%). On the other hand, 10% of Python developers (a much larger cohort in terms of absolute numbers) plan to pick up Go, roughly 5.5 times the rate at which Go developers plan to pick up Python.

Why make the switch from Python to Go?

Despite working in different roles and on different products, the developers we interviewed gave consistent reasons for transitioning from Python to Go. These were:

• Better performance and speed, including cold starts, latency, and operating cost.
• Easier and more effective concurrency model.
• Type safety that catches failures that would otherwise reach production at compile time.
• Proximity to the platform, since Kubernetes and much of the cloud-native toolchain are written in Go, so teams working on that infrastructure already interact with Go daily.

What they gained and what they lost

Perceived potential gains are one thing, but did Go actually deliver? According to the developers we interviewed, it did in the areas described above. But they also found benefits they weren’t expecting: predictable formatting and linting that contributed to “clean code”, out-of-the-box tooling, and simplicity comparable to Python’s.

But Go also has flaws that are obvious to developers coming from Python. Just like the reasons for adopting Go were consistent, so were the complaints:

• Explicit error handling that’s fundamentally different from Python, less intuitive, and more repetitive.
• Overall verbosity and opinionatedness, with more lines needed to convey the same behavior and fewer ways to express it.
• An object model that makes testing and mocking noticeably more difficult.
• Library gaps, especially for testing.

Did they really leave?

“Migrating”, “transitioning”, and “switching over” may all sound like final decisions to leave Python behind, but that’s not really the case. Not one of the developers we interviewed removed Python from their stack completely. They kept it for artificial intelligence and machine learning, data science, and pipelines on platforms that only support Python, as well as simply because they work on larger teams that already know Python and are productive in it.

The realistic outcome of “moving to Go” is not becoming a monoglot, but having a polyglot codebase where each language is used for what it’s best suited for.

Conclusions

So, which language should you choose? Is it worth dropping Python in favor of Go? We hope that by now the answer is clear – it’s not a matter of which language is better, but which one is a better fit. Based on our data and developer testimony, here’s what we found.

Go may be a better fit if:

• Performance is crucial for your app: Latency, throughput, or cold starts are problems you actually have and can measure.
• The workload is concurrent, especially if it is I/O-heavy.
• The service is long-lived and maintained by a team, not one person.
• The system already depends heavily on Kubernetes and the rest of the cloud-native toolchain.

Python may be a better fit if:

• The work is machine learning, data science, or numerical computing.
• Your platform only accepts Python, as managed ETL and notebook environments frequently do.
• Iteration speed matters more than runtime speed, which is often the case for internal tooling and prototypes.
• The library you depend on has no Go equivalent; for a lot of the scientific stack, there isn’t one.

Language features alone rarely determine the best choice. When deciding what to build with, the teams weigh in the toolchain they already run, the languages their colleagues already know or are willing to learn, and how much of the existing system they are willing to change. Those things carry more weight than any benchmark, and they are why developers we talked to ended up using both languages, instead of choosing one.

Frequently asked questions

Can Go replace Python completely?

For a lot of backend work, yes, in principle. In practice, it doesn’t. None of the developers we interviewed removed Python from their stack completely. They kept it for machine learning and data science, for pipelines on platforms that only accept Python, and because the teams around them already know it. In the Developer Ecosystem 2026 survey, about a quarter of Go developers report using Python in the same project.

Is Go good for data engineering?

It depends on which end of the pipeline you mean. Go works well for moving data around, including ingestion services, stream processing, API integrations, and CLI tooling, and 30% of Go developers report working on data processing and analytics, compared with Python’s 38%. The analytical end is a different story: Only 15% of Gophers do data science and data analytics, against 32% of Python developers, and the library ecosystem reflects that.

How long does it take a Python developer to learn Go?

Days to weeks for the language itself. The syntax is small, gofmt settles the formatting arguments, and developers we talked to said Go “feels as easy to write as Python”. What takes longer is everything around it: system concepts such as pointers, interfaces, goroutines, and channels, as well as the habits Go asks you to change, from explicit error handling to designing test seams instead of patching at runtime.

The bigger adjustment may not be the language after all. Go work tends to sit closer to Kubernetes, Terraform, and GitOps, so if you’re moving into a Go team from a Python one, budget as much time for learning the toolchain as for the syntax.

Is Go good for machine learning?

For training models, probably not. 20% of Go developers work on artificial intelligence and machine learning, against 36% of Python developers, and the developers we interviewed were blunt about why: Python has the libraries, while Go lacks equivalents.

When it comes to building products around the models, it’s a different story. 46% of Go developers implement AI integrations, against Python’s 44% – a negligible difference. Gophers generally aren’t training the models, but they sure are serving them.

Can Go and Python be used in the same project?

Not only can they be used together, they often are. 27% of Go developers report using Python alongside Go in the same project, behind TypeScript (43%) and just ahead of JavaScript (24%). We know from interviews that the usual division of labor follows each language’s strengths: Go for the networked services and infrastructure, Python for data work, machine learning, and anything that depends on the scientific library stack.

October 13, 2026 01:41 PM UTC

Rodrigo Girão Serrão

Sentinel built-in

Learn how to use the sentinel built-in from Python 3.15 for placeholder values.

Python 3.15 introduced the new sentinel built-in. The sentinel built-in can be used to create placeholder values:

NOTHING = sentinel("NOTHING")

A placeholder created by sentinel is the more idiomatic way to provide default arguments or return values where None wouldn't be usable.

15 days of Python 3.15

To celebrate the release of Python 3.15, over the next 15 business days I'll be writing about a new 3.15 feature every day. Explained clearly and with examples so you don't have to sift through the changelog.

Subscribe to receive this free email series:

If you want, you can also check the schedule of the upcoming emails.

Creating and using sentinels

The built-in sentinel accepts a string argument which is the name of the sentinel:

NOTHING = sentinel("NOTHING")
print(NOTHING)  # NOTHING

The name of the sentinel is used as its default string representation.

Alternatively, you can provide a second named argument to be used as the representation of the sentinel:

NOTHING = sentinel("NOTHING", repr="__main__.NOTHING")
print(NOTHING)  # __main__.NOTHING

While there's no runtime restriction imposed, the name of the sentinel and the name of the variable that the sentinel is assigned to should match:

# Correct:
NOTHING = sentinel("NOTHING")

# Wrong:
NOTHING = sentinel("nothing")
N = sentinel("NOTHING")
BANANAS = sentinel("APPLES")

Linters and type checkers may complain if there's a mismatch. Since sentinels are typically constants you won't update, it's also common for sentinels to have names in all uppercase.

Sentinels are typically used as placeholders and the most common operation is to check if a value is a specific sentinel. For example, imagine a function find that looks...

October 13, 2026 01:11 PM UTC

PyCharm

Python vs Go: A Practical Comparison for Developers

October 13, 2026 09:02 AM UTC

Seth Michael Larson

Gaming’s all-digital future doesn’t include “Sonic the Hedgehog 3” and “Pikmin 2”

Sony announced that all games from 2028 and onwards would be digital-only. It seems likely that Xbox will follow and that Nintendo will continue making “physical” releases for first-party games during the Switch 2 generation.

In the all-digital gaming future, every game platform will be subject to the same problems and constraints as media streaming services like Netflix and Spotify. We can see hints of how this will affect future games and creative freedom in the medium by looking at re-releases of older games, in particular: Sonic the Hedgehog 3 and Pikmin 2.

The core problem is that digital games are licenses, which forces an ongoing relationship between you and the owner of the media. And because there’s an ongoing relationship with you, any ongoing licensing relationships that the media owner has also affect you and your games. If a license for any media that is part of the game expires or is affected, then the developer must take action to remediate the “issue” in the game.

This is already commonplace for games that feature music, such as Rock Band or Guitar Hero, but maybe players find this more “expected” because these games are essentially a music streaming service in themselves. But what about games that aren’t like this on the surface?

Sonic the Hedgehog 3 for Genesis (1994), GameCube (2002), and Switch (2022)

Sonic the Hedgehog 3 was originally published in 1994, and beyond the game being great to play, the soundtrack is really something special. I have fond memories of dancing to the end credits music on my parents’ bed with my brother as a kid after beating the game.

Unfortunately, this track and many others in the game would not survive our all-digital future. Michael Jackson’s alleged uncredited involvement with Sonic 3 has meant that all re-releases of Sonic 3 since 2009 have not included the entire original soundtrack. If this game were released only digitally today, it can be assumed that these tracks would be pulled from the game, just as is done for Rock Band and Guitar Hero when licensing terms expire or there are legal issues.

Pikmin 2 for GameCube (JP, NA, PAL, 2004) and Switch (2023)

Pikmin 2 was published in 2004, and the main objective is collecting “treasure” from an alien planet in the form of food, toys, and, most surprisingly, items featuring real-life brands like Duracell, Dr. Pepper, Yoo-Hoo, and Snapple. This artistic decision and the work to license and include these brands were a substantial part of the surprise and delight while playing the game.

However, you can see that these licensing terms eventually run out, too: in all re-releases of Pikmin 2 from 2023 onwards, the real-life brands are replaced with generic fictional brands. It’s not clear to me whether licensing agreements with so many brands would be undertaken in the future if work would have to be done to create fictional models and textures anyway once the license terms expire.

If it wasn’t clear from this post, I’m not excited for an all-digital future of games. An all-digital future for games means the medium will be further constrained creatively, in addition to the negative impacts on ownership and preservation. Read-only physical media does more for gaming than being something to collect and own: developers can make choices that they won’t have to walk back in 20 years, and players can continue to enjoy games as the developers intended long after licensing terms expire.

Thanks for reading ♥ I would love to hear your thoughts! Contact me via Mastodon, Bluesky, or email. Browse the blog archive. Check out my blogroll.

October 13, 2026 12:00 AM UTC

October 12, 2026

Rodrigo Girão Serrão

Explicit lazy imports

Learn how to use lazy imports to speed up the startup time of your Python applications.

Python 3.15 introduced explicit lazy imports. An explicit lazy import is an import statement that starts with the keyword lazy:

import json
lazy import math
lazy from pathlib import Path

The module json is imported normally, but math and Path are imported lazily.

If an import is lazy, the module will only be loaded when it is needed instead of being loaded immediately when Python encounters the import statement. This article explains how to use lazy imports and how to write backwards-compatible code with these features.

15 days of Python 3.15

To celebrate the release of Python 3.15, over the next 15 business days I'll be writing about a new 3.15 feature every day. Explained clearly and with examples so you don't have to sift through the changelog.

Subscribe to receive this free email series:

If you want, you can also check the schedule of the upcoming emails.

Why does Python need lazy imports?

The import system in Python loads a module when it encounters the import statement. That means that when Python finds a statement import some_module it looks for the corresponding Python module file and runs it. In turn, that file might import other modules that will run at that point in time, and this branching can be arbitrarily deep.

Since Python files usually collect all imports at the top, this means that you may spend an arbitrarily long amount of time taking care of your imports even before your start running your own code. If there are situations where you won't even end up needing those...

October 12, 2026 12:46 PM UTC

LernerPython blog, from Reuven Lerner

Pandas groupby: Aggregating multiple columns with multiple functions

Does Python Pandas allow multiple data columns and multiple methods?

Yes!

df.groupby('passenger_count')[['trip_distance', 'total_amount']].agg(['mean', 'std'])

The above returns a data frame. Its 4 columns are a 2-level multi-index with mean/std in the inner level.

The post Pandas groupby: Aggregating multiple columns with multiple functions appeared first on LernerPython.

October 12, 2026 06:00 AM UTC

Mike C. Fletcher

PyOpenGL 4.0.0a7 -- Cleanup and Preparation

4.0.0a7 is closing in on the final form for the 4.0.0 release. There's a raft of bug-fixes from testing and tickets, the Windows GLUT binaries are now a separate python package, documentation system updates, and OpenGL_accelerate now pins the OpenGL version exactly.

At this point it's likely worth testing your PyOpenGL codebases with the alpha to report any regressions. This is a major release with a raft of changes. It's also tested far more than any PyOpenGL release has ever been tested, so I'm relatively confident that it works in the sense of letting you write 3D rendering engines with modern features, but there are potentially going to be regressions, particularly if you have older code (the majority of testing is all on OpenGL 3.3+ contexts with legacy-free feature-sets), or Tk based apps (where there's a new widget implementation).

We're still missing some Mac work, porting the new Tk widget to use CGL. We've also not yet got confirmation that we've got real-world (as opposed to CI) operation all working on Macs.

October 12, 2026 02:27 AM UTC

October 11, 2026

Kay Hayen

Nuitka Release 4.3

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 experimental Python 3.15 support, the frame locals proxy implementation of Python 3.13, and optimization of iterator unpacking.

Bug Fixes

• Fix, comparisons and add or subtract operations of Python long values with C long operands could produce incorrect results. (Fixed in 4.2.1 already.)

• Python 3.14: Fix, deferred annotations did not work with hard import names, e.g. io.BytesIO, since those were unnecessarily generated as __import__ calls, now we detect the need for it. (Fixed in 4.2.1 already.)

• Python 3.14: Fix, the --devel-no-bytecode-to-compiled-fallback option was not honored when source generation for an __annotate__ function failed, where the fallback to compiled code happened anyway. (Fixed in 4.2.1 already.)

• Python 3.14: Fix, source generation for __annotate__ functions did not handle closures, constants, and calls correctly. Closure variables were then rejected to fall back to compiled code, and values like non-finite floats, empty sets, and types from modules are rendered as valid source. (Fixed in 4.2.1 already.)

• Plugins: Fix, nested uses of the forkserver context were not working. (Fixed in 4.2.1 already.)

• Compatibility: Fix, conditional expressions did not decide their type shapes from the branches properly, which could lead to wrong optimization of list appends and subscript operations. (Fixed in 4.2.2 already.)

• Compatibility: Fix, keyword arguments created from str subclass instances were rejected, since the check compared the exact type instead of allowing subclasses. (Fixed in 4.2.2 already.)

• Windows: Fix, the MinGW variant of MSYS2 now links the compiler runtime statically, avoiding a runtime dependency on e.g. libwinpthread-1.dll, which also fixes module mode requiring that DLL. (Fixed in 4.2.2 already.)

• Windows: Fix, adapting Python header files did not work on MinGW variant of MSYS2 yet. (Fixed in 4.2.2 already.)

• macOS: Fix, newer Xcode versions only ship tools like install_name_tool, lipo, nm, and otool as ARM64 binaries, which fail to run in an x86_64 translated process. These are now invoked with arch -arm64 as needed, and the same for the C compiler and ccache. (Fixed in 4.2.2 already.)

• Debian: Fix, onefile mode was no longer usable when the zstd inline copy is absent, e.g. in the official Debian package, since the system zstd and zlib are now linked statically instead. (Fixed in 4.2.2 already.)

• Installer: Fix, Linux installer creation crashed in onefile mode, which it is not designed for, now informs the user that --mode=app-dist (or --mode=standalone) mode is required. (Fixed in 4.2.2 already.)

• Fix, when outline functions were removed, e.g. class bodies that raise, the variable tracing for them was not properly undone, so the value traces could become inconsistent.

• Fix, cloned outline functions did not copy the variables they take from the enclosing scope, so the clones could lack closure variables, if they got removed in the other variant.

• Fix, the context manager for directory changes only restored the previous directory on success, now it does so also on errors, which the nuitka-watch tool pip retries depends on.

• Fix, recursion decisions for modules restored from the bytecode cache could differ from a cold cache, since the excluded module names were derived from the decision cache rather than the module usages.

• Fix, temporary variable names in cloned outline functions, e.g. from comprehensions in finally blocks, could collide with the ones of the original, giving wrong results potentially.

• Fix, async generator expressions had a code object kind matching that of a plain generator, which could give incorrect behavior for them.

• Fix, the generator heap space using for storing temporary values during yield was limited to a hard coded 1024 bytes, which could overflow and crash for very complex generators, now the exact needed size is captured, which also reduces context memory for most running generators.

• Fix, dictionaries put into containers were not escaped, so mutating a constant dictionary through the container could corrupt compile time decisions made for it, if they got modified through the container access.

• Fix, visitTree recursed once per node, so very deep node trees could exceed the Python recursion limit and raise RecursionError during finalization, variable closure and inlining, they are now visited iteratively.

• Fix, the traceback of exceptions thrown into not yet started generators, coroutines, and async generators was not preserved, the frame is now added to an existing traceback, and the traceback of an exception instance that is thrown is used when none is given.

• Fix, the import scan for --python-flag=-m searched the main script directory before the current directory, while CPython searches the current directory first in module mode.

• Fix, keyword arguments that built-ins do not accept, e.g. sorted(iterable=...) or zip(iterables=...), were not rejected like CPython does.

• Fix, getattr(obj, name, default) returned the default for any exception raised by the attribute lookup and left other exceptions set, which could later surface as a SystemError from an unrelated call, and now only an AttributeError gives the default.

• Fix, return exits were generated for functions and outlines whose returns cannot complete, e.g. inside a finally block that raises, which is now determined with a mayReturn check first. This avoids dead code generated, that the C compiler might warn about.

• Fix, return values that were prevented from an actual return, e.g. by a finally block or context manager exit that raises, were leaked, and now the exception exits release them, including breaks and continues from return handlers.

• Fix, extra directories from the global-sys-path package configuration were only registered late, so packages they enable could be cached as not found by other modules, they are now added as soon as the providing module is recursed, with import caches flushed when new paths are added.

• Fix, build time imports for compile time computations, e.g. metadata, could import a different module than the import scan found for the build, or even none at all when it is only in a directory the import scan knows, now the containing directory of the found module is temporarily prepended to sys.path making sure it matches.

• Fix, compile time results of importlib.metadata.entry_points had truth value for empty result, and as a result branches checking that were taken unexpectedly.

• Fix, distribution metadata, e.g. included with include-metadata, was bound only to the first top-level package and silently dropped when that one was not included, now any included package of the distribution can serve that purpose, and metadata of a distribution without any included package gives an explicit error.

• Python 2: Fix, class bodies gave the internal line number in tracebacks instead of the class statement line that CPython reports.

• Python 3.5+: Fix, generators decorated with types.coroutine were not awaitable, since the compiled generator type did not implement the __await__ slot, which returns itself for iterable coroutines now, and raises the matching TypeError otherwise.

• Python 3.5+: Fix, two phase initialization of extension modules below compiled packages was not working, as their module definition was not executed, which e.g. left gi._gi without its attributes.

• Python 3.5: Fix, the runtime YAML checks used exact dict type comparisons, which failed for the ordered dictionaries used before Python 3.6, giving errors for valid configurations.

• Python 3.6+: Fix, the __classcell__ value was set through the dictionary API, which is wrong when the class namespace is a custom mapping returned by the __prepare__ method, and is now set through the mapping interface like the class body does.

• Python 3.7+: Fix, asynchronous generator expressions inside synchronous generator expressions were detected as making the outer expression asynchronous as well, while only the inner scope is asynchronous.

• Python 3.7+: Fix, namespace packages did not set __file__ to None like CPython does since that version, which could make detecting namespace packages already loaded at compile time differ.

• Python 3.7+: Fix, the UTF-8 mode is now auto-enabled for the C and POSIX locales like CPython does, avoiding broken non-ASCII paths there, and command line arguments are decoded with surrogate handling.

• Python 3.8+: Fix, assignment expressions inside generator expressions bound their target in the module when the enclosing function did not otherwise use the name, since it had no such variable, now the target is made a variable of the enclosing function.

• Python 3.10+: Fix, duplicate constant keys of mapping patterns were not rejected at compile time, duplicate non-constant keys were not checked at match time, and class pattern matching leaked references in some cases.

• Python 3.11+: Fix, the except* support was incomplete and barely usable, now each handler is matched against the remaining exception group in sequence, the match is published as the current exception for sys.exc_info() and a bare raise, exceptions raised by handlers are collected, and the unhandled remainder is raised again with the matching context.

• Python 3.11+: Fix, the eval built-in did not accept globals and locals as keyword arguments that Python 3.13 allows, while for exec these arguments are positional only in Python 3.11 and 3.12, which is now enforced as well.

• Python 3.11+: Fix, when the frame free list was full, releasing a frame could crash, since the interpreter frame linkage was cleared only after the frame was released.

• Python 3.12: Fix, type variables of a class had the wrong scope, which put them into the class dictionary instead of an enclosing scope, they now get a dedicated scope, making them usable from methods and bases, but not visible as class attributes.

• Python 3.12: Fix, threading could dead lock, since the evaluation breaker did not consider work indications of the main thread.

• Python 3.12+: Fix, the __bound__ of type variables was always None, since the bound was not used when creating them.

• Python 3.12+: Fix, the awaitables of aclose() and athrow() of asynchronous generators were not closed when they terminated the generator, so reusing them gave StopIteration instead of the matching errors, and for Python 3.13 and higher, asend().close() and athrow().close() now use throw(GeneratorExit).

• Python 3.12+: Fix, the __module__ attribute of type variables, parameter specifications, and type variable tuples was wrong, since compiled frames lack the function object for the runtime to determine it from, which is now patched.

• Python 3.12+: Fix, the patched sys._getframemodulename looked up __name__ as an attribute of f_globals instead of a dictionary key, required the depth argument although it is optional, and registered a wrong method name.

• Python 3.12+: Fix, the bound of type variables was evaluated immediately, instead of only when __bound__ is accessed, which could run expressions too early, especially in classes.

• Python 3.13: Fix, the new internal _IncompleteInputError exception was not supported, e.g. when used in tuples of caught exception types.

• Python 3.14: Fix, template strings had their literal parts wrongly combined when interpolations were adjacent, since empty string parts were not added reliably.

• Python 3.14+: Fix, __annotate__ functions now have frames, since they can use closure variables and must be able to raise errors.

• Python 3.14+: Fix, objects that are already immortal had their reference counter modified by the static immortal handling, degrading them from static immortals to plain immortals and changing e.g. sys.getrefcount values, which is now avoided.

• Python 3.14+: Fix, the compiled types used the CPython generic attribute and allocation functions directly, which debug mode on Windows rejects, they are now set up by Nuitka_PyType_Ready from indicators instead.

• Python 3.15: Fix, the _math_integer extension module was missing from the standard library modules known to never raise on import, which prevented optimizing its imports.

• Python 3.15: Fix, the Py_GetPath API was no longer available, requiring an explicit declaration again.

• Python 3.15: Fix, the older inline copy of Scons no longer works there, now all Python 3.7+ versions use the newer copy that was previously only used on Windows.

• Python 3.15: Fix, creating long objects triggered assertions there, since the tag field needs initialization before setting the sign and digit count.

• Python 3.15: Fix, the layout of type variable objects gained a qualname field that needs to be filled in from the code object of the function that computes the value.

• Standalone: Fix, the source package __init__.py is now preferred over a C extension __init__.so or __init__.pyd file, respecting the recompile decisions of the user, whose plugin queries are now also cached.

• Standalone: Fix, packages with both source and extension module files gave duplicate module entries when included by the user, now the recompile decision decides the preferred one, like it already did for package __init__ files.

• Standalone: Fix, included symlinks whose target was not yet copied were dereferenced, now they are copied after the files, so their targets are present and the links can be preserved.

• Standalone: Fix, DLLs used by openvino and av were duplicated when they were already included through their package, and could then be found instead of the package directory one, where OpenVINO discovers its frontends and plugins, and versioned shared libraries like libopenvino.so.2503 are no longer included from data file directories.

• Standalone: Fix, shared libraries next to the main script or in directories added with global-sys-path were dropped when reducing the used DLLs, now these program directories are considered part of the search path and kept.

• Reports: Fix, plugin report data was silently discarded, since the report generation did not use the key/value pairs and swallowed all errors, it is now included and validated.

• Plugins: Fix, plugins that put files into the build directory could not do that after other processing, as the directory was removed before the final result callback, which is now called first.

• Windows: Fix, the experimental MinGW64 usage with Python 3.13 and higher did not work in Python debug mode, as the internal structure offsets for debug builds were missing.

• Windows: Fix, NTFS junctions were not resolved before the drive letter check when testing if a filename is inside a path, so e.g. relative report paths could escape their prefix.

• Windows: Fix, the increased stack size was not applied to onefile DLL mode, as it was only done in EXE mode.

• Windows: Fix, some non-ASCII DBCS paths cannot be handled by Dependency Walker, which would then not find dependencies in them, and the pefile based tool is now used for affected binaries instead, with a warning given once.

• MSYS2: Fix, normalized paths were missing in plugin and DLL handling, e.g. for the pywin32 system directory and glfw library paths.

• macOS: Fix, code signing no longer mutates the keychain file, since the security commands change it in place, a temporary copy is now used instead.

• macOS: Fix, the architecture prefix is now also applied to git and other tool invocations in the process execution helpers, since these only exist as ARM64 binaries in newer Xcode versions, which broke e.g. the test tooling in translated x86_64 processes.

• macOS: Fix, debugging translated x86_64 binaries on Rosetta did not work, since the lldb shim of newer Xcode is ARM64 only, now getting the arch prefix, and the debug server requires the binary to allow being debugged, so accelerated mode with a --debugger is now signed with the entitlements that standalone mode already uses.

• Compatibility: Fix, nested frames used the same exception line number storage, leading to corruption of either the inner or outer line numbers in exceptions, they now have separate storage.

• Compatibility: Fix, values used in and and or expressions could lose their escape tracking, so e.g. adding to a set through them could corrupt values, they now handle their operands like the conditional expressions do.

• PGO: Fix, the isolated Python flag did not work with Python PGO mode, since its input build is accelerated and loads the standard library from sys.path, for which the isolation is now skipped, while accelerated mode now rejects the flag with an error, as Nuitka empties sys.path there.

• Scons: Fix, the linker response file workaround for command line length limits was only used for GCC mode, so linking could fail with many modules for Clang and Zig modes, which now benefit from it as well.

• Scons: Fix, the target of the build is now always created as _nuitka_temp with the proper extension in the build directory and renamed into place after the build, avoiding paths that the C compiler cannot encode, e.g. for Unicode output binary filenames.

• Scons: Fix, the stack size limit of the scons process is now raised on non-Windows, so compiling very large generated source files cannot crash the C compiler child processes with a stack overflow.

• Distutils: Fix, the project expected data files check reported files like py.typed that Nuitka ignores by default as missing, and treated user included extra data files as a mismatch, now only actually missing files are an error.

• Distutils: Fix, generated main entry point files in the source directory could shadow the modules they import for project name based builds, since that directory was only ignored for output folder based builds before.

• Watch: Fix, the pipenv lock file of a case was looked up in the case directory rather than the result path, giving wrong paths on updates.

• AIX: Fix, COFF dump based dependency detection for archives now extracts object members to a temporary file before dumping them, since the direct member selection was not portable.

• AIX: Fix, the Python DLL is now properly detected, so it no longer needs to be added as a data file, which was conflicting with the DLL.

• Scons: Large data blobs on x86_64 Linux now use the medium code model and large data sections for the incbin and linker resource modes, so blobs beyond the 2 GB range of the small code model no longer give relocation errors.

Package Support

• Standalone: Added support for newer PyAV. (Added in 4.2.1 already.)

• Standalone: Fix, vtk8 was no longer working, since the package path configuration was needlessly restricted to vtk version 9 and higher. (Fixed in 4.2.1 already.)

• Standalone: Added support for the latest toga on macOS, with the toga_cocoa.resources dependency now included. (Added in 4.2.1 already.)

• Standalone: Added support for Tkinter version 9.1.

• Standalone: Added support for the onnxruntime DLLs on non-Windows.

• Standalone: Added gevent.selectors to the implicit imports of gevent.

• Standalone: Added lazy loader support for newer huggingface_hub, covering the huggingface_hub.utils module with its class based lazy module.

• Standalone: Added support for the wirerope package, working around compiled function type checks using anti-bloat replacements.

• Standalone: Fix, the imgui_bundle GLFW backend used a different GLFW library than the glfw package, and three copies of it were included, now the one needed library is shared by both.

• Plugins: Fix, the PySide6 singleShot timer workaround protected the wrong argument when called with more arguments, allowing the issue it is meant to avoid to occur. (Fixed in 4.2.1 already.)

• Plugins: Made PySide6 work in module mode using configuration references.

• Plugins: Added support for gi.repository namespaces, using virtual modules that resolve them at run time and include their typelib dependencies, replacing the previous inclusion of all typelib files.

• Plugins: Added support for newer versions of the lazy_loader package, using its attach_stub interface rather than the private stub visitor.

• Plugins: Fix, compiled methods in PySide6 signal slots failed with a SystemError on Shiboken builds using the unlimited API, e.g. conda-forge, which call PyFunction_GetDefaults, with cached wrappers now used when a probe detects this issue.

• Plugins: Fix, the torch config module detection only matched exact config and _config names, missing modules like torch._inductor.config_comms, whose _compile_ignored_keys were then left unhandled.

• Plugins: Fix, the torch.jit plugin missed script_method uses, and script or script_method used as decorators without a call, so modules using these forms were not handled.

• Plugins: The source-inclusion plugin now records source files by intercepting linecache.getlines during the probe run, so that inspect.getsource, inspect.getsourcelines, and inspect.findsource all work, its probe timeout defaults to no timeout, and plugin cache contribution values no longer need to include the plugin name.

New Features

• Python 3.15: Pronounce Python 3.15 as experimentally supported.

• Python 3.13: Added a compatible frames locals proxy implementation, with frame locals of compiled functions now held in a C struct that the frame can point at, and available for all scopes with --experimental=force-locals-frame-proxy, where the proxy is a write-through mapping, but coming with a performance penalty. We want to only selectively enable that for functions known to need it in future releases.

• Python 3.14: Added source generation for function calls and more hard import types for __annotate__ functions. (Added in 4.2.1 already.)

• Python 3.14: Added source generation for more constant value types for __annotate__ functions, e.g. bytes, range, slice, bytearray, and complex values, including non-finite components. (Added in 4.2.1 already.)

• Python 3.14: Added support for closure variables in __annotate__ functions, which no longer need to fall back to compiled C code, with the providing functions using real Python cell objects rather than compiled cells, as annotationlib requires for re-wrapping them.

• Python 3.14: Added source generation for many more constructs of __annotate__ functions, e.g. all binary operators, set displays, template strings, the abs and repr unary operations, type(x) calls, built-in references including anonymous ones like NoneType or function, and ctypes.CDLL.

• Python 3.15: Added support for the new frozendict type as a constant, including optimization of its constant values, where deep copies are only made when nested values can still change.

• Package configuration can now reference other configurations with include-config, and configure the main module through the <main> pseudo name.

• Plugins: Added support for virtual modules, i.e. modules that plugins provide generated source code for, used for modules that only exist at run time, and that can also be included on the command line.

• PGO: The class dictionary shape of __prepare__ call results is now detected and captured, allowing classes with a plain dictionary namespace to benefit from optimizations, with mismatches ignored by default, raising a RuntimeError when the pgo-assertions non-deployment flag is active, and aborting in debug mode.

• UI: Added the __uncompiled__ module value for modules provided as bytecode, with the same information as __compiled__, so globals().get("__uncompiled__", globals().get("__compiled__")) tells whether Nuitka provided a module, whether compiled or as bytecode, and the new python_runtime_dir and process_exe fields of __compiled__ replace the deprecated __nuitka_binary_dir and __nuitka_binary_exe variables.

• Plugins: Implicit imports can now have a reason provided by the plugin, and compilation reports include implicit module usages with it, making it easier to see where and why a module was added.

• Windows: Added age based cleanup for clcache, removing cache entries not modified for a while, controlled by the NUITKA_CLCACHE_MAX_AGE_DAYS environment variable, defaulting to 30 days, with a value of 0 disabling it, and performed at most every NUITKA_CLCACHE_CLEANUP_INTERVAL_DAYS days, defaulting to 7, replacing the previous maximum size based full cleanup.

• Plugins: Added support for redacting option values, so plugins can mark their sensitive options, and compilation reports and the logged command line show them as “REDACTED” instead.

• UI: Added support for disabling the onefile splash screen at runtime, by setting the NUITKA_SPLASH_SCREEN environment variable to 0 or off, e.g. for automated tests, with the application side dismissal of the splash screen still working.

• AIX: Added the xcoff_obj resource mode, generating XCOFF64 object files with the constants blob directly instead of C source arrays, which avoids the size limits of the code mode, and can be selected with the NUITKA_RESOURCE_MODE environment variable.

• UI: Made the --main-entry-point option usable without --project, requiring a project name for the output naming and making sure the entry point module is included.

• Plugins: Package configuration merging now works for all sections, extending lists and updating mappings, so user configurations can extend the standard configuration of a module, with only mismatching entry types giving an error that names the module and section.

Optimization

• Standalone: Moved implicit import consideration from module recursion into the optimization pass, avoiding an unnecessary third pass for standard library modules using a cold bytecode cache. (Added in 4.2.2 already.)

• Standalone: Enabled LTO for the “Python Build Standalone” flavor as well, since it is known to be supported. (Added in 4.2.2 already.)

• Standalone: The import lowering to fixed and hard imports now also handles the fromlist submodule imports that __import__ performs, so those apply there correctly.

• Unpacking from values that are known to be indexable now uses direct subscript access instead of the iterator protocol, making e.g. a, b = some_tuple a lot faster, with starred unpacking to follow once this has proven stable.

• Loop value traces now detect identity stability of values, enabling more optimizations, and when the loop analysis gives up, the continue traces are now reversed properly, which could otherwise produce false results.

• Slice values built from constants are now cached, except when they contain mutable values, which are still created at runtime to avoid corruption.

• Internal source code references are now actually used again, which was lost in a memory saving refactor years ago, lowering the generated code amount for some constructs.

• Replaced runtime assertions with static assertions where possible, using a shared STATIC_ASSERT helper.

• The meta path loader entries now reference their pre-load, post-load, and parent entries directly rather than relying on name based lookups, with the main module now determined by a flag rather than its name.

• Avoided passing the frozen module count as a C define, since that could break caching, using an accessor function instead.

• Module and class code objects are now specialized with fixed details, saving constant blob space, and the module code object name is now always <module>, which actual upstream code relies on to identify module frames.

• Generator expression code objects are now specialized, since they lack attributes of functions, saving space and sharing the <genexpr> name.

• Direct CPython C-API calls were replaced with Nuitka helper replacements where they exist, e.g. LOOKUP_ATTRIBUTE and SET_SUBSCRIPT, which is mostly a cleanup, but relevant for the locals dictionary handling at startup.

• Binary operations of compile time constants are now folded during tree building already, avoiding optimization churn and giving compatible match behavior, e.g. for folded complex literals.

• Compile time constant folding now uses the same limits as CPython for too large results, e.g. 128 bit integers for multiplication, 256 items for collections, and 4096 characters for strings.

• macOS: The Homebrew rpath scan is now limited to directories that hold libraries, pruning include, docs and other trees, which previously registered tens of thousands of paths on every standalone build.

• Package configuration parsing now prefers the C based CSafeLoader of a libyaml built PyYAML when available, and caches the ordered loader class, making it several times faster on the large configuration file.

• The try/else construct no longer uses an indicator variable when the handling aborts, since only normal completion of the try block can reach the else block then.

• Loop traces that are not used no longer mark late attached continue traces as used, which could prevent dead assignment removal.

• The generated getVisitableNodes implementations now use tuple literals and concatenation instead of building and converting lists, which speeds up tree visits for many node types.

• Added more C float helper variants for comparisons and binary operations, e.g. RICH_COMPARE_LE_CFLOAT_CFLOAT and BINARY_OPERATION_ADD_CFLOAT_FLOAT, fixing missing overloads, they are groundwork for intermediate value type selection and not used yet.

• Direct imports were added, where modules are imported through their loader entry with a shared load state under the module lock of the import machinery, so that pre- and post-load trigger modules are directly linked, and a module is run only once regardless of the load path.

• Built-ins like open, print, sorted, reversed, enumerate, zip, and memoryview now have specs and generated nodes, going through the hard import node machinery, replacing the manually written open nodes.

• Incomplete loop variables are now resolved in the same optimization pass that discovered them, avoiding an unnecessary extra full pass.

• visitTree now uses an iterative traversal rather than recursion, which saves a large part of the time spent on the visiting mechanics and speeds up the optimizations overall.

• The io.open built-in is now treated like open.

• OpenBSD: Added support for getting the binary path on OpenBSD 8 using the getexecpath function intended for that.

Anti-Bloat

• Avoided using pydoc in the official PySimpleGUI package as well, which so far was only done for the non-official one. (Fixed in 4.2.1 already.)

Organizational

• UI: Made the --file-description help text clear that it is no longer Windows only, as it is also used as the summary of the AppStream metadata of Linux --mode=app mode. (Fixed in 4.2.1 already.)

• Release: Added clangd to the CI container to allow checking with it. (Added in 4.2.2 already.)

• Release: Made it clear that on Python 3.14 and higher, the standard library compression.zstd is used instead of the zstandard package in the requirements.

• AI: Added the setup-pr-branch skill for setting up fork pull request branches for pushing updates, pointed the module-not-found skill at the MRE workflow, and ignored the scratch folder used for AI work.

• Docs: Made it clear in the Developer Manual that Python 3.14 is covered by feature parity.

• Docs: Integrated the website documentation changes into the User Manual, including the report template data tables and the CPU architecture baseline section.

• Quality: Disabled more ruff warnings that are not important for Nuitka, and enhanced the clangd and Visual Code configuration for correctness.

• UI: The error message for --static-libpython=yes with the “Python Build Standalone” flavor now includes a hint for downloading the full build that supports it.

• Quality: Made the check for unpushed files work for branches without a remote, comparing against the merge base or default branch instead.

• Docs: Removed the Doxygen based API documentation generation and its tooling, as it never reached a usable state and is not used anymore.

• Scons: Slow C compilation reports now name the C file that caused them, making it easier to identify scalability problems.

• Quality: The private pip space is now usable with multiple site-packages layouts, e.g. from different Python installations of it, considering all of them instead of refusing.

• UI: Added the --pgo-json option to write the PGO input file contents as JSON for debugging and testing, and the --devel-pgo-warn-unknown option to report PGO values that are not usable.

• AI: The verification rules now hint at using the WSL host Python installations through /mnt/c.

• Debian: The package builder image script now uses archive URLs for old Debian and Ubuntu releases, trusts the expired jessie archive key explicitly, and includes aptitude and build-essential needed for the dependency resolution of pbuilder.

• Quality: The pre-push hook now allows downloads for the pylint checks, like the formatting checks already do.

• Quality: Tools of the private pip space that cannot be executed at all are quietly treated as not existing, so that a broken binary no longer stops their download.

• UI: The anti-bloat plugin option help no longer advertises the nofollow choice, which was only available as a regular user command line option since last release.

• Scons: ccache files are now stored in a directory per Python ABI version, so that cache cleanup does not interfere between versions.

• Quality: The git patching now tolerates files that are staged but already deleted from the working tree, instead of crashing.

• Quality: The BOM transfer of the auto-format tool no longer crashes for new files, reading the source contents once and only updating the target file when the BOM changes.

• Quality: The auto-format tool now replaces all forms of typographic dashes and hyphens in text files and Python comments with plain dashes.

• Coverage: Publishing coverage data now copies the files into the coverage directory directly, since the CI does the uploading, instead of the previous scp transfer.

• Debugging: Added the keep-dependency-walker-files experimental option, which keeps the output and configuration files of the Dependency Walker on Windows for inspection instead of deleting them.

• UI: On non-glibc Linux, e.g. musl based systems, importing extension modules from a statically linked binary, e.g. with -static, now gives a RuntimeError explaining that dynamic loading is not supported, instead of the low level “Dynamic loading not supported” error, and this can be disabled with --no-deployment-flag=static-extension-loading.

• Watch: Added the --accept-pypi-bumps option, which accepts version bumps of existing packages in Pipfile.lock files and related report changes for PyPI updates, while newly added or removed packages remain in the diff for review.

• Debugging: Added the --debug-address-sanitizer option to compile and link with AddressSanitizer instrumentation, known to work with GCC and Clang, and implying debug information, with leak detection disabled by default for the compiled program, since Python and third party libraries intend to leak, and it can be enabled with ASAN_OPTIONS=detect_leaks=1.

• Quality: Suppressed or solved more warnings for the clangd LSP, e.g. unused includes and internal undefined references in C code.

Tests

• Added support for the win32, linux, and macos variables in wait_for conditions of nuitka-watch test cases. (Added in 4.2.1 already.)

• Added --devel-no-bytecode-to-compiled-fallback to nuitka-watch compilations with Python 3.14 and higher, requiring that annotate functions do not fall back to compiled code for the packages we actively monitor.

• The test runner now displays the full Python version string, which is useful for release candidate versions, where the numeric version alone is ambiguous.

• Allowed to specify test names without their version specific suffixes in the test runner.

• Enhanced the XML comparison utility to run Nuitka with --generate-c-only and --nofollow-imports, comparing the XML output files directly.

• Fixed the BrotliUsing and PmwUsing tests to specify standalone mode, so they become usable of their own.

• Avoided specifying default file reference choices in the CPython comparison tool, where they only cause warnings.

• The test runner now supports the _3.py suffix for tests that require Python 3 at minimum, replacing the previous 32 suffix that was used for those.

• The test runners now support --pattern filters and a --skip option that implies resuming, with the only, resume, skip, search, coverage, and all shortcuts adjusted, and partial runs no longer update or delete the resume state.

• The output comparison tool now normalizes temporary file names of Windows error messages as well, like it already did for POSIX /tmp paths.

Cleanups

• The temporary filename context manager now deletes the file itself, also on errors, simplifying its users such that don’t have to do it. (Fixed in 4.2.1 already.)

• Quality: Addressed the warnings reported by the clangd LSP, adding shared headers for the long digit, dictionary internal, power, and repeat helpers, and organizing the IDE only includes.

• Quality: Updated the inline copy of hedley to the latest version, and added the dump backtraces declaration for the clangd LSP.

• Generalized the deferred release handling in code generation, now allowing values to be released at the end of their code scope when needed.

• Debugging: Fixed that disabling all free lists was not fully effective, since the release path still used them.

• Unbound local and closure errors are now formatted by helpers from the frame’s code object, removing the per-raise-point variable name constants and inline exception chaining.

• Removed dead code for generator expression frames that was no longer used.

• Removed the --experimental=old-code-objects support, as the constants blob based code objects are the only mechanism now.

• De-duplicated the MODLIBS entries used for linking.

• Node classes can now use comma separated conditions, e.g. ranges, in their python_version_spec declaration.

• The meta path loader now uses the OS_LISTDIR helper instead of its own duplicate of the os.listdir wrapping.

• Debugging: Removed an invalid assertion when throwing into an async generator, since the ownership was transferred and the exception state could already be released.

• Removed dead code and unused slots, e.g. for closure variable demotion, generator return checks, and trace collection variable versions.

Summary

This release pronounces Python 3.15 as experimentally supported, with its new frozendict type handled as a constant, and adds a compatible frame locals proxy implementation for Python 3.13, which is experimental for now and intended to be selectively enabled for the functions that need it in a future release.

The Python source generation for __annotate__ functions no longer falls back to compiled code for closures, and now covers many more constant value types and constructs.

Optimization work continues with unpacking from known indexable values using direct subscript access instead of the iterator protocol, making e.g. a, b = some_tuple a lot faster, with starred unpacking to follow once this has proven stable. Built-ins like open, print, sorted, reversed, enumerate, zip, and memoryview now have specs and generated nodes, going through the hard import node machinery, and compile time constant folding now uses the same limits as CPython.

The except* support of Python 3.11 and higher is now complete and usable, matching CPython by matching each handler against the remaining exception group in sequence, publishing the match as the current exception, and collecting exceptions raised by handlers.

Package support improved for gi.repository namespaces through virtual modules, PySide6 signal slots and module mode, toga on macOS, and Tkinter version 9.1, among others.

All in all, Nuitka development continues at a steady pace and even more optimization has been prepared for the next release.

October 11, 2026 10:00 PM UTC

Ned Batchelder

Making git hooks visible

Frank Wiles wrote about an attack he nearly fell victim to: a downloaded git repo had active git hooks that would have compromised his system. Seeing the risks, I wanted to make git hooks more visible on my own machine.

A git hook is a script in the .git directory of a git repo on your machine. They run during various git operations. The important detail to understand about hooks is that they do not get installed locally when you clone a repo. A newly cloned repo never has active hooks. Hooks have to be enabled after cloning, usually by you.

The attack Frank saw was dangerous because it wasn’t a cloned repo: it was a local checkout that had hooks installed then shared as a Dropbox folder. So when it landed on Frank’s machine, the hooks were active without him realizing it.

Git hooks are not apparent: they are meant to sit quietly until they run and ideally to be unobtrusive even then. But this attack made me want to know what hooks were in each of my git directories.

In zsh, you can define a function called chpwd, and it will execute whenever the current directory changes. Using this feature, I could create a script that lists the active hooks when I change into a git directory:

git_show_hooks() {

    local git_dir=$(git rev-parse --absolute-git-dir 2>/dev/null)

    if [[ -z $git_dir ]]; then

        _git_shown_hooks_dir=

        return

    fi

    local hooks_dir=$(git rev-parse --git-path hooks)

    hooks_dir=${hooks_dir:a}

    # Only announce once per repo, not for every cd inside it.

    if [[ $hooks_dir == $_git_shown_hooks_dir ]]; then

        return

    fi

    _git_shown_hooks_dir=$hooks_dir



    local -a hooks

    local hook

    setopt localoptions nullglob

    for hook in $hooks_dir/*; do

        if [[ -f $hook && -x $hook && $hook != *.sample ]]; then

            hooks+=(${hook:t})

        fi

    done

    if (( $#hooks )); then

        echo -e "\e[31mgit hooks:\e[0m $hooks (from $git_dir)"

    fi

}



autoload -Uz add-zsh-hook

add-zsh-hook chpwd git_show_hooks

Now entering a git repo I get an announcement of active hooks, if any. It’s very rare to see a hook other than pre-commit, but if any are there, they will be reported. The message will only be shown the first time I cd into a repo to keep the noise down.

Once I had this in place, there was another git hook consideration I could address: it’s common to have a .pre-commit-config.yaml file in a repo, but it’s easy to forget to enable the pre-commit hook that will actually use the file. Many developers probably have cloned repos where they haven’t enabled the pre-commit hook, so the desired checks aren’t running.

A second chpwd function can look for the configuration file and let you know if you have the pre-commit hook enabled:

git_check_precommit() {

    local toplevel=$(git rev-parse --show-toplevel 2>/dev/null)

    if [[ -z $toplevel ]]; then

        _git_shown_precommit_dir=

        return

    fi

    # Only announce once per repo, not for every cd inside it.

    if [[ $toplevel == $_git_shown_precommit_dir ]]; then

        return

    fi

    _git_shown_precommit_dir=$toplevel



    if [[ ! -f $toplevel/.pre-commit-config.yaml ]]; then

        return

    fi

    local hooks_dir=$(git rev-parse --git-path hooks)

    hooks_dir=${hooks_dir:a}

    local pc_tool=

    if [[ -f $hooks_dir/pre-commit ]]; then

        if grep -q 'File generated by prek:' $hooks_dir/pre-commit 2>/dev/null; then

            pc_tool=prek

        elif grep -q 'File generated by pre-commit:' $hooks_dir/pre-commit 2>/dev/null; then

            pc_tool=pre-commit

        fi

    fi

    if [[ -n $pc_tool ]]; then

        echo "$pc_tool installed"

    else

        echo -e "\e[31mpre-commit:\e[0m not installed," \

            "run 'pre-commit install' or 'prek install'" \

            "($toplevel/.pre-commit-config.yaml)"

    fi

}



add-zsh-hook chpwd git_check_precommit

One more step, just to be extra safe: zsh doesn’t run the chpwd function when starting a new shell. So we run the functions explicitly to check our initial directory:

# Run them once on shell startup to check our starting directory.

git_show_hooks

git_check_precommit

These shell functions are keeping me aware of the enabled git hooks. The messages might appear too often, and I might stop noticing them after a while, but I think this is much better than not knowing what’s going on. I haven’t seen any attacks, but I found at least one of my projects where I forgot to install pre-commit.

October 11, 2026 12:25 PM UTC

Mahmoud Hashemi

CalVer 26.0: 10th Anniversary Edition

A decade ago, a little bit of history was made. I didn't realize it, but a colleague made a great point, one of those real mind-changing points that seem too obvious to admit same-day. But, the next day, calver.org was born.

At the time my team maintained the Python infrastructure for eBay and PayPal, and we were stuck deciding whether we were really ready for a "major" 1.0 release. Semantic Versioning was the only game in town and "major" means "big", right?!

Thankfully, a wiser colleague mentioned: Ubuntu and Twisted don't struggle with version number debates. They slap a date on it and keep shipping. In fact, their date-based versions were even better because you always knew where it stood, in terms of updatedness and support.

The only problem is that no one really knew about it. Somehow, this problem solving versioning alternative, arguably as old as history itself, had gone nameless for millenia, conspiring to make me feel foolish in an office meeting. Never again!

Ten years of adoption

Fast forward 10 years, we've seen CalVer adopted by Apple, Nvidia, JetBrains, and countless others. (We have a timeline!) The site may have more inbound links than any other project of mine. Apple made the biggest jump, at WWDC 2025:

• iOS went from 18 to 26
• macOS from 15 to 26
• watchOS from 11 to 26
• and visionOS from 2 to 26

All landing on one, consistent number like a car's model year. I still remember the texts from the Venn diagram fanbase of my friends who love Apple and reasonable versioning. No such texts from when NVIDIA announced calendar versions across the GPU Operator, RAPIDS, and its monthly NGC containers, but still very cool.

Open source, too: Home Assistant, pip, CockroachDB, and yt-dlp all ship on dates, with plenty more on the users page. The conversation even reached the language core; PEP 2026 proposed versioning CPython as 3.YY, and it almost happened, too. And it's never too late, time marches on!

Fixing the notation

But I don't think I got every detail right from day 1. That's the main motivator for CalVer 26. It's high time to start righting a couple idiosyncratic token design choices, starting with some additions:

Seeing double

First, the doubled letters. From the first version (16.6), MM and DD meant the unpadded month and day, which reads backwards to anyone who knows date formats (ISO 8601's YYYY-MM-DD, Java, moment.js, day.js), as some community members correctly pointed out. I was ready to flip them, until I checked what people actually use: most projects with a YY.MM.MICRO badge (conda, Twisted, Ansible's tooling) don't pad, and more than a dozen other version management tools (like bumpver and bump-my-version) implement the old meaning.

So, it's too late to flip MM's meaning. Instead, 26.0 deprecates it and offers a more explicit and hopefully clearer option: M is the short month, 0M the padded one, and MM is a technically-retired synonym for M. In case you're wondering, the explicit 0M was me being overinspired by Ubuntu's approach, perhaps: 6.06 pads its month but not its year, and YY.0M says exactly that.

To pad or not to pad

I think it's worth a detour into why padding is even a thing anyways.

It's become important now that new ecosystems have emerged that enforced SemVer formatting semantics, and I wanted clear guidance about on the spec site. SemVer forbids leading zeros outright, so Cargo rejects 26.04.0 and Go modules reject v26.04.0. Even Python's packaging spec normalizes leading zeros away, so you can tag 2026.08.19 if you want, but PyPI will still show 2026.8.19. NVIDIA's GPU Operator docs put it this way: "Zero padding is omitted for month to be still compatible with semantic versioning."

CalVer was always intended to drop in where SemVer was used. So 26.0 recommends unpadded (YYYY.M.D) as a sane "pure" default for software libraries. But libraries are not the only objects of versioning schemes.

The exception is a version that becomes a filename, an image tag, or an object-store key that gets listed lexically. There, padding keeps 26.10 sorted after 26.09, which is why Ubuntu, NixOS, and NVIDIA's own NGC containers pad. More evidence of teams designing their versions. We love to see it.

Our FAQ has a longer discussion of the padding issue, as well.

Optional segments

There was never any rule against them, but 26.0 makes optional trailing segments more explicit with square brackets. Now, yt-dlp's scheme can finally be written down: YYYY.0M.0D[.MICRO].

For the CalVer badges I could find on GitHub, they all stay valid for now. I've got a note on the deprecated spellings and a new copy-paste badge section for new ones.

What else is new?

It's always a great time to add more citations to the site.

• A spec changelog; the spec now versions itself: 16.6, 19.7, 26.0.
• A FAQ: breaking changes, same-day releases, and padding.
• The users page, rebuilt by category, with past users of note (schemes change; that's fine) and tooling.
• Case studies: Apple and NVIDIA in, yt-dlp replacing youtube-dl.

Much of the thinking behind these changes happened in the GitHub issue tracker over the years, and 19 or so issues close with this release. That's where ideas for CalVer should go, so by all means, open an issue, and we'll get it sorted! In due time, of course.

In closing, I can't believe I still love belaboring these numbers so much. Thanks to all (but especially Mark, Glyph, Hugo, issue reporters, translators, and maintainers) for the discussion, and ultimately making the most timely versioning system a timeless classic.

See also

• 2016 announcement
• Designing a version
• My Yap on Why CalVer beats Semver

October 11, 2026 07:00 AM UTC

LernerPython blog, from Reuven Lerner

Pandas groupby: Multiple columns and multiple aggregation methods

Does Python Pandas allow multiple categorical columns and multiple methods?

Yes!

df.groupby(['passenger_count', 'VendorID'])['trip_distance'].agg(['mean', 'std'])

The above returns:

– A 2-column data frame (mean + std)
– A 2-level index (passenger_count + VendorID)

The post Pandas groupby: Multiple columns and multiple aggregation methods appeared first on LernerPython.

October 11, 2026 06:00 AM UTC

October 10, 2026

The Python Coding Stack

1. What makes an AI agent different from a chatbot?

AI agents are often described as the next step beyond chatbots. But what does that step involve? A chatbot can already search the web, write code, and sometimes run it. Is an agent simply a chatbot with more tools, or is something different happening behind the conversation? That’s where we’ll begin Agents Unpacked, a series of conversations exploring what AI agents are, how they work, and when they’re useful.

You ask an AI to organise a folder of photographs. It might tell you how to do it. Or it might start doing the work. Does that make it an agent? In this first Agents Unpacked conversation, Monty and I use photographs and planning a day out to explore what changes when a model can choose actions, inspect the results, and decide what to do next. Along the way, we separate that flexibility from permission, accuracy, and the ability to know when a job is finished.

Who’s Monty? Monty is my personal AI agent. Read an introduction to this series here: Stephen’s Preface to Agents Unpacked

In conversation • Chapter 1

Monty:

Imagine you give a chatbot this request:
“Here’s a folder of photographs. Organise them into dated folders, flag duplicates, and make a browsable index. Don’t delete anything or change the originals.”
For now, suppose it can only reply with words. It cannot touch the files.

What would you expect it to give you, and what would still be left for you to do?

Stephen:

Hmmm? I guess I need to assume it can read the folder, right? Then, can it read the files’ metadata? Can it actually see and analyse the photos themselves? You said “it cannot touch the files”, so I suppose it can’t really do anything for me, right?

Monty:

You’re right. I left its access unclear. “Cannot touch” was sloppy wording.

Let’s say it can inspect the folder, read dates stored with the photographs, and view the images, but cannot create, move, or change files.

It could then give you something useful: “These photographs belong in these date groups. These two files are identical. This one has no recorded date.” But you’d still have to do the organising.

So the first distinction is describing what should happen versus making it happen. Shall we now give it permission to create organised copies, while leaving the originals alone?

Stephen:

Let’s go ahead, yes.

Monty:

Now it can do the organising, rather than merely recommend it. It can create dated folders and put copies into them, leaving the originals unchanged.

But being able to act isn’t, by itself, what makes something an agent. A simple sorting program can do that too.

Here’s where our synthetic sample gets interesting: one image has no recorded date. The system encounters a gap in the information it needs.

What would you want it to do with that image?

Stephen:

If I was doing that manually, I’d try to look at other photos where the scene is similar, the people are wearing the same clothes, and make an educated guess on the date if I can. But that’s how I as a human would do it.

Monty:

That’s a sensible investigation: look for more evidence before deciding.

A system with suitable image-analysis tools could try something similar. But matching clothes or scenery would support an estimated date, not establish one. It shouldn’t quietly turn a guess into a fact.

And your approach helps us sharpen the distinction: a program could have a preset instruction saying “if the date is missing, compare photographs”. Alternatively, a model could choose that investigation after discovering the missing date.

The outward action might look identical. The difference is who—or what—selects the next step.

Stephen:

I suppose I could ask the system to ask me to confirm each of these edge cases. Although after a while, if I feel it’s doing a good job at estimating, I may want it to go ahead without my input.

Monty:

Yes, you can give it more room to act as your confidence grows. For example: “Ask me about every estimated date” could become “Group those photographs without asking, but keep their dates labelled as estimates.”

That changes how much independence you allow, not whether the system is an agent. An agent can stop and ask you. It doesn’t have to always work unattended.

There are two separate questions here: how does it choose its next action, and which actions may it take without your approval? More permission doesn’t make its guesses more accurate.

Stephen:

Go ahead, I’m curious now.

Monty:

Let’s follow the missing-date photograph one step further.

The model chooses to look for related photographs. The tools return a result: there’s a similar scene, but that photograph has no date either.

Now the model has to choose again: investigate another clue, ask you, or leave the photograph undated. Its next action depends on what it just found.

That’s the useful working picture of an agent: a model chooses an action, gets a result, then uses that result to choose what to do next, within agreed limits.

People use “agent” in different ways, so this is a useful working distinction for our conversation, not a universally agreed definition.

But couldn’t a carefully written program also respond to those results?

Stephen:

A carefully written program would need to take care of every eventuality, I suppose. Whereas an LLM can deal with every situation, with the trade-off that it may make mistakes.

Monty:

Close. But I’d soften both “every” claims.

A fixed program can have a fallback for cases its designer didn’t anticipate: “If none of these rules fits, put the photograph in ‘undated’.” It doesn’t need a separate rule for every possibility.

An LLM can propose a next step for situations that weren’t explicitly anticipated, but that doesn’t mean it can handle every situation successfully. It can misunderstand, lack the right tools, or pursue an unhelpful approach.

So the distinction is following a predefined process versus letting the model choose how to proceed, and not limited software versus unlimited intelligence.

Stephen:

Go ahead.

Monty:

Let’s try the same distinction with a day out.

Imagine a visitor planning a museum day in Oxford. The system checks opening times and walking routes, then puts together an itinerary.

Now suppose one museum is unavailable.

One system follows a preset rule: “Replace it with Museum B.” Another lets the model choose what to investigate next, considering the visitor’s interests, remaining time, and budget.

Both might produce the same revised itinerary. What would you need to know to tell which process was agent-like?

Stephen:

I’d need to know the steps the system took between finding out that the first museum is closed and proposing the second one.

Monty:

Yes. The steps and how they were selected, rather than just the finished itinerary.

Did the system follow a rule written in advance, or did the model choose to search for alternatives, inspect the results, and decide which option to check next?

A record of searches and tool results helps us inspect that process. We don’t need access to the model’s private internal reasoning. But the steps alone may not settle it: a fixed workflow could perform those same searches.

So a convincing result doesn’t, by itself, tell us whether an agent produced it.

Stephen:

Go ahead.

Monty:

There’s another wrinkle: a chatbot and an agent aren’t necessarily different products.

The same chat window might give you advice about organising photographs, or start a process that inspects files, chooses actions, and creates organised copies.

The window hasn’t changed. What happens behind it has.

And the LLM isn’t doing the copying itself. It requests an action. The surrounding software carries it out and returns the result. The model is one part of the agent system, alongside its tools and controls.

So “it looks like a chatbot” doesn’t tell us whether it can act as an agent.

Stephen:

Some chatbots can also perform actions, such as browsing the web or writing a Python program, say. Is that because they’ve been enhanced with some of the features of agents, but not all? Or am I skipping too far ahead here?

Monty:

Not too far ahead. That’s exactly where the distinction gets useful.

Having a tool doesn’t automatically make something an agent. A chatbot might search the web once, then answer. Or follow a fixed sequence: search, summarise, reply. An agent-like process lets the model use the results to choose what to do next.

And “writing a Python program” could simply mean producing text. Running that program requires an execution tool. Inspecting what happened and choosing a follow-up add further steps.

So I wouldn’t treat agent features as a checklist. I’d ask: what can the system do, and how does it select its next action?

Stephen:

So, how does an agent select the next action?

Monty:

The surrounding software gives the model the goal, relevant instructions, available tools, and results so far. The model uses that information to propose the next step.

With our photographs, that might be: “The date is missing. Ask Stephen.” With the day out: “That museum is unavailable. Search for another nearby.”

If it requests a tool, a system with suitable controls checks whether the action is allowed before carrying it out and feeding the result back to the model. Not every system provides those checks. Then the model gets another turn.

There isn’t necessarily a separate, perfect decision-maker inside it. Choosing an action is another use of the LLM, and it can choose badly.

Stephen:

But will it realise it chose badly when it gets the wrong result? Will it correct course?

Monty:

Sometimes, but getting feedback doesn’t guarantee recognising a mistake.

If copying a photograph returns “folder not found”, that’s a clear signal. The model might create the folder and try again.

But if it guesses the wrong date and the copy succeeds, there’s no obvious error. The action worked, but the judgement was wrong. It may carry on quite happily.

An agent can use results to correct course, but it needs useful checks. And it can misinterpret those checks too. That’s why “the tool ran successfully” and “the task was done correctly” are different claims.

Stephen:

So, how do we minimise these problems?

Monty:

We can’t eliminate them, but we can limit the damage and make mistakes easier to spot.

For the photographs, that means working on copies, keeping uncertain dates labelled as estimates, and asking you when the evidence is too weak. Afterwards, check that every photograph is accounted for and the originals are unchanged.

Those checks catch missing files or unwanted changes, not every mistaken date. That needs different evidence, or your judgement.

And we need a stopping rule: if investigating isn’t resolving the uncertainty, leave the photograph undated or ask, rather than keep guessing.

An agent’s freedom is useful only when it comes with sensible boundaries and checks.

Stephen:

Who takes care of this infrastructure: the user, the agent, or something else?

Monty:

Mostly, the people building and operating the system, through software around the model. We’ll talk about harnesses in a future chapter.

They provide the tools and should enforce access restrictions and set things such as approval requirements and limits on repeated attempts. Those safeguards depend on how the system is built. They aren’t guaranteed merely because it’s called an agent. The user supplies the goal and choices within those controls, for example whether estimated dates need confirmation.

The model can request a check or decide to ask you. But a safeguard that matters shouldn’t depend solely on it remembering to behave.

“Please don’t change my originals” is an instruction and instructions could be ignored. Software that only permits reading those originals provides a stronger boundary. The agent works inside that infrastructure. It isn’t its own reliable policeman.

Stephen:

Got it.

Monty:

Let’s check one subtle case.

An LLM writes a program that sorts photographs into dated folders and always puts those with missing dates into “Undated”. Once you run it, that program follows those rules without consulting the LLM again.

Would you call that an agent or ordinary automation, even though an LLM helped create it?

Stephen:

This is just an automation, not an agent. An agent would follow through to confirm that’s the correct approach and what the user wants.

Monty:

You’re right: that’s ordinary automation. But confirming what the user wants isn’t the defining difference.

A fixed program could also ask, “Shall I put these in ‘Undated’?” Conversely, an agent could choose that folder without asking, if your instructions already allowed it.

The key is whether the model participates while the task is running, choosing how to proceed from the information returned, and not simply whether an LLM wrote the program or the system asks for confirmation.

So an agent might investigate, ask you, or leave the image undated. None of those actions, on its own, proves it’s an agent.

Stephen:

Got it.

Monty:

Back to our fictional Oxford trip: the model learns that a museum is unavailable, chooses to search for alternatives, checks their opening times, and revises the itinerary, all within your agreed budget, without asking you.

Would that still fit our working definition of an agent? What makes the difference here?

Stephen:

Yes, that’s an agent now because it decided what actions to take, used the results to decide what comes next, and stopped only when it felt that the job was done.

Monty:

Yes. That captures the central distinction: the model chooses actions and uses their results to choose what comes next.

I’d adjust only “felt that the job was done”. It should check completion against the request: are the opening times checked, is travel accounted for, and does the itinerary fit the budget? Its confidence isn’t proof.

And it may need to stop before finishing. For example, if it needs your decision or reaches a limit.

Choosing the route through the task makes it agent-like. Checking the outcome helps make it dependable. Those are different things.

Stephen:

I think I understand the distinction now.

Monty:

That’s a good stopping point. Our working distinction is a model choosing how to proceed using the results it receives, rather than simply following a predefined process. That makes it agent-like, not necessarily dependable.

Subscribe now

What we’ve unpacked in this chapter

The useful distinction isn’t the chat window, the presence of a tool, or whether a system asks for permission. For this series, we’re using “agent” to describe a system in which a model helps direct the task as it runs, choosing what to do next using the results it receives. Other people draw the boundary differently.

The key points:

• A fixed workflow and an agent can produce the same result. The result alone doesn’t reveal how the steps were selected.

• The model proposes actions. Surrounding software executes them and determines which controls are actually in place.

• Choosing what to do and having permission to do it are separate questions.

• Feedback can help an agent change course, but it doesn’t guarantee that it will recognise or correct a mistake.

• Neither a successful action nor a confident completion message is proof that the task was done correctly.

Next, we’ll look more closely at who actually does the work: the model, its tools, and the software connecting them.

Subscribe now

<< Previous Post: Stephen’s Preface to Agents Unpacked

>> Next Post: Coming soon…

Table of Contents

October 10, 2026 05:41 PM UTC

Stephen's Preface to Agents Unpacked

Things moved quickly after I started using chatbots. New versions, new terms, new acronyms. And I was busy with actual work, family, and life.

Then I started hearing about agents. And I remember wondering: “Is this really any different from the ChatGPT-type chatbots?”

You still type into a chat window. It still replies. But now it can also do things for you. So what’s different?

That’s what Monty and I are exploring in Agents Unpacked. Monty is my AI assistant. I’m asking the questions.

I’ve set Monty up to follow my teaching and writing style. I teach the way I like to learn, so that matters here. The aim is for his explanations to reflect that approach, too: start with something concrete, build the intuition, and introduce the technical terms when they’re needed.

I tried an earlier version of this exercise. My learning agent drafted a chapter, and I went through it adding questions and comments. We revised it until I was happy with it.

This time, we’re having the conversation first. Monty researches the topic, and then we talk. I ask questions when something isn’t clear, or challenge an explanation that doesn’t quite work. Sometimes I try to explain what I’ve understood, and Monty points out what I’ve got wrong.

And sometimes I need to point out what Monty’s got wrong, too.

What you’ll read is the conversation we actually had. We tidy it up afterwards, take out some clutter, and check the explanations. If an explanation needs correcting, I review that change, too. The questions aren’t added later to make a tutorial look like a conversation.

Yes, Monty’s answers are AI-generated. But I’m involved throughout, and I decide what makes it into the article. An answer that sounds convincing isn’t necessarily a correct one.

We’ll start with that question about agents and chatbots. Then we’ll look at who’s doing the work, what an agent remembers, and how much freedom we should give it. And what happens when it gets things wrong.

You don’t need to know how to program to follow along. We’re trying to understand what’s happening, rather than learn one particular tool.

There’s a planned table of contents, but it may change. We’ll see where the questions take us.

Subscribe now

>> Next Post: 1. What makes an AI agent different from a chatbot?

Table of Contents

October 10, 2026 04:19 PM UTC

Agents Unpacked • Table of Contents

Here’s the planned route through Agents Unpacked. The titles and article boundaries may change as the conversations develop.

Part I • From conversation to action

1. What makes an AI agent different from a chatbot?

2. Who actually does the work—the model or the software?

3. How can words turn into actions?

4. Does an agent need a plan?

Part II • Checking the work and setting boundaries

5. How do we know it really finished the job?

6. What does an agent actually remember?

7. How much freedom should we give it?

8. What happens when a web page tells it what to do?

Part III • Beyond a single conversation

9. Can we teach an agent new skills without retraining it?

10. What happens when the job outlasts the conversation?

11. Are several agents better than one?

12. When is an agent the wrong tool?

October 10, 2026 12:42 PM UTC

October 09, 2026

Python Morsels

Python 3.15's best new features

Python 3.15 includes a UTF-8 default encoding, explicit lazy imports, * unpacking in comprehensions, a new sampling profiler, sentinel, frozendict, and more!

Table of contents

1. A UTF-8 default encoding
2. Sentinel objects
3. Unpacking in comprehensions
4. Explicit lazy imports
5. The new profiling package
6. Improved error messages
7. More color!
8. A few quick ones
9. Try out Python 3.15 yourself

>>> with open("cafe.txt", mode="wt") as f:
...     f.write("café")
...
4

>>> open("cafe.txt", encoding="cp1252").read()
'café'

>>> with open("snake.txt", mode="wt", encoding="cp1252") as f:
...     f.write("🐍")
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
    f.write("🐍")
    ~~~~~~~^^^^^^
  File "/home/trey/.local/share/uv/python/cpython-3.15.0rc2-linux-x86_64-gnu/lib/python3.15/encodings/cp1252.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_table)[0]
           ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
UnicodeEncodeError: 'charmap' codec can't encode character '\U0001f40d' in position 0: character maps to <undefined>

Read the full article: https://www.pythonmorsels.com/python315/

October 09, 2026 02:11 PM UTC

Rodrigo Girão Serrão

The 5 most exciting new features of Python 3.15

This article explains the 5 best new features of Python 3.15 with clear examples and explanations.

Python 3.15 has been published and it packs plenty of new features and improvements over Python 3.14. This article explores the five most exciting new features of Python 3.15:

1. Lazy imports
2. New built-in frozendict
3. New built-in sentinel
4. Unpacking inside comprehensions
5. Tachyon, a new sampling profiler

You'll get the elevator pitch of each feature and you'll see a couple of examples of their usage.

By the end of this article you'll have a clear picture of some of the new cool features that Python 3.15 brings to the table and you'll be excited to try them out.

15 days of Python 3.15

To celebrate the release of Python 3.15, over the next 15 business days I'll be writing about a new 3.15 feature every day. Explained clearly and with examples so you don't have to sift through the changelog.

Subscribe to receive this free email series:

If you want, you can also check the schedule of the upcoming emails.

Lazy imports

Explicit lazy imports, introduced in PEP 810, introduce the new keyword lazy so that you can mark an import as lazy. Lazy imports don't run the module you're importing until the imported name is needed.

This feature is very useful if you have applications that have a slow startup time because they import heavy modules. For example, you can speed up the startup time of a CLI by lazy importing the dependencies of the CLI or the startup time of a development server that doesn't need to frontload every single dependency while you're debugging.

A lazy import starts with...

October 09, 2026 12:15 PM UTC

Glyph Lefkowitz

Programming Isn’t Special

Creative Work

Writers went on strike to get protections against “AI”. Thousands of artists have signed open letters in protest of “AI”. There are so many copyright lawsuits from creative industry groups against AI that there’s a whole dedicated website for it. Popular YouTubers absolutely hate it. If they’re also musicians, they REALLY hate it. Across all creative industries, there is a concerted push to reject this technology.

Yet, almost unique among creative fields, many experienced programmers remain convinced that it’s fine to use “AI” for programming. We do seem to hate it, and it’s making us all miserable, and what it’s doing to our industry, but we are using it anyway.

A lot of the justification of this resignation seems to be to be because programming is not Art. If the tool can get the job done, and the job is just functional, then why does it matter?

It does matter, though. It matters because we shouldn’t be using AI to produce Art, and programming is Art.

Art can be Mundane

Some people will say that programs cannot be art because programs are functional, rather than being expressive. Programs are mundane whereas art is transcendent.

This is based on a distorted understanding of what Art actually is.

In John Berger’s “Ways of Seeing”, he names this type of distortion “mystification”. His example of this process is both amusing and illustrative. I encourage you to read it in its entirety.

In summary, though: Berger critiques the florid prose of an art historian describing a commissioned group portrait, including phrases like “subtle modulations of the deep, glowing blacks” and “harmonious fusion”. The portrait is described as sublime, in nearly ecstatic terms.

Berger reveals that the reality of this portrait is that a poor old painter needed some work, and some officials probably thought it might be nice to have an official portrait. So they paid some money to the poor old man, and he painted it, and then they had a painting. It’s a well-executed portrait of a group of people. Beautiful, even. But it was work commissioned for a fairly mundane purpose and it suited that purpose just fine. It was not, and is not, a divine relic.

Culturally, we are prone to mystifying painting, and sculpture, and film, and music. We imbue them with “subtle modulations”. We ignore their functional aspects — we desire decoration, amusement, and distraction — and focus on their emotional impact.

Don’t get me wrong: I love me some good aesthetic philosophy. I think it’s great to really examine our reactions to artwork and to try and gain a deeper understanding of our culture and our selves through media analysis. If anything we really need to do more of it.

This does not mean that the creation of such works is mystical or that it should be venerated beyond any other sort of labor.

Not least of which other types of labor that are adjacent to, but not as culturally venerated, as fine art. We tend to mystify the work of a novelist, but to denigrate the work of a journalist. In reality, the functional prose of the journalist is no less important and deserves no less respect.

Although they might be far below the ethereal realm that novelists inhabit in our collective imagination, even journalists receive more respect and thus more mystification than lowly copywriters. Yet, there is no transcendental distinction between “novelist” and “copywriter”; the many of the skills are the same, and the distinction is merely an accident of commerce and opportunity.

In fact, many famous writers have famously inhabited both roles. This is not an accident! Working with words professionally, even (perhaps especially) mundane words, is excellent practice for working with words in a more purely artistic context, because even mundane creativity is still artistic.

Code can be Beautiful

One thousand Internet years ago, when I was in my late teens, I would describe myself as a “code poet”. I was relentlessly mocked for this as what the Youth would today call “being cringe”, and at the time was referred to as “pretentious”.

I succumbed to the peer pressure, removed it from my email signature and my bio. While I still believed strongly in the parallels, I accepted that — socially, at least — comparing code to poetry, or indeed to Art, was a silly thing to do.

However, I never abandoned the idea, in my heart.

The thing that I am most well-known for, the invention of Deferred, was specifically an aesthetic reaction to the tedium of passing callback and errback parameters to every single remote procedure call in an RPC client/server application. Those two callbacks got the job done just fine. But they were ugly, and annoying to work with.

Deferred is an intentional poem about asynchronous task execution, with a deliberate eye to the aesthetics of the problem and the experience of using it. It was influential because of its focus on aesthetics.

I do not want to overstate the beauty or profundity of this minor contribution, or indeed its durability. That a poem exists does not mean it is a great poem, merely that it is a poem.

Our aesthetic culture around programs is more like folk epic poetry than fine art, so the influence of this contribution is less about its specific enduring power than it is about its influence on what came next; from MochiKit.Async to JQuery Deferred to JavaScript Promises and eventually to async/await; a long chain of different artisans each adding something of their own until the original has all but dissolved. (And I wasn’t the “original” here, either, as I drew heavily from the E language’s Promises, among other things.)

In order to make code into a deliberate artistic expression, one must have spent quite a bit of time contemplating the problem domain. Without having experienced the tedium of manually passing a thousand callback parameters, I would have had neither the skill, nor indeed the motivation, to bother creating such a thing.

Now, most code does not have to be like this. Most code does not get to be like this. Most code is functional, workday code. Most code could not make a lady weep. It’s just copy-writing, if you will.

As I explained previously, most writing couldn’t do that either. Most writing is just copy-writing, too. Most visual art is advertising. Most live music performance is background music in bars that will go largely ignored.

However, code that is intentionally aesthetically designed tends to be important, both socially and technologically.

We do have some tradition of self-mystification in software. As Abelson memorably put it, “Programs must be written for people to read, and only incidentally for machines to execute.”, so we have long had some conception of programs as highly expressive, even if we can’t always agree on what they’re expressing or to whom. We will occasionally wax poetical about the philosophical implications of a particular piece of software. This is not unique to a single piece of software, either; more than one community has indulged in similar philosophizing.

The expressive and aesthetic qualities of software are not limited to reading source code or interacting with other programmers via APIs, either. For example, every year, Federico Viticci does a review of Apple’s new operating system, which is (among other things) an aesthetic critique. Such a project would not be possible if the software did not have an aesthetic impact on its users.

Not to mention that every video game review is also a software review.

Defend The Mundane

If we use AI to erase all the copy-writing, all the graphic design, all the boring mundane art, and yes, all the boring custom WordPress theme development, then we will be removing all the practical opportunities for the vast amounts of practice and contemplation required for people to elevate their craft to eventually achieve great things. Education is great, but the majority of true skill development happens on the job and always has.

This doesn’t mean that we can’t use abstractions, or automation, to make our work easier. Programming is the art of abstraction, of understanding how to compose smaller ideas into bigger ones, of how to understand the automation of a larger system by understanding the rules that automate smaller ones and understanding how to combine them.

When we use “AI” to eliminate that understanding rather than raise it up to a higher level, to entirely destroy that creative decision-making process, we do a disservice both to ourselves as programmers and to our users. We would be doing a disservice to our users and our downstream fellow developers in the same way that a visual artist would be doing a disservice to their viewers or a musician would be doing a disservice to their listeners if they served them auto-generated filler instead of their own creative output.

Slop is slop, no matter the medium.

Each mundane project has some tiny chance — let’s say, something like 0.1% — of achieving greatness. If we do a single project with AI, then sure, whatever, there’s almost no chance that that project was going to be the one hit to create that career-defining moment for an engineer working on it. If we make a habit of doing all projects that way, though, we take the total likelihood of those moments of greatness from “definitely sometimes” to “never”.

The precisely appropriate ways in which to resist AI encroachment on all software development lie well beyond the margins of this one short post. How much you can resist and which specific uses you should resist are up to you. But it is worth resisting in software just as much as it would be worth resisting in any creative medium.

Programming isn’t special. It’s just Art, and Art is the most human — and thus, the most universal — thing that there is.

Acknowledgments

Thank you to my patrons who are supporting my writing on this blog. If you like what you’ve read here and you’d like to read more of it, or you’d like to support my various open-source endeavors, you can support my work as a sponsor!

October 09, 2026 07:00 AM UTC

LernerPython blog, from Reuven Lerner

Pandas groupby: Get a data frame instead of a series

groupby on a single column in Python Pandas returns a series. Want a single-column data frame?

Instead of

df.groupby('passenger_count')['total_amount'].mean()

pass a one-element list of data columns:

df.groupby('passenger_count')[['total_amount']].mean()

The post Pandas groupby: Get a data frame instead of a series appeared first on LernerPython.

October 09, 2026 06:00 AM UTC

Wingware

Wing Python IDE 12.1 Beta - October 9, 2026

Wing 12.1 is now available as a beta release. It introduces guided autonomous development. You specify the goals, answer questions, and review results. AI agents design and write the code, unit tests, and documentation. Wing keeps you in control. Wing Pro 12.1 now supports Claude Code, Codex, Antigravity, Copilot, Cursor, goose, OpenCode, and other ACP-compatible AI coding agents. It also adds a new Modern look and display themes, graphical revision control history, and many other improvements.

Downloads

This is a beta release. Please try it and email us if you find problems or have suggestions!

Wing 12.1.0 -- Full-featured Python IDE with two licensing tiers

Wing 101 12.1.0 -- Free IDE for teaching beginners to program

Wing 12.1 will replace Wing 12.0 when it is installed. You can revert to Wing 12.0 by reinstalling it at any time.

To get started quickly with autonomous development in Wing 12.1, see Getting Started with Autonomous Development.

New in Wing 12.1

Autonomous Development with the Tasks Manager

The new Tasks Manager is an agent that runs the Tasks tool's queues for you, so that development proceeds autonomously under your direction. You write tasks, mark the ones you want started as Ready, and review the results.

The Manager accepts anything from a bug report to a high-level specification for a new software project. It can break down larger tasks into a design and development plan. It decides task order, serializes those that are likely to edit the same files, and runs closely related tasks in shared session context. It can message a running agent to tell it about related work or new insights, or redirect it if it goes astray.

While the Manager is on, tasks run autonomously: Rather than stopping to ask questions or present intermediate results, each works as far as it can and ends with a report of the judgement calls it made along the way, and any questions it has left. A new Questions tab in the Tasks tool collects everything that is waiting for you, so you can provide answers in one place. Follow-up work and problems that agents notice as they run are added to the Plan tab of the Tasks tool as new tasks. The Manager may automatically start found tasks that are closely related to ongoing work; others wait for your review.

You stay in control of which work runs, how much the Manager can do, and how results are reviewed. Every change the Manager makes is listed and can be reverted or revised, even after changes have been committed. You can also talk to the Manager to ask about the status of development or give it special instructions about your development workflow.

Claude Code and Codex are best for autonomous development, since they self-check the safety of commands that they run. Antigravity, Copilot, and Cursor also work but don't implement the same level of safety checks. See AI Agent Safety in the AI Agent-Assisted Development chapter of the manual in Wing 12.1's Help menu for details and safety recommendations.

The Manager agent itself and queues in the Tasks tool can each use a different agent. You bring your own subscriptions or API keys for the agents you choose. Wing does not install agents or provide access to models.

Other Improvements

Your Choice of AI Agent: Wing 12.1 adds support for other AI agents, now including Claude Code, Codex, Antigravity, Copilot, Cursor, goose, and OpenCode, either using their Textual User Interfaces (TUIs) or the Agent Client Protocol (ACP).

User Interface: An optional new Modern look redesigns the toolbar, Preferences dialog, status bar, and tab overflow, and improves the display font. A welcome window lets you choose what to open at startup. Two new display themes, Night Flight and Solo Flight, have been added. Themes can now incorporate transparent colors, be imported from VS Code, created from a small set of colors, or exported from your current color configuration.

Tasks Tool (Wing Pro): New Checklists hold recurring reviews, fixes, and release and deployment steps. A task's committed changes can now be reverted, edited, or commented on. Every task has a short ID that links to the task wherever it is cited, and mini-search works on every tab. Tracking of changes made by concurrently running tasks is more reliable, and there are many other fixes to task and session management.

Version Control (Wing Pro and Wing Classic): The git and mercurial logs now show a graphical history with expandable diffs, Project Log replaces Show Changeset, and the editor can show annotations with commit message tooltips.

Editor and Analysis: In all products, the editor's scroll bar shows marks for diffs, search matches, and errors and warnings. Source analysis is faster and its database is about 30% smaller.

Other Changes: Wing now offers to remove large cache directories left behind by older versions. Accept Debug Connections has moved to Project Properties so it is set per project. Wing 12.1 also includes many bug fixes, particularly for remote development and Docker containers, debugging free-threaded Python on Windows, git worktrees and submodules, non-ASCII text on Windows, unit test discovery, and display themes.

See the change log for details.

Getting Started with Autonomous Development

To get started quickly with autonomous development in Wing 12.1, see Getting Started with Autonomous Development.

If you have questions, please don't hesitate to contact us at support@wingware.com.

October 09, 2026 01:00 AM UTC

Python Insider

Python 3.15.0 (final) is here!

A brand new Python here for you to enjoy!

October 09, 2026 12:00 AM UTC

Core Dispatch

Core Dispatch #11

Welcome back to Core Dispatch! This edition covers August 27 through October 9, 2026 (It's been a while 😅). Python 3.15.0 final landed today after an extra release candidate for lazy-import blockers. Huge congrats to Hugo van Kemenade for getting the 3.14 and 3.15 feature releases out the door! The latest maintenance releases also mark Python 3.10's end of life and 3.13's move to security-only support. Python 3.16.0 alpha 1 is expected on October 13.

New PEPs revisit None-aware access, coalescing operators, incremental garbage collection, and more expressive type annotations. PEP 755 was withdrawn; PyPI's namespace rules will instead live in PyPI policy. On CPython's main branch, notable merges improve free-threaded performance and fix security and memory-safety issues.

The Python Language Summit writeups cover free-threading, garbage collection, the buffer protocol, and Rust in CPython. The PSF Board and inaugural Python Packaging Council election results are out, and Nathan Goldbaum and Sergey Miryanov have joined the core team.

Please test your projects with Python 3.15.0 and publish compatible wheels where applicable. If you find a bug, file a CPython issue.

Upcoming Releases

• Python 3.16.0 alpha 1 — Oct 13

Official News

• Python 3.15.0 final is here — By Hugo van Kemenade
• Python 3.10.22, 3.11.17, 3.12.15, 3.13.16, and 3.14.8 are available — By Pablo Galindo
• PEP 827 and type manipulation at the Python Language Summit — By Seth Larson
• The next phase of free-threaded Python — By Seth Larson
• Rust for CPython at the Python Language Summit — By Seth Larson
• Revisiting Python’s memory buffer protocol — By Seth Larson
• Generational and incremental garbage collection — By Seth Larson
• 2026 PSF Board election results — By Marie Nordin
• Inaugural Python Packaging Council election results — By Deb Nicholson

PEP Updates

• PEP 755: Implicit namespace policy for PyPI — Withdrawn; PyPI will maintain the namespace policy separately
• PEP 848: Generational incremental garbage collection
• PEP 849: More expressive type expressions
• PEP 823: None-aware access operators
• PEP 824: None-coalescing operators
• PEP 845: Leading-dot value patterns
• PEP 846: Docstrings for type aliases

Steering Council Updates

• 2026-09-10 Steering Council meeting summary
• 2026-09-03 Steering Council meeting summary
• 2026-08-27 Steering Council meeting summary
• 2026-08-20 Steering Council meeting summary
• 2026-08-13 Steering Council meeting summary

Merged PRs

• Validate http.client response lengths and chunk sizes
• Fix a crash in bytes.join() when a list is mutated concurrently
• Fix a use-after-free in io.TextIOWrapper during reentrant detach
• Soft-deprecate C APIs that modify str objects
• Speed up list.insert() and indexed deletion in free-threaded builds
• Speed up deallocation of non-GC objects
• Validate SSLContext.wrap_bio() arguments when hostname checks are enabled
• Fix a use-after-free in server-side SSLContext callbacks
• Prevent a symlink race during TemporaryDirectory cleanup
• Fix an out-of-bounds write in mmap.mmap.__setitem__()
• Honor tarfile filters when extracting link fallbacks
• Correct submodule binding for lazy import a.b as c
• Make Py_InitializeFromConfig() return without exiting Python
• Prevent thread starvation during free-threaded stop-the-world pauses

Discussion

• PEP 823: None-aware access operators — New PEP discussion
• PEP 824: None-coalescing operators — New PEP discussion
• PEP 848: Generational incremental garbage collection — New PEP discussion
• PEP 843: export statement for DRY re-exports — 🔥 69 new replies · 4.0k views
• PEP 805: Safe parallel Python — 🔥 43 new replies · 8.5k views
• PEP 832: Virtual environment discovery — 🔥 30 new replies · 13.9k views
• PEP 836: Path to a supported CPython JIT — 🔥 11 new replies · 7.9k views

Core Dev Musings

• Why re.match() was soft-deprecated — By Hugo van Kemenade

Upcoming CFPs & Conferences

• PyCon Greece 2026 — Oct 12
• 📋 PyCon Wrocław 2026 CFP deadline (extended) — Oct 15
• PyCon NL 2026 — Oct 15
• PyCon Taiwan 2026 — Oct 17
• 📋 SciPy India 2026 CFP deadline — Oct 19
• PyCon Panamá 2026 — Oct 22
• Swiss Python Summit 2026 — Oct 22
• PyHo 2026 — Oct 22–24
• PyBeach 2026 — Oct 24

Credits

• Savannah Ostrowski

October 09, 2026 12:00 AM UTC

October 08, 2026

Anarcat

PSA: Europe changes time forward soon, North America next, for the last time?

This is a copy of an email I sent at work. I'm not sure I should be making noise about this here, feedback welcome.

This is your bi-yearly reminder that time is changing soon! October 25th in Europe, November 1st in North America. Less people in Canada are changing this year, with BC, Alberta, Manitoba and Northwest Territories getting rid of DST.

What's happening?

Some places in the world implement what is called Daylight saving time or DST:

https://en.wikipedia.org/wiki/Daylight_saving_time

Normally, you shouldn't have to do anything: computers automatically change time following local rules, assuming they are correctly configured, provided recent updates have been applied in the case of a recent change in said rules (because yes, this happens, and happened this year, and yes, you need to upgrade your software!).

Of course, appliances like your microwave oven will likely not change time and will need to adjusted unless they are so-called "smart", in which case they are part of the skynet botnet and should be destroyed.

If your clock is flashing "0:00" or "12:00", you have no action to take to adapt to this change, lucky you.

If you haven't changed time in six months, congratulations, your clock will be accurate again!

In any case, you should still consider DST because it might affect some of your meeting schedules, particularly if you set up a new meeting schedule in the last 6 months and forgot to consider this change.

If your location does not have DST

Properly scheduled meetings affecting multiple time zones are set in UTC time, which does not change. So if your location does not observer time changes, your (local!) meeting time will not change.

But be aware that some other folks attending your meeting might have the DST bug and their meeting times will change.

Be kind to those poor souls which might be missing meetings by a full hour because time flies backwards for them.

If you do observe DST

If you are affected by daylight savings, your local meeting times will change for UTC meetings. Normally, your meeting times are scheduled to take this into account and the new hours should be reasonable.

But now is a good time to verify that. Take a look at your schedule for the next couple of weeks and reschedule meetings before the daylight saving come up to avoid too much disruption. You have only a couple of weeks to do so right now.

When do times change, how, and and where?

As regular readers will remember, the rule of thumb is:

Spring forward, fall backwards.

That is, during the season of Spring, the clocks move forward, and during the Fall (like right now), they move backwards. That is in the northern hemisphere, but then the southern hemisphere is often saner and doesn't switch anyways.

So time will move backwards which means an extra hour of sleep. Unless you have children or bad sleep, in which case your body doesn't care about what the clock says and will wake up one hour earlier than what it should.

And of course, this doesn't happen everywhere at once, so let's see when it happens where.

Europe

The dance starts in Europe.

The change happens on the last Sunday in October at 01:00 UTC (not local time!), that is October 25th. If you are in the central European timezone, also known as Amsterdam, Berlin, or Paris time depending on your national affiliation, that essentially means that at 2:59 local the clocks will fall back to 2:00 instead of going to 3:00.

Concretely, set your watch back one hour before going to bed, go to bed at the normal time, and enjoy an extra hour of sleep or leisure.

If you have kids, you might want to start getting them to bed slightly earlier every day for a week before the change so they take time getting used to the change. If you have trouble sleeping in the morning, find your inner child and do that to yourself as well.

USA / Canada

Then it's the US[1] and Canada[2] joining the dance, on the First Sunday in November at 02:00 local (not UTC!), that is, I believe, November 1st 2026.

This means that, at 1:59, the clocks will flip to 1:00, instead of 2:00.

Concretely, do like the Europeans and tweak your clock before going to bed.

That is a little less than four weeks from now.

[1] except Arizona (except the Navajo nation), US territories, and Hawaii

[2] except Yukon, Saskatchewan, (newly) British Columbia, (newly) Alberta, (newly) Northwest Territories, (newly) Manitoba, one island in Nunavut (Southampton Island), one town in Ontario (Atikokan) and small parts of Quebec (Le Golfe-du-Saint-Laurent)

Other places with DST

This time again, I must apologize to the people of Cuba, Lebanon, Israel, Palestine, Egypt, Chile, Australia, and New Zealand, as you fine folks all have your own DST rules that are omitted here for brevity. I rely on this page from Wikipedia to be updated by time nerds accurately for this message, and it should provide you with a rough idea of what's coming:

https://en.wikipedia.org/wiki/Daylight_saving_time_by_country

In general, changes also happen in October, but either on different times or different days, except in the south hemisphere, where they might happen in September (oops, sorry NZ folks, I'm late!).

Places without DST

Everyone else, enjoy, you're on the right side of history, and we thank you for the good example you give us.

Changes since last time

There's been lots of changes since last time:

• British Columbia moved to permanent -07 on 2026-03-09, that is it will not change to normal time in November

• Alberta moved to permanent -06 on 2026-06-18, similar to BC above.

• Canada’s Northwest Territories moved to permanent -06 on 2026-08-21, matching Alberta.

• Manitoba moves to permanent -05 on 2026-10-31.

• Morocco moves to permanent +00 on 2026-09-20.

• Moldova has used EU transition times since 2022, but the tz database only noticed in 2026

This is my interpretation of the changes announced on the tzdata mailing list here:

https://lists.iana.org/hyperkitty/list/tz-announce@iana.org/latest

If the eastward trend continues, Canada should adopt country-wide "no daylight savings" rules by 2027, although there's actually no sign of the other provinces (Ontario, Québec and so on) currently running bills to change those rules just yet. Poor Canadians like me confused about time in their countries can refer to this section of Wikipedia for details:

https://en.wikipedia.org/wiki/Daylight_saving_time_in_Canada#By_province_and_territory

... and particularly the image featured there:

https://commons.wikimedia.org/wiki/File:Canada_time_zone_map-en.svg

It also seems like the US government might finally adopt a permanent daylight saving change bill in 2026, as the "Sunshine protection act" pass the house in July:

https://en.wikipedia.org/wiki/Sunshine_Protection_Act

True to form, this was associated with absolutely ridiculous pressure from Donald Trump against republicans (his own party!) objecting to the change:

On July 14, 2026, the House passed a Sunshine Protection Act bill backed by President Trump. Nevertheless, the bill was opposed in the Senate by Republicans, including Senator Cotton. In response, on October 3, 2026, Trump shared a post on Truth Social urging Cotton to approve the bill, where he revealed Cotton's personal cellphone number and called on people to call him.

https://www.theguardian.com/us-news/2026/oct/03/trump-tom-cotton-daylight-saving-time

Given that the last time the US did a major change to the daylight savings policy (in 2005), Canada followed suit to stay in sync, it's quite possible Trump's mad dash might actually finish getting rid of DST in North America:

https://en.wikipedia.org/wiki/Energy_Policy_Act_of_2005#Change_to_daylight_saving_time

October 08, 2026 07:30 PM UTC

Django Weblog

Django security reporting update

We are no longer accepting new security reports for the Django project through HackerOne. Existing reports submitted through HackerOne will remain open and continue to be handled by the Django Security Team.

If you discover a security issue in Django, please follow the reporting process described in the Django security policies.

Security issues should be reported by emailing security@djangoproject.com

October 08, 2026 11:00 AM UTC

Eli Bendersky

Monte-Carlo simulations

Monte Carlo simulations (or methods) is the technique of applying randomness and the Law of large numbers to the solution of various scientific and engineering problems. One of its first documented uses was by Stanislaw Ulam and John von Neumann for nuclear weapon simulations after WWII [1].

In this post I want to provide examples of some simple uses of Monte Carlo simulations. We'll start with the classical example of calculating the value of \pi by throwing darts.

const total = Number(samples.value);
let inside = 0;
for (let i = 0; i < total; i++) {
  const x = Math.random();
  const y = Math.random();
  const inCircle = x * x + y * y <= 1;
  if (inCircle) inside++;
}
estimateValue = 4 * inside / total;

C = 0
run N times:
  draw a random 12-card hand from a fresh deck
  count sets in the hand
  if no sets:
    C += 1

Estimated probability = C / N

Retirement projection

One domain where Monte Carlo simulations are ubiquitous is projections for retirement portfolios. Suppose someone prepares to retire with a total sum of 1 million dollars in their portfolio; they'd like to be able to draw $30,000 a year from the portfolio for their living expenses. Would that work?

There's a large number of factors to take into account when analyzing this question, but for simplicity let's focus on just two: portfolio return and inflation. We can run a naive estimate, assuming average values: suppose an average yearly portfolio return of 4%, and average yearly inflation of 2% [4]

Let's denote our portfolio return as r=0.04, and inflation as q=0.02. Then the real return each year is:

\[r^{\mathrm{real}}=\frac{1+r}{1+q}-1\approx0.0196\]

Starting with $1,000,000, at the end of the year we'll have $1,019,600 and then draw $30,000 for living expenses [5], ending with $989,600. If we continue this way, the money runs out after ~55 years, which means that a person retiring at the age of 65 should be reasonably safe, right?

But this is very simplistic; assuming just average returns is risky, because they do a poor job of representing reality, and many factors have uncertainty. For example, the sequence of returns matters a lot; a bad year (-10%) followed by a great year (+18%) would still count as "4% on average" but produces significantly less money than two consecutive +4% years. Inflation is also unpredictable, and sometimes correlated with portfolio returns; there could be bad years of high inflation and low / volatile returns that can wreak havoc on a portfolio.

As we add factors (variance in yearly draws, mixed portfolios of stocks, bonds, real estate, life expectancy, unexpected events, changing tax laws etc.), relying on a single average estimate becomes increasingly more fraught. This is why Monte Carlo simulations are very popular in this domain: by drawing from reasonable distributions based on historical data, a Monte Carlo simulation can easily run a million different scenarios and provide estimates: for example, what are the odds of money running out before death.

Here's a useful chart from a simulation I ran:

In the top chart:

• The dashed line shows the constant assumptions mentioned before: what happens when yearly return is always 4% and inflation is always 2%.
• The shaded blue areas demonstrate the outcomes of 1,000,000 simulations where inflation and return numbers are drawn from reasonable normal distributions based on historical data. We see that in 25% of the cases, all money ran out by roughly 22 years.

In the bottom chart:

• It's even easier to see how long the funds last; if we're interested in knowing, say, what are the odds that this plan will have enough money for 30 years - the chart shows it's about 60% (since in 40% of the simulations the funds were depleted at this point).

Looking a this simulation, under the current assumptions the plan sounds much riskier than the average assumption makes it appear. Assuming that a 65-y.o. person would plan for 25 years of retirement until death, the ~30% odds of not having sufficient funds for this duration of time are sobering. Perhaps a change in plans is needed (such as a more frugal lifestyle or securing additional funds in some way).

Retirement projection is only one of may ways in which Monte Carlo simulations are used for financial and economical applications; given the high uncertainty of these domains, it's very difficult to plan using analytical calculations. Company sales projections, growth projections, stock offering prices and much more uses Monte Carlo simulations to arrive at estimates with reasonable error bars.

October 08, 2026 09:35 AM 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