minor copy-editing fixes

source/contribute.rst

@@ -11,7 +11,7 @@ including:
 * Reviewing new contributions
 * Revising existing content
 * Writing new content
-* Translate the guide
+* Translating the guide
 
 Most of the work on the |PyPUG| takes place on the
 `project's GitHub repository`__. To get started, check out the list of

source/discussions/deploying-python-applications.rst

@@ -23,7 +23,7 @@ Supporting multiple hardware platforms
   For Python-only distributions, it *should* be straightforward to deploy on all
   platforms where Python can run.
 
-  For distributions with binary extensions, deployment is major headache.  Not only
+  For distributions with binary extensions, deployment is a major headache.  Not only
   must the extensions be built on all the combinations of operating system and
   hardware platform, but they must also be tested, preferably on continuous
   integration platforms.  The issues are similar to the "multiple Python

source/discussions/pip-vs-easy-install.rst

@@ -11,7 +11,7 @@ It was notable at the time for installing :term:`packages <Distribution Package>
 :term:`PyPI <Python Package Index (PyPI)>` using requirement specifiers, and
 automatically installing dependencies.
 
-:ref:`pip` came later in 2008, as alternative to :ref:`easy_install <easy_install>`, although still
+:ref:`pip` came later in 2008, as an alternative to :ref:`easy_install <easy_install>`, although still
 largely built on top of :ref:`setuptools` components.  It was notable at the
 time for *not* installing packages as :term:`Eggs <Egg>` or from :term:`Eggs <Egg>` (but
 rather simply as 'flat' packages from :term:`sdists <Source Distribution (or

source/discussions/versioning.rst

@@ -75,7 +75,7 @@ semantic versioning and calendar versioning.
    number. The maintainers may consciously choose to break the
    assumption that the last version segment only contains
    backwards-compatible changes.
-   One such case is when security vulnerability needs to be
+   One such case is when a security vulnerability needs to be
    addressed. Security releases often come in patch versions
    but contain breaking changes inevitably.
 
@@ -124,7 +124,7 @@ Calendar versioning
 -------------------
 
 Semantic versioning is not a suitable choice for all projects, such as those
-with a regular time based release cadence and a deprecation process that
+with a regular time-based release cadence and a deprecation process that
 provides warnings for a number of releases prior to removal of a feature.
 
 A key advantage of date-based versioning, or `calendar versioning <calver_>`_
@@ -148,7 +148,7 @@ user, as serial version numbers convey little or no information regarding API
 backwards compatibility.
 
 Combinations of the above schemes are possible. For example, a project may
-combine date based versioning with serial versioning to create a *year.serial*
+combine date-based versioning with serial versioning to create a *year.serial*
 numbering scheme that readily conveys the approximate age of a release, but
 doesn't otherwise commit to a particular release cadence within the year.
 

source/glossary.rst

@@ -291,7 +291,7 @@ Glossary
         <https://bitbucket.org/pypa>`_, and discuss issues on the
         `distutils-sig mailing list
         <https://mail.python.org/mailman3/lists/distutils-sig.python.org/>`_
-	and `the Python Discourse forum <https://discuss.python.org/c/packaging>`__.
+	and `the Python Discourse forum <https://discuss.python.org/c/packaging>`_.
 
 
     Python Package Index (PyPI)

source/guides/creating-command-line-tools.rst

@@ -5,7 +5,7 @@ Creating and packaging command-line tools
 =========================================
 
 This guide will walk you through creating and packaging a standalone command-line application
-that can be installed with :ref:`pipx`, a tool creating and managing :term:`Python Virtual Environments <Virtual Environment>`
+that can be installed with :ref:`pipx`, a tool for creating and managing :term:`Python Virtual Environments <Virtual Environment>`
 and exposing the executable scripts of packages (and available manual pages) for use on the command-line.
 
 Creating the package
@@ -98,7 +98,7 @@ Now, add an empty :file:`__init__.py` file, to define the project as a regular :
 
 The file :file:`__main__.py` marks the main entry point for the application when running it via :mod:`runpy`
 (i.e. ``python -m greetings``, which works immediately with flat layout, but requires installation of the package with src layout),
-so initizalize the command-line interface here:
+so initialize the command-line interface here:
 
 .. code-block:: python
 
@@ -162,7 +162,7 @@ To just run the program without installing it permanently, use ``pipx run``, whi
 
 	$ pipx run --spec . greet --knight
 
-This syntax is a bit unpractical, however; as the name of the entry point we defined above does not match the package name,
+This syntax is a bit impractical, however; as the name of the entry point we defined above does not match the package name,
 we need to state explicitly which executable script to run (even though there is only on in existence).
 
 There is, however, a more practical solution to this problem, in the form of an entry point specific to ``pipx run``.
@@ -184,7 +184,7 @@ default one and run it, which makes this command possible:
 Conclusion
 ==========
 
-You know by now how to package a command-line application written in Python. A further step could be to distribute you package,
+You know by now how to package a command-line application written in Python. A further step could be to distribute your package,
 meaning uploading it to a :term:`package index <Package Index>`, most commonly :term:`PyPI <Python Package Index (PyPI)>`. To do that, follow the instructions at :ref:`Packaging your project`. And once you're done, don't forget to :ref:`do some research <analyzing-pypi-package-downloads>` on how your package is received!
 
 .. _click: https://click.palletsprojects.com/

source/guides/installing-using-pip-and-virtual-environments.rst

@@ -200,7 +200,7 @@ When your virtual environment is activated, you can install packages. Use the
 Install a package
 ~~~~~~~~~~~~~~~~~
 
-For example,let's install the
+For example, let's install the
 `Requests`_ library from the :term:`Python Package Index (PyPI)`:
 
 .. tab:: Unix/macOS

source/index.rst

@@ -79,7 +79,7 @@ topics.
 Explanations and Discussions
 ============================
 
-The :doc:`discussions/index` section for in-depth explanations and discussion
+The :doc:`discussions/index` section provides in-depth explanations and discussion
 about topics, such as:
 
 * :doc:`discussions/deploying-python-applications`

source/specifications/source-distribution-format.rst

@@ -5,7 +5,7 @@
 Source distribution format
 ==========================
 
-The current standard format of source distribution format is identified by the
+The current standard source distribution format is identified by the
 presence of a :file:`pyproject.toml` file in the distribution archive.  The layout
 of such a distribution was originally specified in :pep:`517` and is formally
 documented here.
@@ -27,7 +27,7 @@ Source trees
 
 A *source tree* is a collection of files and directories -- like a version
 control system checkout -- which contains a :file:`pyproject.toml` file that
-can be use to build a source distribution from the contained files and
+can be used to build a source distribution from the contained files and
 directories. :pep:`517` and :pep:`518` specify what is required to meet the
 definition of what :file:`pyproject.toml` must contain for something to be
 deemed a source tree.

source/specifications/version-specifiers.rst

@@ -226,7 +226,7 @@ part of the ``3.3`` release series.
    form to ``X.Y.0`` when comparing it to any release segment that includes
    three components.
 
-Date based release segments are also permitted. An example of a date based
+Date-based release segments are also permitted. An example of a date-based
 release scheme using the year and month of the release::
 
     2012.4