Copy edit of TorchScript Language Reference (#57694)

Summary:
Initial copy edit of the file.

Pull Request resolved: https://github.com/pytorch/pytorch/pull/57694

Reviewed By: malfet, ngimel

Differential Revision: D28289209

Pulled By: holly1238

fbshipit-source-id: 7035d6790767a2f758e6019ae63df16537ef2725
diff --git a/docs/source/jit_language_reference_v2.rst b/docs/source/jit_language_reference_v2.rst
index d6c04b5..49abb60 100644
--- a/docs/source/jit_language_reference_v2.rst
+++ b/docs/source/jit_language_reference_v2.rst
@@ -1,8 +1,3 @@
-.. contents::
-    :local:
-    :depth: 2
-
-
 .. testsetup::
 
     # These are hidden from the docs, but these are necessary for `doctest`
@@ -29,12 +24,16 @@
 TorchScript Language Reference
 ==============================
 
-This TorchScript Language reference manual describes the syntax and core semantics of the TorchScript language.
-TorchScript is a statically typed subset of Python language. This document attempts to explain the supported features of
-Python in TorchScript and also how the language diverges from regular Python. Any features of Python not mentioned in
-this reference are not part of TorchScript. TorchScript focuses specifically on the features of Python that are needed to
+This reference manual describes the syntax and core semantics of the TorchScript language.
+TorchScript is a statically typed subset of the Python language. This document explains the supported features of
+Python in TorchScript and also how the language diverges from regular Python. Any features of Python that are not mentioned in
+this reference manual are not part of TorchScript. TorchScript focuses specifically on the features of Python that are needed to
 represent neural network models in PyTorch.
 
+.. contents::
+    :local:
+    :depth: 1
+
 .. _type_system:
 
 Terminology
@@ -49,19 +48,19 @@
    * - Pattern
      - Notes
    * - ``::=``
-     - indicates the given symbol is defined as.
+     - Indicates that the given symbol is defined as.
    * - ``" "``
-     - represents real keywords and delimiters that are part of the syntax
+     - Represents real keywords and delimiters that are part of the syntax.
    * - ``A | B``
-     - indicates either A or B
+     - Indicates either A or B.
    * - ``( )``
-     - indicates grouping
+     - Indicates grouping.
    * - ``[]``
-     - indicates optional
+     - Indicates optional.
    * - ``A+``
-     - indicates a regular expression where term A is repeated at least once
+     - Indicates a regular expression where term A is repeated at least once.
    * - ``A*``
-     - indicates a regular expression where term A is repeated zero or more times
+     - Indicates a regular expression where term A is repeated zero or more times.
 
 Type System
 ~~~~~~~~~~~
@@ -78,13 +77,13 @@
     TSAllType ::= TSType | TSModuleType
     TSType    ::= TSMetaType | TSPrimitiveType | TSStructuralType | TSNominalType
 
-``TSType`` represents the majority of TorchScript types that are composable and can be used in TorchScript type annotations.
+``TSType`` represents the majority of TorchScript types that are composable and that can be used in TorchScript type annotations.
 ``TSType`` refers to any of the following:
 
 * Meta Types, e.g., ``Any``
-* Primitive Types, e.g., ``int``, ``float``, ``str``
+* Primitive Types, e.g., ``int``, ``float``, and ``str``
 * Structural Types, e.g., ``Optional[int]`` or ``List[MyClass]``
-* Nominal Types (Python classes), e.g., ``MyClass`` (user-defined), ``torch.tensor`` (builtin)
+* Nominal Types (Python classes), e.g., ``MyClass`` (user-defined), ``torch.tensor`` (built-in)
 
 ``TSModuleType`` represents ``torch.nn.Module`` and its subclasses. It is treated differently from ``TSType`` because its type schema is inferred partly from the object instance and partly from the class definition.
 As such, instances of a ``TSModuleType`` may not follow the same static type schema. ``TSModuleType`` cannot be used as a TorchScript type annotation or be composed with ``TSType`` for type safety considerations.
@@ -98,42 +97,42 @@
 ``Any`` Type
 """"""""""""
 
-The ``Any`` type represents any TorchScript type. ``Any`` specifies no type constraints, thus there is no type checking on ``Any``.
-As such it can be bound to any Python or TorchScript data types (e.g., int, TorchScript ``tuple``, or an arbitrary Python class that is not scripted).
+The ``Any`` type represents any TorchScript type. ``Any`` specifies no type constraints, thus there is no type-checking on ``Any``.
+As such it can be bound to any Python or TorchScript data types (e.g., ``int``, TorchScript ``tuple``, or an arbitrary Python class that is not scripted).
 
 ::
 
     TSMetaType ::= "Any"
 
-where
+Where:
 
-* ``Any`` is the Python class name from the typing module, therefore usage of the ``Any`` type requires from ``typing import Any``
-* Since ``Any`` can represent any TorchScript type, the set of operators allowed to operate on values of this type on Any is limited.
+* ``Any`` is the Python class name from the typing module. Therefore, to use the ``Any`` type, you must import it from ``typing`` (e.g., ``from typing import Any``).
+* Since ``Any`` can represent any TorchScript type, the set of operators that are allowed to operate on values of this type on ``Any`` is limited.
 
-Operators supported for ``Any`` type
+Operators Supported for ``Any`` Type
 """"""""""""""""""""""""""""""""""""
 
-* assignment to data of ``Any`` type
-* binding to parameter or return of ``Any`` type
-* ``x is``, ``x is not`` where ``x`` is of ``Any`` type
-* ``isinstance(x, Type)`` where ``x`` is of ``Any`` type
-* data of ``Any`` type is printable
-* Data of ``List[Any]`` type may be sortable if the data is a list of values of the same type ``T`` and that ``T`` supports comparison operators
+* Assignment to data of ``Any`` type.
+* Binding to parameter or return of ``Any`` type.
+* ``x is``, ``x is not`` where ``x`` is of ``Any`` type.
+* ``isinstance(x, Type)`` where ``x`` is of ``Any`` type.
+* Data of ``Any`` type is printable.
+* Data of ``List[Any]`` type may be sortable if the data is a list of values of the same type ``T`` and that ``T`` supports comparison operators.
 
 **Compared to Python**
 
 
-``Any`` is the least constrained type in the TorchScript type system. In that sense, it is quite similar to
-``Object`` class in Python. However, ``Any`` only supports a subset of the operators and methods that are supported by Object.
+``Any`` is the least constrained type in the TorchScript type system. In that sense, it is quite similar to the
+``Object`` class in Python. However, ``Any`` only supports a subset of the operators and methods that are supported by ``Object``.
 
-Design notes
+Design Notes
 """"""""""""
 
-When we script a PyTorch module, we may encounter data that are not involved in the execution of the script, nevertheless has to be described
-by a type schema. It is not only cumbersome to describe static types for unused data (in the context of the script) but also may lead to unnecessary
+When we script a PyTorch module, we may encounter data that is not involved in the execution of the script. Nevertheless, it has to be described
+by a type schema. It is not only cumbersome to describe static types for unused data (in the context of the script), but also may lead to unnecessary
 scripting failures. ``Any`` is introduced to describe the type of the data where precise static types are not necessary for compilation.
 
-**Example**
+**Example 1**
 
 This example illustrates how ``Any`` can be used to allow the second element of the tuple parameter to be of any type. This is possible
 because ``x[1]`` is not involved in any computation that requires knowing its precise type.
@@ -153,18 +152,21 @@
     print(m((1,2.0)))
     print(m((1,(100,200))))
 
-The example will generate the following output, where the second element of the tuple is of ``Any`` type
-thus can bind to multiple types, e.g., (1, 2.0) binds a float type to ``Any`` as in ``Tuple[int, Any]``,
-whereas ``(1, (100, 200))`` binds a tuple to ``Any`` in the second invocation.
+The example above produces the following output:
 
 .. testoutput::
 
     (2, 2.0)
     (2, (100, 200))
 
-**Example**
+The second element of the tuple is of ``Any`` type, thus can bind to multiple types.
+For example, ``(1, 2.0)`` binds a float type to ``Any`` as in ``Tuple[int, Any]``,
+whereas ``(1, (100, 200))`` binds a tuple to ``Any`` in the second invocation.
 
-We can use ``isinstance`` to dynamically check the type of the data annotated as ``Any`` type.
+
+**Example 2**
+
+This example illustrates how we can use ``isinstance`` to dynamically check the type of the data that is annotated as ``Any`` type:
 
 .. testcode::
 
@@ -179,7 +181,7 @@
     m = torch.jit.script(f)
     print(m(ones))
 
-The above example produces the following output
+The example above produces the following output:
 
 .. testoutput::
 
@@ -191,7 +193,7 @@
 Primitive Types
 ^^^^^^^^^^^^^^^
 
-Primitive TorchScript types represent types that represent a single type of value and go with a single pre-defined
+Primitive TorchScript types are types that represent a single type of value and go with a single pre-defined
 type name.
 
 ::
@@ -218,20 +220,19 @@
     TSDict           ::= "Dict" "[" KeyType "," TSType "]"
     KeyType          ::= "str" | "int" | "float" | "bool" | TensorType | "Any"
 
-where
+Where:
 
-* ``Tuple``, ``List``, ``Optional``, ``Union``, ``Future``, ``Dict`` represent Python type class names defined in module ``typing``. Therefore before using these type names, one must import them from ``typing`` (e.g., ``from typing import Tuple)``.
-* ``namedtuple`` represents Python class  ``collections.namedtuple`` or ``typing.NamedTuple`` .
-* ``Future`` and ``RRef`` represent Python classes  ``torch.futures``, ``torch.distributed.rpc``.
+* ``Tuple``, ``List``, ``Optional``, ``Union``, ``Future``, ``Dict`` represent Python type class names that are defined in the module ``typing``. To use these type names, you must import them from ``typing`` (e.g., ``from typing import Tuple``).
+* ``namedtuple`` represents the Python class ``collections.namedtuple`` or ``typing.NamedTuple``.
+* ``Future`` and ``RRef`` represent the Python classes ``torch.futures`` and ``torch.distributed.rpc``.
 
 **Compared to Python**
 
+Apart from being composable with TorchScript types, these TorchScript structural types often support a common subset of the operators and methods of their Python counterparts.
 
-* Apart from being composable with TorchScript types, these TorchScript structural types often support a common subset of the operators and methods of their Python counterparts.
+**Example 1**
 
-**Example**
-
-This example uses ``typing.NamedTuple`` syntax:
+This example uses ``typing.NamedTuple`` syntax to define a tuple:
 
 .. testcode::
 
@@ -250,11 +251,15 @@
     scripted_inc = torch.jit.script(inc)
     print("TorchScript:", scripted_inc(t))
 
+The example above produces the following output:
+
 .. testoutput::
 
     TorchScript: (2, 3)
 
-This example uses ``collections.namedtuple`` syntax:
+**Example 2**
+
+This example uses ``collections.namedtuple`` syntax to define a tuple:
 
 .. testcode::
 
@@ -272,14 +277,16 @@
     m = torch.jit.script(inc)
     print(inc(_UnannotatedNamedTuple(1,2)))
 
+The example above produces the following output:
+
 .. testoutput::
 
     (2, 3)
 
-**Example**
+**Example 3**
 
 This example illustrates a common mistake of annotating structural types, i.e., not importing the composite type
-classes from the ``typing`` module.
+classes from the ``typing`` module:
 
 ::
 
@@ -293,7 +300,7 @@
     m = torch.jit.script(inc)
     print(m((1,2)))
 
-Running the above codes yields the following scripting error. The remedy is to add ``from typing import Tuple``.
+Running the above code yields the following scripting error:
 
 ::
 
@@ -301,23 +308,25 @@
         def inc(x: Tuple[int, int]):
     NameError: name 'Tuple' is not defined
 
+The remedy is to add the line ``from typing import Tuple`` to the beginning of the code.
+
 Nominal Types
 ^^^^^^^^^^^^^
 
-Nominal TorchScript types are Python classes. They are called nominal because these types are declared with a custom
+Nominal TorchScript types are Python classes. These types are called nominal because they are declared with a custom
 name and are compared using class names. Nominal classes are further classified into the following categories:
 
 ::
 
     TSNominalType ::= TSBuiltinClasses | TSCustomClass | TSEnum
 
-Among them, ``TSCustomClass`` and ``TSEnum`` must be compilable to TorchScript IR (as enforced by the type-checker).
+Among them, ``TSCustomClass`` and ``TSEnum`` must be compilable to TorchScript Intermediate Representation (IR). This is enforced by the type-checker.
 
-Builtin Class
-^^^^^^^^^^^^^
+Built-in Class
+^^^^^^^^^^^^^^
 
-Builtin nominal types are Python classes whose semantics are built into the TorchScript system, such as tensor types.
-TorchScript defines the semantics of these builtin nominal types, and often supports only a subset of the methods or
+Built-in nominal types are Python classes whose semantics are built into the TorchScript system (e.g., tensor types).
+TorchScript defines the semantics of these built-in nominal types, and often supports only a subset of the methods or
 attributes of its Python class definition.
 
 ::
@@ -328,17 +337,19 @@
                        "torch.nn.parameter.Parameter" | and subclasses of torch.Tensor
 
 
-Special note on torch.nn.ModuleList and torch.nn.ModuleDict
+Special Note on torch.nn.ModuleList and torch.nn.ModuleDict
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
 Although ``torch.nn.ModuleList`` and ``torch.nn.ModuleDict`` are defined as a list and dictionary in Python,
-they behave more like tuples in TorchScript.
+they behave more like tuples in TorchScript:
 
 * In TorchScript, instances of ``torch.nn.ModuleList``  or ``torch.nn.ModuleDict`` are immutable.
 * Code that iterates over ``torch.nn.ModuleList`` or ``torch.nn.ModuleDict`` is completely unrolled so that elements of ``torch.nn.ModuleList`` or keys of ``torch.nn.ModuleDict`` can be of different subclasses of ``torch.nn.Module``.
 
 **Example**
 
+The following example highlights the use of a few built-in Torchscript classes (``torch.*``):
+
 ::
 
     import torch
@@ -371,26 +382,26 @@
                     [ "@torch.jit.ignore" ] | [ "@torch.jit.unused" ]
                         MethodDefinition
 
-where
+Where:
 
-* Classes must be new-style classes (note that Python 3 supports only new-style classes, for Python 2.x new-style class is specified by subclassing from object)
-* Instance data attributes are statically typed, and instance attributes must be declared by assignments inside the ``__init__()`` method
-* Method overloading is not supported (i.e., cannot have multiple methods with the same method name)
-* MethodDefinition must be compilable to TorchScript IR and adhere to TorchScript’s type-checking rules, (e.g., all methods must be valid TorchScript functions and class attribute definitions must be valid TorchScript statements)
-* ``torch.jit.ignore`` and ``torch.jit.unused`` can be used to ignore the method or function that is not fully torchscriptable or should be ignored by the compiler
+* Classes must be new-style classes. Python 3 supports only new-style classes. In Python 2.x, a new-style class is specified by subclassing from the object.
+* Instance data attributes are statically typed, and instance attributes must be declared by assignments inside the ``__init__()`` method.
+* Method overloading is not supported (i.e., you cannot have multiple methods with the same method name).
+* ``MethodDefinition`` must be compilable to TorchScript IR and adhere to TorchScript’s type-checking rules, (i.e., all methods must be valid TorchScript functions and class attribute definitions must be valid TorchScript statements).
+* ``torch.jit.ignore`` and ``torch.jit.unused`` can be used to ignore the method or function that is not fully torchscriptable or should be ignored by the compiler.
 
 **Compared to Python**
 
 
-TorchScript custom classes are quite limited compared to their Python counterpart.
+TorchScript custom classes are quite limited compared to their Python counterpart. Torchscript custom classes:
 
-* do not support class attributes
-* do not support subclassing except for subclassing an interface type or object
-* do not support method overloading
-* must initialize all its instance attributes in  ``__init__()``; this is because TorchScript constructs a static schema of the class by inferring attribute types in ``__init__()``
-* must contain only methods that satisfy TorchScript type-checking rules and are compilable to TorchScript IRs
+* Do not support class attributes.
+* Do not support subclassing except for subclassing an interface type or object.
+* Do not support method overloading.
+* Must initialize all its instance attributes in  ``__init__()``; this is because TorchScript constructs a static schema of the class by inferring attribute types in ``__init__()``.
+* Must contain only methods that satisfy TorchScript type-checking rules and are compilable to TorchScript IRs.
 
-**Example**
+**Example 1**
 
 Python classes can be used in TorchScript if they are annotated with ``@torch.jit.script``, similar to how a TorchScript function would be declared:
 
@@ -405,7 +416,7 @@
             self.x += val
 
 
-**Example**
+**Example 2**
 
 A TorchScript custom class type must "declare" all its instance attributes by assignments in ``__init__()``. If an instance attribute is not defined in ``__init__()`` but accessed in other methods of the class, the class cannot be compiled as a TorchScript class, as shown in the following example:
 
@@ -422,7 +433,7 @@
     def assign_x(self):
         self.x = torch.rand(2, 3)
 
-The above class will fail to compile and issue the following error:
+The class will fail to compile and issue the following error:
 
 ::
 
@@ -432,9 +443,9 @@
         self.x = torch.rand(2, 3)
         ~~~~~~~~~~~~~~~~~~~~~~~~ <--- HERE
 
-**Example**
+**Example 3**
 
-In this example, a TorchScript custom class defines a class variable name, which is not allowed.
+In this example, a TorchScript custom class defines a class variable name, which is not allowed:
 
 ::
 
@@ -463,7 +474,7 @@
 Enum Type
 ^^^^^^^^^
 
-Like custom classes, semantics of enum type are user-defined and the entire class definition must be compilable to TorchScript IR and adhere to TorchScript type-checking rules.
+Like custom classes, semantics of the enum type are user-defined and the entire class definition must be compilable to TorchScript IR and adhere to TorchScript type-checking rules.
 
 ::
 
@@ -471,19 +482,21 @@
                    ( MemberIdentifier "=" Value )+
                    ( MethodDefinition )*
 
-where
+Where:
 
-* Value must be a TorchScript literal of type ``int``, ``float``, or ``str``, and must be of the same TorchScript type
+* Value must be a TorchScript literal of type ``int``, ``float``, or ``str``, and must be of the same TorchScript type.
 * ``TSEnumType`` is the name of a TorchScript enumerated type. Similar to Python enum, TorchScript allows restricted ``Enum`` subclassing, that is, subclassing an enumerated is allowed only if it does not define any members.
 
 **Compared to Python**
 
 
-* TorchScript supports only ``enum.Enum``, but not other variations such as ``enum.IntEnum``, ``enum.Flag``, ``enum.IntFlag``, or  ``enum.auto``
-* Values of TorchScript enum members must be of the same type and can only be of ``int``, ``float``, or ``str`` type, whereas Python enum members can be of any type
+* TorchScript supports only ``enum.Enum``. It does not support other variations such as ``enum.IntEnum``, ``enum.Flag``, ``enum.IntFlag``, and ``enum.auto``.
+* Values of TorchScript enum members must be of the same type and can only be ``int``, ``float``, or ``str`` types, whereas Python enum members can be of any type.
 * Enums containing methods are ignored in TorchScript.
 
-**Example**
+**Example 1**
+
+The following example defines the class ``Color`` as an ``Enum`` type:
 
 ::
 
@@ -504,9 +517,9 @@
     print("Eager: ", enum_fn(Color.RED, Color.GREEN))
     print("TorchScript: ", m(Color.RED, Color.GREEN))
 
-**Example**
+**Example 2**
 
-The following example shows the case of restricted enum subclassing, where ``BaseColor`` does not define any member, thus can be subclassed by ``Color``.
+The following example shows the case of restricted enum subclassing, where ``BaseColor`` does not define any member, thus can be subclassed by ``Color``:
 
 ::
 
@@ -524,39 +537,46 @@
     def enum_fn(x: Color, y: Color) -> bool:
         if x == Color.RED:
             return True
-
         return x == y
 
     m = torch.jit.script(enum_fn)
+
     print("TorchScript: ", m(Color.RED, Color.GREEN))
     print("Eager: ", enum_fn(Color.RED, Color.GREEN))
 
 TorchScript Module Class
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
-``TSModuleType`` is a special class type that is inferred from object instances created outside TorchScript. ``TSModuleType`` is named by the Python class of the object instance. The ``__init__()`` method of the Python class is not considered as a TorchScript method, so it does not have to comply with TorchScript’s type checking rules.
+``TSModuleType`` is a special class type that is inferred from object instances that are created outside TorchScript. ``TSModuleType`` is named by the Python class of the object instance. The ``__init__()`` method of the Python class is not considered a TorchScript method, so it does not have to comply with TorchScript’s type-checking rules.
 
-Since the type schema of module instance class is constructed directly from an instance object (created outside the scope of TorchScript), rather than inferred from ``__init__()`` like custom classes. It is possible that two objects of the same instance class type follow two different type schemas.
+The type schema of a module instance class is constructed directly from an instance object (created outside the scope of TorchScript) rather than inferred from ``__init__()`` like custom classes. It is possible that two objects of the same instance class type follow two different type schemas.
 
 In this sense, ``TSModuleType`` is not really a static type. Therefore, for type safety considerations, ``TSModuleType`` cannot be used in a TorchScript type annotation or be composed with ``TSType``.
 
 Module Instance Class
 ^^^^^^^^^^^^^^^^^^^^^
 
-TorchScript module type represents type schema of a user-defined PyTorch module instance.  When scripting a PyTorch module, the module object is always created outside TorchScript (i.e., passed in as parameter to ``forward``), The Python module class is treated as a module instance class, so the ``__init__()`` method of the Python module class is not subject to the type checking rules of TorchScript.
+TorchScript module type represents the type schema of a user-defined PyTorch module instance.  When scripting a PyTorch module, the module object is always created outside TorchScript (i.e., passed in as parameter to ``forward``). The Python module class is treated as a module instance class, so the ``__init__()`` method of the Python module class is not subject to the type-checking rules of TorchScript.
 
 ::
 
     TSModuleType ::= "class" Identifier "(torch.nn.Module)" ":"
                         ClassBodyDefinition
 
-where
+Where:
 
-* ``forward()`` and other methods decorated with ``@torch.jit.export`` must be compilable to TorchScript IR and subject to TorchScript’s type checking rules
+* ``forward()`` and other methods decorated with ``@torch.jit.export`` must be compilable to TorchScript IR and subject to TorchScript’s type-checking rules.
 
 Unlike custom classes, only the forward method and other methods decorated with ``@torch.jit.export``  of the module type need to be compilable. Most notably, ``__init__()`` is not considered a TorchScript method. Consequently, module type constructors cannot be invoked within the scope of TorchScript. Instead, TorchScript module objects are always constructed outside and passed into ``torch.jit.script(ModuleObj)``.
 
-**Example**
+**Example 1**
+
+This example illustrates a few features of module types:
+
+*  The ``TestModule`` instance is created outside the scope of TorchScript (i.e., before invoking ``torch.jit.script``).
+* ``__init__()`` is not considered a TorchScript method, therefore, it does not have to be annotated and can contain arbitrary Python code. In addition, the ``__init__()`` method of an instance class cannot be invoked in TorchScript code. Because ``TestModule`` instances are instantiated in Python, in this example, ``TestModule(2.0)`` and ``TestModule(2)`` create two instances with different types for its data attributes. ``self.x`` is of type ``float`` for ``TestModule(2.0)``, whereas ``self.y`` is of type ``int`` for ``TestModule(2.0)``.
+* TorchScript automatically compiles other methods (e.g., ``mul()``) invoked by methods annotated via ``@torch.jit.export`` or ``forward()`` methods.
+* Entry-points to a TorchScript program are either ``forward()`` of a module type, functions annotated as ``torch.jit.script``, or methods annotated as ``torch.jit.export``.
 
 .. testcode::
 
@@ -576,21 +596,16 @@
     m = torch.jit.script(TestModule(torch.ones([5])))
     print(f"Second instance: {m(3)}")
 
+The example above produces the following output:
+
 .. testoutput::
 
     First instance: 4
     Second instance: tensor([4., 4., 4., 4., 4.])
 
-This example illustrates a few features of module types:
+**Example 2**
 
-*  The ``TestModule`` instance is created outside the scope of TorchScript (i.e., before invoking ``torch.jit.script``).
-* ``__init__()`` is not considered to be a TorchScript method, therefore it does not have to be annotated and can contain arbitrary Python code. In addition, the ``__init__()`` method of an instance class cannot be invoked in TorchScript code.* Because ``TestModule`` instances are instantiated in Python, in this example, ``TestModule(2.0)`` and ``TestModule(2)`` create two instances with different types for its data attributes. ``self.x is of type ``float`` for ``TestModule(2.0)``, whereas ``self.y`` is of type ``int`` for ``TestModule(2.0)``.
-* TorchScript automatically compiles other methods (e.g., ``mul()``) invoked by methods annotated via ``@torch.jit.export`` or ``forward()`` methods
-* Entry-points to a TorchScript program are either ``forward()`` of a module type or functions annotated as ``torch.jit.script`` or methods annotated as ``torch.jit.export``
-
-**Example**
-
-The following shows an incorrect usage of module type. Specifically, this example invokes the constructor of ``TestModule`` inside the scope of TorchScript.
+The following example shows an incorrect usage of module type. Specifically, this example invokes the constructor of ``TestModule`` inside the scope of TorchScript:
 
 .. testcode::
 
@@ -625,25 +640,24 @@
 Since TorchScript is statically typed, programmers need to annotate types at *strategic points* of TorchScript code so that every local variable or
 instance data attribute has a static type, and every function and method has a statically typed signature.
 
-When to annotate types
+When to Annotate Types
 ^^^^^^^^^^^^^^^^^^^^^^
-In general, type annotations are only needed in places where static types cannot be automatically inferred, such as parameters or sometimes return types to
-methods or functions. Types of local variables and data attributes are often automatically inferred from their assignment statements. Sometimes, an inferred type
+In general, type annotations are only needed in places where static types cannot be automatically inferred (e.g., parameters or sometimes return types to
+methods or functions). Types of local variables and data attributes are often automatically inferred from their assignment statements. Sometimes an inferred type
 may be too restrictive, e.g., ``x`` being inferred as ``NoneType`` through assignment ``x = None``, whereas ``x`` is actually used as an ``Optional``. In such
 cases, type annotations may be needed to overwrite auto inference, e.g., ``x: Optional[int] = None``. Note that it is always safe to type annotate a local variable
-or data attribute even if its type can be automatically inferred. But the annotated type must be congruent with TorchScript’s type checking.
+or data attribute even if its type can be automatically inferred. The annotated type must be congruent with TorchScript’s type-checking.
 
 When a parameter, local variable, or data attribute is not type annotated and its type cannot be automatically inferred, TorchScript assumes it to be a
 default type of ``TensorType``, ``List[TensorType]``, or ``Dict[str, TensorType]``.
 
-Annotate function signature
+Annotate Function Signature
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Since parameter may not be automatically inferred from the body of the function (including both functions and methods), they need to be type annotated,
-otherwise they assume the default type ``TensorType``.
+Since a parameter may not be automatically inferred from the body of the function (including both functions and methods), they need to be type annotated. Otherwise, they assume the default type ``TensorType``.
 
 TorchScript supports two styles for method and function signature type annotation:
 
-* **Python3-style** annotates types directly on the signature. As such, it allows individual parameters be left unannotated (whose type will be the default type of ``TensorType``) , or the return type be left unannotated (whose type will be automatically inferred).
+* **Python3-style** annotates types directly on the signature. As such, it allows individual parameters to be left unannotated (whose type will be the default type of ``TensorType``), or allows the return type to be left unannotated (whose type will be automatically inferred).
 
 
 ::
@@ -653,9 +667,9 @@
     ParamAnnot        ::= Identifier [ ":" TSType ] ","
     ReturnAnnot       ::= "->" TSType
 
-Note that using Python3 style, the type of ``self`` is automatically inferred and should not be annotated.
+Note that when using Python3 style, the type ``self`` is automatically inferred and should not be annotated.
 
-* **Mypy style** annotates types as a comment right below the function/method declaration. In the My-Py style, since parameter names do not appear in the annotation, all parameters have to be annotated.
+* **Mypy style** annotates types as a comment right below the function/method declaration. In the Mypy style, since parameter names do not appear in the annotation, all parameters have to be annotated.
 
 
 ::
@@ -666,8 +680,11 @@
 
 **Example 1**
 
-In this example, ``a`` is not annotated and assumes the default type of ``TensorType``, ``b`` is annotated as type ``int``, and the return type is not
-annotated and is automatically inferred as type ``TensorType`` (based on the type of the value being returned).
+In this example:
+
+* ``a`` is not annotated and assumes the default type of ``TensorType``.
+* ``b`` is annotated as type ``int``.
+* The return type is not annotated and is automatically inferred as type ``TensorType`` (based on the type of the value being returned).
 
 ::
 
@@ -681,7 +698,7 @@
 
 **Example 2**
 
-The following code snippet gives an example of using mypy style annotation. Note that parameters or return values must be annotated even if some of
+The following example uses Mypy style annotation. Note that parameters or return values must be annotated even if some of
 them assume the default type.
 
 ::
@@ -696,21 +713,21 @@
     print("TorchScript:", m(torch.ones([6]), 100))
 
 
-Annotate variables and data attributes
+Annotate Variables and Data Attributes
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 In general, types of data attributes (including class and instance data attributes) and local variables can be automatically inferred from assignment statements.
 Sometimes, however, if a variable or attribute is associated with values of different types (e.g., as ``None`` or ``TensorType``), then they may need to be explicitly
 type annotated as a *wider* type such as ``Optional[int]`` or ``Any``.
 
-Local variables
+Local Variables
 """""""""""""""
-Local variables can be annotated according to Python3 typing module annotation rule, i.e.,
+Local variables can be annotated according to Python3 typing module annotation rules, i.e.,
 
 ::
 
     LocalVarAnnotation ::= Identifier [":" TSType] "=" Expr
 
-In general, types of local variables can be automatically inferred. In some cases, however, programmers may need to annotate a multi-type for local variables
+In general, types of local variables can be automatically inferred. In some cases, however, you may need to annotate a multi-type for local variables
 that may be associated with different concrete types. Typical multi-types include ``Optional[T]`` and ``Any``.
 
 **Example**
@@ -729,7 +746,7 @@
     m = torch.jit.script(f)
     print("TorchScript:", m(ones, True), m(ones, False))
 
-Instance data attributes
+Instance Data Attributes
 """"""""""""""""""""""""
 For ``ModuleType`` classes, instance data attributes can be annotated according to Python3 typing module annotation rules. Instance data attributes can be annotated (optionally) as final
 via ``Final``.
@@ -740,14 +757,13 @@
     InstanceAttrIdentifier ":" ["Final("] TSType [")"]
     ...
 
-where ``InstanceAttrIdentifier`` is the name of an instance attribute and ``Final`` indicates that the attribute cannot be re-assigned outside
-of ``__init__`` or overridden in subclasses.
+Where:
+
+* ``InstanceAttrIdentifier`` is the name of an instance attribute.
+* ``Final`` indicates that the attribute cannot be re-assigned outside of ``__init__`` or overridden in subclasses.
 
 **Example**
 
-In this example, ``a`` is not annotated and assumes the default type of ``TensorType``, ``b`` is annotated as type ``int``, and the return type is not
-annotated and is automatically inferred as type ``TensorType`` (based on the type of the value being returned).
-
 ::
 
     import torch
@@ -768,13 +784,13 @@
 ``torch.jit.annotate(T, expr)``
 """""""""""""""""""""""""""""""
 This API annotates type ``T`` to an expression ``expr``. This is often used when the default type of an expression is not the type intended by the programmer.
-For instance, an empty list (dictionary) has the default type of ``List[TensorType]`` (``Dict[TensorType, TensorType]``) but sometimes it may be used to initialize
-a list of some other types. Another common use case is for annotating the return type of ``tensor.tolist()``. Note, however that it cannot be used to annotate
+For instance, an empty list (dictionary) has the default type of ``List[TensorType]`` (``Dict[TensorType, TensorType]``), but sometimes it may be used to initialize
+a list of some other types. Another common use case is for annotating the return type of ``tensor.tolist()``. Note, however, that it cannot be used to annotate
 the type of a module attribute in `__init__`; ``torch.jit.Attribute`` should be used for this instead.
 
 **Example**
 
-In this example, ``[]`` is declared as a list of integers via ``torch.jit.annotate`` (instead of assuming ``[]`` to be the default type of ``List[TensorType]``).
+In this example, ``[]`` is declared as a list of integers via ``torch.jit.annotate`` (instead of assuming ``[]`` to be the default type of ``List[TensorType]``):
 
 ::
 
@@ -797,11 +813,11 @@
 See :meth:`torch.jit.annotate` for more information.
 
 
-Appendix
-^^^^^^^^
+Type Annotation Appendix
+^^^^^^^^^^^^^^^^^^^^^^^^
 
 TorchScript Type System Definition
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+""""""""""""""""""""""""""""""""""
 
 ::
 
@@ -831,7 +847,7 @@
 Unsupported Typing Constructs
 """""""""""""""""""""""""""""
 TorchScript does not support all features and types of the Python3 `typing <https://docs.python.org/3/library/typing.html#module-typing>`_ module.
-Any functionality from the typing `typing <https://docs.python.org/3/library/typing.html#module-typing>`_ module not explicitly specified in this
+Any functionality from the `typing <https://docs.python.org/3/library/typing.html#module-typing>`_ module that is not explicitly specified in this
 documentation is unsupported. The following table summarizes ``typing`` constructs that are either unsupported or supported with restrictions in TorchScript.
 
 =============================  ================
@@ -843,7 +859,7 @@
 ``typing.Callable``             Not supported
 ``typing.Literal``              Not supported
 ``typing.ClassVar``             Not supported
-``typing.Final``                Supported for module attributes, class attribute, and annotations but not for functions
+``typing.Final``                Supported for module attributes, class attribute, and annotations, but not for functions.
 ``typing.AnyStr``               Not supported
 ``typing.overload``             In development
 Type aliases                    Not supported
@@ -868,12 +884,12 @@
 There are a number of implicit type conversions that are performed in TorchScript:
 
 
-* a ``Tensor`` with a ``float`` or ``int`` datatype can be implicitly converted to an instance of ``FloatType`` or ``IntType`` provided that it has a size of 0, and does not have ``require_grad`` set to ``True`` and will not require narrowing.
-* instances of ``StringType`` can be implicitly converted to ``DeviceType``
-* the above implicit conversion rules can be applied to instances of ``TupleType`` to produce instances of ``ListType`` with the appropriate contained type
+* A ``Tensor`` with a ``float`` or ``int`` data type can be implicitly converted to an instance of ``FloatType`` or ``IntType`` provided that it has a size of 0, does not have ``require_grad`` set to ``True``, and will not require narrowing.
+* Instances of ``StringType`` can be implicitly converted to ``DeviceType``.
+* The implicit conversion rules from the two bullet points above can be applied to instances of ``TupleType`` to produce instances of ``ListType`` with the appropriate contained type.
 
 
-Explicit conversions can be invoked using the ``float``, ``int``, ``bool``, ``str`` built-in functions
+Explicit conversions can be invoked using the ``float``, ``int``, ``bool``, and ``str`` built-in functions
 that accept primitive data types as arguments and can accept user-defined types if they implement
 ``__bool__``, ``__str__``, etc.
 
@@ -931,12 +947,12 @@
     key_datum          ::=  expression ':' expression
     dict_comprehension ::=  key_datum comp_for
 
-Lists and dicts can be constructed by either listing the container contents explicitly or providing
+Lists and dicts can be constructed by either listing the container contents explicitly or by providing
 instructions on how to compute them via a set of looping instructions (i.e. a *comprehension*). A comprehension
-is semantically equivalent to using a for loop and appending to an ongoing list the expression of the comprehension.
-Comprehensions implicitly create their own scope to make sure the items of the target list do not leak into the
+is semantically equivalent to using a for loop and appending to an ongoing list.
+Comprehensions implicitly create their own scope to make sure that the items of the target list do not leak into the
 enclosing scope. In the case that container items are explicitly listed, the expressions in the expression list
-are evaluated left-to-right. If a key is repeated in a ``dict_display`` that has a ``key_datum_list``, then, the
+are evaluated left-to-right. If a key is repeated in a ``dict_display`` that has a ``key_datum_list``, the
 resultant dictionary uses the value from the rightmost datum in the list that uses the repeated key.
 
 Primaries
@@ -955,7 +971,7 @@
     attributeref ::=  primary '.' identifier
 
 
-``primary`` must evaluate to an object of a type that supports attribute references that has an attribute named
+The ``primary`` must evaluate to an object of a type that supports attribute references that have an attribute named
 ``identifier``.
 
 Subscriptions
@@ -966,15 +982,17 @@
     subscription ::=  primary '[' expression_list ']'
 
 
-The primary must evaluate to an object that supports subscription. If it is a ``List`` , ``Tuple``, or ``str``,
-the expression list must evaluate to an integer or slice. If it is a ``Dict``, the expression list must evaluate
-to an object of the same type as the key type of the ``Dict``. If the primary is a ``ModuleList``, the expression
-list must be an ``integer`` literal. If the primary is a ``ModuleDict``, the expression must be a ``stringliteral``.
+The ``primary`` must evaluate to an object that supports subscription.
+
+* If the primary is a ``List``, ``Tuple``, or ``str``, the expression list must evaluate to an integer or slice.
+* If the primary is a ``Dict``, the expression list must evaluate to an object of the same type as the key type of the ``Dict``.
+* If the primary is a ``ModuleList``, the expression list must be an ``integer`` literal.
+* If the primary is a ``ModuleDict``, the expression must be a ``stringliteral``.
 
 
 Slicings
 """"""""
-A slicing selects a range of items in a ``str``, ``Tuple``, ``List`` or ``Tensor``. Slicings may be used as
+A slicing selects a range of items in a ``str``, ``Tuple``, ``List``, or ``Tensor``. Slicings may be used as
 expressions or targets in assignment or ``del`` statements.
 
 ::
@@ -1001,7 +1019,7 @@
     arg           ::=  identifier
 
 
-`primary` must desugar or evaluate to a callable object. All argument expressions are evaluated
+The ``primary`` must desugar or evaluate to a callable object. All argument expressions are evaluated
 before the call is attempted.
 
 Power Operator
@@ -1040,7 +1058,7 @@
 The binary arithmetic operators can operate on ``Tensor``, ``int``, and ``float``. For tensor-tensor ops, both arguments must
 have the same shape. For scalar-tensor or tensor-scalar ops, the scalar is usually broadcast to the size of the
 tensor. Division ops can only accept scalars as their right-hand side argument, and do not support broadcasting.
-The ``@ ``operator is for matrix multiplication and only operates on ``Tensor`` arguments. The multiplication operator
+The ``@`` operator is for matrix multiplication and only operates on ``Tensor`` arguments. The multiplication operator
 (``*``) can be used with a list and integer in order to get a result that is the original list repeated a certain
 number of times.
 
@@ -1053,7 +1071,7 @@
 
 
 These operators accept two ``int`` arguments, two ``Tensor`` arguments, or a ``Tensor`` argument and an ``int`` or
-``float`` argument. In all cases, a right shift by ``n`` is defined as floor division by ``pow(2, n)`` and a left shift
+``float`` argument. In all cases, a right shift by ``n`` is defined as floor division by ``pow(2, n)``, and a left shift
 by ``n`` is defined as multiplication by ``pow(2, n)``. When both arguments are ``Tensors``, they must have the same
 shape. When one is a scalar and the other is a ``Tensor``, the scalar is logically broadcast to match the size of
 the ``Tensor``.
@@ -1068,10 +1086,10 @@
     or_expr  ::=  xor_expr | or_expr '|' xor_expr
 
 
-The ``&`` operator computes the bitwise AND of its arguments, the ``^`` the bitwise XOR and ``|`` the bitwise OR.
+The ``&`` operator computes the bitwise AND of its arguments, the ``^`` the bitwise XOR, and the ``|`` the bitwise OR.
 Both operands must be ``int`` or ``Tensor``, or the left operand must be ``Tensor`` and the right operand must be
 ``int``. When both operands are ``Tensor``, they must have the same shape. When the right operand is ``int``, and
-the left operand is ``Tensor`` , the right operand is logically broadcast to match the shape of the ``Tensor``.
+the left operand is ``Tensor``, the right operand is logically broadcast to match the shape of the ``Tensor``.
 
 Comparisons
 ^^^^^^^^^^^
@@ -1081,7 +1099,7 @@
     comparison    ::=  or_expr (comp_operator or_expr)*
     comp_operator ::=  '<' | '>' | '==' | '>=' | '<=' | '!=' | 'is' ['not'] | ['not'] 'in'
 
-A comparison yields a boolean values (``True`` or ``False``) or, if one of the operands is a ``Tensor``, a boolean
+A comparison yields a boolean value (``True`` or ``False``), or if one of the operands is a ``Tensor``, a boolean
 ``Tensor``. Comparisons can be chained arbitrarily as long as they do not yield boolean ``Tensors`` that have more
 than one element. ``a op1 b op2 c ...`` is equivalent to ``a op1 b and b op2 c and ...``.
 
@@ -1089,17 +1107,17 @@
 """""""""""""""""
 The operators ``<``, ``>``, ``==``, ``>=``, ``<=``, and ``!=`` compare the values of two objects. The two objects generally need to be of
 the same type, unless there is an implicit type conversion available between the objects. User-defined types can
-be compared if rich comparison methods ( ``__lt__`` etc.) are defined on them. Built-in type comparison works like
+be compared if rich comparison methods (e.g., ``__lt__``) are defined on them. Built-in type comparison works like
 Python:
 
-* numbers are compared mathematically
-* strings are compared lexicographically
-* lists, tuples, and dicts can be compared only to other lists, tuples, and dicts of the same type and are compared using the comparison operator of corresponding elements
+* Numbers are compared mathematically.
+* Strings are compared lexicographically.
+* ``lists``, ``tuples``, and ``dicts`` can be compared only to other ``lists``, ``tuples``, and ``dicts`` of the same type and are compared using the comparison operator of corresponding elements.
 
 Membership Test Operations
 """"""""""""""""""""""""""
-The operators ``in`` and ``not in`` test for membership. ``x in s`` evaluates to ``True`` if ``x`` is a member of ``s`` and ``False```` otherwise.
-``x not in s`` is equivalent to ``not x in s``. This operator is supported for lists, dicts, and tuples, and can be used with
+The operators ``in`` and ``not in`` test for membership. ``x in s`` evaluates to ``True`` if ``x`` is a member of ``s`` and ``False`` otherwise.
+``x not in s`` is equivalent to ``not x in s``. This operator is supported for ``lists``, ``dicts``, and ``tuples``, and can be used with
 user-defined types if they implement the ``__contains__`` method.
 
 Identity Comparisons
@@ -1143,7 +1161,7 @@
     expression_list ::=  expression (',' expression)* [',']
     starred_item    ::=  '*' primary
 
-A starred item can only appear on the left-hand side of an assignment statement, e.g. ``a, *b, c = ...``.
+A starred item can only appear on the left-hand side of an assignment statement, e.g., ``a, *b, c = ...``.
 
 .. statements:
 
@@ -1153,7 +1171,7 @@
 The following section describes the syntax of simple statements that are supported in TorchScript.
 It is modeled after `the simple statements chapter of the Python language reference <https://docs.python.org/3/reference/simple_stmts.html>`_.
 
-Expression statements:
+Expression Statements
 ^^^^^^^^^^^^^^^^^^^^^^
 
 ::
@@ -1162,7 +1180,7 @@
     starred_expression ::=  expression | (starred_item ",")* [starred_item]
     starred_item       ::=  assignment_expression | "*" or_expr
 
-Assignment Statements:
+Assignment Statements
 ^^^^^^^^^^^^^^^^^^^^^^
 
 ::
@@ -1177,7 +1195,7 @@
                          | slicing
                          | "*" target
 
-Augmented assignment statements:
+Augmented Assignment Statements
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 ::
@@ -1188,69 +1206,69 @@
                                   "**="| ">>=" | "<<=" | "&=" | "^=" | "|="
 
 
-Annotated assignment statements:
+Annotated Assignment Statements
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 ::
 
     annotated_assignment_stmt ::= augtarget ":" expression
                                   ["=" (starred_expression)]
 
-The ``raise`` statement:
+The ``raise`` Statement
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 ::
 
     raise_stmt ::=  "raise" [expression ["from" expression]]
 
-* Raise statements in TorchScript do not support ``try\except\finally``.
+Raise statements in TorchScript do not support ``try\except\finally``.
 
-The ``assert`` statement:
+The ``assert`` Statement
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 ::
 
     assert_stmt ::=  "assert" expression ["," expression]
 
-* Assert statements in TorchScript do not support ``try\except\finally``.
+Assert statements in TorchScript do not support ``try\except\finally``.
 
-The ``return`` statement:
+The ``return`` Statement
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 ::
 
     return_stmt ::=  "return" [expression_list]
 
-* Return statements in TorchScript do not support ``try\except\finally``.
+Return statements in TorchScript do not support ``try\except\finally``.
 
-The ``del`` statement:
+The ``del`` Statement
 ^^^^^^^^^^^^^^^^^^^^^^
 
 ::
 
     del_stmt ::=  "del" target_list
 
-The ``pass`` statement:
+The ``pass`` Statement
 ^^^^^^^^^^^^^^^^^^^^^^^
 
 ::
 
     pass_stmt ::= "pass"
 
-The ``print`` statement:
+The ``print`` Statement
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 ::
 
     print_stmt ::= "print" "(" expression  [, expression] [.format{expression_list}] ")"
 
-The ``break`` statement:
+The ``break`` Statement
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 ::
 
     break_stmt ::= "break"
 
-The ``continue`` statement:
+The ``continue`` Statement:
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 ::
@@ -1264,11 +1282,12 @@
 The section also highlights how Torchscript differs from regular Python statements.
 It is modeled after `the compound statements chapter of the Python language reference <https://docs.python.org/3/reference/compound_stmts.html>`_.
 
-The ``if`` statement:
+The ``if`` Statement
 ^^^^^^^^^^^^^^^^^^^^^
-* Torchscript supports both basic ``if/else`` and ternary ``if/else``.
 
-Basic ``if/else`` statement:
+Torchscript supports both basic ``if/else`` and ternary ``if/else``.
+
+Basic ``if/else`` Statement
 """"""""""""""""""""""""""""
 
 ::
@@ -1277,18 +1296,18 @@
                 ("elif" assignment_expression ":" suite)
                 ["else" ":" suite]
 
-* ``elif`` statement can repeat for arbitrary number of times, but it needs to be before ``else`` statement.
+``elif`` statements can repeat for an arbitrary number of times, but it needs to be before ``else`` statement.
 
-Ternary ``if/else`` statement:
+Ternary ``if/else`` Statement
 """"""""""""""""""""""""""""""
 
 ::
 
     if_stmt ::= return [expression_list] "if" assignment_expression "else" [expression_list]
 
-**Example**
+**Example 1**
 
-* ``Tensor`` with 1 dimension is promoted to ``bool``
+A ``tensor`` with 1 dimension is promoted to ``bool``:
 
 .. testcode::
 
@@ -1301,13 +1320,15 @@
         return False
     print(fn(torch.rand(1)))
 
+The example above produces the following output:
+
 .. testoutput::
 
     True
 
-* ``Tensor`` with multi dimensions are not promoted to ``bool``
+**Example 2**
 
-**Example**
+A ``tensor`` with multi dimensions are not promoted to ``bool``:
 
 ::
 
@@ -1325,7 +1346,7 @@
 
     print(fn())
 
-The above code results in the below RuntimeError
+Running the above code yields the following ``RuntimeError``.
 
 ::
 
@@ -1338,10 +1359,11 @@
             print("Tensor is available")
     RuntimeError: Boolean value of Tensor with more than one value is ambiguous
 
-* If a conditional variable is annotated as Final, either true or false branch is
-* evaluated depending on the evaluation of the conditional variable.
+If a conditional variable is annotated as ``final``, either the true or false branch is evaluated depending on the evaluation of the conditional variable.
 
-**Example**
+**Example 3**
+
+In this example, only the True branch is evaluated, since ``a`` is annotated as ``final`` and set to ``True``:
 
 ::
 
@@ -1354,18 +1376,17 @@
     else:
         return []
 
-Here, only True branch is evaluated, since ``a`` is annotated as ``final`` and set to ``True``
 
-The ``while`` statement:
+The ``while`` Statement
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 ::
 
     while_stmt ::=  "while" assignment_expression ":" suite
 
-* `while...else` statements are not supported in Torchscript. It results in a `RuntimeError`
+`while...else` statements are not supported in Torchscript. It results in a ``RuntimeError``.
 
-The ``for-in`` statement:
+The ``for-in`` Statement
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 ::
@@ -1373,11 +1394,11 @@
     for_stmt ::=  "for" target_list "in" expression_list ":" suite
                   ["else" ":" suite]
 
-* ``for...else`` statements are not supported in Torchscript. It results in a ``RuntimeError``
+``for...else`` statements are not supported in Torchscript. It results in a ``RuntimeError``.
 
-* for loops on tuples: These unroll the loop, generating a body for each member of the tuple.The body must type-check correctly for each member.
+**Example 1**
 
-**Example**
+For loops on tuples: these unroll the loop, generating a body for each member of the tuple. The body must type-check correctly for each member.
 
 .. testcode::
 
@@ -1392,6 +1413,8 @@
 
     fn()
 
+The example above produces the following output:
+
 .. testoutput::
 
     3
@@ -1402,9 +1425,9 @@
     [ CPUFloatType{4} ]
 
 
-*  for loops on lists: For loops over a ``nn.ModuleList`` will unroll the body of the loop at compile time, with each member of the module list.
+**Example 2**
 
-**Example**
+For loops on lists: for loops over a ``nn.ModuleList`` will unroll the body of the loop at compile time, with each member of the module list.
 
 ::
 
@@ -1429,39 +1452,37 @@
 
     model = torch.jit.script(MyModule())
 
-The ``with`` statement:
+The ``with`` Statement
 ^^^^^^^^^^^^^^^^^^^^^^^
-* The ``with`` statement is used to wrap the execution of a block with methods defined by a context manager
+The ``with`` statement is used to wrap the execution of a block with methods defined by a context manager.
 
 ::
 
     with_stmt ::=  "with" with_item ("," with_item) ":" suite
     with_item ::=  expression ["as" target]
 
-* If a target was included in the ``with`` statement, the return value from context manager’s ``__enter__()``
-* is assigned to it. Unlike python, if an exception caused the suite to be exited, its type, value, and traceback are
-* not passed as arguments to ``__exit__()``. Three ``None`` arguments are supplied.
-
-* ``try/except/finally`` statements are not supported inside ``with`` blocks.
+* If a target was included in the ``with`` statement, the return value from the context manager’s ``__enter__()`` is assigned to it. Unlike python, if an exception caused the suite to be exited, its type, value, and traceback are not passed as arguments to ``__exit__()``. Three ``None`` arguments are supplied.
+* ``try``, ``except``, and ``finally`` statements are not supported inside ``with`` blocks.
 *  Exceptions raised within ``with`` block cannot be suppressed.
 
-The ``tuple`` statement:
+The ``tuple`` Statement
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 ::
 
     tuple_stmt ::= tuple([iterables])
 
-* Iterable types in TorchScript include ``Tensors``, ``lists``,``tuples``, ``dictionaries``, ``strings``,``torch.nn.ModuleList`` and ``torch.nn.ModuleDict``.
-* Cannot convert a List to Tuple by using this built-in function.
-* Unpacking all outputs into a tuple is covered by:
+* Iterable types in TorchScript include ``Tensors``, ``lists``, ``tuples``, ``dictionaries``, ``strings``, ``torch.nn.ModuleList``, and ``torch.nn.ModuleDict``.
+* You cannot convert a List to Tuple by using this built-in function.
+
+Unpacking all outputs into a tuple is covered by:
 
 ::
 
     abc = func() # Function that returns a tuple
     a,b = func()
 
-The ``getattr`` statement:
+The ``getattr`` Statement
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 ::
@@ -1469,10 +1490,10 @@
     getattr_stmt ::= getattr(object, name[, default])
 
 * Attribute name must be a literal string.
-* Module type object is not supported for example, torch._C
-* Custom Class object is not supported for example, torch.classes.*
+* Module type object is not supported (e.g., torch._C).
+* Custom class object is not supported (e.g., torch.classes.*).
 
-The ``hasattr`` statement:
+The ``hasattr`` Statement
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 ::
@@ -1480,10 +1501,10 @@
     hasattr_stmt ::= hasattr(object, name)
 
 * Attribute name must be a literal string.
-* Module type object is not supported for example, torch._C
-* Custom Class object is not supported for example, torch.classes.*
+* Module type object is not supported (e.g., torch._C).
+* Custom class object is not supported (e.g., torch.classes.*).
 
-The ``zip`` statement:
+The ``zip`` Statement
 ^^^^^^^^^^^^^^^^^^^^^^
 
 ::
@@ -1493,7 +1514,9 @@
 * Arguments must be iterables.
 * Two iterables of same outer container type but different length are supported.
 
-**Example**
+**Example 1**
+
+Both the iterables must be of the same container type:
 
 .. testcode::
 
@@ -1501,9 +1524,9 @@
     b = [2, 3, 4] # List
     zip(a, b) # works
 
-* Both the iterables must be of the same container type - (List here).
+**Example 2**
 
-**Example**
+This example fails because the iterables are of different container types:
 
 ::
 
@@ -1511,16 +1534,16 @@
     b = [2, 3, 4] # List
     zip(a, b) # Runtime error
 
-The above code results in the below RuntimeError
+Running the above code yields the following ``RuntimeError``.
 
 ::
 
     RuntimeError: Can not iterate over a module list or
         tuple with a value that does not have a statically determinable length.
 
-* Two iterables of same container Type but different data type is supported
+**Example 3**
 
-**Example**
+Two iterables of the same container Type but different data type is supported:
 
 .. testcode::
 
@@ -1528,9 +1551,9 @@
     b = [2, 3, 4]
     zip(a, b) # Works
 
-* Iterable types in TorchScript include ``Tensors``, ``lists``, ``tuples``, ``dictionaries``, ``strings``, ``torch.nn.ModuleList`` and ``torch.nn.ModuleDict``.
+Iterable types in TorchScript include ``Tensors``, ``lists``, ``tuples``, ``dictionaries``, ``strings``, ``torch.nn.ModuleList``, and ``torch.nn.ModuleDict``.
 
-The ``enumerate`` statement:
+The ``enumerate`` Statement
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 ::
@@ -1550,41 +1573,41 @@
 
 Resolution Rules
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-When given a Python value, TorchScript attempts to resolve it in following five different ways:
+When given a Python value, TorchScript attempts to resolve it in the following five different ways:
 
 * Compilable Python Implementation:
     * When a Python value is backed by a Python implementation that can be compiled by TorchScript, TorchScript compiles and uses the underlying Python implementation.
     * Example: ``torch.jit.Attribute``
 * Op Python Wrapper:
-    * When a Python value is a wrapper of a native PyTorch op, TorchScript emits corresponding operator.
+    * When a Python value is a wrapper of a native PyTorch op, TorchScript emits the corresponding operator.
     * Example: ``torch.jit._logging.add_stat_value``
 * Python Object Identity Match:
     * For a limited set of ``torch.*`` API calls (in the form of Python values) that TorchScript supports, TorchScript attempts to match a Python value against each item in the set.
     * When matched, TorchScript generates a corresponding ``SugaredValue`` instance that contains lowering logic for these values.
     * Example: ``torch.jit.isinstance()``
 * Name Match:
-    * For Python built-in functions and constants, TorchScript identifies them by name, and creates a corresponding SugaredValue instance that implements their functionality.
+    * For Python built-in functions and constants, TorchScript identifies them by name, and creates a corresponding ``SugaredValue`` instance that implements their functionality.
     * Example: ``all()``
 * Value Snapshot:
-    * For Python values from unrecognized modules, TorchScript attempts to take a snapshot of the value and converts to a constant in the graph of the function(s) or method(s) being compiled
+    * For Python values from unrecognized modules, TorchScript attempts to take a snapshot of the value and converts it to a constant in the graph of the function(s) or method(s) that are being compiled.
     * Example: ``math.pi``
 
 
 
 .. _python-builtin-functions-support:
 
-Python Builtin Functions Support
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-.. list-table:: TorchScript Support for Python Builtin Functions
+Python Built-in Functions Support
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+.. list-table:: TorchScript Support for Python Built-in Functions
    :widths: 25 25 50
    :header-rows: 1
 
-   * - Builtin Function
+   * - Built-in Function
      - Support Level
      - Notes
    * - ``abs()``
      - Partial
-     - Only supports ``Tensor``/``Int``/``Float`` type inputs | Doesn't honor ``__abs__`` override
+     - Only supports ``Tensor``/``Int``/``Float`` type inputs. | Doesn't honor ``__abs__`` override.
    * - ``all()``
      - Full
      -
@@ -1596,13 +1619,10 @@
      -
    * - ``bin()``
      - Partial
-     - Only supports ``Int``-type input
+     - Only supports ``Int`` type input.
    * - ``bool()``
      - Partial
-     - Only supports ``Tensor``/``Int``/``Float`` type inputs
-   * - ``breakpoint()``
-     - None
-     -
+     - Only supports ``Tensor``/``Int``/``Float`` type inputs.
    * - ``breakpoint()``
      - None
      -
@@ -1617,7 +1637,7 @@
      -
    * - ``chr()``
      - Partial
-     - Only ASCII character set is supported
+     - Only ASCII character set is supported.
    * - ``classmethod()``
      - Full
      -
@@ -1653,16 +1673,16 @@
      -
    * - ``float()``
      - Partial
-     - Doesn't honor ``__index__`` override
+     - Doesn't honor ``__index__`` override.
    * - ``format()``
      - Partial
-     - Manual index specification not supported | Format type modifier not supported
+     - Manual index specification not supported. | Format type modifier not supported.
    * - ``frozenset()``
      - None
      -
    * - ``getattr()``
      - Partial
-     - Attribute name must be string literal
+     - Attribute name must be string literal.
    * - ``globals()``
      - None
      -
@@ -1671,22 +1691,22 @@
      -
    * - ``hash()``
      - Full
-     - ``Tensor``'s hash is based on identity not numeric value
+     - ``Tensor``'s hash is based on identity not numeric value.
    * - ``hex()``
      - Partial
-     - Only supports ``Int``-type input
+     - Only supports ``Int`` type input.
    * - ``id()``
      - Full
-     - Only supports ``Int``-type input
+     - Only supports ``Int`` type input.
    * - ``input()``
      - None
      -
    * - ``int()``
      - Partial
-     - ``base`` argument not supported | Doesn't honor ``__index__`` override
+     - ``base`` argument not supported. | Doesn't honor ``__index__`` override.
    * - ``isinstance()``
      - Full
-     - ``torch.jit.isintance`` provides better support when checking against container types like ``Dict[str, int]``
+     - ``torch.jit.isintance`` provides better support when checking against container types like ``Dict[str, int]``.
    * - ``issubclass()``
      - None
      -
@@ -1701,13 +1721,13 @@
      -
    * - ``ord()``
      - Partial
-     - Only ASCII character set is supported
+     - Only ASCII character set is supported.
    * - ``pow()``
      - Full
      -
    * - ``print()``
      - Partial
-     - ``separate``, ``end`` and ``file`` arguments are not supported
+     - ``separate``, ``end`` and ``file`` arguments are not supported.
    * - ``property()``
      - None
      -
@@ -1722,25 +1742,25 @@
      -
    * - ``round()``
      - Partial
-     - ``ndigits`` argument is not supported
+     - ``ndigits`` argument is not supported.
    * - ``set()``
      - None
      -
    * - ``setattr()``
      - None
-     - Partial
+     -
    * - ``slice()``
      - Full
      -
    * - ``sorted()``
      - Partial
-     - ``key`` argument is not supported
+     - ``key`` argument is not supported.
    * - ``staticmethod()``
      - Full
      -
    * - ``str()``
      - Partial
-     - ``encoding`` and ``errors`` arguments are not supported
+     - ``encoding`` and ``errors`` arguments are not supported.
    * - ``sum()``
      - Full
      -
@@ -1762,13 +1782,13 @@
 
 .. _python-builtin-values-support:
 
-Python Builtin Values Support
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-.. list-table:: TorchScript Support for Python Builtin Values
+Python Built-in Values Support
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+.. list-table:: TorchScript Support for Python Built-in Values
    :widths: 25 25 50
    :header-rows: 1
 
-   * - Builtin Value
+   * - Built-in Value
      - Support Level
      - Notes
    * - ``False``
@@ -1790,8 +1810,8 @@
 
 .. _torch_apis_in_torchscript:
 
-``torch.*`` APIs
-~~~~~~~~~~~~~~~~
+torch.* APIs
+~~~~~~~~~~~~
 
 .. _torch_apis_in_torchscript_rpc:
 
@@ -1799,19 +1819,19 @@
 ^^^^^^^^^^^^^^^^^^^^^^
 
 TorchScript supports a subset of RPC APIs that supports running a function on
-on a specified remote worker instead of locally.
+a specified remote worker instead of locally.
 
 Specifically, following APIs are fully supported:
 
 - ``torch.distributed.rpc.rpc_sync()``
-    - ``rpc_sync()`` makes a blocking RPC call to run a function on remote worker. RPC messages are sent and received in parallel to execution of Python code.
-    - More deatils about its usage and examples can be found in :meth:`~torch.distributed.rpc.rpc_sync`.
+    - ``rpc_sync()`` makes a blocking RPC call to run a function on a remote worker. RPC messages are sent and received in parallel to execution of Python code.
+    - More details about its usage and examples can be found in :meth:`~torch.distributed.rpc.rpc_sync`.
 
 - ``torch.distributed.rpc.rpc_async()``
-    - ``rpc_async()`` makes a non-blocking RPC call to run a function on remote worker. RPC messages are sent and received in parallel to execution of Python code.
+    - ``rpc_async()`` makes a non-blocking RPC call to run a function on a remote worker. RPC messages are sent and received in parallel to execution of Python code.
     - More deatils about its usage and examples can be found in :meth:`~torch.distributed.rpc.rpc_async`.
 - ``torch.distributed.rpc.remote()``
-    - Executing a remote call on worker and getting a Remote Reference ``RRef`` as return value.
+    - ``remote.()`` executes a remote call on a worker and gets a Remote Reference ``RRef`` as the return value.
     - More details about its usage and examples can be found in :meth:`~torch.distributed.rpc.remote`.
 
 .. _torch_apis_in_torchscript_async:
@@ -1819,12 +1839,12 @@
 Asynchronous Execution
 ^^^^^^^^^^^^^^^^^^^^^^
 
-TorchScript allows creating asynchronous computation tasks to make better use
+TorchScript enables you to create asynchronous computation tasks to make better use
 of computation resources. This is done via supporting a list of APIs that are
 only usable within TorchScript:
 
 - ``torch.jit.fork()``
-    - Creates an asynchronous task executing func and a reference to the value of the result of this execution. fork will return immediately.
+    - Creates an asynchronous task executing func and a reference to the value of the result of this execution. Fork will return immediately.
     - Synonymous to ``torch.jit._fork()``, which is only kept for backward compatibility reasons.
     - More deatils about its usage and examples can be found in :meth:`~torch.jit.fork`.
 - ``torch.jit.wait()``
@@ -1838,17 +1858,17 @@
 Type Annotations
 ^^^^^^^^^^^^^^^^
 
-TorchScript is statically-typed, it provides and supports a set of utilities to help annotate variables and attributes.:
+TorchScript is statically-typed. It provides and supports a set of utilities to help annotate variables and attributes:
 
 - ``torch.jit.annotate()``
     - Provides a type hint to TorchScript where Python 3 style type hints do not work well.
-    - One common example is to annotate type for expressions like ``[]``. ``[]`` is treated as ``List[torch.Tensor]`` by default, when a different type is needed, one can use following code to hint TorchScript: ``torch.jit.annotate(List[int], [])``.
+    - One common example is to annotate type for expressions like ``[]``. ``[]`` is treated as ``List[torch.Tensor]`` by default. When a different type is needed, you can use this code to hint TorchScript: ``torch.jit.annotate(List[int], [])``.
     - More details can be found in :meth:`~torch.jit.annotate`
 - ``torch.jit.Attribute``
-    - Common use cases include providing type hint for ``torch.nn.Module`` attributes. Because their ``__init__`` methods are not parsed by TorchScript, ``torch.jit.Attribute`` should be used instead of ``torch.jit.annotate`` in module's ``__init__`` methods.
+    - Common use cases include providing type hint for ``torch.nn.Module`` attributes. Because their ``__init__`` methods are not parsed by TorchScript, ``torch.jit.Attribute`` should be used instead of ``torch.jit.annotate`` in the module's ``__init__`` methods.
     - More details can be found in :meth:`~torch.jit.Attribute`
 - ``torch.jit.Final``
-    - An alias for Python's ``typing.Final``. ``torch.jit.Final`` is only kept for backward compatibility reasons.
+    - An alias for Python's ``typing.Final``. ``torch.jit.Final`` is kept only for backward compatibility reasons.
 
 
 .. _torch_apis_in_torchscript_meta_programming:
@@ -1856,12 +1876,12 @@
 Meta Programming
 ^^^^^^^^^^^^^^^^
 
-TorchScript provides a set of utilities to facilitate meta programming.
+TorchScript provides a set of utilities to facilitate meta programming:
 
 - ``torch.jit.is_scripting()``
-    - Returns a boolean value indicating whether current program is compiled by ``torch.jit.script`` or not.
-    - When used in an ``assert`` or ``if`` statement, the scope or branch where ``torch.jit.is_scripting()`` evaluates to ``False`` is not compiled.
-    - Its value can be evaluated statically at compile time, thus commonly used in ``if`` statement to stop TorchScript from compiling one of the branches.
+    - Returns a boolean value indicating whether the current program is compiled by ``torch.jit.script`` or not.
+    - When used in an ``assert`` or an ``if`` statement, the scope or branch where ``torch.jit.is_scripting()`` evaluates to ``False`` is not compiled.
+    - Its value can be evaluated statically at compile time, thus commonly used in ``if`` statements to stop TorchScript from compiling one of the branches.
     - More details and examples can be found in :meth:`~torch.jit.is_scripting`
 - ``@torch.jit.ignore``
     - This decorator indicates to the compiler that a function or method should be ignored and left as a Python function.
@@ -1881,5 +1901,5 @@
 ^^^^^^^^^^^^^^^
 
 - ``torch.jit.isinstance()``
-    - Returns a boolean indicating whether a variable is of specified type.
+    - Returns a boolean indicating whether a variable is of the specified type.
     - More deatils about its usage and examples can be found in :meth:`~torch.jit.isinstance`.