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.