pyRPCv0.7.3 adds the third framework adapter — Django — alongside the existing FastAPI and Flask adapters. It also fixes a crash inget_registry_schema() that affected FastAPI and Flask when no explicit router was provided.
The Django adapter
The adapter is a new package: pyrpc-django-adapter. It exposes a mount_django() function similar tomount_fastapi() and mount_flask(), but tailored for Django's URL routing system:
# app/views.py
from pyrpc_core import rpc
@rpc
def add(a: int, b: int) -> int:
return a + b# app/urls.py
from django.urls import path
from pyrpc_django import mount_django
urlpatterns = [
*mount_django(),
]Native async views
Unlike the Flask adapter (which uses anyio.run to bridge sync and async), Django supports async def views natively since Django 3.1. The adapter takes advantage of this — no extra runtime overhead, no thread-pool bridges, just direct async dispatch.
Name collision on PyPI
The original name pyrpc-django was already taken by an unrelated project from 2020. We renamed topyrpc-django-adapter, which is available and follows the same naming pattern as pyrpc-fastapi andpyrpc-flask.
The introspection bug
While building the Django adapter, we discovered that all three adapters had the same latent bug: when no routerargument was passed to mount_fastapi() ormount_flask(), the introspection endpoint (GET /rpc) calledget_registry_schema(router=None), which crashed withAttributeError: 'NoneType' object has no attribute '_procedures'.
The fix is consistent across all three adapters: resolverouter or default_router at the top of each mount function, before any endpoint is registered. The Django adapter was built with this pattern from the start; FastAPI and Flask were patched after.
What’s next
This rounds out the initial adapter coverage for the major Python web frameworks. Future work includes performance benchmarks across all three adapters, a middleware API for pyRPC, and more documentation for advanced patterns.
Read the full changelogfor the complete list of changes.