Fix markup for plurals.

pep-0557.rst

@@ -147,7 +147,7 @@ A function ``dataclass`` which is typically used as a class decorator
 is provided to post-process classes and add generated methods,
 described below.
 
-The ``dataclass`` decorator examines the class to find ``field``'s.  A
+The ``dataclass`` decorator examines the class to find ``field``\s.  A
 ``field`` is defined as any variable identified in
 ``__annotations__``.  That is, a variable that has a type annotation.
 With two exceptions described below, none of the Data Class machinery
@@ -230,7 +230,7 @@ The parameters to ``dataclass`` are:
   generate an exception.  This emulates read-only frozen instances.
   See the discussion below.
 
-``field``'s may optionally specify a default value, using normal
+``field``\s may optionally specify a default value, using normal
 Python syntax::
 
   @dataclass
@@ -649,9 +649,9 @@ workarounds:
 
 - Manually add ``__slots__`` in the class definition.
 
-- Write a function (which could be used as a decorator) that
-  inspects the class using ``fields()`` and creates a new class with
-  ``__slots__`` set.
+- Write a function (which could be used as a decorator) that inspects
+  the class using ``fields()`` and creates a new class with
+  ``__slots__`` set.
 
 For more discussion, see [#]_.
 
@@ -694,7 +694,7 @@ Why not just use typing.NamedTuple?
 
 For classes with statically defined fields, it does support similar
 syntax to Data Classes, using type annotations.  This produces a
-namedtuple, so it shares ``namedtuple``'s benefits and some of its
+namedtuple, so it shares ``namedtuple``\s benefits and some of its
 downsides.  Data Classes, unlike ``typing.NamedTuple``, support
 combining fields via inheritance.
 
@@ -739,14 +739,14 @@ also execute code immmediately after constructing the object) is
 functionally equivalent to being able to pass parameters to a
 ``__post_init__`` function.
 
-With ``InitVar``'s, ``__post_init__`` functions can now take
+With ``InitVar``\s, ``__post_init__`` functions can now take
 parameters.  They are passed first to ``__init__`` which passes them
 to ``__post_init__`` where user code can use them as needed.
 
 The only real difference between alternate classmethod constructors
 and ``InitVar`` pseudo-fields is in regards to required non-field
 parameters during object creation.  With ``InitVar``\s, using
-``__init__`` and the module-level ``replace()`` function ``InitVar``'s
+``__init__`` and the module-level ``replace()`` function ``InitVar``\s
 must always be specified.  Consider the case where a ``context``
 object is needed to create an instance, but isn't stored as a field.
 With alternate classmethod constructors the ``context`` parameter is