Apply suggestions from code review

Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com> Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
python · brettcannon · Jul 24, 2024 · Mar 20, 2024 · Mar 21, 2024 · Mar 21, 2024
commit a914c12ed81473316a3124745d3e66ea74223203
@@ -631,7 +631,7 @@ An example workflow is:
   "best" file to install
 - If no file is found, check for ``[package.vcs]``
 - If no match is found, an error MUST be raised
-- Find and verify the selected files and/or CVS entries based on their hash or
+- Find and verify the selected files and/or VCS entries based on their hash or
   commit ID as appropriate
 - If the match is a source distribution or VCS and
   ``[[package.build-requires]]`` is provided, repeat the above as appropriate to
@@ -670,7 +670,7 @@ within the file in a ``[tool]`` entry or via a side channel external to the lock
 file itself.
 
 This PEP does not do anything to prevent a user from installing an incorrect
-package. While including many details to help in audting a package's inclusion,
+package. While including many details to help in auditing a package's inclusion,
 there isn't any mechanism to stop e.g. name confusion attacks via typosquatting.
 Lockers may be able to provide some UX to help with this (e.g. by providing
 download counts for a package).
@@ -683,13 +683,13 @@ How to Teach This
 Users should be informed that when they ask to install some package, that
 package may have its own dependencies, those dependencies may have dependencies,
 and so on. Without writing down what gets installed as part of installing the
-package they requested, things could change from underneatch them (e.g. package
+package they requested, things could change from underneath them (e.g. package
 versions). Changes to the underlying dependencies can lead to accidental
 breakage of their code. Lock files help deal with that by providing a way to
 write down what was installed.
 
-Having what to install written down also helps in collabortaing with others. By
-agreeing to a lock file's contents, everyone to end up with the same packages
+Having what to install written down also helps in collaborating with others. By
+agreeing to a lock file's contents, everyone ends up with the same packages
 installed. This helps make sure no one relies on e.g. an API that's only
 available in a certain version that not everyone working on the project has
 installed.
@@ -705,15 +705,15 @@ Reference Implementation
 ========================
 
 A rough proof-of-concept for per-file locking can be found at
-https://github.com/brettcannon/mousebender/tree/pep . An example lock file can
+https://github.com/brettcannon/mousebender/tree/pep. An example lock file can
 be seen at
-https://github.com/brettcannon/mousebender/blob/pep/pylock.example.toml .
+https://github.com/brettcannon/mousebender/blob/pep/pylock.example.toml.
 
 For per-package locking, PDM_ indirectly proves the approach works as this PEP
 maintains equivalent data as PDM does for its lock files (whose format was
 inspired by Poetry_). Some of the details of PDM's approach are covered in
 https://frostming.com/en/2024/pdm-lockfile/ and
-https://frostming.com/en/2024/pdm-lock-strategy/ .
+https://frostming.com/en/2024/pdm-lock-strategy/.
 
 
 ==============
@@ -771,7 +771,7 @@ Requiring specific hash algorithm support
 It was proposed to require a baseline hash algorithm for the files. This was
 rejected as no other Python packaging specification requires specific hash
 algorithm support. As well, the minimum hash algorithm suggested may eventually
-become an outdated/unsafe suggetion, requiring further updates. In order to
+become an outdated/unsafe suggestion, requiring further updates. In order to
 promote using the best algorithm at all times, no baseline is provided to avoid
 simply defaulting to the baseline in tools without considering the security
 ramifications of that hash algorithm.
@@ -802,7 +802,7 @@ knowledge about the file extension.
 Not having a naming convention for the file
 ===========================================
 
-Having not requirements or guidance for a lock file's name was considered, but
+Having no requirements or guidance for a lock file's name was considered, but
 ultimately rejected. By having a standardized naming convention it makes it easy
 to identify a lock file for both a human and a code editor. This helps
 facilitate discovery when e.g. a tool wants to know all of the lock files that