django-fastdrf 0.1.0__tar.gz

django_fastdrf-0.1.0/.gitignore

@@ -0,0 +1,11 @@
+.venv/
+.nox/
+__pycache__/
+.pytest_cache/
+.ruff_cache/
+.hypothesis/
+.coverage*
+htmlcov/
+dist/
+build/
+.local/

django_fastdrf-0.1.0/CHANGELOG.md

@@ -0,0 +1,74 @@
+# Changelog
+
+All notable changes to this project are documented in this file. The format
+follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and the
+project uses [Semantic Versioning](https://semver.org/).
+
+## [0.1.0] - 2026-10-01
+
+First release.
+
+### Added
+
+Serializers:
+
+- Serializer bases in `fastdrf.serializers` (`BaseSerializer`, `Serializer`,
+  `ListSerializer`, `ModelSerializer`, `HyperlinkedModelSerializer`) that
+  behave as DRF's with the default settings.
+- Compiled serializer output with the `msgspec`, `pydantic` or
+  dependency-free `python` backend (`SERIALIZER_BACKEND`, or
+  `Meta.serializer_backend`). In `strict` parity the output equals DRF's,
+  including datetimes in the current time zone, quantized decimals,
+  primary-key and slug relations, file URLs, nested and to-many serializers.
+  `fast` parity accepts documented differences.
+- `SERIALIZER_BACKEND_FALLBACK`: serializers the backend cannot compile are
+  represented by DRF, or raise with the reason.
+- Input recognition for the msgspec and pydantic backends: JSON input that
+  DRF would accept unchanged is validated by a compiled class; all other
+  input, and every error, is DRF's.
+- Field caching (`CACHE_SERIALIZER_FIELDS`) with `deepcopy`, `clone` and
+  `compiled` copy modes (`FIELD_COPY_MODE`), configurable per serializer and
+  per view.
+- `default_list_serializer_class` for choosing the `many=True` list
+  serializer of a project base, and weakly bound list serializers in
+  `fastdrf.list_serializers`.
+- Schema serializers: `MsgspecSerializer` and `PydanticSerializer`, defined by
+  a msgspec `Struct` or a pydantic model, with `fastdrf.typed.adapt`,
+  `schema_serializer`, `SchemaViewMixin` and the
+  `ALLOWED_SERIALIZER_BACKENDS` setting.
+
+Queries:
+
+- `QueryOptimizationMixin`, which derives `select_related` and
+  `prefetch_related` lookups from the serializer (`Meta.auto_prefetch`) and
+  applies explicit `Meta.prefetch` hints.
+- `FETCH_MODE` for Django 6.1's `QuerySet.fetch_mode()`.
+- `BATCH_RELATED_LOOKUPS`: one query for the items of
+  `PrimaryKeyRelatedField(many=True)` input.
+- `PrefetchListSerializer` for loading data for all items of a list at once.
+
+Views and responses:
+
+- Dispatch mixins `NegotiationCacheMixin`, `RequestPlanMixin`,
+  `DataResponseMixin` and `DispatchOptimizationMixin`.
+- `fastdrf.mixins.CreateModelMixin` and `UpdateModelMixin`, which produce
+  create and update responses with the serializer class's compiled encoder.
+- `fastdrf.response.Response`, which releases its request objects when
+  closed, and `DataResponse`, rendered without DRF's template response.
+
+Rendering and caching:
+
+- `fastdrf.renderers.JSONRenderer`, DRF's renderer with a kept encoder.
+- `MsgspecJSONRenderer` and `MsgspecJSONParser`.
+- `MsgspecCodec` and `PydanticCodec` for Django's `RedisCache`.
+
+Tooling:
+
+- An optional Django app (`"fastdrf"`) with system checks `fastdrf.E001` to
+  `fastdrf.E006` and the management commands `fastdrf_inspect_serializers`
+  and `fastdrf_convert`.
+- Support for Python 3.12 to 3.14, Django 5.2, 6.0 and 6.1, and DRF 3.16 to
+  3.18, tested on free-threaded Python 3.14t too.
+- Type information (`py.typed`).
+- An example project, `examples/blog`, that serves the same API with DRF and
+  with fastdrf and tests both for identical responses.

django_fastdrf-0.1.0/CODE_OF_CONDUCT.md

@@ -0,0 +1,14 @@
+# Code of conduct
+
+This project follows the
+[Contributor Covenant, version 2.1](https://www.contributor-covenant.org/version/2/1/code_of_conduct/).
+Everyone taking part in the project's issues, pull requests, discussions and
+other spaces is expected to follow it.
+
+## Reporting
+
+Report unacceptable behaviour to the project maintainer,
+[@ctolon](https://github.com/ctolon), privately. Reports are reviewed
+promptly and handled confidentially. The maintainer may remove content, or
+restrict or end participation, as described in the Covenant's enforcement
+guidelines.

django_fastdrf-0.1.0/CONTRIBUTING.md

@@ -0,0 +1,120 @@
+# Contributing
+
+Bug reports, questions and pull requests are welcome on
+[GitHub](https://github.com/ctolon/django-fastdrf). For security issues,
+follow the [security policy](SECURITY.md) instead of opening an issue.
+
+## Development setup
+
+The project uses [uv](https://docs.astral.sh/uv/):
+
+```console
+git clone https://github.com/ctolon/django-fastdrf.git
+cd django-fastdrf
+uv sync
+```
+
+`uv sync` installs the package in editable mode with the `dev` dependency
+group, which includes msgspec, pydantic, the test tools, ruff and nox.
+
+## Running the checks
+
+```console
+uv run pytest                    # the test suite; warnings are errors
+uv run ruff check .              # lint
+uv run ruff format --check .     # formatting
+```
+
+CI also measures coverage and requires at least 90% branch coverage:
+
+```console
+uv run pytest --cov=fastdrf --cov-branch --cov-fail-under=90
+```
+
+nox runs the suite against released Django and DRF versions. List the
+sessions with `uv run nox -l`:
+
+| Session | What it runs |
+| --- | --- |
+| `tests-<python>(django<x>-drf<y>)` | The suite on Python 3.12, 3.13 and 3.14 for each supported Django and DRF pair, for example `uv run nox -s "tests-3.14(django6.1-drf3.18)"`. |
+| `freethreaded` | The suite on free-threaded Python 3.14t. |
+| `tests_minimum` | The suite at the declared minimum versions of Django, DRF, msgspec and pydantic. |
+| `tests_without_extras` | The `drf` and `python` backend tests with neither msgspec nor pydantic installed. |
+| `differential(django<x>-drf<y>)` | The same requests to DRF's viewsets and to fastdrf's options, compared. |
+| `lint` | `ruff check` and `ruff format --check`. |
+
+To check the built package as CI does:
+
+```console
+uv build
+uvx twine check --strict dist/*
+uv run --isolated --no-project --with dist/*.whl python tools/check_wheel.py
+```
+
+`tools/check_wheel.py` imports every module of the installed wheel without
+the optional extras and checks that the wheel carries the type marker and
+the management commands.
+
+The example project has its own tests:
+
+```console
+cd examples/blog
+uv run pytest
+```
+
+## Rules for changes
+
+django-fastdrf exists to make DRF faster without changing what DRF does.
+Changes follow these rules:
+
+- Do not replace, patch or mutate Django or DRF classes or functions, at
+  import or at run time. Add subclasses, mixins or helpers that a project
+  selects, and keep DRF's method names, signatures and return types.
+- Make every new optimization opt-in, with DRF's code as the fallback
+  wherever the optimization cannot show that its result equals DRF's.
+- Identify framework code by class, as `fastdrf.utils` does, never by module
+  name. Treat any hook defined by a project class, or set on an instance, as
+  the project's.
+- Write the test first. A change to output, input or queries needs a
+  differential test that compares the result with plain DRF, for invalid
+  input and custom hooks as well as for successful output, and a query-count
+  test where queries change. A change to shared state needs a concurrency
+  test.
+- Keep caches bounded, keyed by classes or request-independent values, and
+  invalidated when the settings they read change.
+- For a performance change, include the workload, the environment and
+  repeated measurements against the previous behaviour.
+
+User-visible changes update the documentation in `docs/` and the unreleased
+section at the top of `CHANGELOG.md`.
+
+## Pull requests
+
+- Open pull requests against the `dev` branch. `main` receives `dev` at
+  release time; a workflow closes other pull requests into `main` with a
+  pointer to `dev`.
+- CI runs lint, the full suite with coverage, the nox matrix and the
+  `freethreaded`, `tests_minimum`, `tests_without_extras` and `differential`
+  sessions, and builds and checks the package. A pull request from someone
+  other than the maintainer waits for the maintainer's approval before CI
+  runs.
+- Keep a pull request to one change, and describe what it changes for users
+  and which DRF behaviour it preserves.
+
+## Releases
+
+Releases are made by the maintainer:
+
+1. Set `version` in `pyproject.toml` and `__version__` in
+   `src/fastdrf/__init__.py` to the new version.
+2. Give the version's section of `CHANGELOG.md` its release date:
+   `## [X.Y.Z] - YYYY-MM-DD`.
+3. Merge `dev` into `main`.
+4. Run `python tools/release.py vX.Y.Z`, which checks that the three
+   versions agree and prints the release notes, then push the tag `vX.Y.Z`
+   on `main`.
+
+The release workflow checks that the tag matches the package version and is
+on `main`, builds and checks the distributions, publishes them to PyPI
+through trusted publishing once the `pypi` environment is approved, and
+creates the GitHub release with that version's changelog section as notes.

django_fastdrf-0.1.0/LICENSE

@@ -0,0 +1,28 @@
+BSD 3-Clause License
+
+Copyright (c) 2026, ctolon
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+1. Redistributions of source code must retain the above copyright notice, this
+   list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright notice,
+   this list of conditions and the following disclaimer in the documentation
+   and/or other materials provided with the distribution.
+
+3. Neither the name of the copyright holder nor the names of its
+   contributors may be used to endorse or promote products derived from
+   this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

django_fastdrf-0.1.0/NOTICE

@@ -0,0 +1,8 @@
+django-fastdrf includes code derived from aiodrf, Copyright (c) ctolon,
+distributed under the BSD 3-Clause license included in LICENSE.
+
+The many_init list-construction protocol derives from Django REST framework:
+Copyright (c) 2011-present, Encode OSS Ltd. All rights reserved.
+Redistribution and use in source and binary forms, with or without modification,
+are permitted under the BSD 3-Clause license in LICENSE. The original DRF
+project is https://github.com/encode/django-rest-framework.

django_fastdrf-0.1.0/PKG-INFO

@@ -0,0 +1,214 @@
+Metadata-Version: 2.5
+Name: django-fastdrf
+Version: 0.1.0
+Summary: Opt-in serializer and query optimizations for synchronous Django REST framework.
+Project-URL: Homepage, https://github.com/ctolon/django-fastdrf
+Project-URL: Documentation, https://github.com/ctolon/django-fastdrf/tree/main/docs
+Project-URL: Changelog, https://github.com/ctolon/django-fastdrf/blob/main/CHANGELOG.md
+Project-URL: Issues, https://github.com/ctolon/django-fastdrf/issues
+Project-URL: Source, https://github.com/ctolon/django-fastdrf
+Author: Cevat Batuhan Tolon
+License-Expression: BSD-3-Clause
+License-File: LICENSE
+License-File: NOTICE
+Keywords: django,django-rest-framework,msgspec,performance,serializers
+Classifier: Development Status :: 3 - Alpha
+Classifier: Environment :: Web Environment
+Classifier: Framework :: Django
+Classifier: Framework :: Django :: 5.2
+Classifier: Framework :: Django :: 6.0
+Classifier: Framework :: Django :: 6.1
+Classifier: Intended Audience :: Developers
+Classifier: Operating System :: OS Independent
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3 :: Only
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Classifier: Programming Language :: Python :: 3.14
+Classifier: Programming Language :: Python :: Free Threading :: 2 - Beta
+Classifier: Topic :: Internet :: WWW/HTTP
+Classifier: Topic :: Software Development :: Libraries :: Python Modules
+Classifier: Typing :: Typed
+Requires-Python: >=3.12
+Requires-Dist: django>=5.2
+Requires-Dist: djangorestframework>=3.16
+Provides-Extra: msgspec
+Requires-Dist: msgspec>=0.19; extra == 'msgspec'
+Provides-Extra: pydantic
+Requires-Dist: pydantic>=2.9; extra == 'pydantic'
+Description-Content-Type: text/markdown
+
+# django-fastdrf
+
+Opt-in serializer, query and response optimizations for synchronous
+[Django REST framework](https://www.django-rest-framework.org/) projects.
+
+django-fastdrf is for DRF projects that stay synchronous (WSGI, or ASGI with
+synchronous views) and want less time per request without leaving DRF. It
+adds subclasses, mixins and settings next to DRF's own classes. Each
+optimization is enabled explicitly, per project, per view or per serializer,
+and falls back to DRF's code wherever it cannot produce DRF's result.
+
+It does not replace or patch any Django or DRF class, add async support, or
+change DRF's validation errors.
+
+## Installation
+
+```console
+pip install django-fastdrf
+```
+
+The distribution is `django-fastdrf`; the import name is `fastdrf`. Two
+extras install the optional backends:
+
+```console
+pip install "django-fastdrf[msgspec]"    # msgspec backend, renderer, parser, codec
+pip install "django-fastdrf[pydantic]"   # pydantic backend, schema serializers, codec
+```
+
+Adding `"fastdrf"` to `INSTALLED_APPS` is optional. It registers system checks
+and two management commands; everything else works without it.
+
+## Quick start
+
+Use fastdrf's serializer bases and choose a backend for their output:
+
+```python
+# settings.py
+FASTDRF = {
+    "SERIALIZER_BACKEND": "msgspec",  # or "pydantic", or "python" (no dependency)
+    "CACHE_SERIALIZER_FIELDS": True,
+    "FIELD_COPY_MODE": "compiled",
+}
+```
+
+```python
+# serializers.py
+from fastdrf import serializers
+
+
+class ArticleSerializer(serializers.ModelSerializer):
+    class Meta:
+        model = Article
+        fields = ["id", "title", "author", "published_at"]
+        auto_prefetch = True
+```
+
+```python
+# views.py
+from rest_framework import viewsets
+
+from fastdrf.views import DispatchOptimizationMixin, QueryOptimizationMixin
+
+
+class ArticleViewSet(
+    DispatchOptimizationMixin, QueryOptimizationMixin, viewsets.ModelViewSet
+):
+    queryset = Article.objects.all()
+    serializer_class = ArticleSerializer
+```
+
+`.data`, `.is_valid()`, `.save()`, `many=True`, routers, pagination,
+permissions and error responses are DRF's. With `"fastdrf"` in
+`INSTALLED_APPS`, this command lists which serializers the backend compiles,
+and why the others stay on DRF:
+
+```console
+python manage.py fastdrf_inspect_serializers
+```
+
+## Features
+
+Serialization:
+
+- Compiled serializer output with the msgspec, pydantic or dependency-free
+  `python` backend, equal to DRF's `.data` in the default strict parity mode
+  ([serializers](https://github.com/ctolon/django-fastdrf/blob/main/docs/serializers.md#output-backends)).
+- Input recognition: JSON input that DRF would accept unchanged is validated
+  by a compiled class; everything else, including every error, is DRF's
+  ([input recognition](https://github.com/ctolon/django-fastdrf/blob/main/docs/serializers.md#input-recognition)).
+- Cached field templates, copied per request with `deepcopy`, a scalar clone
+  or a compiled copy plan
+  ([field caching](https://github.com/ctolon/django-fastdrf/blob/main/docs/serializers.md#field-caching-and-copying)).
+- List serializers whose child refers to the list weakly
+  ([list serializers](https://github.com/ctolon/django-fastdrf/blob/main/docs/serializers.md#list-serializers)).
+- Schema serializers: a msgspec `Struct` or a pydantic model as a DRF
+  serializer, and `SchemaViewMixin` for views
+  ([schema serializers](https://github.com/ctolon/django-fastdrf/blob/main/docs/schema-serializers.md)).
+
+Queries:
+
+- `select_related` and `prefetch_related` derived from the serializer by
+  `QueryOptimizationMixin`, explicit `Meta.prefetch` hints, Django 6.1's
+  `FETCH_MODE`, one query for many-valued primary-key input, and
+  `PrefetchListSerializer` for per-list enrichment
+  ([queries](https://github.com/ctolon/django-fastdrf/blob/main/docs/queries.md)).
+
+Views and responses:
+
+- Dispatch mixins that keep content negotiation and request construction
+  between requests, compiled create and update responses, a `Response` that
+  releases its request objects when closed, and `DataResponse`, rendered
+  without DRF's template response
+  ([views and responses](https://github.com/ctolon/django-fastdrf/blob/main/docs/views.md)).
+- A `JSONRenderer` that keeps its encoder, msgspec's JSON renderer and
+  parser, and msgspec and pydantic codecs for Django's Redis cache
+  ([rendering and codecs](https://github.com/ctolon/django-fastdrf/blob/main/docs/rendering.md)).
+
+Tooling:
+
+- System checks for the `FASTDRF` setting and two management commands:
+  `fastdrf_inspect_serializers` and `fastdrf_convert`, which writes a schema
+  for a serializer or a serializer for a schema
+  ([commands](https://github.com/ctolon/django-fastdrf/blob/main/docs/commands.md)).
+
+## Guarantees and limits
+
+- No Django or DRF class is replaced, patched or monkeypatched. fastdrf's
+  classes are subclasses and mixins that a project selects.
+- Everything is opt-in. With the default settings, fastdrf's serializer bases
+  behave as DRF's.
+- In strict parity, compiled output equals DRF's output; a field, value or
+  hook the compiler cannot prove equal keeps the serializer, or that one
+  source, on DRF. Input recognition never produces an error of its own.
+- Synchronous only: no ORM call becomes asynchronous, and transactions,
+  authentication, permissions, throttling and pagination are DRF's and
+  Django's.
+- Schema serializers, `fast` parity and the msgspec renderer have their own
+  documented output and validation rules; they are not DRF-identical by
+  design.
+- A serializer instance belongs to one request; do not share it between
+  threads.
+
+See [architecture](https://github.com/ctolon/django-fastdrf/blob/main/docs/architecture.md)
+for how the caches are bounded and invalidated, and for the deliberate
+differences.
+
+## Compatibility
+
+| Django | DRF | Python |
+| --- | --- | --- |
+| 5.2 | 3.16, 3.17, 3.18 | 3.12, 3.13, 3.14 |
+| 6.0 | 3.17, 3.18 | 3.12, 3.13, 3.14 |
+| 6.1 | 3.18 | 3.12, 3.13, 3.14 |
+
+The test suite also runs on free-threaded Python 3.14t (Django 6.1,
+DRF 3.18) and at the declared minimum versions (Django 5.2, DRF 3.16,
+msgspec 0.19, pydantic 2.9). `FETCH_MODE` needs Django 6.1.
+
+## Documentation
+
+- [Documentation index](https://github.com/ctolon/django-fastdrf/blob/main/docs/README.md)
+- [Configuration reference](https://github.com/ctolon/django-fastdrf/blob/main/docs/configuration.md)
+- [Example project](https://github.com/ctolon/django-fastdrf/blob/main/examples/blog/README.md):
+  the same API with plain DRF and with fastdrf, with parity tests and a
+  measurement script
+- [Changelog](https://github.com/ctolon/django-fastdrf/blob/main/CHANGELOG.md)
+- [Contributing](https://github.com/ctolon/django-fastdrf/blob/main/CONTRIBUTING.md)
+- [Security policy](https://github.com/ctolon/django-fastdrf/blob/main/SECURITY.md)
+
+## License
+
+BSD 3-Clause. See
+[LICENSE](https://github.com/ctolon/django-fastdrf/blob/main/LICENSE) and
+[NOTICE](https://github.com/ctolon/django-fastdrf/blob/main/NOTICE): the optimizations derive from the aiodrf project, and the list-construction protocol from Django REST framework.

django_fastdrf-0.1.0/README.md

@@ -0,0 +1,174 @@
+# django-fastdrf
+
+Opt-in serializer, query and response optimizations for synchronous
+[Django REST framework](https://www.django-rest-framework.org/) projects.
+
+django-fastdrf is for DRF projects that stay synchronous (WSGI, or ASGI with
+synchronous views) and want less time per request without leaving DRF. It
+adds subclasses, mixins and settings next to DRF's own classes. Each
+optimization is enabled explicitly, per project, per view or per serializer,
+and falls back to DRF's code wherever it cannot produce DRF's result.
+
+It does not replace or patch any Django or DRF class, add async support, or
+change DRF's validation errors.
+
+## Installation
+
+```console
+pip install django-fastdrf
+```
+
+The distribution is `django-fastdrf`; the import name is `fastdrf`. Two
+extras install the optional backends:
+
+```console
+pip install "django-fastdrf[msgspec]"    # msgspec backend, renderer, parser, codec
+pip install "django-fastdrf[pydantic]"   # pydantic backend, schema serializers, codec
+```
+
+Adding `"fastdrf"` to `INSTALLED_APPS` is optional. It registers system checks
+and two management commands; everything else works without it.
+
+## Quick start
+
+Use fastdrf's serializer bases and choose a backend for their output:
+
+```python
+# settings.py
+FASTDRF = {
+    "SERIALIZER_BACKEND": "msgspec",  # or "pydantic", or "python" (no dependency)
+    "CACHE_SERIALIZER_FIELDS": True,
+    "FIELD_COPY_MODE": "compiled",
+}
+```
+
+```python
+# serializers.py
+from fastdrf import serializers
+
+
+class ArticleSerializer(serializers.ModelSerializer):
+    class Meta:
+        model = Article
+        fields = ["id", "title", "author", "published_at"]
+        auto_prefetch = True
+```
+
+```python
+# views.py
+from rest_framework import viewsets
+
+from fastdrf.views import DispatchOptimizationMixin, QueryOptimizationMixin
+
+
+class ArticleViewSet(
+    DispatchOptimizationMixin, QueryOptimizationMixin, viewsets.ModelViewSet
+):
+    queryset = Article.objects.all()
+    serializer_class = ArticleSerializer
+```
+
+`.data`, `.is_valid()`, `.save()`, `many=True`, routers, pagination,
+permissions and error responses are DRF's. With `"fastdrf"` in
+`INSTALLED_APPS`, this command lists which serializers the backend compiles,
+and why the others stay on DRF:
+
+```console
+python manage.py fastdrf_inspect_serializers
+```
+
+## Features
+
+Serialization:
+
+- Compiled serializer output with the msgspec, pydantic or dependency-free
+  `python` backend, equal to DRF's `.data` in the default strict parity mode
+  ([serializers](https://github.com/ctolon/django-fastdrf/blob/main/docs/serializers.md#output-backends)).
+- Input recognition: JSON input that DRF would accept unchanged is validated
+  by a compiled class; everything else, including every error, is DRF's
+  ([input recognition](https://github.com/ctolon/django-fastdrf/blob/main/docs/serializers.md#input-recognition)).
+- Cached field templates, copied per request with `deepcopy`, a scalar clone
+  or a compiled copy plan
+  ([field caching](https://github.com/ctolon/django-fastdrf/blob/main/docs/serializers.md#field-caching-and-copying)).
+- List serializers whose child refers to the list weakly
+  ([list serializers](https://github.com/ctolon/django-fastdrf/blob/main/docs/serializers.md#list-serializers)).
+- Schema serializers: a msgspec `Struct` or a pydantic model as a DRF
+  serializer, and `SchemaViewMixin` for views
+  ([schema serializers](https://github.com/ctolon/django-fastdrf/blob/main/docs/schema-serializers.md)).
+
+Queries:
+
+- `select_related` and `prefetch_related` derived from the serializer by
+  `QueryOptimizationMixin`, explicit `Meta.prefetch` hints, Django 6.1's
+  `FETCH_MODE`, one query for many-valued primary-key input, and
+  `PrefetchListSerializer` for per-list enrichment
+  ([queries](https://github.com/ctolon/django-fastdrf/blob/main/docs/queries.md)).
+
+Views and responses:
+
+- Dispatch mixins that keep content negotiation and request construction
+  between requests, compiled create and update responses, a `Response` that
+  releases its request objects when closed, and `DataResponse`, rendered
+  without DRF's template response
+  ([views and responses](https://github.com/ctolon/django-fastdrf/blob/main/docs/views.md)).
+- A `JSONRenderer` that keeps its encoder, msgspec's JSON renderer and
+  parser, and msgspec and pydantic codecs for Django's Redis cache
+  ([rendering and codecs](https://github.com/ctolon/django-fastdrf/blob/main/docs/rendering.md)).
+
+Tooling:
+
+- System checks for the `FASTDRF` setting and two management commands:
+  `fastdrf_inspect_serializers` and `fastdrf_convert`, which writes a schema
+  for a serializer or a serializer for a schema
+  ([commands](https://github.com/ctolon/django-fastdrf/blob/main/docs/commands.md)).
+
+## Guarantees and limits
+
+- No Django or DRF class is replaced, patched or monkeypatched. fastdrf's
+  classes are subclasses and mixins that a project selects.
+- Everything is opt-in. With the default settings, fastdrf's serializer bases
+  behave as DRF's.
+- In strict parity, compiled output equals DRF's output; a field, value or
+  hook the compiler cannot prove equal keeps the serializer, or that one
+  source, on DRF. Input recognition never produces an error of its own.
+- Synchronous only: no ORM call becomes asynchronous, and transactions,
+  authentication, permissions, throttling and pagination are DRF's and
+  Django's.
+- Schema serializers, `fast` parity and the msgspec renderer have their own
+  documented output and validation rules; they are not DRF-identical by
+  design.
+- A serializer instance belongs to one request; do not share it between
+  threads.
+
+See [architecture](https://github.com/ctolon/django-fastdrf/blob/main/docs/architecture.md)
+for how the caches are bounded and invalidated, and for the deliberate
+differences.
+
+## Compatibility
+
+| Django | DRF | Python |
+| --- | --- | --- |
+| 5.2 | 3.16, 3.17, 3.18 | 3.12, 3.13, 3.14 |
+| 6.0 | 3.17, 3.18 | 3.12, 3.13, 3.14 |
+| 6.1 | 3.18 | 3.12, 3.13, 3.14 |
+
+The test suite also runs on free-threaded Python 3.14t (Django 6.1,
+DRF 3.18) and at the declared minimum versions (Django 5.2, DRF 3.16,
+msgspec 0.19, pydantic 2.9). `FETCH_MODE` needs Django 6.1.
+
+## Documentation
+
+- [Documentation index](https://github.com/ctolon/django-fastdrf/blob/main/docs/README.md)
+- [Configuration reference](https://github.com/ctolon/django-fastdrf/blob/main/docs/configuration.md)
+- [Example project](https://github.com/ctolon/django-fastdrf/blob/main/examples/blog/README.md):
+  the same API with plain DRF and with fastdrf, with parity tests and a
+  measurement script
+- [Changelog](https://github.com/ctolon/django-fastdrf/blob/main/CHANGELOG.md)
+- [Contributing](https://github.com/ctolon/django-fastdrf/blob/main/CONTRIBUTING.md)
+- [Security policy](https://github.com/ctolon/django-fastdrf/blob/main/SECURITY.md)
+
+## License
+
+BSD 3-Clause. See
+[LICENSE](https://github.com/ctolon/django-fastdrf/blob/main/LICENSE) and
+[NOTICE](https://github.com/ctolon/django-fastdrf/blob/main/NOTICE): the optimizations derive from the aiodrf project, and the list-construction protocol from Django REST framework.

django_fastdrf-0.1.0/SECURITY.md

@@ -0,0 +1,30 @@
+# Security policy
+
+## Supported versions
+
+Security fixes are made for the latest release of django-fastdrf. Upgrade to
+it before reporting an issue, if you can.
+
+## Reporting a vulnerability
+
+Report a suspected vulnerability privately through GitHub's private
+vulnerability reporting:
+[open a report](https://github.com/ctolon/django-fastdrf/security/advisories/new)
+on the repository's Security tab. Do not open a public issue or pull request
+for it.
+
+Include the affected version, the Django, DRF and Python versions, the
+settings and classes involved, and the steps to reproduce. Do not include
+credentials, personal data or production data.
+
+You will receive an acknowledgement, and the advisory will be published with
+the fixed release once a fix is available.
+
+## Scope
+
+django-fastdrf changes how DRF serializes, validates, loads related objects
+and renders. It does not replace authentication, permissions, throttling,
+queryset scoping or validation that a project defines. A report is in scope
+when an optimization makes a response, a validation result or a query differ
+from what DRF would produce with the same project code, or exposes data
+across requests.