-whitespace bonanza, contd

1 files changed, 11 insertions, 11 deletions

diff --git a/lib/sqlalchemy/dialects/mssql/pyodbc.py b/lib/sqlalchemy/dialects/mssql/pyodbc.py
index 17dcbfecd..b3b1641e0 100644
--- a/lib/sqlalchemy/dialects/mssql/pyodbc.py
+++ b/lib/sqlalchemy/dialects/mssql/pyodbc.py
@@ -35,14 +35,14 @@ Examples of pyodbc connection string URLs:
 
     dsn=mydsn;UID=user;PWD=pass;LANGUAGE=us_english
 
-* ``mssql+pyodbc://user:pass@host/db`` - connects using a connection 
+* ``mssql+pyodbc://user:pass@host/db`` - connects using a connection
   that would appear like::
 
     DRIVER={SQL Server};Server=host;Database=db;UID=user;PWD=pass
 
 * ``mssql+pyodbc://user:pass@host:123/db`` - connects using a connection
   string which includes the port
-  information using the comma syntax. This will create the following 
+  information using the comma syntax. This will create the following
   connection string::
 
     DRIVER={SQL Server};Server=host,123;Database=db;UID=user;PWD=pass
@@ -83,9 +83,9 @@ the python shell. For example::
 Unicode Binds
 ^^^^^^^^^^^^^
 
-The current state of PyODBC on a unix backend with FreeTDS and/or 
+The current state of PyODBC on a unix backend with FreeTDS and/or
 EasySoft is poor regarding unicode; different OS platforms and versions of UnixODBC
-versus IODBC versus FreeTDS/EasySoft versus PyODBC itself dramatically 
+versus IODBC versus FreeTDS/EasySoft versus PyODBC itself dramatically
 alter how strings are received.  The PyODBC dialect attempts to use all the information
 it knows to determine whether or not a Python unicode literal can be
 passed directly to the PyODBC driver or not; while SQLAlchemy can encode
@@ -93,13 +93,13 @@ these to bytestrings first, some users have reported that PyODBC mis-handles
 bytestrings for certain encodings and requires a Python unicode object,
 while the author has observed widespread cases where a Python unicode
 is completely misinterpreted by PyODBC, particularly when dealing with
-the information schema tables used in table reflection, and the value 
+the information schema tables used in table reflection, and the value
 must first be encoded to a bytestring.
 
 It is for this reason that whether or not unicode literals for bound
-parameters be sent to PyODBC can be controlled using the 
-``supports_unicode_binds`` parameter to ``create_engine()``.  When 
-left at its default of ``None``, the PyODBC dialect will use its 
+parameters be sent to PyODBC can be controlled using the
+``supports_unicode_binds`` parameter to ``create_engine()``.  When
+left at its default of ``None``, the PyODBC dialect will use its
 best guess as to whether or not the driver deals with unicode literals
 well.  When ``False``, unicode literals will be encoded first, and when
 ``True`` unicode literals will be passed straight through.  This is an interim
@@ -199,7 +199,7 @@ class MSExecutionContext_pyodbc(MSExecutionContext):
 
         super(MSExecutionContext_pyodbc, self).pre_exec()
 
-        # don't embed the scope_identity select into an 
+        # don't embed the scope_identity select into an
         # "INSERT .. DEFAULT VALUES"
         if self._select_lastrowid and \
                 self.dialect.use_scope_identity and \
@@ -211,11 +211,11 @@ class MSExecutionContext_pyodbc(MSExecutionContext):
     def post_exec(self):
         if self._embedded_scope_identity:
             # Fetch the last inserted id from the manipulated statement
-            # We may have to skip over a number of result sets with 
+            # We may have to skip over a number of result sets with
             # no data (due to triggers, etc.)
             while True:
                 try:
-                    # fetchall() ensures the cursor is consumed 
+                    # fetchall() ensures the cursor is consumed
                     # without closing it (FreeTDS particularly)
                     row = self.cursor.fetchall()[0]
                     break