7 files changed, 13 insertions, 13 deletions
diff --git a/lib/sqlalchemy/dialects/firebird/kinterbasdb.py b/lib/sqlalchemy/dialects/firebird/kinterbasdb.py
index b8a83a07b..afd62ffd3 100644
--- a/lib/sqlalchemy/dialects/firebird/kinterbasdb.py
+++ b/lib/sqlalchemy/dialects/firebird/kinterbasdb.py
@@ -24,7 +24,7 @@ also accepts the following:
 
 * ``concurrency_level`` - set the backend policy with regards to threading
   issues: by default SQLAlchemy uses policy 1.  See the linked documents
-  below for futher information.
+  below for further information.
 
 .. seealso::
 
diff --git a/lib/sqlalchemy/dialects/mysql/zxjdbc.py b/lib/sqlalchemy/dialects/mysql/zxjdbc.py
index b5fcfbdaf..5f8825f36 100644
--- a/lib/sqlalchemy/dialects/mysql/zxjdbc.py
+++ b/lib/sqlalchemy/dialects/mysql/zxjdbc.py
@@ -19,7 +19,7 @@ SQLAlchemy zxjdbc dialects pass unicode straight through to the
 zxjdbc/JDBC layer. To allow multiple character sets to be sent from the
 MySQL Connector/J JDBC driver, by default SQLAlchemy sets its
 ``characterEncoding`` connection property to ``UTF-8``. It may be
-overriden via a ``create_engine`` URL parameter.
+overridden via a ``create_engine`` URL parameter.
 
 """
 import re
diff --git a/lib/sqlalchemy/dialects/oracle/base.py b/lib/sqlalchemy/dialects/oracle/base.py
index 8bacb885f..5dcc93f79 100644
--- a/lib/sqlalchemy/dialects/oracle/base.py
+++ b/lib/sqlalchemy/dialects/oracle/base.py
@@ -961,7 +961,7 @@ class OracleDialect(default.DefaultDialect):
     def get_table_names(self, connection, schema=None, **kw):
         schema = self.denormalize_name(schema or self.default_schema_name)
 
-        # note that table_names() isnt loading DBLINKed or synonym'ed tables
+        # note that table_names() isn't loading DBLINKed or synonym'ed tables
         if schema is None:
             schema = self.default_schema_name
         s = sql.text(
diff --git a/lib/sqlalchemy/dialects/oracle/cx_oracle.py b/lib/sqlalchemy/dialects/oracle/cx_oracle.py
index b8ee90b53..d485820f9 100644
--- a/lib/sqlalchemy/dialects/oracle/cx_oracle.py
+++ b/lib/sqlalchemy/dialects/oracle/cx_oracle.py
@@ -255,7 +255,7 @@ The "decimal point is present" logic itself is also sensitive to
 locale.  Under OCI_, this is controlled by the NLS_LANG
 environment variable. Upon first connection, the dialect runs a
 test to determine the current "decimal" character, which can be
-a comma "," for european locales. From that point forward the
+a comma "," for European locales. From that point forward the
 outputtypehandler uses that character to represent a decimal
 point. Note that cx_oracle 5.0.3 or greater is required
 when dealing with numerics with locale settings that don't use
@@ -741,7 +741,7 @@ class OracleDialect_cx_oracle(OracleDialect):
 
     def _detect_decimal_char(self, connection):
         """detect if the decimal separator character is not '.', as
-        is the case with european locale settings for NLS_LANG.
+        is the case with European locale settings for NLS_LANG.
 
         cx_oracle itself uses similar logic when it formats Python
         Decimal objects to strings on the bind side (as of 5.0.3),
diff --git a/lib/sqlalchemy/dialects/postgresql/hstore.py b/lib/sqlalchemy/dialects/postgresql/hstore.py
index 76562088d..74419460b 100644
--- a/lib/sqlalchemy/dialects/postgresql/hstore.py
+++ b/lib/sqlalchemy/dialects/postgresql/hstore.py
@@ -52,7 +52,7 @@ def _parse_error(hstore_str, pos):
 
 
 def _parse_hstore(hstore_str):
-    """Parse an hstore from it's literal string representation.
+    """Parse an hstore from its literal string representation.
 
     Attempts to approximate PG's hstore input parsing rules as closely as
     possible. Although currently this is not strictly necessary, since the
diff --git a/lib/sqlalchemy/dialects/postgresql/psycopg2.py b/lib/sqlalchemy/dialects/postgresql/psycopg2.py
index 714b9618c..c4f7c032d 100644
--- a/lib/sqlalchemy/dialects/postgresql/psycopg2.py
+++ b/lib/sqlalchemy/dialects/postgresql/psycopg2.py
@@ -102,7 +102,7 @@ This overrides the encoding specified in the Postgresql client configuration.
     :func:`.create_engine`.
 
 SQLAlchemy can also be instructed to skip the usage of the psycopg2
-``UNICODE`` extension and to instead utilize it's own unicode encode/decode
+``UNICODE`` extension and to instead utilize its own unicode encode/decode
 services, which are normally reserved only for those DBAPIs that don't
 fully support unicode directly.  Passing ``use_native_unicode=False`` to
 :func:`.create_engine` will disable usage of ``psycopg2.extensions.UNICODE``.
@@ -169,7 +169,7 @@ connection, a sequence like the following is performed:
    If this function returns a list of HSTORE identifiers, we then determine that
    the ``HSTORE`` extension is present.
 
-2. If the ``use_native_hstore`` flag is at it's default of ``True``, and
+2. If the ``use_native_hstore`` flag is at its default of ``True``, and
    we've detected that ``HSTORE`` oids are available, the
    ``psycopg2.extensions.register_hstore()`` extension is invoked for all
    connections.
diff --git a/lib/sqlalchemy/dialects/sqlite/base.py b/lib/sqlalchemy/dialects/sqlite/base.py
index 90df9c192..7687493b2 100644
--- a/lib/sqlalchemy/dialects/sqlite/base.py
+++ b/lib/sqlalchemy/dialects/sqlite/base.py
@@ -100,7 +100,7 @@ table.
 Constraint checking on SQLite has three prerequisites:
 
 * At least version 3.6.19 of SQLite must be in use
-* The SQLite libary must be compiled *without* the SQLITE_OMIT_FOREIGN_KEY
+* The SQLite library must be compiled *without* the SQLITE_OMIT_FOREIGN_KEY
   or SQLITE_OMIT_TRIGGER symbols enabled.
 * The ``PRAGMA foreign_keys = ON`` statement must be emitted on all connections
   before use.
@@ -244,7 +244,7 @@ class DATETIME(_DateTimeMixin, sqltypes.DateTime):
     :param regexp: regular expression which will be applied to incoming result
      rows. If the regexp contains named groups, the resulting match dict is
      applied to the Python datetime() constructor as keyword arguments.
-     Otherwise, if positional groups are used, the the datetime() constructor
+     Otherwise, if positional groups are used, the datetime() constructor
      is called with positional arguments via
      ``*map(int, match_obj.groups(0))``.
     """
@@ -337,7 +337,7 @@ class DATE(_DateTimeMixin, sqltypes.Date):
      incoming result rows. If the regexp contains named groups, the
      resulting match dict is applied to the Python date() constructor
      as keyword arguments. Otherwise, if positional groups are used, the
-     the date() constructor is called with positional arguments via
+     date() constructor is called with positional arguments via
      ``*map(int, match_obj.groups(0))``.
     """
 
@@ -397,7 +397,7 @@ class TIME(_DateTimeMixin, sqltypes.Time):
     :param regexp: regular expression which will be applied to incoming result
      rows. If the regexp contains named groups, the resulting match dict is
      applied to the Python time() constructor as keyword arguments. Otherwise,
-     if positional groups are used, the the time() constructor is called with
+     if positional groups are used, the time() constructor is called with
      positional arguments via ``*map(int, match_obj.groups(0))``.
     """
 
@@ -874,7 +874,7 @@ class SQLiteDialect(default.DefaultDialect):
     def _resolve_type_affinity(self, type_):
         """Return a data type from a reflected column, using affinity tules.
 
-        SQLite's goal for universal compatability introduces some complexity
+        SQLite's goal for universal compatibility introduces some complexity
         during reflection, as a column's defined type might not actually be a
         type that SQLite understands - or indeed, my not be defined *at all*.
         Internally, SQLite handles this with a 'data type affinity' for each