The documentation suggests that Paginator.page() 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 Paginator.page. 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)
>>> p.page(1)
<Page 1 of 2>
>>> p.page("Pete Best")
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/home2/ether2/webapps/migration/lib/python2.5/django/core/paginator.py", line 37, in page
number = self.validate_number(number)
File "/home2/ether2/webapps/migration/lib/python2.5/django/core/paginator.py", line 25, in validate_number
raise PageNotAnInteger('That page number is not an integer')
PageNotAnInteger: That page number is not an integer
>>> p.page(None)
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/home2/ether2/webapps/migration/lib/python2.5/django/core/paginator.py", line 37, in page
number = self.validate_number(number)
File "/home2/ether2/webapps/migration/lib/python2.5/django/core/paginator.py", line 23, in validate_number
number = int(number)
TypeError: int() argument must be a string or a number, not 'NoneType'
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.