Medley of typo fixes

Author: ralexstokes

docs/guides/trinity/architecture.rst

@@ -99,7 +99,7 @@ The database process exposes several chain-related operations, all of which are
 single process. These aren't necessarily low-level get/set operations, but also include
 higher-level APIs, such as the :func:`~eth.chains.base.Chain.import_block` API.
 
-The way this works is by facilitazing Pythons :class:`~multiprocessing.managers.BaseManager` API
+The way this works is by utilizing Python's :class:`~multiprocessing.managers.BaseManager` API
 and exposing several :class:`~multiprocessing.managers.BaseProxy` proxies to coordinate
 inter-process access to these APIs.
 
@@ -109,17 +109,17 @@ that all database reads and writes are done by a single process.
 Networking Process
 ------------------
 
-The networking process is what kicks of the peer to peer communication and starts the syncing
+The networking process is what kicks off the peer to peer communication and starts the syncing
 process. It does so by running an instance of
 :func:`~trinity.nodes.base.Node` in an event loop.
 
 Notice that the instance of :func:`~trinity.nodes.base.Node` has access to the APIs that the
-database processes exposes. In pracice that means, that the network process controls the
-connections to other peers, starts of the syncing process but will call APIs that run inside
+database processes exposes. In practice that means that the network process controls the
+connections to other peers and starts the syncing process but will call APIs that run inside
 the database processes when it comes to actual importing of blocks or reading and writing of other
 things from the database.
 
-The networking process also host an instance of the
+The networking process also hosts an instance of the
 :class:`~trinity.extensibility.plugin_manager.PluginManager` to run plugins that need to deeply
 integrate with the networking process (Further reading:
 :doc:`Writing Plugins</guides/trinity/writing_plugins>`).

docs/guides/trinity/writing_plugins.rst

@@ -129,7 +129,7 @@ Plugin state: ``NOT_READY``
 
 Every plugin starts out being in the ``NOT_READY`` state. This state begins with the instantiation
 of the plugin and lasts until the :meth:`~trinity.extensibility.plugin.BasePlugin.on_ready` hook
-was called which happens as soon the core infrastructure of Trinity is ready.
+was called which happens as soon as the core infrastructure of Trinity is ready.
 
 Plugin state: ``READY``
 -----------------------
@@ -190,7 +190,7 @@ on, is a good way to deal with that. Implementing
 :meth:`~trinity.extensibility.plugin.BasePlugin.configure_parser` enables us to do exactly that.
 
 This method is called when Trinity starts and bootstraps the plugin system, in other words,
-**before** the start of any plugin. It is passed a :class:`~argparse.ArgumentParser` as well as a
+**before** the start of any plugin. It is passed an :class:`~argparse.ArgumentParser` as well as a
 :class:`~argparse._SubParsersAction` which allows it to amend the configuration of Trinity's
 command line arguments in many different ways.
 
@@ -332,7 +332,7 @@ Check out the `official documentation on entry points <https://packaging.python.
 for a deeper explanation.
 
 A plugin where the ``setup.py`` file is configured as described can be installed by
-``pip install <package-name>``` and immediately becomes available as a plugin in Trinity.
+``pip install <package-name>`` and immediately becomes available as a plugin in Trinity.
 
 .. note::
 

eth/chains/base.py

@@ -692,7 +692,7 @@ def import_block(self,
 
         - the imported block
         - a tuple of blocks which are now part of the canonical chain.
-        - a tuple of blocks which are were canonical and now are no longer canonical.
+        - a tuple of blocks which were canonical and now are no longer canonical.
         """
 
         try:

eth/db/chain.py

@@ -284,7 +284,7 @@ def _persist_uncles(db: BaseDB, uncles: Tuple[BlockHeader]) -> Hash32:
     #
     def add_receipt(self, block_header: BlockHeader, index_key: int, receipt: Receipt) -> Hash32:
         """
-        Adds the given receipt to the provide block header.
+        Adds the given receipt to the provided block header.
 
         Returns the updated `receipts_root` for updated block header.
         """
@@ -297,7 +297,7 @@ def add_transaction(self,
                         index_key: int,
                         transaction: 'BaseTransaction') -> Hash32:
         """
-        Adds the given transaction to the provide block header.
+        Adds the given transaction to the provided block header.
 
         Returns the updated `transactions_root` for updated block header.
         """
@@ -317,7 +317,7 @@ def get_block_transactions(
 
     def get_block_transaction_hashes(self, block_header: BlockHeader) -> Iterable[Hash32]:
         """
-        Returns an iterable of the transaction hashes from th block specified
+        Returns an iterable of the transaction hashes from the block specified
         by the given block header.
         """
         return self._get_block_transaction_hashes(self.db, block_header)

eth/vm/computation.py

@@ -544,14 +544,14 @@ def __exit__(self, exc_type: None, exc_value: None, traceback: None) -> None:
     @abstractmethod
     def apply_message(self) -> 'BaseComputation':
         """
-        Execution of an VM message.
+        Execution of a VM message.
         """
         raise NotImplementedError("Must be implemented by subclasses")
 
     @abstractmethod
     def apply_create_message(self) -> 'BaseComputation':
         """
-        Execution of an VM message to create a new contract.
+        Execution of a VM message to create a new contract.
         """
         raise NotImplementedError("Must be implemented by subclasses")