Script 'mail_helper' called by obssrc
Hello community,
here is the log from the commit of package python-django-filter for
openSUSE:Factory checked in at 2026-01-22 17:59:14
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/python-django-filter (Old)
and /work/SRC/openSUSE:Factory/.python-django-filter.new.1928 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "python-django-filter"
Thu Jan 22 17:59:14 2026 rev:17 rq:1328709 version:25.2
Changes:
--------
---
/work/SRC/openSUSE:Factory/python-django-filter/python-django-filter.changes
2025-05-02 14:58:08.114659915 +0200
+++
/work/SRC/openSUSE:Factory/.python-django-filter.new.1928/python-django-filter.changes
2026-01-22 17:59:23.371592559 +0100
@@ -1,0 +2,8 @@
+Thu Jan 22 14:37:07 UTC 2026 - Dirk Müller <[email protected]>
+
+- update to 25.2:
+ * Added testing for Django 6.0.
+ * Dropped support for Django <5.2 LTS
+ * Dropped support for Python 3.9.
+
+-------------------------------------------------------------------
Old:
----
django_filter-25.1.tar.gz
New:
----
django_filter-25.2.tar.gz
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ python-django-filter.spec ++++++
--- /var/tmp/diff_new_pack.pmiotx/_old 2026-01-22 17:59:25.359675494 +0100
+++ /var/tmp/diff_new_pack.pmiotx/_new 2026-01-22 17:59:25.375676162 +0100
@@ -1,7 +1,7 @@
#
# spec file for package python-django-filter
#
-# Copyright (c) 2025 SUSE LLC
+# Copyright (c) 2026 SUSE LLC and contributors
#
# All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed
@@ -18,7 +18,7 @@
%{?sle15_python_module_pythons}
Name: python-django-filter
-Version: 25.1
+Version: 25.2
Release: 0
Summary: Reusable Django app to allow users to filter queryset
dynamically
License: BSD-3-Clause
++++++ django_filter-25.1.tar.gz -> django_filter-25.2.tar.gz ++++++
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/django_filter-25.1/.github/workflows/tests.yml
new/django_filter-25.2/.github/workflows/tests.yml
--- old/django_filter-25.1/.github/workflows/tests.yml 2024-12-28
11:05:42.058016800 +0100
+++ new/django_filter-25.2/.github/workflows/tests.yml 2025-10-05
11:41:35.203258000 +0200
@@ -13,12 +13,12 @@
strategy:
fail-fast: false
matrix:
- python-version: ["3.9", "3.10", "3.11", "3.12", "3.13"]
+ python-version: ["3.10", "3.11", "3.12", "3.13"]
steps:
- - uses: actions/checkout@v4
+ - uses: actions/checkout@v5
- name: Set up Python ${{ matrix.python-version }}
- uses: actions/setup-python@v5
+ uses: actions/setup-python@v6
with:
python-version: ${{ matrix.python-version }}
- name: Ensure latest setuptools
@@ -63,9 +63,9 @@
pull-requests: write
contents: write
steps:
- - uses: actions/checkout@v4
+ - uses: actions/checkout@v5
- - uses: actions/download-artifact@v4
+ - uses: actions/download-artifact@v5
id: download
with:
pattern: coverage-*
@@ -88,9 +88,9 @@
isort:
runs-on: ubuntu-latest
steps:
- - uses: actions/checkout@v4
+ - uses: actions/checkout@v5
- name: Set up Python
- uses: actions/setup-python@v5
+ uses: actions/setup-python@v6
with:
python-version: "3.13"
- name: Ensure latest setuptools
@@ -109,9 +109,9 @@
warnings:
runs-on: ubuntu-latest
steps:
- - uses: actions/checkout@v4
+ - uses: actions/checkout@v5
- name: Set up Python
- uses: actions/setup-python@v5
+ uses: actions/setup-python@v6
with:
python-version: "3.13"
- name: Ensure latest setuptools
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/django_filter-25.1/.gitignore
new/django_filter-25.2/.gitignore
--- old/django_filter-25.1/.gitignore 2023-12-04 16:17:21.875263700 +0100
+++ new/django_filter-25.2/.gitignore 2025-10-05 11:38:54.308145000 +0200
@@ -12,3 +12,5 @@
.idea
.env
.vscode
+_docs
+.DS_Store
\ No newline at end of file
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/django_filter-25.1/CHANGES.rst
new/django_filter-25.2/CHANGES.rst
--- old/django_filter-25.1/CHANGES.rst 2025-02-14 17:30:19.678902000 +0100
+++ new/django_filter-25.2/CHANGES.rst 2025-10-05 11:44:34.223698900 +0200
@@ -1,3 +1,12 @@
+Version 25.2 (UNRELEASED)
+-------------------------
+
+* Added testing for Django 6.0.
+
+* Dropped support for Django <5.2 LTS
+
+* Dropped support for Python 3.9.
+
Version 25.1 (2025-02-14)
-------------------------
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/django_filter-25.1/PKG-INFO
new/django_filter-25.2/PKG-INFO
--- old/django_filter-25.1/PKG-INFO 1970-01-01 01:00:00.000000000 +0100
+++ new/django_filter-25.2/PKG-INFO 1970-01-01 01:00:00.000000000 +0100
@@ -1,10 +1,10 @@
Metadata-Version: 2.1
Name: django-filter
-Version: 25.1
+Version: 25.2
Summary: Django-filter is a reusable Django application for allowing users to
filter querysets dynamically.
Author-email: Alex Gaynor <[email protected]>
Maintainer-email: Carlton Gibson <[email protected]>
-Requires-Python: >=3.9
+Requires-Python: >=3.10
Description-Content-Type: text/x-rst
Classifier: Development Status :: 5 - Production/Stable
Classifier: Environment :: Web Environment
@@ -12,22 +12,22 @@
Classifier: License :: OSI Approved :: BSD License
Classifier: Operating System :: OS Independent
Classifier: Framework :: Django
-Classifier: Framework :: Django :: 4.2
-Classifier: Framework :: Django :: 5.0
-Classifier: Framework :: Django :: 5.1
Classifier: Framework :: Django :: 5.2
+Classifier: Framework :: Django :: 6.0
Classifier: Programming Language :: Python
Classifier: Programming Language :: Python :: 3
-Classifier: Programming Language :: Python :: 3.9
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
-Requires-Dist: Django>=4.2
+Classifier: Programming Language :: Python :: 3.13
+Requires-Dist: Django>=5.2
+Requires-Dist: djangorestframework ; extra == "drf"
Project-URL: Bug Tracker, https://github.com/carltongibson/django-filter/issues
Project-URL: Changelog,
https://github.com/carltongibson/django-filter/blob/main/CHANGES.rst
Project-URL: Documentation, https://django-filter.readthedocs.io/en/main/
Project-URL: Homepage, https://github.com/carltongibson/django-filter/tree/main
Project-URL: Source Code, https://github.com/carltongibson/django-filter
+Provides-Extra: drf
Django Filter
=============
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/django_filter-25.1/django_filters/__init__.py
new/django_filter-25.2/django_filters/__init__.py
--- old/django_filter-25.1/django_filters/__init__.py 2024-12-28
11:05:42.058471700 +0100
+++ new/django_filter-25.2/django_filters/__init__.py 2025-10-05
11:50:56.992887000 +0200
@@ -10,7 +10,7 @@
from . import rest_framework
del importlib_util
-__version__ = "25.1"
+__version__ = "25.2"
def parse_version(version):
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/django_filter-25.1/docs/conf.py
new/django_filter-25.2/docs/conf.py
--- old/django_filter-25.1/docs/conf.py 2023-12-04 16:17:34.095506200 +0100
+++ new/django_filter-25.2/docs/conf.py 2025-10-05 11:38:54.309117000 +0200
@@ -28,7 +28,9 @@
# Add any Sphinx extension module names here, as strings. They can be
extensions
# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
-extensions = []
+extensions = [
+ "sphinx.ext.intersphinx"
+]
# Add any paths that contain templates here, relative to this directory.
templates_path = ["_templates"]
@@ -257,3 +259,15 @@
# How to display URL addresses: 'footnote', 'no', or 'inline'.
# texinfo_show_urls = 'footnote'
+
+
+intersphinx_mapping = {
+ "django": (
+ "https://docs.djangoproject.com/en/stable";,
+ "https://docs.djangoproject.com/en/stable/_objects/";,
+ ),
+ "python": ('https://docs.python.org/3', None)
+}
+
+# elide module names in class headings
+add_module_names = False
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/django_filter-25.1/docs/guide/tips.txt
new/django_filter-25.2/docs/guide/tips.txt
--- old/django_filter-25.1/docs/guide/tips.txt 2023-12-04 16:17:34.095669700
+0100
+++ new/django_filter-25.2/docs/guide/tips.txt 2025-10-05 11:38:54.310138000
+0200
@@ -299,3 +299,60 @@
filter = super(HelpfulFilterSet, cls).filter_for_field(f, name,
lookup_expr)
filter.extra['help_text'] = f.help_text
return filter
+
+Adding Postgres Native Full Text Search
+---------------------------------------
+
+Django-Filter does not provide a built-in filter for PostgreSQL Full-Text
Search. However,
+you can enable full-text search functionality in two ways:
+
+1. By adding ``Filter.method``. This approach is useful for one-off instances
where you need
+ a simple search filter.
+
+2. Writing a custom Filter. This approach is more reusable and works well when
you can generalize
+ the query for multiple cases.
+
+Solution 1: Use the ``Filter.method`` feature
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: python
+
+ from django.contrib.postgres.search import SearchVector, SearchQuery
+
+ class ProductFilter(django_filters.FilterSet):
+ # The model `field_name` is the field you want to search on and is
passed to your `method`.
+ # The `method` argument is the name of the method to call to perform
filtering.
+ search = django_filters.CharFilter(field_name="description",
method="search_fulltext")
+
+ def search_fulltext(self, queryset, field_name, value):
+ if not value:
+ return queryset
+ return queryset.annotate(
+ search=SearchVector("name", "description")
+ ).filter(search=SearchQuery(value))
+
+ class Meta:
+ model = Product
+ fields = ["search", "price", "manufacturer"]
+
+Solution 2: Write a new filter class
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: python
+
+ from django.contrib.postgres.search import SearchVector, SearchQuery
+
+ class FullTextSearchFilter(django_filters.CharFilter):
+ def filter(self, queryset, value):
+ if not value:
+ return queryset
+ return queryset.annotate(
+ search=SearchVector("name", "description")
+ ).filter(search=SearchQuery(value))
+
+ class ProductFilter(django_filters.FilterSet):
+ search = FullTextSearchFilter(field_name="description")
+
+ class Meta:
+ model = Product
+ fields = ["search", "price", "manufacturer"]
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/django_filter-25.1/docs/guide/usage.txt
new/django_filter-25.2/docs/guide/usage.txt
--- old/django_filter-25.1/docs/guide/usage.txt 2023-03-26 11:29:15.081597000
+0200
+++ new/django_filter-25.2/docs/guide/usage.txt 2025-10-05 11:38:54.310603900
+0200
@@ -29,7 +29,7 @@
----------
We have a number of fields and we want to let our users filter based on the
-name, the price or the release_date. We create a ``FilterSet`` for this::
+name, the price or the release_date. We create a
:class:`~django_filters.filterset.FilterSet` for this::
import django_filters
@@ -41,8 +41,8 @@
fields = ['price', 'release_date']
-As you can see this uses a very similar API to Django's ``ModelForm``. Just
-like with a ``ModelForm`` we can also override filters, or add new ones using a
+As you can see this uses a very similar API to Django's
:class:`~django.forms.ModelForm`. Just
+like with a :class:`~django.forms.ModelForm` we can also override filters, or
add new ones using a
declarative syntax.
Declaring filters
@@ -50,7 +50,8 @@
The declarative syntax provides you with the most flexibility when creating
filters, however it is fairly verbose. We'll use the below example to outline
-the :ref:`core filter arguments <core-arguments>` on a ``FilterSet``::
+the :ref:`core filter arguments <core-arguments>` on a
:class:`~django_filters.filterset.FilterSet`::
+
class ProductFilter(django_filters.FilterSet):
price = django_filters.NumberFilter()
@@ -72,18 +73,15 @@
- ``field_name``: The name of the model field to filter on. You can traverse
"relationship paths" using Django's ``__`` syntax to filter fields on a
related model. ex, ``manufacturer__name``.
-- ``lookup_expr``: The `field lookup`_ to use when filtering. Django's ``__``
- syntax can again be used in order to support lookup transforms.
- ex, ``year__gte``.
+- ``lookup_expr``: The :ref:`field lookup <django:field-lookups>` to use when
filtering.
+ Django's ``__`` syntax can again be used in order to support lookup
transforms. ex, ``year__gte``.
.. _`field lookup`:
https://docs.djangoproject.com/en/stable/ref/models/querysets/#field-lookups
Together, the field ``field_name`` and ``lookup_expr`` represent a complete
Django
lookup expression. A detailed explanation of lookup expressions is provided in
-Django's `lookup reference`_. django-filter supports expressions containing
-both transforms and a final lookup.
-
-.. _`lookup reference`:
https://docs.djangoproject.com/en/stable/ref/models/lookups/#module-django.db.models.lookups
+Django's :mod:`lookup reference <django.db.models.lookups>`. django-filter
supports
+expressions containing both transforms and a final lookup.
Generating filters with Meta.fields
@@ -139,7 +137,7 @@
Overriding default filters
""""""""""""""""""""""""""
-Like ``django.contrib.admin.ModelAdmin``, it is possible to override
+Like :class:`django.contrib.admin.ModelAdmin`, it is possible to override
default filters for all the models fields of the same kind using
``filter_overrides`` on the ``Meta`` class::
@@ -170,10 +168,10 @@
Request-based filtering
~~~~~~~~~~~~~~~~~~~~~~~
-The ``FilterSet`` may be initialized with an optional ``request`` argument. If
-a request object is passed, then you may access the request during filtering.
-This allows you to filter by properties on the request, such as the currently
-logged-in user or the ``Accepts-Languages`` header.
+The :class:`~django_filters.filterset.FilterSet` may be initialized with an
+optional ``request`` argument. If a request object is passed, then you may
access
+the request during filtering. This allows you to filter by properties on the
request,
+such as the currently logged-in user or the ``Accepts-Languages`` header.
.. note::
@@ -209,10 +207,11 @@
Filtering the related queryset for ``ModelChoiceFilter``
""""""""""""""""""""""""""""""""""""""""""""""""""""""""
-The ``queryset`` argument for ``ModelChoiceFilter`` and
``ModelMultipleChoiceFilter``
-supports callable behavior. If a callable is passed, it will be invoked with
the
-``request`` as its only argument. This allows you to perform the same kinds of
-request-based filtering without resorting to overriding ``FilterSet.__init__``.
+The ``queryset`` argument for
:class:`~django_filters.filters.ModelChoiceFilter` and
+:class:`~django_filters.filters.ModelMultipleChoiceFilter` supports callable
behavior.
+If a callable is passed, it will be invoked with the ``request`` as its only
argument.
+This allows you to perform the same kinds of request-based filtering without
resorting
+to overriding ``FilterSet.__init__``.
.. code-block:: python
@@ -277,7 +276,9 @@
The template
------------
-And lastly we need a template::
+And lastly we need a template:
+
+.. code-block:: django
{% extends "base.html" %}
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/django_filter-25.1/docs/ref/fields.txt
new/django_filter-25.2/docs/ref/fields.txt
--- old/django_filter-25.1/docs/ref/fields.txt 2021-11-10 10:12:06.459052300
+0100
+++ new/django_filter-25.2/docs/ref/fields.txt 2025-10-05 11:38:54.311391000
+0200
@@ -2,22 +2,23 @@
Field Reference
===============
-``IsoDateTimeField``
-~~~~~~~~~~~~~~~~~~~~
+.. module:: django_filters.fields
+ :synopsis: Provided form fields and their arguments.
-Extends ``django.forms.DateTimeField`` to allow parsing ISO 8601 formated
dates, in addition to existing formats
+.. currentmodule:: django_filters.fields
+
+.. class:: IsoDateTimeField
+
+Extends :class:`django.forms.DateTimeField` to allow parsing ISO 8601 formated
dates, in addition to existing formats
Defines a class level attribute ``ISO_8601`` as constant for the format.
Sets ``input_formats = [ISO_8601]`` — this means that by default
``IsoDateTimeField`` will **only** parse ISO 8601 formated dates.
-You may set ``input_formats`` to your list of required formats as per the
`DateTimeField Docs`_, using the ``ISO_8601`` class level attribute to specify
the ISO 8601 format.
+You may set :attr:`~django.forms.DateTimeField.input_formats` to your list of
required formats as per the :class:`~django.forms.DateTimeField` docs, using
the ``ISO_8601`` class level attribute to specify the ISO 8601 format.
.. code-block:: python
f = IsoDateTimeField()
f.input_formats = [IsoDateTimeField.ISO_8601] + DateTimeField.input_formats
-
-.. _`DateTimeField Docs`:
https://docs.djangoproject.com/en/stable/ref/forms/fields/#django.forms.DateTimeField.input_formats
-
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/django_filter-25.1/docs/ref/filters.txt
new/django_filter-25.2/docs/ref/filters.txt
--- old/django_filter-25.1/docs/ref/filters.txt 2022-06-16 17:11:02.219039400
+0200
+++ new/django_filter-25.2/docs/ref/filters.txt 2025-10-05 11:38:54.312126600
+0200
@@ -2,6 +2,11 @@
Filter Reference
================
+.. module:: django_filters.filters
+ :synopsis: Provided filters and their arguments.
+
+.. currentmodule:: django_filters.filters
+
This is a reference document with a list of the filters and their arguments.
.. _core-arguments:
@@ -10,29 +15,26 @@
--------------
The following are the core arguments that apply to all filters. Note that they
-are joined to construct the complete `lookup expression`_ that is the left hand
-side of the ORM ``.filter()`` call.
-
-.. _`lookup expression`:
https://docs.djangoproject.com/en/stable/ref/models/lookups/#module-django.db.models.lookups
+are joined to construct the complete :mod:`lookup expression
<django.db.models.lookups>`
+that is the left hand side of the ORM
:meth:`~django.db.models.query.QuerySet.filter` call.
``field_name``
~~~~~~~~~~~~~~
The name of the model field that is filtered against. If this argument is not
-provided, it defaults the filter's attribute name on the ``FilterSet`` class.
-Field names can traverse relationships by joining the related parts with the
ORM
-lookup separator (``__``). e.g., a product's ``manufacturer__name``.
+provided, it defaults the filter's attribute name on the
+:class:`~django_filters.filterset.FilterSet` class. Field names can traverse
relationships
+by joining the related parts with the ORM lookup separator (``__``). e.g., a
product's
+``manufacturer__name``.
``lookup_expr``
~~~~~~~~~~~~~~~
-The `field lookup`_ that should be performed in the filter call. Defaults to
-``exact``. The ``lookup_expr`` can contain transforms if the expression parts
+The :ref:`field lookup <django:field-lookups>` that should be performed in the
filter call.
+Defaults to ``exact``. The ``lookup_expr`` can contain transforms if the
expression parts
are joined by the ORM lookup separator (``__``). e.g., filter a datetime by its
year part ``year__gt``.
-.. _`Field lookup`:
https://docs.djangoproject.com/en/stable/ref/models/querysets/#field-lookups
-
.. _keyword-only-arguments:
Keyword-only Arguments
@@ -55,9 +57,11 @@
~~~~~~~~~~
An optional argument that tells the filter how to handle the queryset. It can
-accept either a callable or the name of a method on the ``FilterSet``. The
-callable receives a ``QuerySet``, the name of the model field to filter on, and
-the value to filter with. It should return a filtered ``Queryset``.
+accept either a callable or the name of a method on the
+:class:`~django_filters.filterset.FilterSet`. The callable receives a
+:class:`~django.db.models.query.QuerySet`, the name of the model field to
filter
+on, and the value to filter with. It should return a filtered
+:class:`~django.db.models.query.QuerySet`.
Note that the value is validated by the ``Filter.field``, so raw value
transformation and empty value checking should be unnecessary.
@@ -118,8 +122,8 @@
~~~~~~~~~~~~
Any additional keyword arguments are stored as the ``extra`` parameter on the
-filter. They are provided to the accompanying form ``Field`` and can be used to
-provide arguments like ``choices``. Some field-related arguments:
+filter. They are provided to the accompanying form
:class:`~django.forms.Field` and can be used to
+provide arguments like :attr:`~django.forms.ChoiceField.choices`. Some
field-related arguments:
``widget``
""""""""""
@@ -128,29 +132,31 @@
to the widgets that are included with Django that you can use there are
additional ones that django-filter provides which may be useful:
- * :ref:`LinkWidget <link-widget>` -- this displays the options in a manner
+ * :class:`~django_filters.widgets.LinkWidget` -- this displays the options
in a manner
similar to the way the Django Admin does, as a series of links. The link
for the selected option will have ``class="selected"``.
- * :ref:`BooleanWidget <boolean-widget>` -- this widget converts its input
+ * :class:`~django_filters.widgets.BooleanWidget` -- this widget converts
its input
into Python's True/False values. It will convert all case variations of
``True`` and ``False`` into the internal Python values.
- * :ref:`CSVWidget <csv-widget>` -- this widget expects a comma separated
+ * :class:`~django_filters.widgets.CSVWidget` -- this widget expects a
comma separated
value and converts it into a list of string values. It is expected that
the field class handle a list of values as well as type conversion.
- * :ref:`RangeWidget <range-widget>` -- this widget is used with
``RangeFilter``
- to generate two form input elements using a single field.
+ * :class:`~django_filters.widgets.RangeWidget` -- this widget is used with
+ :class:`~django_filters.filters.RangeFilter` to generate two form input
elements
+ using a single field.
-ModelChoiceFilter and ModelMultipleChoiceFilter arguments
----------------------------------------------------------
+``ModelChoiceFilter`` and ``ModelMultipleChoiceFilter`` arguments
+-----------------------------------------------------------------
-These arguments apply specifically to ModelChoiceFilter and
-ModelMultipleChoiceFilter only.
+These arguments apply specifically to
:class:`~django_filters.filters.ModelChoiceFilter` and
+:class:`~django_filters.filters.ModelMultipleChoiceFilter` only.
-``queryset``
+``QuerySet``
~~~~~~~~~~~~
-``ModelChoiceFilter`` and ``ModelMultipleChoiceFilter`` require a queryset to
+:class:`~django_filters.filters.ModelChoiceFilter` and
+:class:`~django_filters.filters.ModelMultipleChoiceFilter` require a queryset
to
operate on which must be passed as a kwarg.
``to_field_name``
@@ -164,30 +170,25 @@
Filters
-------
-``CharFilter``
-~~~~~~~~~~~~~~
+.. class:: CharFilter
-This filter does simple character matches, used with ``CharField`` and
-``TextField`` by default.
+This filter does simple character matches, used with
:class:`~django.db.models.CharField` and
+:class:`~django.db.models.TextField` by default.
-``UUIDFilter``
-~~~~~~~~~~~~~~
+.. class:: UUIDFilter
-This filter matches UUID values, used with ``models.UUIDField`` by default.
+This filter matches UUID values, used with
:class:`~django.db.models.UUIDField` by default.
-``BooleanFilter``
-~~~~~~~~~~~~~~~~~
+.. class:: BooleanFilter
This filter matches a boolean, either ``True`` or ``False``, used with
-``BooleanField`` and ``NullBooleanField`` by default.
+:class:`~django.db.models.BooleanField` and ``NullBooleanField`` by default.
.. _choice-filter:
-
-``ChoiceFilter``
-~~~~~~~~~~~~~~~~
+.. class:: ChoiceFilter
This filter matches values in its ``choices`` argument. The ``choices`` must be
-explicitly passed when the filter is declared on the ``FilterSet``. For
example,
+explicitly passed when the filter is declared on the
:class:`~django_filters.filterset.FilterSet`. For example,
.. code-block:: python
@@ -211,9 +212,9 @@
fields = ['status']
-``ChoiceFilter`` also has arguments that enable a choice for not filtering, as
-well as a choice for filtering by ``None`` values. Each of the arguments have a
-corresponding global setting (:doc:`/ref/settings`).
+:class:`~django_filters.filters.ChoiceFilter` also has arguments that enable a
+choice for not filtering, as well as a choice for filtering by ``None`` values.
+Each of the arguments have a corresponding global setting
(:doc:`/ref/settings`).
* ``empty_label``: The display label to use for the select choice to not
filter.
The choice may be disabled by setting this argument to ``None``. Defaults to
@@ -226,11 +227,10 @@
a non-empty value (``''``, ``None``, ``[]``, ``()``, ``{}``).
-``TypedChoiceFilter``
-~~~~~~~~~~~~~~~~~~~~~
+.. class:: TypedChoiceFilter
-The same as ``ChoiceFilter`` with the added possibility to convert value to
-match against. This could be done by using `coerce` parameter.
+The same as :class:`~django_filters.filters.ChoiceFilter` with the added
possibility
+to convert value to match against. This could be done by using `coerce`
parameter.
An example use-case is limiting boolean choices to match against so only
some predefined strings could be used as input of a boolean filter::
@@ -245,11 +245,10 @@
coerce=strtobool)
-``MultipleChoiceFilter``
-~~~~~~~~~~~~~~~~~~~~~~~~
+.. class:: MultipleChoiceFilter
-The same as ``ChoiceFilter`` except the user can select multiple choices
-and the filter will form the OR of these choices by default to match items.
+The same as :class:`~django_filters.filters.ChoiceFilter` except the user can
select
+multiple choices and the filter will form the OR of these choices by default
to match items.
The filter will form the AND of the selected choices when the
``conjoined=True``
argument is passed to this class.
@@ -268,36 +267,31 @@
Override `is_noop` if you require a different test for your application.
-``TypedMultipleChoiceFilter``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. class:: TypedMultipleChoiceFilter
-Like ``MultipleChoiceFilter``, but in addition accepts the ``coerce``
parameter, as
-in ``TypedChoiceFilter``.
+Like :class:`~django_filters.filters.MultipleChoiceFilter`, but in addition
accepts the
+``coerce`` parameter, as in :class:`~django_filters.filters.TypedChoiceFilter`.
-``DateFilter``
-~~~~~~~~~~~~~~
+.. class:: DateFilter
-Matches on a date. Used with ``DateField`` by default.
+Matches on a date. Used with :class:`~django.db.models.DateField` by default.
-``TimeFilter``
-~~~~~~~~~~~~~~
+.. class:: TimeFilter
-Matches on a time. Used with ``TimeField`` by default.
+Matches on a time. Used with :class:`~django.db.models.TimeField` by default.
-``DateTimeFilter``
-~~~~~~~~~~~~~~~~~~
+.. class:: DateTimeFilter
-Matches on a date and time. Used with ``DateTimeField`` by default.
+Matches on a date and time. Used with
:class:`~django.db.models.DateTimeField` by default.
-``IsoDateTimeFilter``
-~~~~~~~~~~~~~~~~~~~~~
+.. class:: IsoDateTimeFilter
-Uses ``IsoDateTimeField`` to support filtering on ISO 8601 formatted dates, as
are often
-used in APIs, and are employed by default by Django REST Framework.
+Uses :class:`~django_filters.fields.IsoDateTimeField` to support filtering on
ISO 8601
+formatted dates, as are often used in APIs, and are employed by default by
Django REST Framework.
Example::
@@ -310,25 +304,23 @@
fields = ['published']
-``DurationFilter``
-~~~~~~~~~~~~~~~~~~
+.. class:: DurationFilter
-Matches on a duration. Used with ``DurationField`` by default.
+Matches on a duration. Used with :class:`~django.db.models.DurationField` by
default.
Supports both Django ('%d %H:%M:%S.%f') and ISO 8601 formatted durations (but
only the sections that are accepted by Python's timedelta, so no year, month,
and week designators, e.g. 'P3DT10H22M').
-``ModelChoiceFilter``
-~~~~~~~~~~~~~~~~~~~~~
+.. class:: ModelChoiceFilter
-Similar to a ``ChoiceFilter`` except it works with related models, used for
+Similar to a :class:`~django_filters.filters.ChoiceFilter` except it works
with related models, used for
``ForeignKey`` by default.
-If automatically instantiated, ``ModelChoiceFilter`` will use the default
-``QuerySet`` for the related field. If manually instantiated you **must**
-provide the ``queryset`` kwarg.
+If automatically instantiated,
:class:`~django_filters.filters.ModelChoiceFilter` will use the default
+:class:`~django.db.models.query.QuerySet` for the related field. If manually
instantiated you **must**
+provide the :class:`~django.db.models.query.QuerySet` kwarg.
Example::
@@ -340,8 +332,8 @@
model = Book
fields = ['author']
-The ``queryset`` argument also supports callable behavior. If a callable is
-passed, it will be invoked with ``Filterset.request`` as its only argument.
+The :class:`~django.db.models.query.QuerySet` argument also supports callable
behavior. If a callable is
+passed, it will be invoked with ``FilterSet.request`` as its only argument.
This allows you to easily filter by properties on the request object without
having to override the ``FilterSet.__init__``.
@@ -363,16 +355,17 @@
...
-``ModelMultipleChoiceFilter``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. class:: ModelMultipleChoiceFilter
-Similar to a ``MultipleChoiceFilter`` except it works with related models, used
-for ``ManyToManyField`` by default.
+Similar to a :class:`~django_filters.filters.MultipleChoiceFilter` except it
works
+with related models, used for :class:`~django.db.models.ManyToManyField` by
default.
-As with ``ModelChoiceFilter``, if automatically instantiated,
-``ModelMultipleChoiceFilter`` will use the default ``QuerySet`` for the related
-field. If manually instantiated you **must** provide the ``queryset`` kwarg.
-Like ``ModelChoiceFilter``, the ``queryset`` argument has callable behavior.
+As with :class:`~django_filters.filters.ModelChoiceFilter`, if automatically
instantiated,
+:class:`~django_filters.filters.ModelMultipleChoiceFilter` will use the default
+:class:`~django.db.models.query.QuerySet` for the related field. If manually
instantiated
+you **must** provide the :class:`~django.db.models.query.QuerySet` kwarg. Like
+:class:`~django_filters.filters.ModelChoiceFilter`, the
+:class:`~django.db.models.query.QuerySet` argument has callable behavior.
To use a custom field name for the lookup, you can use ``to_field_name``::
@@ -420,26 +413,25 @@
objects = CustomQuerySet.as_manager()
-``NumberFilter``
-~~~~~~~~~~~~~~~~
+.. class:: NumberFilter
-Filters based on a numerical value, used with ``IntegerField``, ``FloatField``,
-and ``DecimalField`` by default.
+Filters based on a numerical value, used with
:class:`~django.db.models.IntegerField`,
+:class:`~django.db.models.FloatField`, and
:class:`~django.db.models.DecimalField` by default.
.. method:: NumberFilter.get_max_validator()
- Return a ``MaxValueValidator`` instance that will be added to
- ``field.validators``. By default uses a limit value of ``1e50``. Return
- ``None`` to disable maximum value validation.
+ Return a :class:`~django.core.validators.MaxValueValidator` instance that
will
+ be added to :attr:`django.forms.Field.validators`. By default uses a limit
value
+ of ``1e50``. Return ``None`` to disable maximum value validation.
-``NumericRangeFilter``
-~~~~~~~~~~~~~~~~~~~~~~
+.. class:: NumericRangeFilter
Filters where a value is between two numerical values, or greater than a
minimum or less
than a maximum where only one limit value is provided. This filter is designed
to work
-with the Postgres Numerical Range Fields, including ``IntegerRangeField``,
-``BigIntegerRangeField`` and ``FloatRangeField`` (available since Django 1.8).
The default
-widget used is the ``RangeField``.
+with the Postgres Numerical Range Fields, including
:class:`~django.contrib.postgres.fields.IntegerRangeField`,
+:class:`~django.contrib.postgres.fields.BigIntegerRangeField` and
+:class:`~django.contrib.postgres.fields.FloatRangeField` (available since
Django 1.8). The default
+widget used is the :class:`~django_filters.widgets.RangeWidget`.
Regular field lookups are available in addition to several containment
lookups, including
``overlap``, ``contains``, and ``contained_by``. More details in the Django
`docs`__.
@@ -449,8 +441,7 @@
If the lower limit value is provided, the filter automatically defaults to
``startswith``
as the lookup and ``endswith`` if only the upper limit value is provided.
-``RangeFilter``
-~~~~~~~~~~~~~~~
+.. class:: RangeFilter
Filters where a value is between two numerical values, or greater than a
minimum or less than a maximum where only one limit value is provided. ::
@@ -474,18 +465,20 @@
f = F({'price_max': '19'}, queryset=qs)
-``DateRangeFilter``
-~~~~~~~~~~~~~~~~~~~
+.. class:: DateRangeFilter
Filter similar to the admin changelist date one, it has a number of common
selections for working with date fields.
-``DateFromToRangeFilter``
-~~~~~~~~~~~~~~~~~~~~~~~~~
-Similar to a ``RangeFilter`` except it uses dates instead of numerical values.
It can be used with ``DateField``. It also works with ``DateTimeField``, but
takes into consideration only the date.
+.. class:: DateFromToRangeFilter
+
+Similar to a :class:`~django_filters.filters.RangeFilter` except it uses dates
+instead of numerical values. It can be used with
:class:`~django.db.models.DateField`.
+It also works with :class:`~django.db.models.DateTimeField`, but takes into
consideration
+only the date.
-Example of using the ``DateField`` field::
+Example of using the :class:`~django.db.models.DateField` field::
class Comment(models.Model):
date = models.DateField()
@@ -508,14 +501,14 @@
f = F({'date_before': '2016-02-01'})
.. note::
- When filtering ranges that occurs on DST transition dates
``DateFromToRangeFilter`` will use the first valid hour of the day for start
datetime and the last valid hour of the day for end datetime.
- This is OK for most applications, but if you want to customize this
behavior you must extend ``DateFromToRangeFilter`` and make a custom field for
it.
+ When filtering ranges that occurs on DST transition dates
:class:`~django_filters.filters.DateFromToRangeFilter` will use the first valid
hour of the day for start datetime and the last valid hour of the day for end
datetime.
+ This is OK for most applications, but if you want to customize this
behavior you must extend :class:`~django_filters.filters.DateFromToRangeFilter`
and make a custom field for it.
.. warning::
If you're using Django prior to 1.9 you may hit ``AmbiguousTimeError`` or
``NonExistentTimeError`` when start/end date matches DST start/end respectively.
This occurs because versions before 1.9 don't allow to change the DST
behavior for making a datetime aware.
-Example of using the ``DateTimeField`` field::
+Example of using the :class:`~django.db.models.DateTimeField` field::
class Article(models.Model):
published = models.DateTimeField()
@@ -543,10 +536,10 @@
f = F({'published_before': '2016-02-01'})
assert len(f.qs) == 2
-``DateTimeFromToRangeFilter``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. class:: DateTimeFromToRangeFilter
-Similar to a ``RangeFilter`` except it uses datetime format values instead of
numerical values. It can be used with ``DateTimeField``.
+Similar to a :class:`~django_filters.filters.RangeFilter` except it uses
datetime
+format values instead of numerical values. It can be used with
:class:`~django.db.models.DateTimeField`.
Example::
@@ -576,10 +569,11 @@
f = F({'published_before': '2016-01-01 10:00'})
assert len(f.qs) == 2
-``IsoDateTimeFromToRangeFilter``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. class:: IsoDateTimeFromToRangeFilter
-Similar to a ``RangeFilter`` except it uses ISO 8601 formatted values instead
of numerical values. It can be used with ``IsoDateTimeField``.
+Similar to a :class:`~django_filters.filters.RangeFilter` except it uses ISO
8601
+formatted values instead of numerical values. It can be used with
+:class:`~django_filters.fields.IsoDateTimeField`.
Example::
@@ -609,10 +603,10 @@
f = F({'published_before': '2016-01-01T10:00:00+0100'})
assert len(f.qs) == 2
-``TimeRangeFilter``
-~~~~~~~~~~~~~~~~~~~
+.. class:: TimeRangeFilter
-Similar to a ``RangeFilter`` except it uses time format values instead of
numerical values. It can be used with ``TimeField``.
+Similar to a :class:`~django_filters.filters.RangeFilter` except it uses time
+format values instead of numerical values. It can be used with
:class:`~django.db.models.TimeField`.
Example::
@@ -636,26 +630,22 @@
# Max-Only: Comments added before 10:00
f = F({'time_before': '10:00'})
-``AllValuesFilter``
-~~~~~~~~~~~~~~~~~~~
+.. class:: AllValuesFilter
-This is a ``ChoiceFilter`` whose choices are the current values in the
+This is a :class:`~django_filters.filters.ChoiceFilter` whose choices are the
current values in the
database. So if in the DB for the given field you have values of 5, 7, and 9
each of those is present as an option. This is similar to the default behavior
of the admin.
-``AllValuesMultipleFilter``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. class:: AllValuesMultipleFilter
-This is a ``MultipleChoiceFilter`` whose choices are the current values in the
+This is a :class:`~django_filters.filters.MultipleChoiceFilter` whose choices
are the current values in the
database. So if in the DB for the given field you have values of 5, 7, and 9
each of those is present as an option. This is similar to the default behavior
of the admin.
.. _lookup-choice-filter:
-
-``LookupChoiceFilter``
-~~~~~~~~~~~~~~~~~~~~~~
+.. class:: LookupChoiceFilter
A combined filter that allows users to select the lookup expression from a
dropdown.
@@ -678,9 +668,7 @@
)
.. _base-in-filter:
-
-``BaseInFilter``
-~~~~~~~~~~~~~~~~
+.. class:: BaseInFilter
This is a base class used for creating IN lookup filters. It is expected that
this filter class is used in conjunction with another filter class, as this
@@ -707,8 +695,7 @@
f = F({'id__in': '1,3'})
assert len(f.qs) == 2
-``BaseRangeFilter``
-~~~~~~~~~~~~~~~~~~~
+.. class:: BaseRangeFilter
This is a base class used for creating RANGE lookup filters. It behaves
identically to ``BaseInFilter`` with the exception that it expects only two
@@ -736,19 +723,18 @@
.. _ordering-filter:
+.. class:: OrderingFilter
-``OrderingFilter``
-~~~~~~~~~~~~~~~~~~
-
-Enable queryset ordering. As an extension of ``ChoiceFilter`` it accepts
-two additional arguments that are used to build the ordering choices.
+Enable queryset ordering. As an extension of
:class:`~django_filters.filters.ChoiceFilter`
+it accepts two additional arguments that are used to build the ordering
choices.
* ``fields`` is a mapping of {model field name: parameter name}. The
parameter names are exposed in the choices and mask/alias the field
- names used in the ``order_by()`` call. Similar to field ``choices``,
- ``fields`` accepts the 'list of two-tuples' syntax that retains order.
- ``fields`` may also just be an iterable of strings. In this case, the
- field names simply double as the exposed parameter names.
+ names used in the :meth:`~django.db.models.query.QuerySet.order_by` call.
+ Similar to field :attr:`~django.db.models.Field.choices`, ``fields``
+ accepts the 'list of two-tuples' syntax that retains order. ``fields``
+ may also just be an iterable of strings. In this case, the field names
+ simply double as the exposed parameter names.
* ``field_labels`` is an optional argument that allows you to customize
the display label for the corresponding parameter. It accepts a mapping
@@ -814,7 +800,7 @@
are not able to retain selection order.
Adding Custom filter choices
-""""""""""""""""""""""""""""
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you wish to sort by non-model fields, you'll need to add custom handling to
an
``OrderingFilter`` subclass. For example, if you want to sort by a computed
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/django_filter-25.1/docs/ref/filterset.txt
new/django_filter-25.2/docs/ref/filterset.txt
--- old/django_filter-25.1/docs/ref/filterset.txt 2024-12-28
10:35:11.321407300 +0100
+++ new/django_filter-25.2/docs/ref/filterset.txt 2025-10-05
11:38:54.312521200 +0200
@@ -2,8 +2,16 @@
FilterSet Options
=================
+.. module:: django_filters.filterset
+ :synopsis: FilterSet features and options.
+
+.. currentmodule:: django_filters.filterset
+
This document provides a guide on using additional FilterSet features.
+
+.. class:: FilterSet
+
Meta options
------------
@@ -21,12 +29,10 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ``FilterSet`` is capable of automatically generating filters for a given
-``model``'s fields. Similar to Django's ``ModelForm``, filters are created
+``model``'s fields. Similar to Django's :class:`~django.forms.ModelForm`,
filters are created
based on the underlying model field's type. This option must be combined with
either the ``fields`` or ``exclude`` option, which is the same requirement for
-Django's ``ModelForm`` class, detailed `here`__.
-
-__
https://docs.djangoproject.com/en/stable/topics/forms/modelforms/#selecting-the-fields-to-use
+Django's :class:`~django.forms.ModelForm` class, detailed :ref:`here
<modelforms-selecting-fields>`.
.. code-block:: python
@@ -68,13 +74,12 @@
The list syntax will create an ``exact`` lookup filter for each field included
in ``fields``. The dictionary syntax will create a filter for each lookup
expression declared for its corresponding model field. These expressions may
-include both transforms and lookups, as detailed in the `lookup reference`__.
-
-__
https://docs.djangoproject.com/en/stable/ref/models/lookups/#module-django.db.models.lookups
+include both transforms and lookups, as detailed in the
+:mod:`lookup reference <django.db.models.lookups>`.
Note that it is **not** necessary to include declared filters in a ``fields``
-list - doing so will only affect the order in which fields appear on a
FilterSet's form. Including declarative aliases in a
-``fields`` dict will raise an error.
+list - doing so will only affect the order in which fields appear on a
FilterSet's form.
+Including declarative aliases in a ``fields`` dict will raise an error.
.. code-block:: python
@@ -116,7 +121,7 @@
The inner ``Meta`` class also takes an optional ``form`` argument. This is a
form class from which ``FilterSet.form`` will subclass. This works similar to
-the ``form`` option on a ``ModelAdmin.``
+the ``form`` option on a :class:`~django.contrib.admin.ModelAdmin`.
.. _filter_overrides:
@@ -149,10 +154,11 @@
-A possible usecase would be creating a custom filter to be able to filter on
``FileFields``
-(``FileField`` filtering is hard to define in a generalised way, which is why
there is no ``FileFilter``).
+A possible usecase would be creating a custom filter to be able to filter on a
+:class:`~django.db.models.FileField` (This is hard to define in a generalised
way,
+which is why there is no ``FileFilter``).
-This example shows an override used to filter on a ``FileField``::
+This example shows an override used to filter on a
:class:`~django.db.models.FileField`::
class Questionnaire(models.Model):
file = models.FileField(upload_to=questionnaire_path)
@@ -200,7 +206,7 @@
--------------------------------
When overriding classmethods, calling ``super(MyFilterSet, cls)`` may result
-in a ``NameError`` exception. This is due to the ``FilterSetMetaclass`` calling
+in a :exc:`NameError` exception. This is due to the ``FilterSetMetaclass``
calling
these classmethods before the ``FilterSet`` class has been fully created.
There are two recommmended workarounds:
@@ -219,8 +225,8 @@
model = Product
fields = ['...']
-``filter_for_lookup()``
-~~~~~~~~~~~~~~~~~~~~~~~
+
+.. method:: FilterSet.filter_for_lookup
Prior to version 0.13.0, filter generation did not take into account the
``lookup_expr`` used. This commonly caused malformed filters to be generated
@@ -256,6 +262,8 @@
Using ``filterset_factory``
---------------------------
+.. function:: filterset_factory
+
A ``FilterSet`` for a ``model`` can also be created by the
``filterset_factory``, which creates a ``FilterSet`` with the ``model`` set in
the FilterSets Meta. You can pass a customized ``FilterSet`` class to the
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/django_filter-25.1/docs/ref/widgets.txt
new/django_filter-25.2/docs/ref/widgets.txt
--- old/django_filter-25.1/docs/ref/widgets.txt 2023-03-26 11:29:15.081746300
+0200
+++ new/django_filter-25.2/docs/ref/widgets.txt 2025-10-05 11:38:54.312950400
+0200
@@ -2,14 +2,19 @@
Widget Reference
================
+.. module:: django_filters.widgets
+ :synopsis: Provided form widgets and their arguments.
+
+.. currentmodule:: django_filters.widgets
+
+
This is a reference document with a list of the provided widgets and their
arguments.
.. _link-widget:
-``LinkWidget``
-~~~~~~~~~~~~~~
+.. class:: LinkWidget
This widget renders each option as a link, instead of an actual <input>. It
has
one method that you can override for additional customizability.
@@ -24,13 +29,11 @@
.. _boolean-widget:
-
-``BooleanWidget``
-~~~~~~~~~~~~~~~~~
+.. class:: BooleanWidget
This widget converts its input into Python's True/False values. It will convert
all case variations of ``True`` and ``False`` into the internal Python values.
-To use it, pass this into the ``widgets`` argument of the ``BooleanFilter``:
+To use it, pass this into the ``widgets`` argument of the
:class:`~django_filters.filters.BooleanFilter`:
.. code-block:: python
@@ -38,9 +41,7 @@
.. _csv-widget:
-
-``CSVWidget``
-~~~~~~~~~~~~~
+.. class:: CSVWidget
This widget expects a comma separated value and converts it into a list of
string values. It is expected that the field class handle a list of values as
@@ -48,26 +49,23 @@
.. _range-widget:
+.. class:: RangeWidget
-``RangeWidget``
-~~~~~~~~~~~~~~~
-
-This widget is used with ``RangeFilter`` and its subclasses. It generates two
-form input elements which generally act as start/end values in a range.
-Under the hood, it is Django's ``forms.TextInput`` widget and accepts
-the same arguments and values. To use it, pass it to ``widget`` argument of
-a ``RangeField``:
+This widget is used with :class:`~django_filters.filters.RangeFilter` and its
+subclasses. It generates two form input elements which generally act as
start/end
+values in a range. Under the hood, it is Django's
:class:`~django.forms.TextInput` widget and
+accepts the same arguments and values. To use it, pass it to ``widget``
argument of
+a :class:`~django_filters.filters.RangeFilter`:
.. code-block:: python
date_range = DateFromToRangeFilter(widget=RangeWidget(attrs={'placeholder':
'YYYY/MM/DD'}))
-``SuffixedMultiWidget``
-~~~~~~~~~~~~~~~~~~~~~~~
+.. class:: SuffixedMultiWidget
-Extends Django's builtin ``MultiWidget`` to append custom suffixes instead of
-indices. For example, take a range widget that accepts minimum and maximum
+Extends Django's builtin :class:`~django.forms.MultiWidget` to append custom
suffixes
+instead of indices. For example, take a range widget that accepts minimum and
maximum
bounds. By default, the resulting query params would look like the following:
.. code-block:: http
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/django_filter-25.1/pyproject.toml
new/django_filter-25.2/pyproject.toml
--- old/django_filter-25.1/pyproject.toml 2025-02-14 17:19:33.070458700
+0100
+++ new/django_filter-25.2/pyproject.toml 2025-10-05 11:42:05.229426000
+0200
@@ -16,21 +16,22 @@
"License :: OSI Approved :: BSD License",
"Operating System :: OS Independent",
"Framework :: Django",
- "Framework :: Django :: 4.2",
- "Framework :: Django :: 5.0",
- "Framework :: Django :: 5.1",
"Framework :: Django :: 5.2",
+ "Framework :: Django :: 6.0",
"Programming Language :: Python",
"Programming Language :: Python :: 3",
- "Programming Language :: Python :: 3.9",
"Programming Language :: Python :: 3.10",
"Programming Language :: Python :: 3.11",
"Programming Language :: Python :: 3.12",
+ "Programming Language :: Python :: 3.13",
]
-requires-python = ">=3.9"
-dependencies = ["Django>=4.2"]
+requires-python = ">=3.10"
+dependencies = ["Django>=5.2"]
dynamic = ["version"]
+[project.optional-dependencies]
+drf = ["djangorestframework"]
+
[project.urls]
Homepage = "https://github.com/carltongibson/django-filter/tree/main";
Documentation = "https://django-filter.readthedocs.io/en/main/";
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/django_filter-25.1/tox.ini
new/django_filter-25.2/tox.ini
--- old/django_filter-25.1/tox.ini 2025-01-22 17:23:17.905338000 +0100
+++ new/django_filter-25.2/tox.ini 2025-10-05 11:41:06.430994500 +0200
@@ -1,9 +1,7 @@
[tox]
envlist =
- {py39, py310, py311, py312}-django42,
- {py310, py311, py312}-django50,
- {py310, py311, py312, py313}-django51,
{py310, py311, py312, py313}-django52,
+ {py312, py313}-django60,
{py312, py313}-latest,
isort,lint,docs,warnings,
isolated_build = true
@@ -19,10 +17,8 @@
setenv =
PYTHONDONTWRITEBYTECODE=1
deps =
- django42: Django>=4.2,<5.0
- django50: Django>=5.0,<5.1
- django51: Django>=5.1,<5.2
- django52: Django>=5.2a1,<6.0
+ django52: Django>=5.2,<6.0
+ django60: Django>=6.0a1,<7.0
!latest: djangorestframework
latest: {[latest]deps}
-r requirements/test-ci.txt
