Fix typos.

docs/changes.rst

@@ -83,7 +83,7 @@ Version 1.10.2
 **Bugs Fixed**
 
 * When creating a derived ``ObjectProxy``, if the base class ``__init__()``
-  method wasn't called and the the ``__wrapped__`` attribute was accessed,
+  method wasn't called and the ``__wrapped__`` attribute was accessed,
   in the pure Python implementation a recursive call of ``__getattr__()``
   would occur and the maximum stack depth would be reached and an exception
   raised.
@@ -549,7 +549,7 @@ Version 1.1.0
 * When deriving from ObjectProxy, and the C extension variant
   was being used, if a derived class __init__() attempted to update
   attributes, even the special '_self_' attributed before calling the base
-  class __init__() methid, then an exception would be raised indicating
+  class __init__() method, then an exception would be raised indicating
   that the 'wrapper has not been initialised'.
 
 Version 1.0.0

docs/decorators.rst

@@ -319,7 +319,7 @@ not. This is therefore a global switch and once disabled it cannot be
 dynamically re-enabled at runtime while the process is executing.
 Similarly, once enabled it cannot be disabled.
 
-An alternative to suppling a literal boolean, is to provide a callable
+An alternative to supplying a literal boolean, is to provide a callable
 for ``enabled`` which will yield a boolean value.
 
 ::

docs/examples.rst

@@ -18,7 +18,7 @@ associating a thread mutex with a specific context and when a function is
 called the lock is acquired prior to the call and then released once the
 function returns.
 
-The simplist example of a decorator for synchronization is one where the
+The simplest example of a decorator for synchronization is one where the
 lock is explicitly provided when the decorator is applied to a function. By
 being supplied explicitly, it is up to the user of the decorator to
 determine what context the lock applies to. For example, a lock may be
@@ -409,7 +409,7 @@ frowned on by some, but the implementation would be as follows.
 
         if hasattr(wrapped, 'acquire') and hasattr(wrapped, 'release'):
             # We remember what the original lock is and then return a new
-            # decorator which acceses and locks it. When returning the new
+            # decorator which accesses and locks it. When returning the new
             # decorator we wrap it with an object proxy so we can override
             # the context manager methods in case it is being used to wrap
             # synchronized statements with a 'with' statement.
@@ -439,7 +439,7 @@ frowned on by some, but the implementation would be as follows.
         # automatically based on the context of what was supplied. In
         # this case we supply a final decorator, but need to use
         # FunctionWrapper directly as we want to derive from it to add
-        # context manager methods in in case it is being used to wrap
+        # context manager methods in case it is being used to wrap
         # synchronized statements with a 'with' statement.
 
         def _synchronized_lock(context):

docs/wrappers.rst

@@ -295,7 +295,7 @@ definition.
     AttributeError: 'int' object has no attribute 'attribute'
 
 Alternatively, the attribute can be specified as a class attribute, with
-that then being overidden if necessary, with a specific value in the
+that then being overridden if necessary, with a specific value in the
 ``__init__()`` method of the class.
 
 ::
@@ -457,7 +457,7 @@ It would be used like:
         pass
 
 This example of a simplified decorator factory is made available as
-``wrapt.function_wrapper``. Although it is usuable in its own right, it is
+``wrapt.function_wrapper``. Although it is usable in its own right, it is
 preferable that ``wrapt.decorator`` be used to create decorators as it
 provides additional features. The ``@function_wrapper`` decorator would
 generally be used more when performing monkey patching and needing to

src/wrapt/decorators.py

@@ -424,7 +424,7 @@ def synchronized(wrapped):
 
     if hasattr(wrapped, 'acquire') and hasattr(wrapped, 'release'):
         # We remember what the original lock is and then return a new
-        # decorator which acceses and locks it. When returning the new
+        # decorator which accesses and locks it. When returning the new
         # decorator we wrap it with an object proxy so we can override
         # the context manager methods in case it is being used to wrap
         # synchronized statements with a 'with' statement.
@@ -453,7 +453,7 @@ def synchronized(wrapped):
     # Following only apply when the lock is being created automatically
     # based on the context of what was supplied. In this case we supply
     # a final decorator, but need to use FunctionWrapper directly as we
-    # want to derive from it to add context manager methods in in case it is
+    # want to derive from it to add context manager methods in case it is
     # being used to wrap synchronized statements with a 'with' statement.
 
     def _synchronized_lock(context):