Skip to content
dexpot
Dexpot potion artwork surrounded by Python API code and execution symbols

dexpot

Synchronous Python APIs that adapt concurrency to the interpreter.
Start with a typed APIView source

One application. Two interpreter modes.

Section titled “One application. Two interpreter modes.”

Dexpot keeps application code synchronous while changing admission and scheduling around the interpreter that runs it.

Runtime Serving model Overload behavior
Free-threaded CPython One process; each admitted connection owns a thread A process-wide active-connection cap sheds excess work before thread creation
Standard GIL CPython A bounded pool of connection-owning threads A bounded queue sheds excess work with 503
Standard GIL CPython with workers POSIX SO_REUSEPORT processes, each with its own bounded pool Each worker sheds independently
A Dexpot route compiles into an immutable endpoint plan, then uses the selected request-head parser and interpreter-specific scheduler before both paths execute the same synchronous handler

What dexpot owns

Section titled “What dexpot owns”
  • Plain synchronous handlers without an event loop or coroutine bridge.
  • Compiled endpoint plans for route matching, argument binding, path conversion, and msgspec codecs.
  • Interpreter-adaptive scheduling selected once when the module imports.
  • A bounded HTTP core for parsing, routing, scheduling, draining, and response writes.
  • An optional parser-only Rust extension without moving sockets, routing, handlers, or scheduling out of Python.