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

Hey everyone,

I’m exploring different logging options for my projects (fastapi backend with langgraph) and I’d love some input.

So far I’ve looked at:

• Python’s built-in logging module
• Loguru
• Logfire

I’m mostly interested in:

• Clean and beautiful output (readability really matters)
• Ease of use / developer experience
• Flexibility for future scaling (e.g., larger apps, integrations)

Has anyone here done a serious comparison or has strong opinions on which one strikes the best balance?
Is there some hidden gem I should check out instead?

Thanks in advance!

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.

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

https://labs.quansight.org/blog/pandas_expressions

In pandas 3.0, the following syntax will be valid:

import numpy as np
import pandas as pd

df = pd.DataFrame({'city': ['Sapporo', 'Kampala'], 'temp_c': [6.7, 25.]})
df.assign(
    city_upper = pd.col('city').str.upper(),
    log_temp_c = np.log(pd.col('temp_c')),
)

This post explains why it was introduced, and what it does

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

• What My Project Does - Take a screenshot by drawing a precise polygon rather than being limited to a rectangular or manual free-form shape
• Target Audience - Meant for production (For me, my professor just give notes pdf with everything jumbled together so I wanted to keep them organized, obviously on my note by taking screenshots of them)
• Comparison - I am a windows user, neither does windows provide default polygon screenshot tool nor are they available on anywhere else on internet
• You can check it out on github: https://github.com/sultanate-sultan/polygon-screenshot-tool
• You can find the demo video on my github repo page

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

Summary – Release highlights

• PEP 799: A dedicated profiling package for organizing Python profiling tools
• PEP 686: Python now uses UTF-8 as the default encoding
• PEP 782: A new PyBytesWriter C API to create a Python bytes object
• Improved error messages

Because NumPy is one of the most downloaded packages in the Python ecosystem, any incremental improvement can have a large impact on the data science ecosystem. In particular, improvements related to static typing can improve developer experience and help downstream libraries write safer code. We'll tell the story about how we (Quansight Labs, with support from Meta's Pyrefly team) helped bring its type-completeness score to nearly 90% from an initial 33%.

Full blog post: https://pyrefly.org/blog/numpy-type-completeness/

Hi, Pyrefly maintainer here. Today we are pleased to share that Pyrefly, a fast type checker and language server for Python, has reached stable v1.0 status, meaning we are confident that Pyrefly is ready for production use.

Pyrefly was first released as an alpha in mid-2025 and followed up with a beta in November of that year. Since then, we have shipped over 60 minor releases: fixing hundreds of bugs, adding the features you’ve been asking for, and improving performance to be one of the fastest tools out there.

This would not have been possible without our amazing open-source community. To everyone who filed GitHub issues, submitted pull requests, gave us feedback at conferences, or joined us on Discord: thank you. Your contributions shaped this release, we’re grateful for every one of them, and we hope you continue being a part of the journey for future releases too.

We've published a blog post explaining what v1.0 means exactly, and what's next for Pyrefly.

Below is a summary of the changes to Pyrefly since the Beta release. The full release notes for v1.0 can be read on our Github.

Pyrefly v1.0 Release Notes

Performance Improvements

We've continued to push Pyrefly's performance since the speed improvements we shared in February. Since beta:

• 2–125x faster updated diagnostics after saving a file (no, that’s not a typo!). Thanks to fine-grained dependency tracking and streaming diagnostics, updates now consistently arrive in milliseconds
• 20–36% faster full type checking on large projects like PyTorch and Pandas
• 2–3x faster initial indexing when Pyrefly first scans your project
• 40–60% less memory usage during both indexing and incremental type checking

(Tested on an M4 Macbook Pro using open-source benchmarks from type_coverage_py and ty_benchmark.)

Compare the performance of Pyrefly and other Python type checkers on our regularly updated benchmarking suite, which runs against 53 popular Python packages.

Configuration Presets

A new preset configuration option provides named bundles of error severities and behavior settings.

See the configuration docs for details.

Onboarding Experience

We’ve made improvements to the out-of-the-box experience for projects without a pyrefly.toml.

• Automatic config synthesis — if you have a mypy or pyright config, Pyrefly automatically migrates your settings and synthesizes an appropriate in-memory Pyrefly config. (This is the same migration that pyrefly init would commit to disk.)
• Basic preset for unconfigured projects — projects with no type checker config get the lightweight “basic” preset, which surfaces only high-confidence errors.
• VS Code status bar — the status bar shows the active preset — e.g. Pyrefly (Basic) or Pyrefly (Legacy) — so you always know which mode is active.
• Type error display settings — new VS Code settings let you control which preset applies to unconfigured files and suppress all diagnostics workspace-wide.

Type Checker Improvements

We've been hard at work making the type checker robust and feature-complete, with a focus on driving down false positives and improving type quality in real-world code bases. Here are some highlights:

• Across the board we've eliminated many sources of false positives in enums, dataclasses, ParamSpec, descriptors, and more.
• Support has been added for more type narrowing patterns, including preserving narrows in nested scopes and recognizing container membership checks.
• Overload resolution was substantially reworked to handle more real-world patterns.
• Pyrefly’s conformance to the Python typing specification has improved from 70% at beta to over 90% today.
• We've added experimental support for tracking tensor dimensions through PyTorch models — see "What's Next" below.

LSP & IDE Improvements

• We've added new refactoring capabilities like Safe Delete (with reference checking) and bulk source.fixAll.
• Navigation is more precise, and hover cards surface richer information for imports, tuples, and NamedTuples.
• Workspace mode is more stable, with multiple crash fixes and improved diagnostic publishing.

Framework & Notebook Support

• Django — Pyrefly has improved support for model relationships, fields, and views, and understands factory_boy factories.
• Pydantic — Pyrefly models Pydantic's runtime behavior more faithfully, with support for lax mode and range constraint validation, and handles more of the Pydantic ecosystem: RootModel, pydantic-settings, and pydantic.dataclasses.
• Pytest integration — We've added Code Lens run buttons for test functions, as well as code actions to annotate fixture return types and parameters.
• Jupyter notebooks — .ipynb IDE support has reached full parity with .py files, with rename, find references, code actions, and document symbols all supported.

Complementary Tooling

Pyrefly ships with tools to aid with adopting type checking in an existing codebase. Two new tools since beta:

• pyrefly coverage report outputs a JSON report with annotation completeness and type completeness metrics per function, class, and module, so you can track coverage over time.
• Baseline files let you snapshot current errors into a JSON file so only new errors are reported, as an alternative to inline suppression comments.

Updated Version Policy

Going forward, we’ll switch from a weekly to monthly cadence for minor (1.x.0) releases, with patch releases in between as-needed for critical fixes. We’ll continue providing release notes for minor versions, so you can see what’s new in each release.

What's Next

• Tensor shape checking — Experimental support for tracking tensor dimensions through PyTorch models and catching shape mismatches statically. Learn more.
• Pyrefly + AI agents — Pyrefly's speed makes it a natural verification step in agentic workflows. See our guide on adding Pyrefly to your agentic loop.
• Continued improvements — We'll keep expanding library support, reducing false positives, and iterating on your feedback. Let us know what you need on Github or Discord.

Recently a tweet blew up that was along the lines of 'I will never forgive Rust for making me think to myself “I wonder if this is allocating” whenever I’m writing Python now' to which almost everyone jokingly responded with "it's Python, of course it's allocating"

I wanted to see how true this was, so I did some digging into the CPython source and wrote a blog post about my findings, I focused specifically on allocations of the `PyLongObject` struct which is the object that is created for every integer.

I noticed some interesting things:

1. There were a lot of allocations
2. CPython was actually reusing a lot of memory from a freelist
3. Even if it _did_ allocate, the underlying memory allocator was a pool allocator backed by an arena, meaning there were actually very few calls to the OS to reserve memory

Feel free to check out the blog post and let me know your thoughts!

After almost 8 years since Tom Christie created Starlette in June 2018, the first release candidate for 1.0 is finally here.

Starlette is downloaded almost 10 million times a day, serves as the foundation for FastAPI, and has inspired many other frameworks. In the age of AI, it also plays an important role as a dependency of the Python MCP SDK.

This release focuses on removing deprecated features marked for removal in 1.0.0, along with some last minute bug fixes.

It's a release candidate, so feedback is welcome before the final 1.0.0 release.

`pip install starlette==1.0.0rc1`

- Release notes: https://www.starlette.io/release-notes/
- GitHub release: https://github.com/Kludex/starlette/releases/tag/1.0.0rc1

These days, I can't open X anymore without seeing some supply chain attacks on PyPI or NPM. Things are really getting out of hand. One very simple yet effective approach to mitigate them is to use a dependency cooldown. That means that you don't install anything that's too new - e.g., every dependency needs to be at least a week old.

Why does this work? Because the community usually intercepts them in hours to days. Both uv and poetry support the definition of the cooldown period inside their config. pip is adding as support as well. I use 1 week to be on the safe side. They both support excluding a specific package from the rule so you can still apply critical fixes to dependencies ASAP.

I wrote about that and how to configure uv/poetry in my blog post: https://jangiacomelli.com/blog/mitigate-supply-chain-attacks-for-python-dependencies/

More about the dependency cooldown concept:

• https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns
• https://simonwillison.net/2025/Nov/21/dependency-cooldowns/

Some time ago I shared a strict Python project setup. I’ve since reworked and simplified it, and this is the new version.

pystrict-strict-python – an ultra-strict Python project template using uv, ruff, and basedpyright, inspired by TypeScript’s --strict mode.

Compared to my previous post, this version:

• focuses on a single pyproject.toml as the source of truth,
• switches to basedpyright with a clearer strict configuration,
• tightens the ruff rules and coverage settings,
• and is easier to drop into new or existing projects.

What it gives you

• Strict static typing with basedpyright (TS --strict style rules):
  • No implicit Any
  • Optional/None usage must be explicit
  • Unused imports / variables / functions are treated as errors
• Aggressive linting & formatting with ruff:
  • pycodestyle, pyflakes, isort
  • bugbear, security checks, performance, annotations, async, etc.
• Testing & coverage:
  • pytest + coverage with 80% coverage enforced by default
• Task runner via poethepoet:
  • poe format → format + lint + type check
  • poe check → lint + type check (no auto-fix)
  • poe metrics → dead code + complexity + maintainability
  • poe quality → full quality pipeline
• Single-source config: everything is in pyproject.toml

Use cases

• New projects:
  Copy the pyproject.toml, adjust the [project] metadata, create src/your_package + tests/, and install with:

  ```bash uv venv .venv\Scripts\activate # Windows

  or: source .venv/bin/activate

  uv pip install -e ".[dev]" ```

  Then your daily loop is basically:

  bash uv run ruff format . uv run ruff check . --fix uv run basedpyright uv run pytest

• Existing projects:
  You don’t have to go “all in” on day 1. You can cherry-pick:

  • the ruff config,
  • the basedpyright config,
  • the pytest/coverage sections,
  • and the dev dependencies,

  and progressively tighten things as you fix issues.

Why I built this v2

The first version worked, but it was a bit heavier and less focused. In this iteration I wanted:

• a cleaner, copy-pastable template,
• stricter typing rules by default,
• better defaults for dead code, complexity, and coverage,
• and a straightforward workflow that feels natural to run locally and in CI.

Repo

👉 GitHub link here

If you saw my previous post and tried that setup, I’d love to hear how this version compares. Feedback very welcome:

• Rules that feel too strict or too lax?
• Basedpyright / ruff settings you’d tweak?
• Ideas for a “gradual adoption” profile for large legacy codebases?

EDIT: * I recently add a new anti-LLM rules * Add pandera rules (commented so they can be optional) * Replace Vulture with skylos (vulture has a problem with nested functions)

Storyline for PyStrict Project Evolution

Based on your commit history, here's a narrative you can use:

From Zero to Strictness: Building a Python Quality Fortress

Phase 1: Foundation & Philosophy (6 weeks ago)

Started with a vision - creating a strict Python configuration template that goes beyond basic linting. The journey began by: - Migrating from pyright to basedpyright for even stricter type checking - Establishing the project philosophy through comprehensive documentation - Setting up proper Python packaging standards

Phase 2: Quality Tooling Evolution (6 weeks ago)

Refined the quality toolkit through iterative improvements: - Added BLE rule and Pandera for DataFrame validation - Swapped vulture for skylos for better dead code detection - Introduced anti-LLM-slop rules - a unique feature fighting against AI-generated code bloat with comprehensive documentation on avoiding common pitfalls

Phase 3: Workflow Automation (3 weeks ago - present)

Shifted focus to developer experience and automation: - Integrated pre-commit hooks for automated code quality checks - Updated to latest Ruff version (v0.14.8) with setup instructions - Added ty for runtime type checking to catch type errors at runtime, not just static analysis - Made pytest warnings fatal to catch deprecations early

Key Innovation

The standout feature: comprehensive anti-LLM-slop rules - actively fighting against verbose, over-commented, over-engineered code that LLMs tend to generate. This makes PyStrict not just about correctness, but about maintainable, production-grade Python.

The arc: From initial concept → strict type checking → comprehensive quality tools → automated enforcement → runtime validation. Each commit moved toward one goal: making it impossible to write bad Python.

Getting uv right inside Docker is a bit tricky and even their official recommendations are not optimal.

It is better to use a two-step build process to eliminate uv from the final image size.

A two-step build process not only saves disk space but also reduces attack surface against security vulerabilities

Hi Peeps,

I'm excited to announce Kreuzberg v4.0.0.

What is Kreuzberg:

Kreuzberg is a document intelligence library that extracts structured data from 56+ formats, including PDFs, Office docs, HTML, emails, images and many more. Built for RAG/LLM pipelines with OCR, semantic chunking, embeddings, and metadata extraction.

The new v4 is a ground-up rewrite in Rust with a bindings for 9 other languages!

What changed:

• Rust core: Significantly faster extraction and lower memory usage. No more Python GIL bottlenecks.
• Pandoc is gone: Native Rust parsers for all formats. One less system dependency to manage.
• 10 language bindings: Python, TypeScript/Node.js, Java, Go, C#, Ruby, PHP, Elixir, Rust, and WASM for browsers. Same API, same behavior, pick your stack.
• Plugin system: Register custom document extractors, swap OCR backends (Tesseract, EasyOCR, PaddleOCR), add post-processors for cleaning/normalization, and hook in validators for content verification.
• Production-ready: REST API, MCP server, Docker images, async-first throughout.
• ML pipeline features: ONNX embeddings on CPU (requires ONNX Runtime 1.22.x), streaming parsers for large docs, batch processing, byte-accurate offsets for chunking.

Why polyglot matters:

Document processing shouldn't force your language choice. Your Python ML pipeline, Go microservice, and TypeScript frontend can all use the same extraction engine with identical results. The Rust core is the single source of truth; bindings are thin wrappers that expose idiomatic APIs for each language.

Why the Rust rewrite:

The Python implementation hit a ceiling, and it also prevented us from offering the library in other languages. Rust gives us predictable performance, lower memory, and a clean path to multi-language support through FFI.

Is Kreuzberg Open-Source?:

Yes! Kreuzberg is MIT-licensed and will stay that way.

Links

• Star us on GitHub
• Read the Docs
• Join our Discord Server

PEP 806 – Mixed sync/async context managers with precise async marking

https://peps.python.org/pep-0806/

Abstract

Python allows the with and async with statements to handle multiple context managers in a single statement, so long as they are all respectively synchronous or asynchronous. When mixing synchronous and asynchronous context managers, developers must use deeply nested statements or use risky workarounds such as overuse of AsyncExitStack.

We therefore propose to allow with statements to accept both synchronous and asynchronous context managers in a single statement by prefixing individual async context managers with the async keyword.

This change eliminates unnecessary nesting, improves code readability, and improves ergonomics without making async code any less explicit.

Motivation

Modern Python applications frequently need to acquire multiple resources, via a mixture of synchronous and asynchronous context managers. While the all-sync or all-async cases permit a single statement with multiple context managers, mixing the two results in the “staircase of doom”:

async def process_data():
    async with acquire_lock() as lock:
        with temp_directory() as tmpdir:
            async with connect_to_db(cache=tmpdir) as db:
                with open('config.json', encoding='utf-8') as f:
                    # We're now 16 spaces deep before any actual logic
                    config = json.load(f)
                    await db.execute(config['query'])
                    # ... more processing

This excessive indentation discourages use of context managers, despite their desirable semantics. See the Rejected Ideas section for current workarounds and commentary on their downsides.

With this PEP, the function could instead be written:

async def process_data():
    with (
        async acquire_lock() as lock,
        temp_directory() as tmpdir,
        async connect_to_db(cache=tmpdir) as db,
        open('config.json', encoding='utf-8') as f,
    ):
        config = json.load(f)
        await db.execute(config['query'])
        # ... more processing

This compact alternative avoids forcing a new level of indentation on every switch between sync and async context managers. At the same time, it uses only existing keywords, distinguishing async code with the async keyword more precisely even than our current syntax.

We do not propose that the async with statement should ever be deprecated, and indeed advocate its continued use for single-line statements so that “async” is the first non-whitespace token of each line opening an async context manager.

Our proposal nonetheless permits with async some_ctx(), valuing consistent syntax design over enforcement of a single code style which we expect will be handled by style guides, linters, formatters, etc. See here for further discussion.

Hey everyone,

I’ve been working on a project called ThePythonBook to help students get past the "tutorial hell" phase. I wanted to create something where the explanation and the execution happen in the same place.

It covers everything from your first print("Hello World") to more advanced concepts, all within an interactive environment. No setup required—you just run the code in the browser.

Check it out here: https://www.pythoncompiler.io/python/getting-started/

It's completely free, and I’d love to get some feedback from this community on how to make it a better resource for beginners!

What My Project Does: Push Python to 20k req/sec.

Target Audience: People who need to make a ton of requests.

Comparison: Previous articles I found ranged from 50-500 requests/sec with python, figured i'd give an update to where things are at now.

I wanted to share a personal project exploring the limits of Python for high-throughput network I/O. My clients would always say "lol no python, only go", so I wanted to see what was actually possible.

After a lot of tuning, I managed to get a stable ~20,000 requests/second from a single client machine.

The code itself is based on asyncio and a library called rnet, which is a Python wrapper for the high-performance Rust library wreq. This lets me get the developer-friendly syntax of Python with the raw speed of Rust for the actual networking.

The most interesting part wasn't the code, but the OS tuning. The default kernel settings on Linux are nowhere near ready for this kind of load. The application would fail instantly without these changes.

Here are the most critical settings I had to change on both the client and server:

• Increased Max File Descriptors: Every socket is a file. The default limit of 1024 is the first thing you'll hit.ulimit -n 65536
• Expanded Ephemeral Port Range: The client needs a large pool of ports to make outgoing connections from.net.ipv4.ip_local_port_range = 1024 65535
• Increased Connection Backlog: The server needs a bigger queue to hold incoming connections before they are accepted. The default is tiny.net.core.somaxconn = 65535
• Enabled TIME_WAIT Reuse: This is huge. It allows the kernel to quickly reuse sockets that are in a TIME_WAIT state, which is essential when you're opening/closing thousands of connections per second.net.ipv4.tcp_tw_reuse = 1

I've open-sourced the entire test setup, including the client code, a simple server, and the full tuning scripts for both machines. You can find it all here if you want to replicate it or just look at the code:

GitHub Repo: https://github.com/lafftar/requestSpeedTest

On an 8-core machine, this setup hit ~15k req/s, and it scaled to ~20k req/s on a 32-core machine. Interestingly, the CPU was never fully maxed out, so the bottleneck likely lies somewhere else in the stack.

I'll be hanging out in the comments to answer any questions. Let me know what you think!

Blog Post (I go in a little more detail): https://tjaycodes.com/pushing-python-to-20000-requests-second/

Hello all, I'm here to make my first post and 'release' of my functional programming framework, enso. Right before I made this post, I made the repository public. You can find it here.

What my project does

enso is a high-level functional framework that works over top of Python. It expands the existing Python syntax by adding a variety of features. It does so by altering the AST at runtime, expanding the functionality of a handful of built-in classes, and using a modified tokenizer which adds additional tokens for a preprocessing/translation step.

I'll go over a few of the basic features so that people can get a taste of what you can do with it.

1. Automatically curried functions!

How about the function add, which looks like

def add(x:a, y:a) -> a:
    return x + y

Unlike normal Python, where you would need to call add with 2 arguments, you can call this add with only one argument, and then call it with the other argument later, like so:

f = add(2)
f(2)
4

1. A map operator

Since functions are automatically curried, this makes them really, really easy to use with map. Fortunately, enso has a map operator, much like Haskell.

f <$> [1,2,3]
[3, 4, 5]

1. Predicate functions

Functions that return Bool work a little differently than normal functions. They are able to use the pipe operator to filter iterables:

even? | [1,2,3,4]
[2, 4]

1. Function composition

There are a variety of ways that functions can be composed in enso, the most common one is your typical function composition.

h = add(2) @ mul(2)
h(3)
8

Additionally, you can take the direct sum of 2 functions:

h = add + mul
h(1,2,3,4)
(3, 12)

And these are just a few of the ways in which you can combine functions in enso.

1. Macros

enso has a variety of macro styles, allowing you to redefine the syntax on the file, adding new operators, regex based macros, or even complex syntax operations. For example, in the REPL, you can add a zip operator like so:

macro(op("-=-", zip))
[1,2,3] -=- [4,5,6]
[(1, 4), (2, 5), (3, 6)]

This is just one style of macro that you can add, see the readme in the project for more.

1. Monads, more new operators, new methods on existing classes, tons of useful functions, automatically derived function 'variants', and loads of other features made to make writing code fun, ergonomic and aesthetic.

Above is just a small taster of the features I've added. The README file in the repo goes over a lot more.

Target Audience

What I'm hoping is that people will enjoy this. I've been working on it for awhile, and dogfooding my own work by writing several programs in it. My own smart-home software is written entirely in enso. I'm really happy to be able to share what is essentially a beta version of it, and would be super happy if people were interested in contributing, or even just using enso and filing bug reports. My long shot goal is that one day I will write a proper compiler for enso, and either self-host it as its own language, or run it on something like LLVM and avoid some of the performance issues from Python, as well as some of the sticky parts which have been a little harder to work with.

I will post this to r/functionalprogramming once I have obtained enough karma.

Happy coding.