Python

Sunday Daily Thread: What's everyone working on this week?

2026-03-01T00:00:32+00:00

Weekly Thread: What's Everyone Working On This Week? 🛠️

Hello /r/Python! It's time to share what you've been working on! Whether it's a work-in-progress, a completed masterpiece, or just a rough idea, let us know what you're up to!

How it Works:

Show & Tell: Share your current projects, completed works, or future ideas.
Discuss: Get feedback, find collaborators, or just chat about your project.
Inspire: Your project might inspire someone else, just as you might get inspired here.

Guidelines:

Feel free to include as many details as you'd like. Code snippets, screenshots, and links are all welcome.
Whether it's your job, your hobby, or your passion project, all Python-related work is welcome here.

Example Shares:

Machine Learning Model: Working on a ML model to predict stock prices. Just cracked a 90% accuracy rate!
Web Scraping: Built a script to scrape and analyze news articles. It's helped me understand media bias better.
Automation: Automated my home lighting with Python and Raspberry Pi. My life has never been easier!

Let's build and grow together! Share your journey and learn from others. Happy coding! 🌟

submitted by /u/AutoModerator
[link] [comments]

Friday Daily Thread: r/Python Meta and Free-Talk Fridays

2026-03-06T00:00:46+00:00

Weekly Thread: Meta Discussions and Free Talk Friday 🎙️

Welcome to Free Talk Friday on /r/Python! This is the place to discuss the r/Python community (meta discussions), Python news, projects, or anything else Python-related!

How it Works:

Open Mic: Share your thoughts, questions, or anything you'd like related to Python or the community.
Community Pulse: Discuss what you feel is working well or what could be improved in the /r/python community.
News & Updates: Keep up-to-date with the latest in Python and share any news you find interesting.

Guidelines:

All topics should be related to Python or the /r/python community.
Be respectful and follow Reddit's Code of Conduct.

Example Topics:

New Python Release: What do you think about the new features in Python 3.11?
Community Events: Any Python meetups or webinars coming up?
Learning Resources: Found a great Python tutorial? Share it here!
Job Market: How has Python impacted your career?
Hot Takes: Got a controversial Python opinion? Let's hear it!
Community Ideas: Something you'd like to see us do? tell us.

Let's keep the conversation going. Happy discussing! 🌟

submitted by /u/AutoModerator
[link] [comments]

I built a pre-commit linter that catches AI-generated code patterns

2026-03-05T13:30:24+00:00

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.

submitted by /u/mmartoccia
[link] [comments]

Anyone know what's up with HTTPX?

2026-03-05T02:36:34+00:00

The maintainer of HTTPX closed off access to issues and discussions last week: https://github.com/encode/httpx/discussions/3784

And it hasn't had a release in over a year.

Curious if anyone here knows what's going on there.

submitted by /u/chekt
[link] [comments]

CytoScnPy: Python Dead Code Detection

2026-03-06T02:08:55+00:00

What My Project Does

CytoScnPy is a practical static analysis tool for Python that focuses on identifying dead code, basic security risks, and simple code quality metrics—without heavy configuration or long scan times.

It’s designed to work well even on large codebases and to be usable both locally and in CI environments.

Key features:

Dead Code Hunt: Detects unused imports, methods, variables (with preview & auto-fix)
Security Scan: Secret detection and basic taint tracking (e.g., eval()-style risks)
Quality Check: Cyclomatic complexity, Halstead metrics, maintainability scores
Clone Spotter: Finds duplicated or structurally similar code
MCP Server & VS Code Extension
Integrations: JSON reports for CI pipelines and AI tooling hooks

Target Audience

CytoScnPy is intended for:

Developers and small teams who want fast feedback without heavyweight tooling
CI users who want dead-code and basic security signals as part of automation
Side projects, startups, and internal tools, rather than enterprise-grade compliance scanning

It’s not meant to replace full SAST platforms, but to be a lightweight, practical analyzer you can run often.

Comparison with Existing Tools

Compared to popular Python tools:

vs. pylint / flake8: CytoScnPy focuses more on actual dead code and structural analysis rather than style rules.
vs. bandit: Security checks are intentionally simpler and faster, aimed at early risk detection rather than exhaustive audits.
vs. radon: Includes similar complexity metrics, but combines them with dead-code detection and clone spotting in one pass.
vs. large SAST tools: Much faster, fewer false positives, and easier to integrate—but with a narrower scope by design.

I built a tool that monitors what your package manager actually does during npm/pip install

2026-03-05T14:21:56+00:00

After seeing too many supply chain attacks (XZ Utils, SolarWinds, etc.), I got paranoid about what happens when I run `npm install`. So I built a Python tool that wraps your package manager and watches everything that happens during installation.

What it does:

- Monitors all child processes, network connections, and file accesses in real-time

- Flags suspicious behavior (unexpected network connections, credential theft attempts, reverse shells)

- Verifies SLSA provenance before installation

- Creates baseline profiles to learn what's "normal" for your project

- Generates JSON + HTML security reports for CI/CD pipelines

If a postinstall script tries to read your ~/.ssh/id_rsa or connect to an unknown server, you'll know immediately.

Supports: npm, yarn, pnpm, pip, cargo, Maven, Composer, and others

GitHub: [https://github.com/Mert1004/Supply-Chain-Anomaly-Detector](about:blank)

It's completely open source (MIT). I'd love feedback from anyone who's dealt with supply chain security!

submitted by /u/Mert1004
[link] [comments]

Refactor impact analysis for Python codebases (Arbor CLI)

2026-03-05T13:32:40+00:00

I’ve been experimenting with a tool called Arbor that builds a graph of a codebase and tries to show what might break before a refactor.

This is especially tricky in Python because of dynamic patterns, so Arbor uses heuristics and marks uncertain edges.

Example workflow:

git add .

arbor diff

This shows impacted callers and dependencies for modified symbols.

Repo:

https://github.com/Anandb71/arbor

Curious how Python developers usually approach large refactors safely.

submitted by /u/AccomplishedWay3558
[link] [comments]

Simple CLI time tracker tool.

2026-03-05T21:58:22+00:00

Built it for myself, thought others might find it helpful. What’s your thoughts?

Install: sudo snap install clockin

Github: https://github.com/anuragbhattacharjee/clockin

Snap store link: https://snapcraft.io/clockin

Target audience is anyone using ubuntu and terminal.

I couldn’t find any other compatible time tracker. It cuts the hassle of going to another window and saves all the clicks.

submitted by /u/Organic_Cry333
[link] [comments]

sprint-dash: a type-checked FastAPI + SQLite sprint dashboard — server-rendered, no JS framework

2026-03-05T08:20:15+00:00

What My Project Does

sprint-dash is a sprint tracking dashboard I built for my own projects. Board views, backlog management, sprint lifecycle (create, start, close with carry-over), and a CLI (sd-cli) for terminal-based operations. It integrates with Gitea's API for issue data.

The architecture keeps things simple: sprint structure in SQLite (stdlib sqlite3, no ORM), issue metadata from Gitea's API with a 60-second cachetools TTL. The dashboard is read-only — it never writes back to the issue tracker.

The whole frontend is server-rendered with FastAPI + Jinja2 + HTMX. Routes check the HX-Request header and return either a full page or an HTML partial — one set of templates handles both. Board drag-and-drop uses Sortable.js with HTMX callbacks to post moves server-side. No client-side state.

Type-checked end to end with mypy (strict mode). Tests with pytest. Linted with Ruff. The CI pipeline (Woodpecker) runs lint + tests in parallel, builds a Docker image, runs Trivy, and deploys in about 60 seconds.

Stack: FastAPI, Jinja2, HTMX, SQLite (stdlib), httpx, cachetools Typing: mypy --strict, typed dataclasses throughout Testing: pytest (~60 tests) LOC: ~1,500 Python

Target Audience

Developers who want a lightweight sprint dashboard without adopting a full project management platform. Currently integrates with Gitea, but the architecture separates sprint logic from the issue tracker — the Gitea client is a single module.

Also relevant if you're interested in FastAPI + HTMX as a server-rendered alternative to SPA frameworks for internal tools.

Comparison

Gitea/Forgejo built-in: Labels and milestones give filtered issue lists. No board view, no carry-over, no sprint lifecycle.
Taiga, OpenProject: Full PM platforms. sprint-dash is intentionally minimal — reads from your issue tracker, manages sprints, nothing else.
SPA dashboards (React/Vue): sprint-dash is ~1,500 LOC of Python with zero JS framework dependencies. No webpack, no node_modules.

GitHub: https://github.com/simoninglis/sprint-dash

Blog post with architecture details: https://simoninglis.com/posts/sprint-dash/

submitted by /u/Gronax_au
[link] [comments]

I Made A 3D Renderer Using Pygame And No 3D Library

2026-03-05T01:03:12+00:00

Built a 3D renderer from scratch in Python. No external 3D engines, just Pygame and a lot of math.

What it does:

Renders 3D wireframes and filled polygons at 60 FPS
First-person camera with mouse look
15+ procedural shapes: mountains, fractals, a whole city, Klein bottles, Mandelbulb slices
Basic physics engine (bouncing spheres and collision detection)
OBJ model loading (somewhat glitchy without rasterizaton)

Try it:

bash

pip install aiden3drenderer

Python

from aiden3drenderer import Renderer3D, renderer_type renderer = Renderer3D() renderer.render_type = renderer_type.POLYGON_FILL renderer.run()

Press number keys to switch terrains. Press 0 for a procedural city with 6400 vertices, R for fractals, T for a Klein bottle.

Comparison:
I dont know of other 3D rendering libraries, but this one isnt meant for production use, just as a fun visualization tool

Who's this for?

Learning how 3D graphics work from first principles
Procedural generation experiments
Quick 3D visualizations without heavy dependencies
Understanding the math behind game engines

GitHub: https://github.com/AidenKielby/3D-mesh-Renderer

Feedback is greatly appreciated

submitted by /u/Deep-Pen8466
[link] [comments]

New RAGLight Feature : Serve your RAG as REST API and access a UI

2026-03-05T16:17:26+00:00

What my project does

RAGLight is a framework that helps to develop a RAG or an Agentic RAG quickly.

Now you can serve your RAG as REST API using raglight serve .

Additionally, you can access a UI to chat with your documents using raglight serve --ui .

Configuration is made with environment variables, you can create a .env file that's automatically read.

Target Audience

Everyone who wants to build a RAG quickly. Build for local deployment or for personal usage using many LLM providers (OpenAI, Mistral, Ollama, ...).

Comparison

RAGLight is a Python library for building Retrieval-Augmented Generation pipelines in minutes. It ships with three ready-to-use interfaces:

- Python API : set up a full RAG pipeline in a few lines of code, with support for multiple LLM providers, hybrid search, cross-encoder, reranking, agentic mode, and MCP tool integration.

- CLI (raglight chat) : an interactive wizard that guides you from document ingestion to a live chat session, no code required.

- REST API (raglight serve) : deploy your pipeline as a FastAPI server configured entirely via environment variables, with auto-generated Swagger docs and Docker Compose support out of the box.

- Chat UI (raglight serve --ui) : add a --ui flag to launch a Streamlit interface alongside the API, letting you chat with your documents, upload files, and ingest directories directly from the browser.

Repository : https://github.com/Bessouat40/RAGLight

Documentation : https://raglight.mintlify.app/

submitted by /u/Labess40
[link] [comments]

If you're working with data pipelines, these repos are very useful

2026-03-04T18:10:00+00:00

ibis
A Python API that lets you write queries once and run them across multiple data backends like DuckDB, BigQuery, and Snowflake.

pygwalker
Turns a dataframe into an interactive visual exploration UI instantly.

katana
A fast and scalable web crawler often used for security testing and large-scale data discovery.

submitted by /u/Mysterious-Form-3681
[link] [comments]

I’d love to try a collaborative project

2026-03-05T21:37:40+00:00

Title. I’ve been soloing projects since I started learning but I’ve never really tried to do a collaborative project and think it would be fun. I’m not sure where else to look for a fellow nerd to make something so I’m trying here. Let’s talk!

I’m no developer but to give an idea of my competency I’ve written a handful of automation scripts for work and some little side projects.

submitted by /u/JuicyCiwa
[link] [comments]

AgentGuard — Open-source governance & observability SDK for AI agents

2026-03-05T21:26:50+00:00

I built an open-source Python SDK that wraps AI agent calls (OpenAI for now) to add policy enforcement, PII detection, cost tracking, and audit logging.

The problem: When you deploy AI agents in production, you have zero visibility into what they're doing — no audit trail, no cost controls, PII leaking to APIs, and no way to trace failures.

What it does (3 lines of code):

pythonfrom agentguard import AgentGuard guard = AgentGuard(policies=["pii", "content_filter", "cost_limit"]) safe_client = guard.wrap_openai(client)

Every LLM call and tool use is now intercepted, policy-checked, and logged.

Features:

PII detection & blocking (regex-based, pluggable)
Prompt injection detection
Per-run/daily/total cost limits
Immutable JSON-lines audit trail
CLI tool with step-by-step run replay (agentguard replay <run_id>)
Full async support
104 tests, zero external deps beyond pydantic + openai

pip install agentaudit-sdk

GitHub: https://github.com/AviraL0013/agentguard

This is my first real open-source package. Would genuinely appreciate feedback on the API design, project structure, or anything that looks off.

What My Project Does

AgentGuard is a Python SDK that wraps AI agent calls (OpenAI) to add policy enforcement, PII detection, cost tracking, and audit logging. 3 lines of code to make any agent compliant:

pythonfrom agentguard import AgentGuard guard = AgentGuard(policies=["pii", "content_filter", "cost_limit"]) safe_client = guard.wrap_openai(client) # Every call is now intercepted, policy-checked, and logged

Features:

PII detection & blocking (emails, SSNs, credit cards, phones)
Prompt injection detection
Per-run / daily / total cost limits with per-model pricing
Immutable JSON-lines audit trail
CLI tool with step-by-step run replay (agentguard replay <run\_id>)
Full async support (wrap_openai_async, async tool wrapping)
Custom policy support (subclass Policy, implement evaluate())
104 tests passing, built on pydantic + openai

pip install agentaudit-sdk

Source code: https://github.com/AviraL0013/agentguard

Target Audience

Developers deploying AI agents in production who need observability, compliance, and cost control. Built for real use — not a toy project. Already on PyPI.

Comparison

Guardrails AI / NeMo Guardrails: Focus on output validation and conversational rails. AgentGuard focuses on the full agent lifecycle — tool calls, cost tracking, audit trails, and CLI replay. Different layer.
LangSmith / Langfuse: Observability platforms (hosted dashboards). AgentGuard is an SDK that sits in your code — no external service needed. It enforces policies before the call happens, not just logs after.
Custom middleware: Most teams roll their own. AgentGuard gives you that in a pip install with pluggable policies and zero config.

Would love feedback on the API design and project structure. First time publishing to PyPI.

submitted by /u/ShareSerious2134
[link] [comments]

I turned a Reddit-discussed duplicate-photo script into a tool (architecture, scaling, packaging)

2026-03-05T15:11:22+00:00

A Reddit discussion turned my duplicate-photo Python script into a full application — here are the engineering lessons

A while ago I wrote a small Python script to detect duplicate photos using perceptual hashing.

It worked surprisingly well — even on fairly large photo collections.

I shared it on Reddit and the discussion that followed surfaced something interesting: once people started using it on real photo libraries, the problem stopped being about hashing and became a systems engineering problem.

Some examples that came up: libraries with hundreds of thousands of photos, HEIC - JPEG variants from phones, caching image features for incremental rescans after adding folders, deterministic keeper selection but also wanting to visually review clusters before deleting anything and of course people asking for a GUI instead of a script.

At that point the project started evolving quite a bit.

The monolithic script eventually became a modular architecture:

GUI / CLI -> Worker -> Engine -> Hashing + feature extraction -> SQLite index cache -> Reporting (CSV + HTML thumbnails)

Some of the more interesting engineering lessons.

Scaling beyond O(n²)

Naively comparing every image to every other image explodes quickly. 50k images means 1.25 billion comparisons. So the system uses hash prefix bucketing to reduce comparisons drastically before running perceptual hash checks.

Incremental rescans

Rehashing everything every run was wasteful. Thus a SQLite index was introduces that caches extracted image features and invalidates entries when configuration changes. So rescans only process new or changed images.

Safety-first design

Deleting the wrong image in a photo archive is unacceptable, so the workflow became deliberately conservative. Dry-run by default, quarantine instead of deletion and optional Windows recycle bin integration. A CSV audit trail and a HTML report with thumbnails for visual inspection by ‘the human in the loop’.

Packaging surprises

Turning a Python script into a Windows executable revealed a lot of dependency issues. Some changes that happened during packaging. Removing SciPy dependency from pHash (NumPy-only implementation) and replacing OpenCV sharpness estimation with NumPy Laplacian variance reduced the load with almost 200MB. HEIC support however surprisingly required some unexpected codec DLLs.

The project ended up teaching me much more about architecture and dependency hygiene than about hashing. I wrote a deeper breakdown here if anyone is interested: from-a-finding-duplicates-script-to-the-deduptool-engineering-a-safe-deterministic-photo-deduplication-tool-for-windows

And for context, this was the earlier Reddit discussion around the original script.

Curious if others here have run into similar issues when turning a Python script into a distributable application. Especially around: dependency cleanup, PyInstaller packaging, keeping the core engine independent from the GUI.

submitted by /u/hdw_coder
[link] [comments]

Thursday Daily Thread: Python Careers, Courses, and Furthering Education!

2026-03-05T00:01:05+00:00

Weekly Thread: Professional Use, Jobs, and Education 🏢

Welcome to this week's discussion on Python in the professional world! This is your spot to talk about job hunting, career growth, and educational resources in Python. Please note, this thread is not for recruitment.

How it Works:

Career Talk: Discuss using Python in your job, or the job market for Python roles.
Education Q&A: Ask or answer questions about Python courses, certifications, and educational resources.
Workplace Chat: Share your experiences, challenges, or success stories about using Python professionally.

Guidelines:

This thread is not for recruitment. For job postings, please see r/PythonJobs or the recruitment thread in the sidebar.
Keep discussions relevant to Python in the professional and educational context.

Example Topics:

Career Paths: What kinds of roles are out there for Python developers?
Certifications: Are Python certifications worth it?
Course Recommendations: Any good advanced Python courses to recommend?
Workplace Tools: What Python libraries are indispensable in your professional work?
Interview Tips: What types of Python questions are commonly asked in interviews?

Let's help each other grow in our careers and education. Happy discussing! 🌟

submitted by /u/AutoModerator
[link] [comments]

Built an LSP for Python in Go

2026-03-05T02:17:23+00:00

What my project does

Working in massive Python monorepos, I started getting really frustrated by the sluggishness of Pyright and BasedPyright. They're incredible tools, but large projects severely bog down editor responsiveness.

I wanted something fundamentally faster. So, I decided to build my own Language Server: Rahu.

Rahu is purely static—there’s no interoperability with a Python runtime. The entire lexer, parser pipeline, semantic analyzer, and even the JSON-RPC 2.0 transport over stdio are written completely from scratch in Go to maximize speed and efficiency.

Current Capabilities

It actually has a solid set of in-editor features working right now:

Real-time diagnostics: Catches parser and semantic errors on the fly.
Intelligent Hover: Displays rich symbol/method info and definition locations.
Go-to-definition: Works for variables, functions, classes, parameters, and attributes.
Semantic Analysis: Full LEGB-style name resolution and builtin symbol awareness.
OOP Support: Tracks class inheritance (with member promotion and override handling) and resolves instance attributes (self.x = ...).
Editor Integration: Handles document lifecycles (didOpen, didChange, didClose) with debounced analysis so it doesn't fry your CPU while typing.

I recently added comprehensive tests and benchmarks across the parser, server, and JSON-RPC paths, and finally got a demo GIF up in the README so you can see it in action.

Target audience

Just a toy project so far

The biggest missing pieces I'm tackling next:

Import / module resolution
Cross-file workspace indexing
References, rename, and auto-completion
Deeper type inference

Check it out at the link below! Repo link: https://github.com/ak4-sh/rahu

submitted by /u/lord-mortis420
[link] [comments]

Super Editor is a hardened file editing tool built for AI agent workflows

2026-03-05T21:42:25+00:00

## What My Project Does

Super Editor is a hardened file editing tool built for AI agent workflows. It provides:

- **Atomic writes** – No partial writes, file is either fully updated or unchanged

- **Automatic ZIP backups** – Every change is backed up before modification

- **Safe refactoring** – Regex and AST-based operations with validation

- **Multiple read modes** – full, lines, bytes, or until_pattern

- **Git integration** – Optional auto-commit after changes

- **1,050 torture tests** – 100% pass rate, battle-tested

Built after creating 75+ tools for my AI agent infrastructure. This is the one I use most.

## Target Audience

**Primary:** Developers building AI agents that need to edit files autonomously

**Secondary:**

- Python developers who want safer file operations

- Teams needing auditable file changes with automatic backups

- Anyone doing automated code refactoring

**Production-ready?** Yes – used in production AI agent workflows. Both Python and Go versions available.

## Comparison

|------|--------------|-------------|--------------|----------------|

| **Super Editor** | ✅ | ✅ ZIP | ✅ Python | ✅ Yes |

| sed/awk | ❌ | ❌ | ❌ | ❌ |

| Standard editors | ❌ | ❌ | ❌ | ❌ |

**What makes it different:**

- Designed specifically for autonomous AI agents (not human-in-the-loop)

- Built-in torture test suite (1,050 tests)

- Dual Python + Go implementation (Go is 20x faster)

- Knowledge base integration for policy-driven editing

## Installation

```bash

pip install super-editor

```

## Usage Examples

```bash

# Write to a file

super-editor safe-write file.txt --content "Hello!" --write-mode write

# Read a file

super-editor safe-read file.txt --read-mode full

# Replace text

super-editor replace file.txt --pattern "old" --replacement "new"

# Line operations

super-editor line file.txt --line-number 5 --operation insert

```

## Links

- **PyPI:** https://pypi.org/project/super-editor/

- **GitHub:** https://github.com/larryste1/super-editor

## Feedback Welcome

First major PyPI release. Would appreciate feedback on API design, documentation, and missing features!

submitted by /u/Usual-Capital8132
[link] [comments]

How to call Claude's tool-use API with raw `requests` - no SDK needed

2026-03-05T16:27:33+00:00

I've been building AI tools using only requests and subprocess (I maintain jq, so I'm biased toward small, composable things). Here's a practical guide to using Claude's tool-use / function-calling API without installing the official SDK.

The basics

Tool use lets you define functions the model can call. You describe them with JSON Schema, the model decides when to call them, and you execute them locally. Here's the minimal setup:

import requests, os def call_claude(messages, tools=None): payload = { "model": "claude-sonnet-4-5-20250929", "max_tokens": 8096, "messages": messages, } if tools: payload["tools"] = tools response = requests.post( "https://api.anthropic.com/v1/messages", headers={ "x-api-key": os.environ["ANTHROPIC_API_KEY"], "content-type": "application/json", "anthropic-version": "2023-06-01", }, json=payload, ) response.raise_for_status() return response.json()

Defining a tool

No decorators. Just a dict:

read_file_tool = { "name": "read_file", "description": "Read the contents of a file at the given path.", "input_schema": { "type": "object", "properties": { "path": {"type": "string", "description": "File path to read"} }, "required": ["path"], }, }

The tool-use loop

When the model wants to use a tool, it returns a response with stop_reason: "tool_use" and one or more tool_use blocks. You execute them and send the results back:

messages = [{"role": "user", "content": "What's in requirements.txt?"}] while True: result = call_claude(messages, tools=[read_file_tool]) messages.append({"role": "assistant", "content": result["content"]}) tool_calls = [b for b in result["content"] if b["type"] == "tool_use"] if not tool_calls: # Model responded with text — we're done print(result["content"][0]["text"]) break # Execute each tool and send results back tool_results = [] for tc in tool_calls: if tc["name"] == "read_file": with open(tc["input"]["path"]) as f: content = f.read() tool_results.append({ "type": "tool_result", "tool_use_id": tc["id"], "content": content, }) messages.append({"role": "user", "content": tool_results})

That's the entire pattern. The model calls a tool, you run it, feed the result back, and the model decides what to do next - call another tool or respond to the user.

Why skip the SDK?

Three reasons:

Fewer dependencies. requests is probably already in your project.
Full visibility. You see exactly what goes over the wire. When something breaks, you print(response.json()) and you're done.
Portability. The same pattern works for any provider that supports tool use (OpenAI, DeepSeek, Ollama). Swap the URL and headers, keep the loop.

Taking it further

Once you have this loop, adding more tools is mechanical - define the schema, add an elif branch (or a dispatch dict). I built this up to a ~500-line coding agent with 8 tools that can read/write files, run shell commands, search codebases, and edit files surgically.

I wrote the whole process up as a book if you want the full walkthrough: https://buildyourowncodingagent.com (free sample chapters on the site, source code on GitHub).

Questions welcome - especially if you've tried the raw API approach and hit edge cases.

submitted by /u/jingweno
[link] [comments]

Benchmarked: 10 Python Dependency Injection libraries vs Manual Wiring (50 rounds x 100k requests)

2026-03-04T15:43:23+00:00

Hi /r/python!

DI gets flak sometimes around here for being overengineered and adding overhead. I wanted to know how much it actually adds in a real stack, so I built a benchmark suite to find out. The fastest containers are within ~1% of manual wiring, while others drop between 20-70%

Full disclosure, I maintain Wireup, which is also in the race. The benchmark covers 10 libraries plus manual wiring via globals/creating objects yourself as an upper bound, so you can draw your own conclusions.

Testing is done within a FastAPI + Uvicorn environment to measure performance in a realistic web-based environment. Notably, this also allows for the inclusion of fastapi.Depends in the comparison, as it is the most popular choice by virtue of being the FastAPI default.

This tests the full integration stack using a dense graph of 7 dependencies, enough to show variance between the containers, but realistic enough to reflect a possible dependency graph in the real world. This way you test container resolution, scoping, lifecycle management, and framework wiring in real FastAPI + Uvicorn request/response cycles. Not a microbenchmark resolving the same dependency in a tight loop.

Table below shows Requests per second achieved as well as the secondary metrics:

RPS (Requests Per Second): The number of requests the server can handle in one second. Higher is better.
Latency (p50, p95, p99): The time it takes for a request to be completed, measured in milliseconds. Lower is better.
σ (Standard Deviation): Measures the stability of response times (Jitter). A lower number means more consistent performance with fewer outliers. Lower is better.
RSS Memory Peak (MB): The highest post-iteration RSS sample observed across runs. Lower is better. This includes the full server process footprint (Uvicorn + FastAPI app + framework runtime), not only service objects.

Per-request injection (new dependency graph built and torn down on every request):

Project	RPS (Median Run)	P50 (ms)	P95 (ms)	P99 (ms)	σ (ms)	Mem Peak
Manual Wiring (No DI)	11,044 (100.00%)	4.20	4.50	4.70	0.70	52.93 MB
Wireup	11,030 (99.87%)	4.20	4.50	4.70	0.83	53.69 MB
Wireup Class-Based	10,976 (99.38%)	4.30	4.50	4.70	0.70	53.80 MB
Dishka	8,538 (77.30%)	5.30	6.30	9.40	1.30	103.23 MB
Svcs	8,394 (76.00%)	5.70	6.00	6.20	0.93	67.09 MB
Aioinject	8,177 (74.04%)	5.60	6.60	10.40	1.31	100.52 MB
diwire	7,390 (66.91%)	6.50	6.90	7.10	1.07	58.22 MB
That Depends	4,892 (44.30%)	9.80	10.40	10.60	0.59	53.82 MB
FastAPI Depends	3,950 (35.76%)	12.30	13.80	14.10	1.39	57.68 MB
Injector	3,192 (28.90%)	15.20	15.40	16.10	0.58	53.52 MB
Dependency Injector	2,576 (23.33%)	19.10	19.70	20.10	0.75	60.55 MB
Lagom	898 (8.13%)	55.30	57.20	58.30	1.63	1.32 GB

Singleton injection (cached graph, testing container bookkeeping overhead):

Manual Wiring: 13,351 RPS
Wireup Class-Based: 13,342 RPS
Wireup: 13,214 RPS
Dependency Injector: 6,905 RPS
FastAPI Depends: 6,153 RPS

The full page goes much deeper: stability tables across all 50 runs, memory usage, methodology, feature completeness notes, and reproducibility: https://maldoinc.github.io/wireup/latest/benchmarks/

Reproduce it yourself: make bench iterations=50 requests=100000

Wireup getting this close to manual wiring comes down to how it works: instead of routing everything through a generic resolver, it compiles graph-specific resolution paths and custom injection functions per route at startup. By the time a request arrives there's nothing left to figure out.

If Wireup looks interesting: github.com/maldoinc/wireup, stars appreciated.

Happy to answer any questions on the benchmark, DI and Wireup specifically.

submitted by /u/ForeignSource0
[link] [comments]

I built dkmio – a minimal Object-Key Mapper for DynamoDB to reduce boto3 boilerplate

2026-03-05T01:28:26+00:00

Hi everyone,

I’ve been working with DynamoDB + boto3 for a while, and I kept running into repetitive patterns: building ExpressionAttributeNames, crafting update expressions, and handling pagination loops manually.

So I built dkmio, a small Object-Key Mapper (OKM) focused on reducing boilerplate while keeping DynamoDB semantics explicit.

GitHub: https://github.com/Antonipo/dkmio
PyPI: https://pypi.org/project/dkmio/
Docs: https://dkmio.antoniorodriguez.dev/

What My Project Does

dkmio is a thin, typed wrapper around boto3 that automates the tedious parts of DynamoDB interaction. It reduces code volume by:

Automatically generating update and filter expressions.
Safely handling reserved attribute names (no more manual aliasing).
Auto-paginating queries and auto-chunking batch writes.
Converting DynamoDB Decimal values into JSON-serializable types.

It supports native operations (get, query, scan, update, transactions) without introducing heavy abstractions, hidden state tracking, or implicit scans.

Target Audience

This tool is meant for:

Backend developers using Flask, FastAPI, or AWS Lambda.
Teams building production services who want to avoid the verbosity of raw boto3 but dislike heavy ORMs.
Developers who prefer explicit NoSQL modeling over "magic" abstraction layers.

Comparison

Vs. Raw boto3 Standard boto3 requires verbose setup for simple updates:

# Raw boto3 table.update_item( Key={"PK": pk, "SK": sk}, UpdateExpression="SET #revoked = :val0", ExpressionAttributeNames={"#revoked": "revoked_at"}, ExpressionAttributeValues={":val0": now_epoch()} )

With dkmio, this is simplified to:

# dkmio users.update(PK=pk, SK=sk, set={"revoked_at": now_epoch()})

Vs. PynamoDB / ORMs Unlike PynamoDB, dkmio does not enforce schemas, has no model state tracking, and doesn't hide database behavior. It acts as a productivity layer rather than a full abstraction framework, keeping the developer in control of the actual DynamoDB logic.

Feedback is greatly appreciated

submitted by /u/antoniorodriguez-dev
[link] [comments]

Code Roulette: A P2P Terminal Game of Russian Roulette with Compartmentalized RCE

2026-03-04T23:02:57+00:00

What My Project Does

The long and short of it is that this is a Peer to Peer multiplayer, terminal (TUI) based Russian Roulette type game where the loser automatically executes the winner's Python payload file.

Each player selects a Python 3 payload file before the match begins. Once both players join, they're shown their opponent's code and given the chance to review it. Whether you read it yourself, toss it into an AI to check, or just go full send is up to you.

If both players accept, the game enters the roulette phase where players take turns pulling the "trigger" (a button) until someone lands on the unlucky chamber. The loser's machine is then served the winner's payload file and runs it through Python's eval(). Logs are printed to the screen in real time. The winner gets a chat interface to talk to the loser while the code runs.

Critically, the payloads do not have to be destructive. You can do fun stuff too like opening a specific webpage, flipping someone's screen upside down, or any other flavor of creative mischief can be done.

What matters is who you play with.

Target Audience

This is a hobby project, not meant for any real production use. It's aimed at Python enthusiasts who enjoy messing around with friends on a local network (though the server can work over the Internet with auto-restart on game completion) and are comfortable understanding the code they agree to run.

You do need a basic grasp of Python to review payloads and play safely. Though recent advancements in the tech space have lowered this bar slightly.

Comparison

There isn't really anything like this out there. Plenty of movies and games simulate Russian Roulette, but none of them carry actual stakes. Code Roulette introduces actual digital risk by leveraging arbitrary code execution as the consequence of losing. Something that's normally treated as the worst possible vulnerability in software, repurposed here as a game mechanic.

Future Ideas

Currently, the game doesn't have any public server. A hosted web server option could open it up to a wider audience.

Other ideas include sandboxing options for more cautious players and payload templates for non-programmers. Both additions I think could have a wide appeal (lmk).

If you're interested in Code Roulette and are confident you can play it safely with your friends, then feel free to check it out here: https://github.com/Sorcerio/Code-Roulette

I would love to hear what kind of payloads you can come up with; especially if they're actually creative and fun! A few examples are included in the repo as well.

submitted by /u/passwordwork
[link] [comments]

I built an AI-powered GitHub App that reviews PRs, triages issues, and monitors repo health

2026-03-05T16:05:59+00:00

For anyone interested in the implementation:

GitHub repo: https://github.com/Shweta-Mishra-ai/github-autopilot

Would appreciate feedback from other developers on the architecture and workflow automation.

submitted by /u/Feisty-Cranberry2902
[link] [comments]

Amazing AI Agents Course

2026-03-05T14:47:07+00:00

As AI workflows move beyond prompt engineering toward engineered, context-supported designs, agentic AI is becoming one of the hottest domains in the IT industry. I would like to offer you a course designed to teach you howto build such systems (with orchestration, memory, tools, and structured system thinking at their core). In this hands-on, Python-based, 10-unit course, you will learn to build powerful multi-step, tool-using agents using LangGraph— the popular library that underlies many modern AI agents.

The course follows a stage-by-stage progression and is fully project-based — the way modern technical learning is often designed. Instead of building a new agent in each lesson, you will continuously upgrade one agent – an investment consultant – making the process both coherent and fun. Each unit of the course introduces a new concept in agentic technologies, enriching the architecture, and making the agent more capable.

Feel free to check out the course here:

https://langgraphagentcourse.com/

submitted by /u/Spiritualgrowth_1985
[link] [comments]

Google just open-sourced cel-expr-python (CEL) — safe, typed expressions for Python (C++ wrapper)

2026-03-04T01:46:50+00:00

Google Open Source Blog posted a new release today (Mar 3, 2026): cel-expr-python, a native Python API for compiling + evaluating CEL (Common Expression Language) expressions.

Repo: https://github.com/cel-expr/cel-python

Announcement: https://opensource.googleblog.com/2026/03/announcing-cel-expr-python-the-common-expression-language-in-python-now-open-source.html

Codelab: https://github.com/cel-expr/cel-python/blob/main/codelab/index.lab.md

Why I’m interested:

- It’s the official CEL team’s Python wrapper over the production CEL C++ implementation (so semantics should match what other CEL runtimes do).

- It’s designed for “compile once, eval many” workflows with type-checking during compile (so you can validate expressions up front instead of `eval()`-ing arbitrary Python).

- It supports extensions and can serialize compiled expressions.

Quick start (from the blog/docs; blog snippet had a small typo so I’m writing the corrected version here):

pip install cel-expr-python

from cel_expr_python import cel

env = cel.NewEnv(variables={"who": cel.Type.STRING})

expr = env.compile("'Hello, ' + who + '!'")

print(expr.eval(data={"who": "World"}).value()) # Hello, World!

Doc snippet: serialize + reuse compiled expressions

env = cel.NewEnv(variables={"x": cel.Type.INT, "y": cel.Type.INT})

expr = env.compile("x + y > 10")

blob = expr.serialize()

expr2 = env.deserialize(blob)

print(expr2.eval(data={"x": 7, "y": 4}).value()) # True

Doc snippet: custom function extension in Python

def my_func_impl(x):

return x + 1

my_ext = cel.CelExtension("my_extension", [cel.FunctionDecl("my_func", [cel.Overload("my_func_int", cel.Type.INT[cel.Type.INT], impl=my_func_impl)])])

env = cel.NewEnv(extensions=[my_ext])

expr = env.compile("my_func(41)")

print(expr.eval().value()) # 42

Side note / parallel that made me click on this:

I was just reading the r/Python thread on PEP 827 (type manipulation + expanding the type expression grammar):

https://www.reddit.com/r/Python/comments/1rimuu7/pep_827_type_manipulation_has_just_been_published/

Questions if there are any folks who’ve used CEL before:

- Where has CEL worked well (policy engines, validation, feature flags, filtering, etc.)?

- How does this compare to rolling your own AST-based evaluator / JsonLogic / JMESPath for real-world apps?

- Any gotchas with Python integration, perf, or packaging (looks like Linux + py3.11+ right now)?

submitted by /u/Immediate-Card-4896
[link] [comments]