Django provides a few classes that help you manage paginated data – that is, data that’s split across several pages, with “Previous/Next” links. These classes live in django/core/paginator.py.
Paginator(object_list, per_page, orphans=0, allow_empty_first_page=True)¶
A paginator acts like a sequence of
len()or iterating it directly.Changed in Django 3.1:
Support for iterating over
Required. A list, tuple,
QuerySet, or other sliceable object with a
__len__()method. For consistent pagination,
QuerySets should be ordered, e.g. with an
order_by()clause or with a default
orderingon the model.
Performance issues paginating large
If you’re using a
QuerySetwith a very large number of items, requesting high page numbers might be slow on some databases, because the resulting
OFFSETquery needs to count the number of
OFFSETrecords which takes longer as the page number gets higher.
Required. The maximum number of items to include on a page, not including orphans (see the
orphansoptional argument below).
Optional. Use this when you don’t want to have a last page with very few items. If the last page would normally have a number of items less than or equal to
orphans, then those items will be added to the previous page (which becomes the last page) instead of leaving the items on a page by themselves. For example, with 23 items,
orphans=3, there will be two pages; the first page with 10 items and the second (and last) page with 13 items.
orphansdefaults to zero, which means pages are never combined and the last page may have one item.
Optional. Whether or not the first page is allowed to be empty. If
object_listis empty, then an
EmptyPageerror will be raised.
Pageobject with the given 1-based index, while also handling out of range and invalid page numbers.
If the page isn’t a number, it returns the first page. If the page number is negative or greater than the number of pages, it returns the last page.
EmptyPageexception only if you specify
Paginator(..., allow_empty_first_page=False)and the
get_elided_page_range(number, *, on_each_side=3, on_ends=2)¶
- New in Django Development version.
The number of pages to include on each side of the current page number is determined by the
on_each_sideargument which defaults to 3.
The number of pages to include at the beginning and end of page range is determined by the
on_endsargument which defaults to 2.
For example, with the default values for
on_ends, if the current page is 10 and there are 50 pages, the page range will be
[1, 2, '…', 7, 8, 9, 10, 11, 12, 13, '…', 49, 50]. This will result in pages 4, 5, and 6 to the left of and 8, 9, and 10 to the right of the current page as well as pages 1 and 2 at the start and 49 and 50 at the end.
InvalidPageif the given page number doesn’t exist.
- New in Django Development version.
A translatable string used as a substitute for elided page numbers in the page range returned by
get_elided_page_range(). Default is
The total number of objects, across all pages.
When determining the number of objects contained in
Paginatorwill first try calling
Paginatorwill fall back to using
len(object_list). This allows objects, such as
QuerySet, to use a more efficient
count()method when available.
The total number of pages.
A 1-based range iterator of page numbers, e.g. yielding
[1, 2, 3, 4].
Page(object_list, number, paginator)¶
A page acts like a sequence of
len()or iterating it directly.
Trueif there’s a next page.
Trueif there’s a previous page.
Trueif there’s a next or previous page.
Returns the next page number. Raises
InvalidPageif next page doesn’t exist.
Returns the previous page number. Raises
InvalidPageif previous page doesn’t exist.
Returns the 1-based index of the first object on the page, relative to all of the objects in the paginator’s list. For example, when paginating a list of 5 objects with 2 objects per page, the second page’s
A base class for exceptions raised when a paginator is passed an invalid page number.
Paginator.page() method raises an exception if the requested page is
invalid (i.e. not an integer) or contains no objects. Generally, it’s enough
to catch the
InvalidPage exception, but if you’d like more granularity,
you can catch either of the following exceptions:
Both of the exceptions are subclasses of
InvalidPage, so you can handle
them both with