Don't show `self` in the list of arguments of a method.

This is consistent with Python's official documentation
and it's a sphinx recommendation too[1].

[1] http://sphinx-doc.org/markup/desc.html#dir-method

Refs #21855.

docs/howto/custom-model-fields.txt

@@ -421,7 +421,7 @@ approximately decreasing order of importance, so start from the top.
 Custom database types
 ~~~~~~~~~~~~~~~~~~~~~
 
-.. method:: Field.db_type(self, connection)
+.. method:: Field.db_type(connection)
 
 Returns the database column data type for the :class:`~django.db.models.Field`,
 taking into account the connection object, and the settings associated with it.
@@ -510,7 +510,7 @@ get out of the way.
 Converting database values to Python objects
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. method:: Field.to_python(self, value)
+.. method:: Field.to_python(value)
 
 Converts a value as returned by your database (or a serializer) to a Python
 object.
@@ -571,7 +571,7 @@ automatically.
 Converting Python objects to query values
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. method:: Field.get_prep_value(self, value)
+.. method:: Field.get_prep_value(value)
 
 This is the reverse of :meth:`.to_python` when working with the
 database backends (as opposed to serialization). The ``value``
@@ -596,7 +596,7 @@ For example::
 Converting query values to database values
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. method:: Field.get_db_prep_value(self, value, connection, prepared=False)
+.. method:: Field.get_db_prep_value(value, connection, prepared=False)
 
 Some data types (for example, dates) need to be in a specific format
 before they can be used by a database backend.
@@ -612,7 +612,7 @@ already been passed through :meth:`.get_prep_value` conversions. When
 initial data conversions before performing any database-specific
 processing.
 
-.. method:: Field.get_db_prep_save(self, value, connection)
+.. method:: Field.get_db_prep_save(value, connection)
 
 Same as the above, but called when the Field value must be *saved* to
 the database. As the default implementation just calls
@@ -624,7 +624,7 @@ parameters (which is implemented by :meth:`.get_db_prep_value`).
 Preprocessing values before saving
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. method:: Field.pre_save(self, model_instance, add)
+.. method:: Field.pre_save(model_instance, add)
 
 This method is called just prior to :meth:`.get_db_prep_save` and should return
 the value of the appropriate attribute from ``model_instance`` for this field.
@@ -650,7 +650,7 @@ Preparing values for use in database lookups
 As with value conversions, preparing a value for database lookups is a
 two phase process.
 
-.. method:: Field.get_prep_lookup(self, lookup_type, value)
+.. method:: Field.get_prep_lookup(lookup_type, value)
 
 :meth:`.get_prep_lookup` performs the first phase of lookup preparation,
 performing generic data validity checks
@@ -704,7 +704,7 @@ accepted lookup types to ``exact`` and ``in``::
             else:
                 raise TypeError('Lookup type %r not supported.' % lookup_type)
 
-.. method:: Field.get_db_prep_lookup(self, lookup_type, value, connection, prepared=False)
+.. method:: Field.get_db_prep_lookup(lookup_type, value, connection, prepared=False)
 
 Performs any database-specific data conversions required by a lookup.
 As with :meth:`.get_db_prep_value`, the specific connection that will
@@ -715,7 +715,7 @@ prepared with :meth:`.get_prep_lookup`.
 Specifying the form field for a model field
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. method:: Field.formfield(self, form_class=None, choices_form_class=None, **kwargs)
+.. method:: Field.formfield(form_class=None, choices_form_class=None, **kwargs)
 
 Returns the default form field to use when this model field is displayed in a
 form.  This method is called by the :class:`~django.forms.ModelForm` helper.
@@ -755,7 +755,7 @@ fields.
 Emulating built-in field types
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. method:: Field.get_internal_type(self)
+.. method:: Field.get_internal_type()
 
 Returns a string giving the name of the :class:`~django.db.models.Field`
 subclass we are emulating at the database level. This is used to determine the
@@ -790,7 +790,7 @@ output in some other place, outside of Django.
 Converting field data for serialization
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. method:: Field.value_to_string(self, obj)
+.. method:: Field.value_to_string(obj)
 
 This method is used by the serializers to convert the field into a string for
 output. Calling ``Field._get_val_from_obj(obj)`` is the best way to get the

docs/howto/error-reporting.txt

@@ -250,24 +250,24 @@ following methods:
 
 .. class:: SafeExceptionReporterFilter
 
-.. method:: SafeExceptionReporterFilter.is_active(self, request)
+.. method:: SafeExceptionReporterFilter.is_active(request)
 
     Returns ``True`` to activate the filtering operated in the other methods.
     By default the filter is active if :setting:`DEBUG` is ``False``.
 
-.. method:: SafeExceptionReporterFilter.get_request_repr(self, request)
+.. method:: SafeExceptionReporterFilter.get_request_repr(request)
 
     Returns the representation string of the request object, that is, the
     value that would be returned by ``repr(request)``, except it uses the
     filtered dictionary of POST parameters as determined by
     :meth:`SafeExceptionReporterFilter.get_post_parameters`.
 
-.. method:: SafeExceptionReporterFilter.get_post_parameters(self, request)
+.. method:: SafeExceptionReporterFilter.get_post_parameters(request)
 
     Returns the filtered dictionary of POST parameters. By default it replaces
     the values of sensitive parameters with stars (`**********`).
 
-.. method:: SafeExceptionReporterFilter.get_traceback_frame_variables(self, request, tb_frame)
+.. method:: SafeExceptionReporterFilter.get_traceback_frame_variables(request, tb_frame)
 
     Returns the filtered dictionary of local variables for the given traceback
     frame. By default it replaces the values of sensitive variables with stars

docs/ref/contrib/auth.txt

@@ -260,7 +260,7 @@ Manager methods
 
         See :ref:`Creating users <topics-auth-creating-users>` for example usage.
 
-    .. method:: create_superuser(self, username, email, password, **extra_fields)
+    .. method:: create_superuser(username, email, password, **extra_fields)
 
         Same as :meth:`create_user`, but sets :attr:`~models.User.is_staff` and
         :attr:`~models.User.is_superuser` to ``True``.

docs/ref/contrib/gis/gdal.txt

@@ -873,7 +873,7 @@ systems and coordinate transformation::
    A string representing this envelope as a polygon in WKT format.
 
 
-   .. method:: expand_to_include(self, *args)
+   .. method:: expand_to_include(*args)
 
 Coordinate System Objects
 =========================

docs/ref/contrib/syndication.txt

@@ -137,7 +137,7 @@ into those elements.
 
   See `a complex example`_ below that uses a description template.
 
-  .. method:: Feed.get_context_data(self, **kwargs)
+  .. method:: Feed.get_context_data(**kwargs)
 
     .. versionadded:: 1.6
 

docs/ref/forms/widgets.txt

@@ -216,7 +216,7 @@ foundation for custom widgets.
         The 'value' given is not guaranteed to be valid input, therefore
         subclass implementations should program defensively.
 
-    .. method:: value_from_datadict(self, data, files, name)
+    .. method:: value_from_datadict(data, files, name)
 
         Given a dictionary of data and this widget's name, returns the value
         of this widget. Returns ``None`` if a value wasn't provided.

docs/topics/forms/formsets.txt

@@ -167,7 +167,7 @@ As we can see, ``formset.errors`` is a list whose entries correspond to the
 forms in the formset. Validation was performed for each of the two forms, and
 the expected error message appears for the second item.
 
-.. method:: BaseFormSet.total_error_count(self)
+.. method:: BaseFormSet.total_error_count()
 
 .. versionadded:: 1.6
 

docs/topics/http/file-uploads.txt

@@ -386,7 +386,7 @@ Required methods
 
 Custom file upload handlers **must** define the following methods:
 
-.. method:: FileUploadHandler.receive_data_chunk(self, raw_data, start)
+.. method:: FileUploadHandler.receive_data_chunk(raw_data, start)
 
     Receives a "chunk" of data from the file upload.
 
@@ -407,7 +407,7 @@ Custom file upload handlers **must** define the following methods:
     If you raise a ``StopUpload`` or a ``SkipFile`` exception, the upload
     will abort or the file will be completely skipped.
 
-.. method:: FileUploadHandler.file_complete(self, file_size)
+.. method:: FileUploadHandler.file_complete(file_size)
 
     Called when a file has finished uploading.
 
@@ -434,7 +434,7 @@ attributes:
 
     The default is 64*2\ :sup:`10` bytes, or 64 KB.
 
-.. method:: FileUploadHandler.new_file(self, field_name, file_name, content_type, content_length, charset, content_type_extra)
+.. method:: FileUploadHandler.new_file(field_name, file_name, content_type, content_length, charset, content_type_extra)
 
     Callback signaling that a new file upload is starting. This is called
     before any data has been fed to any upload handlers.
@@ -463,11 +463,11 @@ attributes:
 
         The ``content_type_extra`` parameter was added.
 
-.. method:: FileUploadHandler.upload_complete(self)
+.. method:: FileUploadHandler.upload_complete()
 
     Callback signaling that the entire upload (all files) has completed.
 
-.. method:: FileUploadHandler.handle_raw_input(self, input_data, META, content_length, boundary, encoding)
+.. method:: FileUploadHandler.handle_raw_input(input_data, META, content_length, boundary, encoding)
 
     Allows the handler to completely override the parsing of the raw
     HTTP input.

docs/topics/http/middleware.txt

@@ -85,7 +85,7 @@ Python class that defines one or more of the following methods:
 ``process_request``
 -------------------
 
-.. method:: process_request(self, request)
+.. method:: process_request(request)
 
 ``request`` is an :class:`~django.http.HttpRequest` object.
 
@@ -106,7 +106,7 @@ return the result.
 ``process_view``
 ----------------
 
-.. method:: process_view(self, request, view_func, view_args, view_kwargs)
+.. method:: process_view(request, view_func, view_args, view_kwargs)
 
 ``request`` is an :class:`~django.http.HttpRequest` object. ``view_func`` is
 the Python function that Django is about to use. (It's the actual function
@@ -146,7 +146,7 @@ view; it'll apply response middleware to that
 ``process_template_response``
 -----------------------------
 
-.. method:: process_template_response(self, request, response)
+.. method:: process_template_response(request, response)
 
 ``request`` is an :class:`~django.http.HttpRequest` object. ``response`` is
 the :class:`~django.template.response.TemplateResponse` object (or equivalent)
@@ -173,7 +173,7 @@ includes ``process_template_response()``.
 ``process_response``
 --------------------
 
-.. method:: process_response(self, request, response)
+.. method:: process_response(request, response)
 
 ``request`` is an :class:`~django.http.HttpRequest` object. ``response`` is
 the :class:`~django.http.HttpResponse` or
@@ -230,7 +230,7 @@ must test for streaming responses and adjust their behavior accordingly::
 ``process_exception``
 ---------------------
 
-.. method:: process_exception(self, request, exception)
+.. method:: process_exception(request, exception)
 
 ``request`` is an :class:`~django.http.HttpRequest` object. ``exception`` is an
 ``Exception`` object raised by the view function.

docs/topics/testing/tools.txt

@@ -1241,7 +1241,7 @@ your test suite.
     failure. Similar to unittest's :meth:`~unittest.TestCase.assertRaisesRegexp`
     with the difference that ``expected_message`` isn't a regular expression.
 
-.. method:: SimpleTestCase.assertFieldOutput(self, fieldclass, valid, invalid, field_args=None, field_kwargs=None, empty_value=u'')
+.. method:: SimpleTestCase.assertFieldOutput(fieldclass, valid, invalid, field_args=None, field_kwargs=None, empty_value=u'')
 
     Asserts that a form field behaves correctly with various inputs.