Pure Python web framework using free-threaded Python

Name: Pure Python web framework using free-threaded Python
Availability: InStock
Author: grandimam

by grandimam·Feb 28, 2026·3 points·0 comments

Visit Project View on HN

AI Analysis

●●●BangerBig BrainWizardryBold Bet

Free-threaded Python beats async FastAPI +435% on CPU work—paradigm shift, not toy.

Strengths

•CPU-bound parallelism solves async's fundamental single-thread bottleneck with measured benchmarks
•Minimal 500-line implementation proves threading scales (4→8→16 threads) without GIL
•Honest experimental framing avoids hype while delivering real, reproducible performance claims

Weaknesses

•Production-readiness explicitly disclaimed; requires Python 3.13t adoption and ecosystem maturity
•Benchmarks run on single M2 Pro machine; broader platform coverage and production stability needed

Post Description

Barq is an experimental HTTP framework built entirely in pure Python, designed for free-threaded Python 3.13 (PEP 703). No async/await, no C extensions - just threads with true parallelism. The question I wanted to answer: now that Python has a no-GIL mode, can a simple threaded server beat async frameworks?

Results against FastAPI (100 concurrent clients):

- JSON: 8,400 req/s vs 4,500 req/s (+87%)

- CPU-bound: 1,425 req/s vs 266 req/s (+435%)

The CPU-bound result is the interesting one. Async can't parallelize CPU work - it's fundamentally single-threaded. With free-threaded Python, adding more threads actually scales:

- 4 threads: 608 req/s

- 8 threads: 1,172 req/s (1.9x)

- 16 threads: 1,297 req/s (2.1x)

The framework is ~500 lines across 5 files. Key implementation choices:

- ThreadPoolExecutor for workers

- HTTP/1.1 keep-alive connections

- Radix tree router for O(1) matching

- Pydantic for validation

- Optional orjson for faster serialization

This is experimental and not production-ready, but it's an interesting datapoint for what's possible when Python drops the GIL.

Code: https://github.com/grandimam/barq