Refs #36485 -- Removed unnecessary parentheses in :meth: and :func: roles in docs.

docs/topics/http/sessions.txt

@@ -253,7 +253,7 @@ You can edit it multiple times.
       Deletes the current session data from the session and deletes the session
       cookie. This is used if you want to ensure that the previous session data
       can't be accessed again from the user's browser (for example, the
-      :func:`django.contrib.auth.logout()` function calls it).
+      :func:`django.contrib.auth.logout` function calls it).
 
     .. method:: set_test_cookie()
     .. method:: aset_test_cookie()
@@ -380,7 +380,7 @@ You can edit it multiple times.
       *Asynchronous version*: ``acycle_key()``
 
       Creates a new session key while retaining the current session data.
-      :func:`django.contrib.auth.login()` calls this method to mitigate against
+      :func:`django.contrib.auth.login` calls this method to mitigate against
       session fixation.
 
 .. _session_serialization:
@@ -519,7 +519,7 @@ is necessary due to the way cookies work. When you set a cookie, you can't
 actually tell whether a browser accepted it until the browser's next request.
 
 It's good practice to use
-:meth:`~backends.base.SessionBase.delete_test_cookie()` to clean up after
+:meth:`~backends.base.SessionBase.delete_test_cookie` to clean up after
 yourself. Do this after you've verified that the test cookie worked.
 
 Here's a typical usage example::
@@ -589,7 +589,7 @@ access sessions using the normal Django database API:
     datetime.datetime(2005, 8, 20, 13, 35, 12)
 
 Note that you'll need to call
-:meth:`~base_session.AbstractBaseSession.get_decoded()` to get the session
+:meth:`~base_session.AbstractBaseSession.get_decoded` to get the session
 dictionary. This is necessary because the dictionary is stored in an encoded
 format:
 

docs/topics/http/shortcuts.txt

@@ -23,7 +23,7 @@ introduce controlled coupling for convenience's sake.
    Django does not provide a shortcut function which returns a
    :class:`~django.template.response.TemplateResponse` because the constructor
    of :class:`~django.template.response.TemplateResponse` offers the same level
-   of convenience as :func:`render()`.
+   of convenience as :func:`render`.
 
 Required arguments
 ------------------
@@ -98,7 +98,7 @@ This example is equivalent to::
 
    The arguments could be:
 
-   * A model: the model's :meth:`~django.db.models.Model.get_absolute_url()`
+   * A model: the model's :meth:`~django.db.models.Model.get_absolute_url`
      function will be called.
 
    * A view name, possibly with arguments: :func:`~django.urls.reverse` will be
@@ -196,7 +196,7 @@ original HTTP method::
 
     *Asynchronous version*: ``aget_object_or_404()``
 
-    Calls :meth:`~django.db.models.query.QuerySet.get()` on a given model
+    Calls :meth:`~django.db.models.query.QuerySet.get` on a given model
     manager, but it raises :class:`~django.http.Http404` instead of the model's
     :class:`~django.db.models.Model.DoesNotExist` exception.
 
@@ -277,7 +277,7 @@ will be raised if more than one object is found.
 
     *Asynchronous version*: ``aget_list_or_404()``
 
-    Returns the result of :meth:`~django.db.models.query.QuerySet.filter()` on
+    Returns the result of :meth:`~django.db.models.query.QuerySet.filter` on
     a given model manager cast to a list, raising :class:`~django.http.Http404`
     if the resulting list is empty.
 

docs/topics/http/urls.txt

@@ -377,7 +377,7 @@ itself. It includes a number of other URLconfs::
         # ... snip ...
     ]
 
-Whenever Django encounters :func:`~django.urls.include()`, it chops off
+Whenever Django encounters :func:`~django.urls.include`, it chops off
 whatever part of the URL matched up to that point and sends the remaining
 string to the included URLconf for further processing.
 
@@ -658,7 +658,7 @@ characters you like. You are not restricted to valid Python names.
 When naming URL patterns, choose names that are unlikely to clash with other
 applications' choice of names. If you call your URL pattern ``comment``
 and another application does the same thing, the URL that
-:func:`~django.urls.reverse()` finds depends on whichever pattern is last in
+:func:`~django.urls.reverse` finds depends on whichever pattern is last in
 your project's ``urlpatterns`` list.
 
 Putting a prefix on your URL names, perhaps derived from the application
@@ -670,12 +670,12 @@ want to override a view. For example, a common use case is to override the
 :class:`~django.contrib.auth.views.LoginView`. Parts of Django and most
 third-party apps assume that this view has a URL pattern with the name
 ``login``. If you have a custom login view and give its URL the name ``login``,
-:func:`~django.urls.reverse()` will find your custom view as long as it's in
+:func:`~django.urls.reverse` will find your custom view as long as it's in
 ``urlpatterns`` after ``django.contrib.auth.urls`` is included (if that's
 included at all).
 
 You may also use the same name for multiple URL patterns if they differ in
-their arguments. In addition to the URL name, :func:`~django.urls.reverse()`
+their arguments. In addition to the URL name, :func:`~django.urls.reverse`
 matches the number of arguments and the names of the keyword arguments. Path
 converters can also raise ``ValueError`` to indicate no match, see
 :ref:`registering-custom-path-converters` for details.
@@ -743,7 +743,7 @@ the fully qualified name into parts and then tries the following lookup:
 
 #. If there is a current application defined, Django finds and returns the URL
    resolver for that instance. The current application can be specified with
-   the ``current_app`` argument to the :func:`~django.urls.reverse()`
+   the ``current_app`` argument to the :func:`~django.urls.reverse`
    function.
 
    The :ttag:`url` template tag uses the namespace of the currently resolved