Grammar errors

Author: codeandfire

docs/userguide/package_discovery.rst

@@ -1,11 +1,11 @@
 .. _`package_discovery`:
 
 ========================================
-Package Discovery and Namespace Package
+Package Discovery and Namespace Packages
 ========================================
 
 .. note::
-    a full specification for the keyword supplied to ``setup.cfg`` or
+    a full specification for the keywords supplied to ``setup.cfg`` or
     ``setup.py`` can be found at :doc:`keywords reference </references/keywords>`
 
 .. note::
@@ -15,10 +15,10 @@ Package Discovery and Namespace Package
     new to setuptools, the :doc:`quickstart section <quickstart>` is a good
     place to start.
 
-``Setuptools`` provide powerful tools to handle package discovery, including
-support for namespace package.
+``Setuptools`` provides powerful tools to handle package discovery, including
+support for namespace packages.
 
-Normally, you would specify the package to be included manually in the following manner:
+Normally, you would specify the packages to be included manually in the following manner:
 
 .. tab:: setup.cfg
 
@@ -190,7 +190,7 @@ The package folder(s) are placed directly under the project root::
 
 This layout is very practical for using the REPL, but in some situations
 it can be more error-prone (e.g. during tests or if you have a bunch
-of folders or Python files hanging around your project root)
+of folders or Python files hanging around your project root).
 
 To avoid confusion, file and folder names that are used by popular tools (or
 that correspond to well-known conventions, such as distributing documentation
@@ -271,7 +271,7 @@ Finding simple packages
 -----------------------
 Let's start with the first tool. ``find:`` (``find_packages()``) takes a source
 directory and two lists of package name patterns to exclude and include, and
-then return a list of ``str`` representing the packages it could find. To use
+then returns a list of ``str`` representing the packages it could find. To use
 it, consider the following directory::
 
     mypkg
@@ -288,7 +288,7 @@ it, consider the following directory::
                 └── __init__.py
 
 To have setuptools to automatically include packages found
-in ``src`` that starts with the name ``pkg`` and not ``additional``:
+in ``src`` that start with the name ``pkg`` and not ``additional``:
 
 .. tab:: setup.cfg
 
@@ -364,8 +364,8 @@ in ``src`` that starts with the name ``pkg`` and not ``additional``:
 
 Finding namespace packages
 --------------------------
-``setuptools``  provides the ``find_namespace:`` (``find_namespace_packages()``)
-which behaves similarly to ``find:`` but works with namespace package.
+``setuptools``  provides ``find_namespace:`` (``find_namespace_packages()``)
+which behaves similarly to ``find:`` but works with namespace packages.
 
 Before diving in, it is important to have a good understanding of what
 :pep:`namespace packages <420>` are. Here is a quick recap.
@@ -415,7 +415,7 @@ distribution, then you will need to specify:
         [options.packages.find]
         where = src
 
-    ``find:`` won't work because timmins doesn't contain ``__init__.py``
+    ``find:`` won't work because ``timmins`` doesn't contain ``__init__.py``
     directly, instead, you have to use ``find_namespace:``.
 
     You can think of ``find_namespace:`` as identical to ``find:`` except it
@@ -494,15 +494,15 @@ available to your interpreter.
 
 Legacy Namespace Packages
 =========================
-The fact you can create namespace package so effortlessly above is credited
-to `PEP 420 <https://www.python.org/dev/peps/pep-0420/>`_. It use to be more
+The fact you can create namespace packages so effortlessly above is credited
+to `PEP 420 <https://www.python.org/dev/peps/pep-0420/>`_. It used to be more
 cumbersome to accomplish the same result. Historically, there were two methods
 to create namespace packages. One is the ``pkg_resources`` style supported by
 ``setuptools`` and the other one being ``pkgutils`` style offered by
 ``pkgutils`` module in Python. Both are now considered deprecated despite the
 fact they still linger in many existing packages. These two differ in many
 subtle yet significant aspects and you can find out more on `Python packaging
-user guide <https://packaging.python.org/guides/packaging-namespace-packages/>`_
+user guide <https://packaging.python.org/guides/packaging-namespace-packages/>`_.
 
 
 ``pkg_resource`` style namespace package