Fix many spell glitches

This affects mostly docstrings, except in orm/events.py::dispose_collection()
where one parameter gets renamed: given that the method is
empty, it seemed reasonable to me to fix that too.

Closes: #4440
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/4440
Pull-request-sha: 779ed75acb6142e1f1daac467b5b14134529bb4b

Change-Id: Ic0553fe97853054b09c2453af76d96363de6eb0e

11 files changed, 19 insertions, 19 deletions

diff --git a/doc/build/orm/basic_relationships.rst b/doc/build/orm/basic_relationships.rst
index 2836fe94c..cf37440cb 100644
--- a/doc/build/orm/basic_relationships.rst
+++ b/doc/build/orm/basic_relationships.rst
@@ -271,7 +271,7 @@ There are several possibilities here:
   suppose it's called ``Child.parents``, SQLAlchemy by default will load in
   the ``Child.parents`` collection to locate all ``Parent`` objects, and remove
   each row from the "secondary" table which establishes this link.  Note that
-  this relationship does not need to be bidrectional; SQLAlchemy is strictly
+  this relationship does not need to be bidirectional; SQLAlchemy is strictly
   looking at every :func:`.relationship` associated with the ``Child`` object
   being deleted.
 * A higher performing option here is to use ON DELETE CASCADE directives
diff --git a/doc/build/orm/collections.rst b/doc/build/orm/collections.rst
index abd969933..9e49f7c1e 100644
--- a/doc/build/orm/collections.rst
+++ b/doc/build/orm/collections.rst
@@ -353,7 +353,7 @@ Custom Collection Implementations
 =================================
 
 You can use your own types for collections as well.  In simple cases,
-inherting from ``list`` or ``set``, adding custom behavior, is all that's needed.
+inheriting from ``list`` or ``set``, adding custom behavior, is all that's needed.
 In other cases, special decorators are needed to tell SQLAlchemy more detail
 about how the collection operates.
 
diff --git a/doc/build/orm/extensions/declarative/mixins.rst b/doc/build/orm/extensions/declarative/mixins.rst
index d703469b5..52907ac7c 100644
--- a/doc/build/orm/extensions/declarative/mixins.rst
+++ b/doc/build/orm/extensions/declarative/mixins.rst
@@ -499,7 +499,7 @@ Combining Table/Mapper Arguments from Multiple Mixins
 In the case of ``__table_args__`` or ``__mapper_args__``
 specified with declarative mixins, you may want to combine
 some parameters from several mixins with those you wish to
-define on the class iteself. The
+define on the class itself. The
 :class:`.declared_attr` decorator can be used
 here to create user-defined collation routines that pull
 from multiple collections::
diff --git a/doc/build/orm/inheritance.rst b/doc/build/orm/inheritance.rst
index f371b65c4..cd796f7a7 100644
--- a/doc/build/orm/inheritance.rst
+++ b/doc/build/orm/inheritance.rst
@@ -19,7 +19,7 @@ return objects of multiple types.
 
 .. seealso::
 
-    :ref:`examples_inheritance` - complete exampes of joined, single and
+    :ref:`examples_inheritance` - complete examples of joined, single and
     concrete inheritance
 
 .. _joined_inheritance:
@@ -652,7 +652,7 @@ The :class:`.AbstractConcreteBase` helper class has a more complex internal
 process than that of :class:`.ConcreteBase`, in that the entire mapping
 of the base class must be delayed until all the subclasses have been declared.
 With a mapping like the above, only instances of ``Manager`` and ``Engineer``
-may be persised; querying against the ``Employee`` class will always produce
+may be persisted; querying against the ``Employee`` class will always produce
 ``Manager`` and ``Engineer`` objects.
 
 .. seealso::
diff --git a/doc/build/orm/inheritance_loading.rst b/doc/build/orm/inheritance_loading.rst
index 09631c6c2..7b88b25a5 100644
--- a/doc/build/orm/inheritance_loading.rst
+++ b/doc/build/orm/inheritance_loading.rst
@@ -327,7 +327,7 @@ The :func:`.orm.with_polymorphic` function evolved from a query-level
 method :meth:`.Query.with_polymorphic`.  This method has the same purpose
 as :func:`.orm.with_polymorphic`, except is not as
 flexible in its usage patterns in that it only applies to the first entity
-of the :class:`.Query`.   It then takes effect for all occurences of
+of the :class:`.Query`.   It then takes effect for all occurrences of
 that entity, so that the entity (and its subclasses) can be referred to
 directly, rather than using an alias object.  For simple cases it might be
 considered to be more succinct::
@@ -493,7 +493,7 @@ With careful planning, selectin loading can be applied against a hierarchy
 that itself uses "with_polymorphic".  A particular use case is that of
 using selectin loading to load a joined-inheritance subtable, which then
 uses "with_polymorphic" to refer to further sub-classes, which may be
-joined- or single-table inheritanace.  If we added a class ``VicePresident`` that
+joined- or single-table inheritance.  If we added a class ``VicePresident`` that
 extends ``Manager`` using single-table inheritance, we could ensure that
 a load of ``Manager`` also fully loads ``VicePresident`` subtypes at the same time::
 
diff --git a/doc/build/orm/join_conditions.rst b/doc/build/orm/join_conditions.rst
index 62da15aa8..e9c51c14d 100644
--- a/doc/build/orm/join_conditions.rst
+++ b/doc/build/orm/join_conditions.rst
@@ -360,7 +360,7 @@ particular ``Magazine``, but then associate the ``Article`` with a
 ``Writer`` that's  associated  with a *different* ``Magazine``, the ORM
 will overwrite ``Article.magazine_id`` non-deterministically, silently
 changing which magazine we refer towards; it may
-also attempt to place NULL into this columnn if we de-associate a
+also attempt to place NULL into this column if we de-associate a
 ``Writer`` from an ``Article``.  The warning lets us know this is the case.
 
 To solve this, we need to break out the behavior of ``Article`` to include
diff --git a/doc/build/orm/loading_relationships.rst b/doc/build/orm/loading_relationships.rst
index 4a57aad34..01f65dab1 100644
--- a/doc/build/orm/loading_relationships.rst
+++ b/doc/build/orm/loading_relationships.rst
@@ -362,7 +362,7 @@ an OUTER JOIN:
 
 On older versions of SQLite, the above nested right JOIN may be re-rendered
 as a nested subquery.  Older versions of SQLAlchemy would convert right-nested
-joins into subuqeries in all cases.
+joins into subqueries in all cases.
 
 Joined eager loading and result set batching
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -733,7 +733,7 @@ Above, the second SELECT refers to ``addresses.user_id IN (5, 7)``, where the
 "5" and "7" are the primary key values for the previous two ``User``
 objects loaded; after a batch of objects are completely loaded, their primary
 key values are injected into the ``IN`` clause for the second SELECT.
-Because the relatonship between ``User`` and ``Address`` provides that the
+Because the relationship between ``User`` and ``Address`` provides that the
 primary key values for ``User`` can be derived from ``Address.user_id``, the
 statement has no joins or subqueries at all.
 
@@ -927,7 +927,7 @@ references a scalar many-to-one reference.
 Polymorphic Eager Loading
 -------------------------
 
-Specification of polymorpic options on a per-eager-load basis is supported.
+Specification of polymorphic options on a per-eager-load basis is supported.
 See the section :ref:`eagerloading_polymorphic_subtypes` for examples
 of the :meth:`.PropComparator.of_type` method in conjunction with the
 :func:`.orm.with_polymorphic` function.
diff --git a/doc/build/orm/persistence_techniques.rst b/doc/build/orm/persistence_techniques.rst
index c25c68e17..ec13ff782 100644
--- a/doc/build/orm/persistence_techniques.rst
+++ b/doc/build/orm/persistence_techniques.rst
@@ -481,7 +481,7 @@ flushes objects of type ``User`` and ``Account``.
 
 In the more common case, there are typically base or mixin classes that  can be
 used to distinguish between operations that are destined for different database
-connections.  The :paramref:`.Session.binds` argument can accomodate any
+connections.  The :paramref:`.Session.binds` argument can accommodate any
 arbitrary Python class as a key, which will be used if it is found to be in the
 ``__mro__`` (Python method resolution order) for a particular  mapped class.
 Supposing two declarative bases are representing two different database
@@ -657,7 +657,7 @@ to this approach is strictly one of reduced Python overhead:
   perform vastly better than individual statement invocations.
 
 * UPDATE statements can similarly be tailored such that all attributes
-  are subject to the SET clase unconditionally, again making it much more
+  are subject to the SET clause unconditionally, again making it much more
   likely that ``executemany()`` blocks can be used.
 
 The performance behavior of the bulk routines should be studied using the
diff --git a/doc/build/orm/session_events.rst b/doc/build/orm/session_events.rst
index 7901d8f4a..319ab3c66 100644
--- a/doc/build/orm/session_events.rst
+++ b/doc/build/orm/session_events.rst
@@ -21,7 +21,7 @@ Probably the most widely used series of events are the "persistence" events,
 which correspond to the :ref:`flush process<session_flushing>`.
 The flush is where all the decisions are made about pending changes to
 objects and are then emitted out to the database in the form of INSERT,
-UPDATE, and DELETE staetments.
+UPDATE, and DELETE statements.
 
 ``before_flush()``
 ^^^^^^^^^^^^^^^^^^
@@ -33,7 +33,7 @@ Use :meth:`.SessionEvents.before_flush` in order to operate
 upon objects to validate their state as well as to compose additional objects
 and references before they are persisted.   Within this event,
 it is **safe to manipulate the Session's state**, that is, new objects
-can be attached to it, objects can be deleted, and indivual attributes
+can be attached to it, objects can be deleted, and individual attributes
 on objects can be changed freely, and these changes will be pulled into
 the flush process when the event hook completes.
 
@@ -390,7 +390,7 @@ moving back to the persistent state using the
 Transaction Events
 ------------------
 
-Transaction events allow an application to be notifed when transaction
+Transaction events allow an application to be notified when transaction
 boundaries occur at the :class:`.Session` level as well as when the
 :class:`.Session` changes the transactional state on :class:`.Connection`
 objects.
diff --git a/doc/build/orm/session_state_management.rst b/doc/build/orm/session_state_management.rst
index 7387ee637..2730bb8b2 100644
--- a/doc/build/orm/session_state_management.rst
+++ b/doc/build/orm/session_state_management.rst
@@ -552,7 +552,7 @@ or loaded with :meth:`~.Session.refresh` varies based on several factors, includ
 * :func:`.relationship` attributes configured as "eager loading" via the
   :paramref:`~.relationship.lazy` parameter will load in the case of
   :meth:`~.Session.refresh`, if either no attribute names are specified, or
-  if their names are inclued in the list of attributes to be
+  if their names are included in the list of attributes to be
   refreshed.
 
 * Attributes that are configured as :func:`.deferred` will not normally load,
diff --git a/doc/build/orm/session_transaction.rst b/doc/build/orm/session_transaction.rst
index 6b33a6878..a9e4591bc 100644
--- a/doc/build/orm/session_transaction.rst
+++ b/doc/build/orm/session_transaction.rst
@@ -163,7 +163,7 @@ complete.
 
     "autocommit" mode is a **legacy mode of use** and should not be
     considered for new projects.   If autocommit mode is used, it is strongly
-    advised that the application at least ensure that tranasction scope
+    advised that the application at least ensure that transaction scope
     is made present via the :meth:`.Session.begin` method, rather than
     using the session in pure autocommit mode.
 
@@ -262,7 +262,7 @@ where the end user still maintains the "scope" of the transaction overall.
 Enabling Two-Phase Commit
 -------------------------
 
-For backends which support two-phase operaration (currently MySQL and
+For backends which support two-phase operation (currently MySQL and
 PostgreSQL), the session can be instructed to use two-phase commit semantics.
 This will coordinate the committing of transactions across databases so that
 the transaction is either committed or rolled back in all databases. You can