Apply suggestions from code review

Co-authored-by: Simon Hawkins <[email protected]>

Author: jorisvandenbossche

doc/source/user_guide/migration-3-strings.rst

@@ -18,17 +18,17 @@ enable it with:
 
     pd.options.future.infer_string = True
 
-This allows to test your code before the final 3.0 release.
+This allows you to test your code before the final 3.0 release.
 
 Background
 ----------
 
 Historically, pandas has always used the NumPy ``object`` dtype as the default
 to store text data. This has two primary drawbacks. First, ``object`` dtype is
-not specific to strings: any Python object can be stored in an ``object```-dtype
+not specific to strings: any Python object can be stored in an ``object``-dtype
 array, not just strings, and seeing ``object`` as the dtype for a column with
 strings is confusing for users. Second, this is not always very efficient (both
-performance wise as for memory usage).
+performance wise and for memory usage).
 
 Since pandas 1.0, an opt-in string data type has been available, but this has
 not yet been made the default, and uses the ``pd.NA`` scalar to represent
@@ -57,7 +57,7 @@ for more background and details.
 ..    - None gets coerced to NaN
 ..    - setitem raises an error for non-string data
 
-Brief intro to the new default string dtype
+Brief introduction to the new default string dtype
 -------------------------------------------
 
 By default, pandas will infer this new string dtype instead of object dtype for
@@ -86,14 +86,14 @@ It can also be specified explicitly using the ``"str"`` alias:
    2    NaN
    dtype: str
 
-In contrast the the current object dtype, the new string dtype will only store
+In contrast to the current object dtype, the new string dtype will only store
 strings. This also means that it will raise an error if you try to store a
 non-string value in it (see below for more details).
 
 Missing values with the new string dtype are always represented as ``NaN``, and
-the missing value behaviour is similar as for other default dtypes.
+the missing value behaviour is similar to other default dtypes.
 
-For the rest, this new string dtype should work the same as how you have been
+This new string dtype should work the same as how you have been
 using pandas with string data today. For example, all string-specific methods
 through the ``str`` accessor will work the same:
 
@@ -143,7 +143,7 @@ To check for columns with string data, you should instead use:
 
    >>> ser.dtype == "str"
 
-**How to write compatible code?**
+**How to write compatible code**
 
 For code that should work on both pandas 2.x and 3.x, you can use the
 :func:`pandas.api.types.is_string_dtype` function:
@@ -153,7 +153,7 @@ For code that should work on both pandas 2.x and 3.x, you can use the
    >>> pd.api.types.is_string_dtype(ser.dtype)
    True
 
-This will return ``True`` for both the object dtype as for the string dtypes.
+This will return ``True`` for both the object dtype and the string dtypes.
 
 Hardcoded use of object dtype
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -253,7 +253,7 @@ impacted by this change.
 **How to write compatible code?**
 
 You can update your code to ensure you only set string values in such columns,
-or otherwise you have explicitly ensure the column has object dtype first. This
+or otherwise you can explicitly ensure the column has object dtype first. This
 can be done by specifying the dtype explicitly in the constructor, or by using
 the :meth:`~pandas.Series.astype` method:
 
@@ -264,7 +264,7 @@ the :meth:`~pandas.Series.astype` method:
    >>> ser[1] = 2.5
 
 This ``astype("object")`` call will be redundant when using pandas 2.x, but
-this way such code can work for all versions.
+this code will work for all versions.
 
 For existing users of the nullable ``StringDtype``
 --------------------------------------------------