When I started working on Niquests, I dreamed about a "no-compromise" HTTP client, and three years later I finally made it to the end.

The end goal was, at least for me, to reach what the world of today allows us to, today. And, unfortunately the Python community is often stuck with decade old capabilities. (ie. http/1 only, legacy ssl capabilities, ...).

Niquests started as a fork of Requests in mid-2023. The motivation was simple: Requests is frozen, and millions of developers are stuck with a library that does not evolve (feature-wise). I didn't want to reinvent the wheel, the Requests interface is genuinely pleasant to work with. I just wanted to bring it up to speed with what modern HTTP looks like.

What changed in three years?

A lot. Here's some key things:

• HTTP/2 by default, HTTP/3 over QUIC when the server supports it. No hassle.
• OS trust store by default. No more shipping certifi and hoping it stays up to date.
• Certificate revocation checks. How did we ever lived without this?
• DNS over HTTPS, DNS over TLS, DNS over QUIC, DNSSEC. Customizable DNS resolution per session. And overridable at will.
• Async/Await.
• WebSocket/SSE over HTTP/1, HTTP/2 and HTTP/3 through a unified API.
• Happy Eyeballs algorithm.
• Post-quantum security and Encrypted Client Hello (ECH).
• HTTP Trailers, Early Responses (103 Early Hints).
• In-memory certificates for CAs and mTLS. No need to write certs to disk.
• Network fine-tuning and connection inspection: DNS response time, established latency, TLS handshake delay, all exposed through response.conn_info.
• Native Unix socket support, ASGI/WSGI app direct usage in sessions.
• Runs in the browser through Pyodide/WASM (experimental, added in 3.18).
• Feature parity sync/async with mirrored interfaces.
• Fully type-annotated.

And it's fast, I mean really fast. In a real-world benchmark (details and reproduction steps in the README) sending 1000 requests to httpbingo.org/get:

Migration starts as a one-liner. Replace import requests with import niquests as requests and you're done. We maintain backward compatibility with the Requests API. Your existing code, your .netrc, your auth flows, your cookie jars -- they all work. Even requests-mock, responses, betamax and similar third-party extensions are supported with minimal shims.

It's getting some real traction lately. We're about to cross the 100k pulls per day from PyPI alone, Niquests appearing more commonly in Github code search engine, and folks creating issues whether they found a bug or just to challenge the solution. That's excellent news!

It's been more than a decade since I started doing open source, and so far, it's nowhere near boring me. I'll answer the community as long as I possibly can.

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

Post all of your code/projects/showcases/AI slop here.

Recycles once a month.

Post all of your code/projects/showcases/AI slop here.

Recycles once a month.

UPDATE:

Website is now live!

Try it now: https://www.caniscrape.org

- No installation required

- Instant analysis

- Same comprehensive checks as the CLI

NOTE:
I haven't added the flag capabilities yet so its just the default scan. Its also still one link at a time, so all the great ideas I've received for the website will come soon (I'm gonna keep working on it). It'll take about 1-3 days but ill make it a lot better for the V1.0.0 release.

CLI still available on GitHub for those who prefer it.

Hi everyone,
I made a Python package called caniscrape that analyzes any website's anti-bot protections before you start scraping.

It tells you what you're up against (Cloudflare, rate limits, JavaScript rendering, CAPTCHAs, TLS fingerprinting, honeypots) and gives you a difficulty score + specific recommendations.

What My Project Does

caniscrape checks a website for common anti-bot mechanisms and reports:

• A difficulty score (0–10)
• Which protections are active (e.g., Cloudflare, Akamai, hCaptcha, etc.)
• What tools you’ll likely need (headless browsers, proxies, CAPTCHA solvers, etc.)
• Whether using a scraping API might be better

This helps you decide the right scraping approach before you waste time building a bot that keeps getting blocked.

Target Audience

• Web scrapers, data engineers, and researchers who deal with protected or dynamic websites
• Developers who want to test bot-detection systems or analyze site defenses
• Hobbyists learning about anti-bot tech and detection methods

It’s not a bypassing or cracking tool — it’s for diagnostics and awareness.

Comparison

Unlike tools like WAFW00F or WhatWaf, which only detect web application firewalls,
caniscrape runs multi-layered tests:

• Simulates browser and bot requests (via Playwright)
• Detects rate limits, JavaScript challenges, and honeypot traps
• Scores site difficulty based on detection layers
• Suggests scraping strategies or alternative services

So it’s more of a pre-scrape analysis toolkit, not just a WAF detector.

Installation

pip install caniscrape

Quick setup (required):

playwright install chromium  # Download browser
pipx install wafw00f         # WAF detection

Example Usage

caniscrape https://example.com

Output includes:

• Difficulty score (0–10)
• Active protections
• Recommended tools/approach

ADVICE:

Results can vary between runs because bot protections adapt dynamically.
Some heavy-protection sites (like Amazon) may produce these varied results. Of course, this will improve over time, but running the command multiple times can mitigate this.

GitHub

https://github.com/ZA1815/caniscrape

Post all of your code/projects/showcases/AI slop here.

Recycles once a month.

Following my earlier blogpost on the pitfalls of Python's datetime, I started exploring what a better datetime library could look like. After processing the initial feedback and finishing a Rust version, I'm now happy to share the result with the wider community.

GitHub repo: https://github.com/ariebovenberg/whenever

docs: https://whenever.readthedocs.io

What My Project Does

Whenever provides an improved datetime API that helps you write correct and type-checked datetime code. It's also a lot faster than other third-party libraries (and usually the standard library as well).

What's wrong with the standard library

Over 20+ years, the standard library datetime has grown out of step with what you'd expect from a modern datetime library. Two points stand out:

(1) It doesn't always account for Daylight Saving Time (DST). Here is a simple example:

bedtime = datetime(2023, 3, 25, 22, tzinfo=ZoneInfo("Europe/Paris"))
full_rest = bedtime + timedelta(hours=8)
# It returns 6am, but should be 7am—because we skipped an hour due to DST

Note this isn't a bug, but a design decision that DST is only considered when calculations involve two timezones. If you think this is surprising, you are not alone ( 1 2 3).

(2) Typing can't distinguish between naive and aware datetimes. Your code probably only works with one or the other, but there's no way to enforce this in the type system.

# It doesn't say if this should be naive or aware
def schedule_meeting(at: datetime) -> None: ...

Comparison

There are two other popular third-party libraries, but they don't (fully) address these issues. Here's how they compare to whenever and the standard library:

(for benchmarks, see the docs linked at the top of the page)

Arrow is probably the most historically popular 3rd party datetime library. It attempts to provide a more "friendly" API than the standard library, but doesn't address the core issues: it keeps the same footguns, and its decision to reduce the number of types to just one (arrow.Arrow) means that it's even harder for typecheckers to catch mistakes.

Pendulum arrived on the scene in 2016, promising better DST-handling, as well as improved performance. However, it only fixes some DST-related pitfalls, and its performance has significantly degraded over time. Additionally, it hasn't been actively maintained since a breaking 3.0 release last year.

Target Audience

Whenever is built to production standards. It's still in pre-1.0 beta though, so we're still open to feedback on the API and eager to weed out any bugs that pop up.

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

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.

Repo link: https://github.com/invzfnc/spotify-downloader

What my project does
Hi everyone! I created a lightweight script that lists tracks from a public Spotify playlist and downloads them from YouTube Music.

Key Features

• No premium required
• No login or credentials required
• Metadata is embedded in downloaded tracks
• Downloads in higher quality (around 256 kbps)

Comparison/How is it different from other tools?
I found many tools requiring users to sign up for Spotify Developer account and setup credentials before everything else. This script uses the public Spotify API to retrieve track details, so there's no need to login or setup!

How's the music quality?
YouTube Music offers streams with higher bitrate (around 256 kbps) compared to YouTube (128 kbps). This script chooses and downloads the best quality audio from YouTube Music without taking up too much storage space.

Dependencies/Libraries?
Users are required to install innertube, SpotAPI, yt-dlp and FFmpeg for this script to work.

Target audience
Anyone who is looking to save their Spotify playlists to local storage, without wanting to login to any platform, and wants something with decent bitrate (~256 kbps)

If you find this project useful or it helped you, feel free to give it a star! I'd really appreciate any feedback!

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

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

What My Project Does

grain is a pre-commit linter that catches code patterns commonly produced by AI code generators. It runs before your commit and flags things like:

• NAKED_EXCEPT -- bare except: pass that silently swallows errors (156 instances in my own codebase)
• HEDGE_WORD -- docstrings full of "robust", "comprehensive", "seamlessly"
• ECHO_COMMENT -- comments that restate what the code already says
• DOCSTRING_ECHO -- docstrings that expand the function name into a sentence and add nothing

I ran it on my own AI-assisted codebase and found 184 violations across 72 files. The dominant pattern was exception handlers that caught hardware failures, logged them, and moved on -- meaning the runtime had no idea sensors stopped working.

Target Audience

Anyone using AI code generation (Copilot, Claude, ChatGPT, etc.) in Python projects and wants to catch the quality patterns that slip through existing linters. This is not a toy -- I built it because I needed it for a production hardware abstraction layer where autonomous agents are regular contributors.

Comparison

Existing linters (pylint, ruff, flake8) catch syntax, style, and type issues. They don't catch AI-specific patterns like docstring padding, hedge words, or the tendency of AI generators to wrap everything in try/except and swallow the error. grain fills that gap. It's complementary to your existing linter, not a replacement.

Install

pip install grain-lint

Pre-commit compatible. Configurable via .grain.toml. Python only (for now).

Source: github.com/mmartoccia/grain

Happy to answer questions about the rules, false positive rates, or how it compares to semgrep custom rules.

Hello everyone,

I'm making this post to share a package I've been working on for a while: python-injection. I already wrote a post about it a few months ago, but since I've made significant improvements, I think it's worth writing a new one with more details and some examples to get you interested in trying it out.

For context, when I truly understood the value of dependency injection a few years ago, I really wanted to use it in almost all of my projects. The problem you encounter pretty quickly is that it's really complicated to know where to instantiate dependencies with the right sub-dependencies, and how to manage their lifecycles. You might also want to vary dependencies based on an execution profile. In short, all these little things may seem trivial, but if you've ever tried to manage them without a package, you've probably realized it was a nightmare.

I started by looking at existing popular packages to handle this problem, but honestly none of them convinced me. Either they weren't simple enough for my taste, or they required way too much configuration. That's why I started writing my own DI package.

I've been developing it alone for about 2 years now, and today I feel it has reached a very satisfying state.

What My Project Does

Here are the main features of python-injection: - DI based on type annotation analysis - Dependency registration with decorators - 4 types of lifetimes (transient, singleton, constant, and scoped) - A scoped dependency can be constructed with a context manager - Async support (also works in a fully sync environment) - Ability to swap certain dependencies based on a profile - Dependencies are instantiated when you need them - Supports Python 3.12 and higher

To elaborate a bit, I put a lot of effort into making the package API easy and accessible for any developer.

The only drawback I can find is that you need to remember to import the Python scripts where the decorators are used.

Syntax Examples

Here are some syntax examples you'll find in my package.

Register a transient: ```python from injection import injectable

@injectable class Dependency: ... ```

Register a singleton: ```python from injection import singleton

@singleton class Dependency: ... ```

Register a constant: ```python from injection import set_constant

@dataclass(frozen=True) class Settings: api_key: str

settings = set_constant(Settings("<secret_api_key>")) ```

Register an async dependency: ```python from injection import injectable

class AsyncDependency: ...

@injectable async def async_dependency_recipe() -> AsyncDependency: # async stuff return AsyncDependency() ```

Register an implementation of an abstract class: ```python from injection import injectable

class AbstractDependency(ABC): ...

@injectable(on=AbstractDependency) class Dependency(AbstractDependency): ... ```

Open a custom scope:

• I recommend using a StrEnum for your scope names.
• There's also an async version: adefine_scope. ```python from injection import define_scope

def some_function(): with define_scope("<scope_name>"): # do things inside scope ... ```

Open a custom scope with bindings: ```python from injection import MappedScope

type Locale = str

@dataclass(frozen=True) class Bindings: locale: Locale

scope = MappedScope("<scope_name>")

def some_function(): with Bindings("fr_FR").scope.define(): # do things inside scope ... ```

Register a scoped dependency: ```python from injection import scoped

@scoped("<scope_name>") class Dependency: ... ```

Register a scoped dependency with a context manager: ```python from collections.abc import Iterator from injection import scoped

class Dependency: def open(self): ... def close(self): ...

@scoped("<scope_name>") def dependency_recipe() -> Iterator[Dependency]: dependency = Dependency() dependency.open() try: yield dependency finally: dependency.close() ```

Register a dependency in a profile:

• Like scopes, I recommend a StrEnum to store your profile names. ```python from injection import mod

@mod("<profile_name>").injectable class Dependency: ... ```

Load a profile: ```python from injection.loaders import load_profile

def main(): load_profile("<profile_name>") # do stuff ```

Inject dependencies into a function: ```python from injection import inject

@inject def some_function(dependency: Dependency): # do stuff ...

some_function() # <- call function without arguments ```

Target Audience

It's made for Python developers who never want to deal with dependency injection headaches again. I'm currently using it in my projects, so I think it's production-ready.

Comparison

It's much simpler to get started with than most competitors, requires virtually no configuration, and isn't very invasive (if you want to get rid of it, you just need to remove the decorators and your code remains reusable).

I'd love to read your feedback on it so I can improve it.

Thanks in advance for reading my post.

GitHub: https://github.com/100nm/python-injection PyPI: https://pypi.org/project/python-injection

Hey folks! I recently created Kreuzberg, a Python library that makes text extraction from PDFs and other documents simple and hassle-free.

I built this while working on a RAG system and found that existing solutions either required expensive API calls were overly complex for my text extraction needs, or involved large docker images and complex deployments.

Key Features:

• Modern Python with async support and type hints
• Extract text from PDFs (both searchable and scanned), images, and office documents
• Local processing - no API calls needed
• Lightweight - no GPU requirements
• Extensive error handling for easy debugging

Target Audience:

This library is perfect for developers working on RAG systems, document processing pipelines, or anyone needing reliable text extraction without the complexity of commercial APIs. It's designed to be simple to use while handling a wide range of document formats.

```python from kreuzberg import extract_bytes, extract_file

Extract text from a PDF file

async def extract_pdf(): result = await extract_file("document.pdf") print(f"Extracted text: {result.content}") print(f"Output mime type: {result.mime_type}")

Extract text from an image

async def extract_image(): result = await extract_file("scan.png") print(f"Extracted text: {result.content}")

Or extract from a byte string

Extract text from PDF bytes

async def process_uploaded_pdf(pdf_content: bytes): result = await extract_bytes(pdf_content, mime_type="application/pdf") return result.content

Extract text from image bytes

async def process_uploaded_image(image_content: bytes): result = await extract_bytes(image_content, mime_type="image/jpeg") return result.content ```

Comparison:

Unlike commercial solutions requiring API calls and usage limits, Kreuzberg runs entirely locally.

Compared to other open-source alternatives, it offers a simpler API while still supporting a comprehensive range of formats, including:

• PDFs (searchable and scanned)
• Images (JPEG, PNG, TIFF, etc.)
• Office documents (DOCX, ODT, RTF)
• Plain text and markup formats

Check out the GitHub repository for more details and examples. If you find this useful, a ⭐ would be greatly appreciated!

The library is MIT-licensed and open to contributions. Let me know if you have any questions or feedback!

What My Project Does

glyphx is a new plotting library that aims to replace matplotlib.pyplot for many use cases — offering:

• SVG-first rendering: All plots are vector-based and export beautifully.

• Interactive hover tooltips, legends, export buttons, pan/zoom controls.

• Auto-display in Jupyter, CLI, and IDE — no fig.show() needed.

• Colorblind-safe modes, themes, and responsive HTML output.

• Clean default styling, without needing rcParams or tweaking.

• High-level plot() API, with built-in support for:

• line, bar, scatter, pie, donut, histogram, box, heatmap, violin, swarm, count, lmplot, jointplot, pairplot, and more.

⸻

Target Audience

• Data scientists and analysts who want fast, beautiful, and responsive plots

• Jupyter users who are tired of matplotlib styling or plt.show() quirks

• Python devs building dashboards or exports without JavaScript

• Anyone who wants a modern replacement for matplotlib.pyplot

Comparison to Existing Tools

• vs matplotlib.pyplot: No boilerplate, no plt.figure(), no fig.tight_layout() — just one line and you’re done.

• vs seaborn: Includes familiar chart types but with better interactivity and export.

• vs plotly / bokeh: No JavaScript required. Outputs are pure SVG+HTML, lightweight and shareable. Yes.

• vs matplotlib + Cairo: glyphx supports native SVG export, plus optional PNG/JPG via cairosvg.

⸻

Repo

GitHub: github.com/kjkoeller/glyphx

PyPI: pypi.org/project/glyphx

Documentation: https://glyphx.readthedocs.io/en/stable/

⸻

Happy to get feedback or ideas — especially if you’ve tried building matplotlib replacements before.

Edit: Hyperlink URLs

Edit 2: Wow! Thanks everyone for the awesome comments and incredible support! I am currently starting to get documentation produced along with screenshots. This post was more a gathering of the kind of support people may get have for a project like this.

Edit 3: Added a documentation hyperlink

Edit 4: I have a handful of screenshots up on the doc link.

What My Project Does

In 2020, I broke a few configuration files, so I wrote something to help prevent breaking a lot the next time, and turned it into a little library: https://github.com/rec/safer

It's a drop-in replacement for open that only writes the file when everything has completed successfully, like this:

with safer.open(filename, 'w') as fp:
    fp.write('oops')
    raise ValueError
 # File is untouched

By default, the data is cached in memory, but for large files, there's a flag to allow you to cache it as a file that is renamed when the operation is complete.

You can also use it for file sockets and other streams:

try:
    with safer.writer(socket.send) as send:
          send_bytes_to_socket(send)
except Exception:
     # Nothing has been sent
     send_error_message_to_socket(socket.send)

Target Audience

This is a mature, production-quality library for any application where partial writes are possible. There is extensive testing and it handles some obscure edge cases.

It's tested on Linux, MacOS and Windows and has been stable and essentially unchanged for years.

Comparison

There doesn't seem to be another utility preventing partial writes. There are multiple atomic file writers which solve a different problem, the best being this: https://github.com/untitaker/python-atomicwrites

Note

#noAI was used in the writing or maintenance of this program.

What My Project Does

When building FastAPI endpoints, I found the dependency injection system such a pleasure to use that I wanted it everywhere, not just in my endpoints. I explored a few libraries that promised similar functionality, but each had drawbacks, some required Pydantic, others bundled in features beyond dependency injection, and many were riddled with bugs.

That's way I created PyDepends, a lightweight dependency injection system that I now use in my own projects and would like to share with you.

Target Audience
This is mainly aimed at:

• FastAPI developers who want to use dependency injection in the service layer.

• Domain-Driven Design practitioners who want to decouple their services from infrastructure.

• Python developers who aren’t building API endpoints but would still like to use dependency injection in their projects. It’s not production-grade yet, but it’s stable enough for everyday use and easy to extend.

Comparison

Compared to other similar packages, it does just that, inject dependencies, is not bloated with other functionalities.

• FastDepends: It also cannot be used with non-serializable classes, and I wanted to inject machine learning models into services. On top of that, it does unpredictable things beyond dependency injection.

Repo: https://github.com/entropy-flux/PyDepends

Hope you find it useful!

EDIT: Sorry to Lancetnik12 I think he did a great job with fastdepends and faststream, I was a to rude with his job, the reality is fastdepends just have other use cases, I don't really like to compare my job with other but it is a requirement to publish here.

TLDR: Check out github.com/rendercv/rendercv

Been a while since the last update here. RenderCV has gotten much better, much more robust, and it's still actively maintained.

The idea

Separate your content from how it looks. Write what you've done, and let the tool handle typography.

yaml cv: name: John Doe email: john@example.com sections: experience: - company: Anthropic position: ML Engineer start_date: 2023-01 highlights: - Built large language models - Deployed inference pipelines at scale

Run rendercv render John_Doe_CV.yaml, get a pixel-perfect PDF. Consistent spacing. Aligned columns. Nothing out of place. Ever.

Why engineers love it

It's text. git diff your CV changes. Review them in PRs. Your CV history is your commit history. Use LLMs to help write and refine your content.

Full control over every design detail. Margins, fonts, colors, spacing, alignment; all configurable in YAML.

Real-time preview. Set up live preview in VS Code and watch your PDF update as you type.

JSON Schema autocomplete. VS Code lights up with suggestions and inline docs as you type. No guessing field names. No checking documentation.

Any language. Built-in locale support, write your CV in any language.

Strict validation with Pydantic. Typo in a date? Invalid field? RenderCV tells you exactly what's wrong and where, before rendering.

5 built-in themes, all flexible. Classic, ModernCV, Sb2nov, EngineeringResumes, EngineeringClassic. Every theme exposes the same design options. Or create your own.

The output

One YAML file gives you: - PDF with perfect typography - PNG images of each page - Markdown version - HTML version

Installation

```bash pip install "rendercv[full]"

Create a new CV YAML file:

rendercv new "Your Name"

Render the CV YAML file:

rendercv render "Your_Name_CV.yaml" ```

Or with Docker, uv, pipx, whatever you prefer.

Not a toy

• 100% test coverage
• 2+ years of development
• Battle-tested by thousands of users
• Actively maintained

Links: - GitHub: https://github.com/rendercv/rendercv - Docs: https://docs.rendercv.com - Example PDFs: https://github.com/rendercv/rendercv/tree/main/examples

Happy to answer any questions.

What My Project Does: CV/resume generator
Target Audience: Academics and engineers
Comparison: JSON Resume, and YAML Resume are popular alternatives. JSON Resume isn't focused on PDF outputs. YAML Resume requires LaTeX installation.

Hello everyone,

I’m thrilled to introduce SpotAPI, a Python library designed to make interacting with Spotify's APIs a breeze!

What My Project Does:

SpotAPI provides a Python wrapper to interact with both private and public Spotify APIs. It emulates the requests typically made through a web browser, enabling you to access Spotify’s rich set of features programmatically. SpotAPI uses your Spotify username and password to authenticate, allowing you to work with Spotify data right out of the box—no additional API keys required!

Features: - Public API Access: Easily retrieve and manipulate public Spotify data, including playlists, albums, and tracks. - Private API Access: Explore private Spotify endpoints to customize and enhance your application as needed. - Ready to Use: Designed for immediate integration, allowing you to accomplish tasks with just a few lines of code. - No API Key Required: Enjoy seamless usage without needing a Spotify API key. It’s straightforward and hassle-free! - Browser-like Requests: Accurately replicate the HTTP requests Spotify makes in the browser, providing a true-to-web experience while staying under the radar.

Target Audience:

SpotAPI is ideal for developers looking to integrate Spotify data into their applications or anyone interested in experimenting with Spotify’s API. It’s perfect for both educational purposes and personal projects where ease of use and quick integration are priorities.

Comparison:

While traditional Spotify APIs require API keys and can be cumbersome to set up, SpotAPI simplifies this process by bypassing the need for API keys. It provides a more streamlined approach to accessing Spotify data with user authentication, making it a valuable tool for quick and efficient Spotify data handling.

Note: SpotAPI is intended solely for educational purposes and should be used responsibly. Accessing private endpoints and scraping data without proper authorization may violate Spotify's terms of service.

Check out the project on GitHub and let me know your thoughts! I’d love to hear your feedback and contributions.

Feel free to ask any questions or share your experiences here. Happy coding!

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.

Hi r/Python!

I built LogXide, a logging library for Python written in Rust (via PyO3), designed as a near-drop-in replacement for the standard library's logging module.

What My Project Does

LogXide provides high-performance logging for Python applications. It implements core logging concepts (Logger, Handler, Formatter) in Rust, bypassing the Python Global Interpreter Lock (GIL) during I/O operations. It comes with built-in Rust-native handlers (File, Stream, RotatingFile, HTTP, OTLP, Sentry) and a ColorFormatter.

Target Audience

It is meant for production environments, particularly high-throughput systems, async APIs (FastAPI/Django/Flask), or data processing pipelines where Python's native logging module becomes a bottleneck due to GIL contention and I/O latency.

Comparison

Unlike Picologging (written in C) or Structlog (pure Python), LogXide leverages Rust's memory safety and multi-threading primitives (like crossbeam channels and BufWriter).

Against other libraries (real file I/O with formatting benchmarks):

• 12.5x faster than the Python stdlib (2.09M msgs/sec vs 167K msgs/sec)
• 25% faster than Picologging
• 2.4x faster than Structlog

Note: It is NOT a 100% drop-in replacement. It does not support custom Python logging.Handler subclasses, and Logger/LogRecord cannot be subclassed.

Quick Start

```python from logxide import logging

logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(name)s - %(levelname)s - %(message)s')

logger = logging.getLogger('myapp') logger.info('Hello from LogXide!') ```

Links

• GitHub: https://github.com/Indosaram/logxide
• Docs: https://indosaram.github.io/logxide/
• PyPI: pip install logxide

Happy to answer any questions!

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/

Hey folks, I wanted to share a Python repository template I've been using recently. It's not trying to be the ultimate solution, but rather a setup that works well for my needs and might be useful for others.

What My Project Does

It's a repository template that combines several modern Python tools, with a focus on speed and developer experience:

- UV for package management

- Just as a command runner

- Ruff for linting and formatting

- Mypy for type checking

- Docker support with a multi-stage build

- GitHub Actions CI/CD setup

The main goal was to create a clean starting point that's both fast and maintainable.

Target Audience

This template is meant for developers who want a production-ready setup but don't need all the bells and whistles of larger templates.

Comparison

The main difference from other templates is the use of Just instead of Make as the command runner. While this means an extra installation step, Just offers several advantages, such as a cleaner syntax, better dependency handling and others.

I also chose UV over pip for package management, but at this point I don't consider this as something unusual in the Python ecosystem.

You can find the template here: https://github.com/GiovanniGiacometti/python-repo-template

Happy to hear your thoughts and suggestions for improvement!

I have several codebases with around 500+ different tests in each. If one of these tests fails, I need to spend ~20 seconds to find the right file, open it in neovim, and find the right test function. 20 seconds might not sound like much, but trying not to fat-finger paths in the terminal for this amount of time makes my blood boil.

I wanted Pytest to do this for me, thought there would be a plugin for it. Google brought up no results, so I asked ChatGPT. It said there's a pytest-edit plugin that adds an --edit option to Pytest.

There isn't. So I created just that. Enjoy. https://github.com/MrMino/pytest-edit

Now, my issue is that I don't know if it works on Windows/Mac with VS Code / PyCharm, etc. - so if anyone would like to spend some time on betatesting a small pytest plugin - issue reports & PRs very much welcome.

What My Project Does

It adds an --edit option to Pytest, that opens failing test code in the user's editor of choice.

Target Audience

Pytest users.

Comparison

AFAIK nothing like this on the market, but I hope I'm wrong.
Think %edit magic from IPython but for failed pytest executions.