Opened 7 years ago

Closed 4 years ago

#9195 closed Bug (fixed) should raise PageNotAnInteger when given a NoneType value

Reported by: thomas@… Owned by: nobody
Component: Documentation Version: 1.0
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


The documentation suggests that raises PageNotAnInteger for non-integer values, however passing it None raises a TypeError. I would imagine this is a fairly common use case. If a URL optionally has a search string that specifies a page number (eg. ?page=3) you would want to pass request.GET.get('page') to However, if the request lacks the search string, page() should logically return the PageNotAnInteger exception.

>>> from django.core.paginator import Paginator
>>> objects = ['john', 'paul', 'george', 'ringo']
>>> p = Paginator(objects, 2)
<Page 1 of 2>
>>>"Pete Best")
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/home2/ether2/webapps/migration/lib/python2.5/django/core/", line 37, in page
    number = self.validate_number(number)
  File "/home2/ether2/webapps/migration/lib/python2.5/django/core/", line 25, in validate_number
    raise PageNotAnInteger('That page number is not an integer')
PageNotAnInteger: That page number is not an integer
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/home2/ether2/webapps/migration/lib/python2.5/django/core/", line 37, in page
    number = self.validate_number(number)
  File "/home2/ether2/webapps/migration/lib/python2.5/django/core/", line 23, in validate_number
    number = int(number)
TypeError: int() argument must be a string or a number, not 'NoneType'

Change History (7)

comment:1 Changed 7 years ago by kmtracey

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

I'm not sure this is such a common thing, I think it is more likely that programmers have protected against 'page' not being in the search string by specifying a sensible default on the get, e.g. request.GET.get('page', 1). Technically changing the exception raised would be backwards-incompatible (though I doubt anyone has written code that depends on this behavior...still, it's impossible to know for sure). I'd be inclined to adjust the doc instead of the code to address this.

comment:2 Changed 7 years ago by anonymous

  • milestone post-1.0 deleted

Milestone post-1.0 deleted

comment:3 Changed 7 years ago by thejaswi_puthraya

  • Component changed from Uncategorized to Core framework

comment:4 Changed 5 years ago by julien

  • Component changed from Core framework to Documentation

I agree with Karen and therefore change the component of this ticket to address this case in the documentation.

comment:5 Changed 5 years ago by gabrielhurley

  • Triage Stage changed from Design decision needed to Accepted

Bumping to accepted from DDN. Correcting this in the docs is fine with me.

comment:6 Changed 5 years ago by lukeplant

  • Severity set to Normal
  • Type set to Bug

comment:7 Changed 4 years ago by Horst Gutmann <zerok@…>

  • Easy pickings unset
  • Resolution set to fixed
  • Status changed from new to closed
  • UI/UX unset

This was already addressed by SmileyChris in [16026] with a change to the Paginator.validate_number method which now raises a PageNotAnInteger exception on ValueError as well as on TypeError.

Note: See TracTickets for help on using tickets.
Back to Top