Refs #19973 -- Removed optparse support in management commands per deprecation timeline.

3 files changed, 7 insertions, 64 deletions

diff --git a/docs/howto/custom-management-commands.txt b/docs/howto/custom-management-commands.txt
index d5dd800a94..cc7653dd8e 100644
--- a/docs/howto/custom-management-commands.txt
+++ b/docs/howto/custom-management-commands.txt
@@ -69,16 +69,6 @@ look like this::
 
                 self.stdout.write('Successfully closed poll "%s"' % poll_id)
 
-.. versionchanged:: 1.8
-
-    Before Django 1.8, management commands were based on the :py:mod:`optparse`
-    module, and positional arguments were passed in ``*args`` while optional
-    arguments were passed in ``**options``. Now that management commands use
-    :py:mod:`argparse` for argument parsing, all arguments are passed in
-    ``**options`` by default, unless you name your positional arguments to
-    ``args`` (compatibility mode). You are encouraged to exclusively use
-    ``**options`` for new commands.
-
 .. _management-commands-output:
 
 .. note::
@@ -128,12 +118,6 @@ options can be added in the :meth:`~BaseCommand.add_arguments` method like this:
                 poll.delete()
             # ...
 
-.. versionchanged:: 1.8
-
-    Previously, only the standard :py:mod:`optparse` library was supported and
-    you would have to extend the command ``option_list`` variable with
-    ``optparse.make_option()``.
-
 The option (``delete`` in our example) is available in the options dict
 parameter of the handle method. See the :py:mod:`argparse` Python documentation
 for more about ``add_argument`` usage.
@@ -227,19 +211,6 @@ Attributes
 All attributes can be set in your derived class and can be used in
 :class:`BaseCommand`’s :ref:`subclasses<ref-basecommand-subclasses>`.
 
-.. attribute:: BaseCommand.args
-
-    A string listing the arguments accepted by the command,
-    suitable for use in help messages; e.g., a command which takes
-    a list of application names might set this to '<app_label
-    app_label ...>'.
-
-    .. deprecated:: 1.8
-
-        This should be done now in the :meth:`~BaseCommand.add_arguments()`
-        method, by calling the ``parser.add_argument()`` method. See the
-        ``closepoll`` example above.
-
 .. attribute:: BaseCommand.can_import_settings
 
     A boolean indicating whether the command needs to be able to
@@ -261,17 +232,6 @@ All attributes can be set in your derived class and can be used in
     the message error returned in the case of missing arguments. The default is
     output by :py:mod:`argparse` ("too few arguments").
 
-.. attribute:: BaseCommand.option_list
-
-    This is the list of ``optparse`` options which will be fed
-    into the command's ``OptionParser`` for parsing arguments.
-
-    .. deprecated:: 1.8
-
-        You should now override the :meth:`~BaseCommand.add_arguments` method
-        to add custom arguments accepted by your command. See :ref:`the example
-        above <custom-commands-options>`.
-
 .. attribute:: BaseCommand.output_transaction
 
     A boolean indicating whether the command outputs SQL statements; if
diff --git a/docs/releases/1.8.txt b/docs/releases/1.8.txt
index 1e0c233cba..e6b606505f 100644
--- a/docs/releases/1.8.txt
+++ b/docs/releases/1.8.txt
@@ -738,15 +738,14 @@ Management commands that only accept positional arguments
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 If you have written a custom management command that only accepts positional
-arguments and you didn't specify the
-:attr:`~django.core.management.BaseCommand.args` command variable, you might
-get an error like ``Error: unrecognized arguments: ...``, as variable parsing
-is now based on :py:mod:`argparse` which doesn't implicitly accept positional
+arguments and you didn't specify the ``args`` command variable, you might get
+an error like ``Error: unrecognized arguments: ...``, as variable parsing is
+now based on :py:mod:`argparse` which doesn't implicitly accept positional
 arguments. You can make your command backwards compatible by simply setting the
-:attr:`~django.core.management.BaseCommand.args` class variable. However, if
-you don't have to keep compatibility with older Django versions, it's better to
-implement the new :meth:`~django.core.management.BaseCommand.add_arguments`
-method as described in :doc:`/howto/custom-management-commands`.
+``args`` class variable. However, if you don't have to keep compatibility with
+older Django versions, it's better to implement the new
+:meth:`~django.core.management.BaseCommand.add_arguments` method as described
+in :doc:`/howto/custom-management-commands`.
 
 Custom test management command arguments through test runner
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/docs/topics/testing/advanced.txt b/docs/topics/testing/advanced.txt
index eacc04c6d6..f2a2b103fc 100644
--- a/docs/topics/testing/advanced.txt
+++ b/docs/topics/testing/advanced.txt
@@ -417,10 +417,6 @@ execute and tear down the test suite.
 
     .. versionchanged:: 1.8
 
-        Previously, you had to provide an ``option_list`` attribute to a
-        subclassed test runner to add options to the list of command-line
-        options that the :djadmin:`test` command could use.
-
         The ``keepdb``, ``reverse``, and ``debug_sql`` arguments were added.
 
 Attributes
@@ -448,18 +444,6 @@ Attributes
     By default it is set to ``unittest.defaultTestLoader``. You can override
     this attribute if your tests are going to be loaded in unusual ways.
 
-.. attribute:: DiscoverRunner.option_list
-
-    This is the tuple of ``optparse`` options which will be fed into the
-    management command's ``OptionParser`` for parsing arguments. See the
-    documentation for Python's ``optparse`` module for more details.
-
-    .. deprecated:: 1.8
-
-        You should now override the :meth:`~DiscoverRunner.add_arguments` class
-        method to add custom arguments accepted by the :djadmin:`test`
-        management command.
-
 Methods
 ~~~~~~~