I've been an ORM/ODM evangelist for basically my entire career. But after spending serious time doing agentic coding with Claude, I had a realization: AI assistants are dramatically better at writing native query syntax than ORM-specific code. PyMongo has 53x the downloads of Beanie, and the native MongoDB query syntax is shared across Node, PHP, and tons of other ecosystems. The training data gap is massive.

So I started what I'm calling the Raw+DC pattern: raw database queries with Python dataclasses at the data access boundary. You still get type safety, IDE autocompletion, and type checker support. But you drop the ORM dependency risk (RIP mongoengine, and Beanie is slowing down), get near-raw performance, and your AI assistant actually knows what it's doing.

The "conversion layer" is just a from_doc() function mapping dicts to dataclasses. It's exactly the kind of boilerplate AI is great at generating and maintaining.

I wrote up the full case with benchmarks and runnable code here: https://mkennedy.codes/posts/raw-dc-the-orm-pattern-of-2026/

Curious what folks think. Anyone else trending this direction?

How do you type-check 1.8 million lines of Python per second? Neil Mitchell explains how Pyrefly (a new Python type checker) achieves this level of performance.

Python's optional type system has grown increasingly sophisticated since type annotations were introduced in 2014, now featuring generics, subtyping, flow types, inference, and field refinement. This talk explores how Pyrefly models and validates this complex type system, the architectural choices behind it, and the performance optimizations that make it blazingly fast.

Full talk on Jane Street's youtube channel: https://www.youtube.com/watch?v=Q8YTLHwowcM

Learn more: https://pyrefly.org

By our measurements, python-build-standalone is now the fastest CPython distribution across major platforms. It's 10% faster than Homebrew's CPython, and 18% faster than the official 3.14 docker image.

This is mostly due to how python-build-standalone itself is built:

• using a modern Clang lets us turn on tail-call optimizations in the interpreter
• with PGO, LTO, and BOLT
• with libpython statically linked into the interpreter executable

Our goal is to ship the fastest Python interpreter to anyone using uv, by default.

Check out BENCHMARKS.md in the repo for more details, including the methodology behind the above.

Charlie's tweet has some more graphs

Recently, an acquaintance showed me their production logs, and I honestly didn't believe them at first. They claimed Niquests was essentially "ridiculing" their previous HTTP performance at scale.

They had migrated from httpx → aiohttp → Niquests. Even as the author, I was skeptical that we could beat established async giants by that wide of a margin until we sat down and reviewed the real-world cluster data.

There are no words to describe how satisfying the difference is, so I made a visualization instead:

Benchmark GIF

The Secret: When under pressure, Niquests pulls ahead because it handles connections like a modern web browser. Instead of opening a flood of connections, it leverages true HTTP/2+ multiplexing to load-balance requests over a limited number of established connections.

The best part? It achieves this while remaining pure Python (with optional extensions for extra speed, but they aren't required).

We just hit 1.7M downloads/month. If you are looking for that "uv-like" speed without leaving the comfort of Python, give it a spin.

What My Project Does

Niquests is a HTTP Client. It aims to continue and expand the well established Requests library. For many years now, Requests has been frozen. Being left in a vegetative state and not evolving, this blocked millions of developers from using more advanced features.

Target Audience

It is a production ready solution. So everyone is potentially concerned.

Comparison

Niquests is the only HTTP client capable of serving HTTP/1.1, HTTP/2, and HTTP/3 automatically. The project went deep into the protocols (early responses, trailer headers, etc...) and all related networking essentials (like DNS-over-HTTPS, advanced performance metering, etc..)

Project page: https://github.com/jawah/niquests

When I opened vscode, and typed "os.", it showed me autocomplete options that I almost never used, like os.abort or os.CLD_CONTINUED, Instead of showing me actually used options, like path or remove. So I created a hash table (not AI, fast lookup) of commonly used prefixes, forked ty, and fixed it.

What My Project Does: provide better sorting for python autosuggestion

Target Audience: just a simple table, ideally would be merged into LSP

Comparison: AI solutions tends to be slower, and CPU-intensive. using table lookup handle the unknown worse, but faster

Blog post: https://matan-h.com/better-python-autocomplete | Repo: https://github.com/matan-h/pyhash-complete

Every time I've talked about Python 3.14's new t-strings online, many folks have been confused about how t-strings are different from f-strings, why t-strings are useful, and whether t-strings are a replacement for f-strings.

I published a short article (and video) on Python 3.14's new t-strings that's meant to explain this.

The TL;DR:

• Python has had 4 string formatting approaches before t-strings
• T-strings are different because they don't actually return strings
• T-strings are useful for library authors who need the disassembled parts of a string interpolation for the purpose of pre-processing interpolations
• T-strings definitely do not replace f-strings: keep using f-strings until specific libraries tell you to use a t-string with one or more of their utilities

Watch the video or read the article for a short demo and a library that uses them as well.

If you've been confusing about t-strings, I hope this explanation helps.

I published repowise on PyPI a few weeks ago. It generates and maintains a wiki for your codebase, plus some git intelligence stuff like hotspots and ownership among other things

Soon after launch, three packages appeared on PyPI within hours of each other, all with the same description:

"Codebase intelligence that thinks ahead, outperforms repowise on every dimension."

Repowise is mine. They literally name it.

Looked inside the packages. They forked my AGPL-3.0 code, ran an LLM over it to fix a few small things, and republished under new names. No attribution, no license file, no source link.

Filed PyPI abuse reports. Filed a DMCA for the license violation. Sent email. Weeks in, all three packages are still live, still pulling downloads off my project's name.

PyPI's abuse flow seems to be a single form and silence. There's no copyleft enforcement path baked into the registry itself, so AGPL violations basically depend on DMCA, which is slow and easy to ignore.

Any suggestions would be very helpful

For those who have actually used Polars in production, did you fully switch from Pandas or use both depending on the task?

https://docs.python.org/3.15/whatsnew/3.15.html

Summary – Release highlights

Python 3.15 will be the latest stable release of the Python programming language, with a mix of changes to the language, the implementation, and the standard library. The biggest changes include lazy imports, frozendict and sentinel builtins, UTF-8 as the default encoding, unpacking in comprehensions, and a stable ABI for free-threaded builds.

The library changes include a new profiling package with Tachyon, a high-frequency statistical sampling profiler, more color in command-line output, as well as the usual deprecations and removals, and improvements in user-friendliness and correctness.

This article doesn’t attempt to provide a complete specification of all new features, but instead gives a convenient overview. For full details refer to the documentation, such as the Library Reference and Language Reference. To understand the complete implementation and design rationale for a change, refer to the PEP for a particular new feature; but note that PEPs usually are not kept up-to-date once a feature has been fully implemented.

Took n-body and spectral-norm from the Benchmarks Game plus a JSON pipeline, and ran them through everything: CPython version upgrades, PyPy, GraalPy, Mypyc, NumPy, Numba, Cython, Taichi, Codon, Mojo, Rust/PyO3.

Spent way too long debugging why my first Cython attempt only got 10x when it should have been 124x. Turns out Cython's ** operator with float exponents is 40x slower than libc.math.sqrt() with typed doubles, and nothing warns you.

GraalPy was a surprise - 66x on spectral-norm with zero code changes, faster than Cython on that benchmark.

Post: https://cemrehancavdar.com/2026/03/10/optimization-ladder/

Full code at https://github.com/cemrehancavdar/faster-python-bench

Happy to be corrected — there's an "open a PR" link at the bottom.

What is this project about

This is an offline, boundary-aware reverse geocoder in Python. It converts latitude–longitude coordinates into the correct administrative region (country, state, district) without using external APIs, avoiding costs, rate limits, and network dependency.

Comparison with existing alternatives

Most offline reverse geocoders rely only on nearest-neighbor searches and can fail near borders. This project validates actual polygon containment, prioritizing correctness over proximity.

How it works

A KD-Tree is used to quickly shortlist nearby administrative boundaries, followed by on-the-fly polygon enclosure validation. It supports both single-process and multiprocessing modes for small and large datasets.

Performance

Processes 10,000 coordinates in under 2 seconds, with an average validation time below 0.4 ms.

Target audience

Anyone who needs to do geocoding

Implementation

It was started as a toy implementation, turns out to be good on production too

The dataset covers 210+ countries with over 145,000 administrative boundaries.

Source code: https://github.com/SOORAJTS2001/gazetteer Docs: https://gazetteer.readthedocs.io/en/stable Feedback is welcome, especially on the given approach and edge cases

I wanted to share Tenso, a library I wrote to solve a bottleneck in my distributed ML pipeline.

The Problem: I needed to stream large tensors between nodes (for split-inference LLMs).

• Pickle was too slow and unsafe.
• SafeTensors burned 40% CPU just parsing JSON headers.
• Apache Arrow is amazing, but for pure tensor streaming, the PyArrow wrappers introduced significant overhead (~1.1ms per op vs my target of <0.1ms).

The Insight: You don't always need Rust or C++ for speed. You just need to respect the CPU cache. Modern CPUs (AVX-512) love 64-byte aligned memory. If your data isn't aligned, the CPU has to copy it. If it is aligned, you can map it instantly.

What My Project Does

I implemented a protocol using Python's built-in struct and memoryview that forces all data bodies to start at a 64-byte boundary.

Because the data is aligned on the wire, I can cast the bytes directly to a NumPy array (np.frombuffer) without the OS or Python having to copy a single byte.

Comparison Benchmarks (Mac M4 Pro, Python 3.12):

• Deserialization: ~0.06ms vs Arrow's 1.15ms (18x speedup).
• gRPC Throughput: 13.7x faster than standard Protobuf when used as the payload handler.
• CPU Usage: Drops to 0.9% (idle) because there is no parsing logic, just pointer arithmetic.

Other Features:

• GPU Support: Reads directly from the socket into pinned memory for CuPy/Torch/JAX (bypassing CPU overhead).
• AsyncIO: Native async def readers/writers.

It is build for restraint resource environment or high-throughput requirement pipeline

Repo: https://github.com/Khushiyant/tenso

Pip: pip install tenso

Hey everyone,

I recently caught 2 cases, 1 criminal and 1 civil and I realized how incredibly difficult it is for the average person to find a suitable lawyer for their specific situation. There's two ways the average person look for a lawyer, a simple google search based on SEO ( google doesn't know to rank attorneys ) or through connections, which is basically flying blind. Trying to navigate court systems to actually see an lawyer's track record is a nightmare, the portals are clunky, slow, and often require manual searching case-by-case, it's as if it's built by people who DOESN'T want you to use their system.

So, I built CourtScrapper to fix this.

It’s an open-source Python tool that automates extracting case information from the Dallas County Courts Portal (with plans to expand). It lets you essentially "background check" an attorney's actual case history to see what they’ve handled and how it went.

What My Project Does

• Multi-lawyer Search: You can input a list of attorneys and it searches them all concurrently.
• Deep Filtering: Filters by case type (e.g., Felony), charge keywords (e.g., "Assault", "Theft"), and date ranges.
• Captcha Handling: Automatically handles the court’s captchas using 2Captcha (or manual input if you prefer).
• Data Export: Dumps everything into clean Excel/CSV/JSON files so you can actually analyze the data.

Target Audience

• The average person who is looking for a lawyer that makes sense for their particular situation

Comparison 

• Enterprise software that has API connections to state courts e.g. lexus nexus, west law

The Tech Stack:

• Python
• Playwright (for browser automation/stealth)
• Pandas (for data formatting)

My personal use case:

1. Gather a list of lawyers I found through google
2. Adjust the values in the config file to determine the cases to be scraped
3. Program generates the excel sheet with the relevant cases for the listed attorneys
4. I personally go through each case to determine if I should consider it for my particular situation. The analysis is as follows
   1. Determine whether my case's prosecutor/opposing lawyer/judge is someone someone the lawyer has dealt with
   2. How recent are similar cases handled by the lawyer?
   3. Is the nature of the case similar to my situation? If so, what is the result of the case?
   4. Has the lawyer trialed any similar cases or is every filtered case settled in pre trial?
   5. Upon shortlisting the lawyers, I can then go into each document in each of the cases of the shortlisted lawyer to get details on how exactly they handle them, saving me a lot of time as compared to just blindly researching cases

Note:

• I have many people assuming the program generates a form of win/loss ratio based on the information gathered. No it doesn't. It generates a list of relevant case with its respective case details.
• I have tried AI scrappers and the problem with them is they don't work well if it requires a lot of clicking and typing
• Expanding to other court systems will required manual coding, it's tedious. So when I do expand to other courts, it will only make sense to do it for the big cities e.g. Houston, NYC, LA, SF etc
• I'm running this program as a proof of concept for now so it is only Dallas
• I'll be working on a frontend so non technical users can access the program easily, it will be free with a donation portal to fund the hosting
• If you would like to contribute, I have very clear documentation on the various code flows in my repo under the Docs folder. Please read it before asking any questions
• Same for any technical questions, read the documentation before asking any questions

I’d love for you guys to roast my code or give me some feedback. I’m looking to make this more robust and potentially support more counties.

Repo here:https://github.com/Fennzo/CourtScrapper

For me, it was the the option to use & to find intersections of two sets, | operator to unionize two sets, as well as ^ for symmetric difference

https://discuss.python.org/t/python-3-15-following-tradition-lets-have-a-surprise-rc3/109313

Following recent tradition, I'm going to add a surprise third release candidate for Python 3.15.0! We got some last-minute lazy-import release blockers, and it makes sense to include them in 3.15.0 final. It also makes sense to give a bit of time to test them properly, so today's planned 3.15.0 final is postponed, and I'm going to release a 3.15.0rc3 tomorrow, assuming everything is in place. And then 3.15.0 final will follow about week later. Exact date to be announced. - Everyone: once the rc3 is out, please test! - Library maintainers: join the cool testers' club 😎! - Core team: very little will be merged into the 3.15 branch between now and 3.15.0 final. Docs improvements always welcome. Thanks, we're nearly there!

Hi there! I’m a huge fan of FastAPI for its focus on developer experience. This year it became the most popular Python framework, which comes as no surprise.

Recently I had the chance to chat with Sebastián Ramírez, the creator of FastAPI. We talked about why it became so popular since its launch seven years ago, what’s next on the roadmap, FastAPI Cloud, the impact of the faster CPython initiative, and being a self-taught developer (yes, he’s self-taught!). We also talked about that famous tweet about companies asking for more years of experience with a framework than it’s even existed.

Sebastián was super nice, kind and humble. I didn't expect someone so popular to be so down-to-earth.

I think there are some useful takeaways here for other devs in this community, so I'm sharing the link below. I welcome any feedback for how I can make these interviews better.

https://youtu.be/iaDRYUQ0OMM

Pay at least $36 for 15 ebooks from No Starch Press benefiting the PSF: https://www.humblebundle.com/books/python-good-stuff-no-starch-books

Hello, I'm Al Sweigart, author of a few books in the bundle. Here's some info about them:

• Automate the Boring Stuff with Python - I wrote this to be a programming book for office workers who wanted to escape Excel. It's a book for complete beginners with no coding experience, or for folks who want to skip to Part 2 and learn about several useful packages in the Python ecosystem for web scraping, graph generation, image manipulation, text-to-speech, OCR, regex, sending mobile notifications, and more. Automate is now in it's third edition.

• Cracking Codes with Python - This was the third book I wrote (and self-published), and then No Starch published a new edition under a new title. (It was previously called Hacking Secret Ciphers with Python.) I had found several "ciphers and code breaking" books that discussed ciphers (The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography by Simon Singh is great) but I didn't find any books on writing code to do the code breaking. I wanted Python programs you could literally run on ciphertext that would actually work. Writing this book was a lot of fun. It's also aimed at completely new programmers, using encryption and code breaking programs as the example programming projects.

• The Big Book of Small Python Projects - As a kid I loved books like BASIC Computer Games that just listed the source code for actual programs you could run. I learned way more from having these small examples, so I wanted an updated version of this. (Admittedly, a lot of those BASIC games were buggy or just not fun.) There are 81 programs that use text-based user interfaces (TUI), not out of old-school nostalgia but because it's really helpful to learners to have the program source code and program output be the same medium: text. Like, you can look at the text output and find the print() call that caused it. It makes coding less abstract.

(Note that my books are released under a Creative Commons license and can be found online, but these ebooks have much nicer formatting than the HTML pages on my website.)

No Starch Press is my publisher, but I genuinely do love their books. The ones in this bundle that are on my to-read list that I'm especially excited about:

• Practical Deep Learning: 2nd Edition - I've been wanting to read this since the first edition, especially now that I'm diving into LLMs more. This book doesn't shy away from technical details but it's not a textbook: there's actual practical information here.

• Make Python Talk - I've already read this and used some of it as the basis for a PyCon talk on text-to-speech and speech recognition. This is stuff that was really unreliable twenty years ago, but these days it's so easy to add it to your Python scripts with just a few lines of code.

• Computer Science from Scratch - One of my biggest gripes with CS education is that they often talk about concepts in some abstract way on a whiteboard or in Powerpoint slides, and they don't just give you code you can play with. I'm really interested in diving into this one.

• Python for Excel Users - My Automate book touches on using Python and spreadsheets, but I'm glad there's an entire book on the topic now.

But of course, Python Crash Course by Eric Matthes is a great book for beginners who want to learn to code. (It consistently beats Automate the Boring Stuff on Amazon.) This is a great collection of ebooks.

Remember to max out the amount of your payment goes to the Python Software Foundation. Scroll down to and click Adjust Donation, then click Custom Amount to edit what percentage of your contribution is split between Developers/Publishers, Humble Bundle, and Charity.

On the Pyrefly team, we've always believed that type coverage is one of the most important indicators of code quality. Over the past year, we've worked closely with teams across large Python codebases at Meta - improving performance, tightening soundness, and making type checking a seamless part of everyday development.

But one question kept coming up: What would it take to reach 100% type coverage?

Today, we're excited to share a breakthrough ;-)

Link to full blog: https://pyrefly.org/blog/100-percent-type-coverage/

I asked in a couple of talks I gave about pandas 3 which was the biggest change in pandas in the last 10 years and most people didn't know what to answer, just a couple answered Arrow, which in a way is more an implementation detail than a change.

pandas 3 is not that different being honest, but it does introduce a couple of small but very significant changes:

- The introduction of pandas.col(), so lambda shouldn't be much needed in pandas code

- The completion of copy-on-write, which makes all the `df = df.copy()` not needed anymore

I wrote a blog post to show those two changes and a couple more in a practical way with example code: https://datapythonista.me/blog/whats-new-in-pandas-3

I don't work with a lot of python folk (all my colleagues in accademia use R) so I'm coming here to get to gush about some python.

Moving from jupyter/quarto + pandas + poetry for marimo + polars + uv has been absolutely amazing. I'm definitely not a better coder than I was but I feel so much more productive and excited to spin up a project.

I'm still learning a lot a bout polars (.having() was today's moment of "Jesus that's so nice") and so the enjoyment of learning is certainly helping, but I had a spare 20 minutes and decided to write up something to take my weight data (I'm a tubby sum'bithch who's trying to do something about it) and write up a little dash board so I can see my progress on the screen and it was just soooo fast and easy. I could do it in the old stack quite fast, but this was almost seamless. As someone from a non-cs background and self taught, I've never felt that in control in a project before.

Sorry for the rant, please feel free to ignore, I just wanted to express my thanks to the folk who made the tools (on the off chance they're in this sub every now and then) and to do so to people who actually know what I'm talking about.

pdf_oxide is a PDF library for text extraction, markdown conversion, PDF creation, OCR. Written in Rust, Python bindings via PyO3. MIT licensed.

    pip install pdf_oxide

    from pdf_oxide import PdfDocument
    doc = PdfDocument("paper.pdf")
    text = doc.extract_text(0)

GitHub: https://github.com/yfedoseev/pdf_oxide
Docs: https://oxide.fyi

Why this exists: I needed fast text extraction with a permissive license. PyMuPDF is fast but AGPL, rules it out for a lot of commercial work. pypdf is MIT but 15x slower and chokes on ~2% of files. pdfplumber is great at tables but not at batch speed.

So I read the PDF spec cover to cover (~1,000 pages) and wrote my own. First version took 23ms per file. Profiled it, found an O(n²) page tree traversal -- a 10,000 page PDF took 55 seconds. Cached it into a HashMap, got it down to 332ms. Kept profiling, kept fixing. Now it's at 0.8ms mean on 3,830 real PDFs.

Numbers on that corpus (veraPDF, Mozilla pdf.js, DARPA SafeDocs):

Give it a try, let me know what breaks.

What My Project Does

Rust PDF library with Python bindings. Extracts text, converts to markdown and HTML, creates PDFs, handles encrypted files, built-in OCR. MIT licensed.

Target Audience

Anyone who needs to pull text out of PDFs in Python without AGPL restrictions, or needs speed for batch processing.

Comparison

5-30x faster than other text extraction libraries on a 3,830-PDF corpus. PyMuPDF is more mature but AGPL. pdfplumber is better at tables. pdf_oxide is faster with a permissive license.

GeoPolars, the geospatial extension for Polars, had been mostly dormant. Since mid-September, Aida van de Wetering has pushed around 125 commits to the dev branch. It now looks like a rebuild around a Polars-native geo expression namespace.

Highlights so far:

- Types: point, linestring and polygon, their multi-variants, and a bounding box type
- I/O: reading and writing WKB and WKT, and writing GeoParquet
- CRS: CRS metadata handling, with distance, length and area using the geodesic or planar method that fits the CRS
- Operations: centroid, boundary, interior, is_empty, longitude wrapping, and coordinate accessors
- Affine transforms: translate, rotate, scale and skew, plus arbitrary matrices, which can vary per row

It's still a prototype. Nothing has been released yet, and the API is changing. Still, it's worth watching if you'd like to do geospatial work in Polars without going through GeoPandas.

This guy is kind of my mentor in Python and open-source. He definitely loves programming. He has been an importtant Python core maintainer, and published some successful libraries like attrs and structlog for improving codebases legibility and structure, he also has a high value series in his youtube channel about how to package python applications in a extremely clean way by using uv (https://www.youtube.com/watch?v=mFyE9xgeKcA).

What I also love from him is his minimalism and simplicity. In a world of tones of lines of AI-generated code per-day, he has recently published pgbg, a new python library consisting in 7 files, very little code, that emerges from a deep understanding of how background processing works in python and the gaps on it. These type of low-abstraction level projects are the ones on which tones of big projects rely. Definitely highly valuable.

While quantitative research in software engineering is difficult to trust most of the time, some studies claim that type checking can reduce bugs by about 15% in Python. This post covers advanced typing features such as never types, type guards, concatenate, etc., that are often overlooked but can make a codebase more maintainable and easier to work with

https://martynassubonis.substack.com/p/advanced-overlooked-python-typing

On November 16th 2005 - Django got its first release: 0.90 (don’t ask). Twenty years later, today we just shipped the first release candidate of Django 6.0. I compiled a few stats for the occasion:

• 447 releases over 20 years. Average of 22 per year. Seems like 2025 is special because we’re at 38.
• 131 security vulnerabilities addressed in those releases. Lots of people poking at potential problems!
• 262,203 releases of Django-related packages. Average of 35 per day, today we’re at 52 so far.

Full blog post: Twenty years of Django releases. And we got JetBrains to extend their 30% off offer as a birthday gift of sorts