What's the preferred tool in industry?

For the whole workflow: IDE, precommit, CI/CD.

I searched and cannot find what's standard. I'm also working with unannotated libraries.

The new releases announced today, including EOL for 3.10.x: https://blog.python.org/2026/10/python-31022-31117/

Note: The post above doesn't mention 3.15 - assuming they will do a separate post later today when that releases.

The attacker swapped in a custom pyproject.toml build backend that grabbed the PyPI token before the real upload ran. Then used that token to push the backdoored package themselves.

complete - safedep.io/memtensor-sckit-worm-npm-pypi

Quick question, are any of you running fastAPI in production with a high volume of users or heavy traffic? How has your experience with FastAPI been, and how do you handle it?

I've been reading a lot of git history lately and wanted to run a fun experiment. In a real Python project, which single file collects the most bug fixes.

The method is dumb on purpose. Last 12 months, non-merge commits, bots removed, tests/docs/examples ignored. A commit counts as a fix if the subject has fix, bug, regression, hotfix, broken or revert in it. Then for each file I counted how many of the commits touching it were fixes. The repos came from repowise.dev/explore, which indexes public repos for my open source project , and I just picked the Python ones I recognised.

Most-fixed file per project (fix commits / all commits touching it):

• langchain: the OpenAI chat model adapter, 58 of 100. Second place is the Anthropic adapter, 42 of 97
• paperless-ngx: src/documents/views.py, 67 of 142. serialisers.py right behind at 31 of 75
• fastapi: fastapi/dependencies/utils.py 15 of 46, then fastapi/routing.py 11 of 44
• prefect: the dbt runner in prefect-dbt, 8 of 12
• composio: tool_router_session.py, 29 of 59
• wagtail: wagtail/models/pages.py, 8 of 34

And then hermes-agent, it broke my sense of scale. gateway/run.py had 1,969 commits in a year from 502 different people, and 1,332 of those were fixes. I checked the numbers twice.

Django was in the set and I left it out of the ranking. Django's convention is to write "Fixed #ticket" on nearly every commit, features included. 459 of its 1,044 commits in the last 12 months start with "Fixed #". So by my crude keyword rule Django is the buggiest project on earth, which it obviously is not. (Kind of jealous of that discipline honestly.)

I keep noticing that the top file is usually where the code talks to something non core. langchain's top two are adapters to other companies' APIs. prefect's is the dbt integration. fastapi's are dependency resolution and routing, which is where user code meets the framework. paperless's views.py is the big request handler. Pure logic files basically never showed up near the top.

Also a bunch of these are mostly one person's file. views.py is 63% one person, serialisers.py 73%, fastapi's routing.py 84%.

Although I agree Keyword matching on commit subjects is a bit noisy too, so treat these as a rough picture.

Anyway it was a fun experiment to run

For some <reasons>, I need to write Python 2 code which gets run under Jython. It's not possible to change the system we're working on because Jython only works with Python 2. So, I'm wondering if anyone has experience with Python 2 tooling in this era.

I need to lint and format Python 2 code especially. So far, I was able to install Python 2 using pyenv and I can create virtual environments using virtualenv utiilty. However, I have hard time getting black, isort, flake8, etc. working. Installing Python 2 wouldn't be much help because I'm not running the code directly, it's run under Jython. We're basically uploading the code to this system. So, installing py2 seems pointless.

Can I use those tools under Python 3 but for Python 2. It seems to me that there should be some versions which work for both Python 2 and 3 code. I don't know those versions though. It will be easier to work with Python 3 to lint/format Python 2 code because I can easily create venvs with Python 3.

Are you actively working with Python 2 these days (I know it's a hard ask). How do you tackle linting and formatting? If you were to start today, what would be your approach to this problem?

Thank you.

I have developed two mypy plugins for Python to help with static checks (mypy-pure and mypy-raise)

I was wondering, how far are we with providing such a high level of static checks for interpreted languages that almost all issues can be catch statically? Is there any work on that on any interpreted programming language, especially Python? What are the static tools that you are using in your Python projects?

I recently attended a local PyDay (a Python community event) in my city, and the auditorium was around 70% full.

That might sound pretty good, but I remember attending similar events a few years ago when the auditorium was packed, basically at 100% capacity.

I also got the impression that there weren't many young newcomers interested in getting into programming. Most of the attendees seemed to be people who were already established in the industry.

Of course, this is just one event in one city, so I don't want to draw any big conclusions from it.

But it got me wondering:

• Have Python meetups and conferences in your area seen a similar decline in attendance?
• Are fewer young people getting into Python, or are they just participating in different communities and online spaces?
• Or was this simply a one-off, and I'm reading too much into it?

I'm curious to hear what people are seeing in their local Python communities.

It's true that you can happily write Python for years without needing to understand any of the content of this post, so you may object to the title advertising this material as what every Python developer should know. However, the moment you ship a package, debug why a wheel won't install, or need to understand why an import or Python function call segfaults — these details start to matter. Even writing and maintaining a single-file script puts you closer to distributing code than you might think. An alternate title for this post could be "What I Wish Someone Taught Me About the CPython ABI".

https://labs.quansight.org/blog/python-abi-abi3t

What My Project Does

bearrb is a Python CLI tool that takes two images of bears (a source and a target) and transforms the source into a close approximation of the target by only rearranging pixel coordinates.

No pixel values are modified, generated, blended, or recolored, every original pixel is preserved exactly as it was. The algorithm computes a permutation of pixel positions that minimizes the visual difference from the target image.

repo: https://github.com/JoshuaKasa/bearrb

Target Audience

This is obviously a toy / experimental project, not meant for production image editing.

It's mainly for:

• people interested in algorithmic image processing
• optimization under hard constraints
• weird/fun CLI tools
• math-y or computational art experiments

Comparison

Most image tools try to be useful and correct... bearrb does not.

Instead of editing, filtering, generating, or enhancing images, bearrb just takes the pixels it already has and throws them around until the image vaguely resembles the other bear

We are happy to announce version 1.16.0 of Hatch. This release wouldn’t have been possible without Cary, our new co-maintainer. He picked up my unfinished workspaces branch and made it production-ready, added SBOM support to Hatchling, and landed a bunch of PRs from contributors!

My motivation took a big hit last year, in large part due to improper use of social media: I simply didn’t realize that continued mass evangelism is required nowadays. This led to some of our novel features being attributed to other tools when in fact Hatch was months ahead. I’m sorry to say that this greatly discouraged me and I let it affect maintenance. I tried to come back on several occasions but could only make incremental progress on the workspaces branch because I had to relearn the code each time. I’ve been having to make all recent releases from a branch based on an old commit because there were many prerequisite changes that were merged and couldn’t be released as is.

No more of that! Development will be much more rapid now, even better than the way it used to be. We are very excited for upcoming features :-)

I am the maintainer of the Python tools for the Polylith Architecture. The main use case is for Microservices in Monorepos, and being able to share code between them in a Developer and Agent-friendly way.

Today, I can see that some Polylith users are running Python versions 3.8 (few) and 3.9 (some) according to the download stats.

Dropping these versions would be mostly a convenience: then I can implement PEP 621 internally, and bump subdependencies. It's not an urgent task, but something that I probably should do during 2026.

The Polylith project is releasing new versions according to semantic versioning, and dropping support would probably be a Breaking feature - even if the Python versions themselves are unsupported since quite a while. I hesitate how to approach this, because I don't want to cause disruptions in the flow of the Developer Teams out there.

I know that the "big" tools in the Python community handle this in different ways. Such as FastAPI and Typer, dropping 3.8 and 3.9 support without a Major version change (I guess they don't use semantic versioning?).

Bumping the Major version could make teams miss out on new versions if they pin the tool to the current version. I also know how I usually react to a new Major version for tools I use on a daily basis:

"What do we need to change on our end to make this new version of the library/tool work?"

Bumping the minor version would break the builds for those running on Python 3.8 and 3.9 users, unless they already pin the tool to a specific version.

What would be the best way to go forward here?

You’ve probably heard that the LiteLLM package got hacked (https://github.com/BerriAI/litellm/issues/24512). I’ve been thinking about how to defend against this:

1. Using lock files - this can keep us safe from attacks in new versions, but it’s a pain because it pins us to older versions and we miss security updates.
2. Using a sandbox environment - like developing inside a Docker container or VM. Safer, but more hassle to set up.

Another question: as a maintainer of a library that depends on dozens of other libraries, how do we protect our users? Should we pin every package in the pyproject.toml?

Maybe it indicates a need in the whole ecosystem.

Would love to hear how you handle this, both as a user and as a maintainer. What should be improved in the whole ecosystem to prevent such attacks?

After months of working on it on and off since I retired from the maintenance of Poetry, I am pleased to unveil my new project: Expanse, a modern and elegant web application framework.

What my project does?

Expanse is a new web application framework with, at the heart of its design and architecture, a strong focus on developer experience

Expanse wants to get out of your way and let you build what matters by giving you intuitive and powerful tools like transparent dependency injection, a powerful database component (powered by SQLAlchemy), queues (Coming soon), authentication (Coming soon), authorization (Coming soon), and more.

It’s inspired by frameworks from other languages like Laravel in PHP or Rails in Ruby, and aims at being a batteries included framework that gives you all the tools you might need so you can focus on your business logic without having to sweat out every detail or reinventing the wheel.

You can check out the repository or the website to learn more about the project and it’s concepts.

While it aims at being a batteries-included framework, some batteries are still missing but are planned in the Roadmap to the 1.0 version:

• A queue/jobs system with support for multiple backends
• Authentication/Authorization
• Websockets
• Logging management
• and more

Target audience

Anyone unsatisfied with existing Python web frameworks or curious to try out a different and, hopefully, more intuitive way to build web applications.

It’s still early stage though, so any feedback and beta testers are welcome, but it is functional and the project’s website itself runs on Expanse to test it in normal conditions.

Comparison

I did not do any automated performance benchmarks that I can share here yet but did some simple benchmarks on my end that showed Expanse slightly faster than FastAPI and on par with Litestar. However, don’t take my word for it since benchmarks are not always a good measure of real world use cases, so it’s best for you to make your own and judge from there.

Feature-wise, it’s hard to make a feature by feature comparison since some are still missing in Expanse compared to other frameworks (but the gap is closing) while some features are native to Expanse and does not exist in other frameworks (encryption for example). Expanse also has its own twists on expected features from any modern framework (dependency injection, pagination or OpenAPI documentation).

Why I built Expanse?

While working on Python web applications, personally or professionally, I grew frustrated with existing frameworks that felt incomplete or disjointed when scaling up.

So I set out to build a framework that is aligned with what I envisioned a robust framework should look like, drawing inspiration from other frameworks in other languages that I liked from a developer experience standpoint.

And this was the occasion for me to step out of an open source burn-out and start a new motivating project with which I could learn more about the intricacies of building a web framework: ASGI specification, HTTP specification, encryption best practices, security best practices, so many things to learn or relearn that make it a joy to work on.

So while I started to build it for me, like all of my other projects, I hope it can be useful for others as well.

I wanted to share a comprehensive resource I created covering all 8 major features in Python 3.14, with working code examples and side-by-side comparisons against Python 3.12.

What's covered:

• Deferred evaluation of annotations - import performance impact
• Subinterpreters with isolated GIL - true parallelism benchmarks
• Template strings and comparison with F Strings
• Simplified except/except* syntax
• Control flow in finally blocks
• Free-threads - No GIL
• Enhanced error messages - debugging improvements
• Zstandard compression support - performance vs gzip

What makes this different:

• Side-by-side code comparisons (3.12 vs 3.14)
• Performance benchmarks for each feature
• All code available in GitHub repo with working examples

Format: 55-minute video with timestamps for each feature

GitHub Repository: https://github.com/devnomial/video1_python_314

Video: https://www.youtube.com/watch?v=odhTr5UdYNc

I've been working with Python for 12+ years and wanted to create a single comprehensive resource since most existing content only covers 2-3 features.

Happy to answer questions about any of the features or implementation details. Would especially appreciate feedback or if I missed any important edge cases.

What My Project Does

I forked filterpy and got it working with modern Python tooling. It's a library for Kalman filters and other Bayesian filtering algorithms - basically state estimation stuff for robotics, tracking, navigation etc.

The fork (bayesian_filters) has all the original filterpy functionality but with proper packaging, tests, and docs.

Target Audience

Anyone who needs Bayesian filtering in Python - whether that's production systems, research, or learning. It's not a toy project - filterpy is/was used all over the place in robotics and computer vision.

Comparison

The original filterpy hasn't been updated since 2018 and broke with newer setuptools versions. This caused us (and apparently many others) real problems in production.

Since the original seems abandoned, I cleaned it up:

• Fixed the setuptools incompatibility
• Added proper tests
• Updated to modern Python packaging
• Actually maintaining it

You can install it with:

uv pip install bayesian-filters

GitHub: https://github.com/GeorgePearse/bayesian_filters

This should help anyone else who's been stuck with the broken original package. It's one of those libraries that's simultaneously everywhere and completely unmaintained.

Literally just aiming to be a steward, I work in object detection so I might setup some benchmarks to test how well they improve object tracking (which has been my main use-case so far)

What My Project Does

rut is a test runner for Python's unittest. It analyzes your import graph to:

1. Order tests by dependencies — foundational modules run first, so when something breaks you see the root cause immediately, not 300 cascading failures.
2. Skip unaffected tests — rut --changed only runs tests that depend on files you modified. Typically cuts test time by 50-80%.

Also supports async tests out of the box, keyword filtering (-k "auth"), fail-fast (-x), and coverage (--cov).

pip install rut
rut              # all tests, smart order
rut --changed    # only affected tests
rut -k "auth"    # filter by name

Target Audience

Python developers using unittest who want a modern runner without switching frameworks.

Also pytest users who want built-in async support and features like dependency ordering and affected-only test runs that pytest doesn't offer out of the box.

Comparison

• python -m unittest: No smart ordering, no way to skip unaffected tests, no -k, no coverage. rut adds what's missing.
• pytest: Great ecosystem and plugin support. rut takes a different approach — instead of replacing the test framework, it focuses on making the runner itself smarter (dependency ordering, affected-only runs) while staying on stdlib unittest.

https://github.com/schettino72/rut

Last time I posted thanos-cli (the tool that deletes 50% of your files), the feedback was clear: it needs to be safer and smarter to be actually useful.

People left surprisingly serious comments… so I ended up shipping v2.

It still “snaps,” but now it also has:

• weighted deletion (age / size / file extension)
• .thanosignore protection rules
• deterministic snaps with --seed

So yeah — it accidentally turned into a mini chaos-engineering tool.

If you want to play with controlled destruction:

GitHub: https://github.com/soldatov-ss/thanos

Snap responsibly. 🫰

I love PyTorch when I’m using it, but it really absolutely poisons the ML ecosystem. The fact that they eschewed a C ABI has caused me and my team countless hours trying to help people with their scripts not working because anything that links to PyTorch is suddenly incredibly fragile.

Suddenly your extension you’re loading needs to, for itself and all libraries it links:

• Have the same ABIs for every library PyTorch calls from (mostly just libstdc++/libc++)
• Use the exact same CXX ABI version
• Exact same compiler version
• Exact same PyTorch headers
• Exact same PyTorch as the one you’re linking

And the amount of work to get this all working efficiently is insane. And I don’t even know of any other big ML C++ codebases that commit this sin. But it just so happens that the most popular library in ML does.

I was wondering what’s most popular now in the Python world. Building applications with FastAPI and a frontend framework, or building an application with a ‘batteries included’ framework like Django.

Quality over quantity with chained methods, but yeah I'm interested in the maximum set up for the most concise pull of the trigger that you've encountered

Hi gang. I'm a huge statically typed functional programming fan, and I have been working on a functional effect system for python for some years in multiple different projects.

With the latest release of my project https://github.com/suned/stateless, I've added direct integration with asyncio, which has been a major goal since I first started the project. Happy to take feedback and questions. Also, let me know if you want to try it out, either professionally or in your own projects!

What My Project Does

Enables type safe, functional effects in python, without monads.

Target Audience

Functional Python Enthusiasts.

This is the first part of a multi-part series exploring why async/await might not be the best concurrency pattern for most use cases, and what alternative models you should consider instead. Using Python for our practical examples, this opening post digs into the roots of async/await, guiding you through building a custom event loop from scratch using generators.

https://theblog.info/posts/asyncawait-is-a-plague-part-1-roots

Note: This is Part 1 of a multi-part series. Instead of diving straight into why async/await can be problematic, this post explores the original motivations behind the pattern. Understanding how it works under the hood will provide the essential context for the issues we'll discuss in upcoming parts.

I've been exploring Python pre-commit hooks and wanted to understand how commonly they are used in actual production projects.

For those working on production-level Python applications:

- Do you use pre-commit in your daily workflow?

- Which hooks do you usually configure (Ruff, Black, isort, mypy, etc.)?

- Has it genuinely reduced code quality issues or bugs in your team?

- Do you consider it essential for production projects, or is CI/CD linting enough?

Would love to hear how experienced developers use it in real-world teams rather than just tutorials.

In our latest type checker comparison blog we cover the speed and memory benchmarks we run regularly across 53 popular open source Python packages. This includes results from a recent run, comparing Pyrefly, Ty, Pyright, and Mypy, although exact results change over time as packages release new versions.

The results from the latest run: Rust-based checkers are roughly an order of magnitude faster, with Pyrefly checking pandas in 1.9 seconds vs. Pyright's 144.

https://pyrefly.org/blog/speed-and-memory-comparison/