Fix misspellings

blog/01-how-you-implemented-your-python-decorator-is-wrong.md

@@ -125,7 +125,7 @@ original function object. When the now wrapped function is called, it is
 actually the ``__call__()`` method of the wrapper object which is invoked.
 This in turn would then call the original wrapped function.
 
-Simply passing through the call to the wrapper alone isnt particularly
+Simply passing through the call to the wrapper alone isn't particularly
 useful, so normally you would actually want to do some work either before
 or after the wrapped function is called. Or you may want to modify the
 input arguments or the result as they pass through the wrapper. This is

blog/08-the-synchronized-decorator-as-context-manager.md

@@ -1,7 +1,7 @@
 The @synchronized decorator as context manager
 ==============================================
 
-This is the eigth post in my series of blog posts about Python decorators
+This is the eight post in my series of blog posts about Python decorators
 and how I believe they are generally poorly implemented. It follows on from
 the previous post titled [The missing @synchronized
 decorator](07-the-missing-synchronized-decorator.md), with the very first

blog/14-automatic-patching-of-python-applications.md

@@ -14,7 +14,7 @@ where it has used:
 from module import function
 ```
 
-If we cant get in early enough, then it becomes necessary to monkey patch
+If we can't get in early enough, then it becomes necessary to monkey patch
 all such uses of a target function as well, which in the general case is
 impossible as we will not know where the function has been imported.
 
@@ -24,7 +24,7 @@ the module is even returned back to any code where it is being imported.
 This technique is still though dependent on the post import hook mechanism
 itself being installed before any other code is effectively run. This means
 having to manually modify the main Python script file for an application,
-something which isnt always practical.
+something which isn't always practical.
 
 The point of this post is to look at how we can avoid the need to even
 modify that main Python script file. For this there are a few techniques
@@ -135,7 +135,7 @@ In practice however, the code we will need is actually going to have to be
 slightly more complicated than this and as a result not something that can
 be readily added directly to a .pth file due to the limitation of code
 needing to all be on one line. What we will therefore do is put all our
-code in a separate module and execute it from there. We dont want to be too
+code in a separate module and execute it from there. We don't want to be too
 nasty and import that module every time though, perhaps scaring users when
 they see it imported even if not used, so we will gate even that by the
 presence of the environment variable.
@@ -149,7 +149,7 @@ import os, sys; os.environ.get('AUTOWRAPT_BOOTSTRAP') and __import__('autowrapt.
 That is, if the environment variable is set to a non empty value only then
 do we import our module containing our bootstrap code and execute it.
 
-As to the bootstrap code, this is where things get a bit messy. We cant
+As to the bootstrap code, this is where things get a bit messy. We can't
 just use the code we had used before when manually modifying the Python
 application script file. This is because of where in the Python interpreter
 initialisation the parsing of .pth files is done.
@@ -235,7 +235,7 @@ def bootstrap():
 
 Despite everything I have ever said about how manually constructed monkey
 patches is bad and that the wrapt module should be used for doing monkey
-patching, we cant actually use the wrapt module in this case. This is
+patching, we can't actually use the wrapt module in this case. This is
 because technically, as a user installed package, the wrapt package may not
 be usable at this point. This could occur where wrapt was installed in such
 a way that the ability to import it was itself dependent on the processing
@@ -307,7 +307,7 @@ within the site-packages directory.
 
 The only .pth file added to the site-packages directory will be that used
 to map that the autowrapt package exists in the sub directory. The
-addsitepackages() function called from the site module doesnt in turn
+addsitepackages() function called from the site module doesn't in turn
 process .pth files contained in a directory added by a .pth file, so our
 custom .pth file would be skipped.
 
@@ -346,7 +346,7 @@ So to run the test do:
 pip install autowrapt
 ```
 
-This should also install the wrapt module if you dont have the required
+This should also install the wrapt module if you don't have the required
 minimum version.
 
 Now run the command line interpreter as normal and at the prompt do:
@@ -384,7 +384,7 @@ import this
 
 we should now see an extended version of the Zen of Python.
 
-We didnt actually monkey patch any code in the target module in this case,
+We didn't actually monkey patch any code in the target module in this case,
 but it shows that the monkey patch function was actually triggered when
 expected.
 

docs/changes.rst

@@ -110,7 +110,7 @@ Version 1.10.1
   then calling the method was causing an unwanted reference to the instance
   meaning that if the instance was transient, it would leak.
 
-  This was only occuring when the C extension component for the
+  This was only occurring when the C extension component for the
   ``wrapt`` module was being used.
 
 Version 1.10.0
@@ -310,12 +310,12 @@ Version 1.6.0
   even though the wrapped object didn't have one. Similarly, callable()
   would always return True even if the wrapped object was not callable.
 
-  This resulted due to the existance of the __call__() method on the
+  This resulted due to the existence of the __call__() method on the
   wrapper, required to support the possibility that the wrapped object
   may be called via the proxy object even if it may not turn out that
   the wrapped object was callable.
 
-  Because checking for the existance of a __call__() method or using
+  Because checking for the existence of a __call__() method or using
   callable() can sometimes be used to indirectly infer the type of an
   object, this could cause issues. To ensure that this now doesn't
   occur, the ability to call a wrapped object via the proxy object has
@@ -367,7 +367,7 @@ Version 1.4.2
 * A process could crash if the C extension module was used and when using
   the ObjectProxy class a reference count cycle was created that required
   the Python garbage collector to kick in to break the cycle. This was
-  occuring as the C extension had not implemented GC support in the
+  occurring as the C extension had not implemented GC support in the
   ObjectProxy class correctly.
 
 Version 1.4.1
@@ -509,7 +509,7 @@ Version 1.1.1
 
 **Bugs Fixed**
 
-* Python object memory leak was occuring due to incorrect increment of
+* Python object memory leak was occurring due to incorrect increment of
   object reference count in C implementation of object proxy when an
   instance method was called via the class and the instance passed in
   explicitly.

src/wrapt/_wrappers.c

@@ -2678,7 +2678,7 @@ moduleinit(void)
     if (PyType_Ready(&WraptObjectProxy_Type) < 0)
         return NULL;
 
-    /* Ensure that inheritence relationships specified. */
+    /* Ensure that inheritance relationships specified. */
 
     WraptCallableObjectProxy_Type.tp_base = &WraptObjectProxy_Type;
     WraptFunctionWrapperBase_Type.tp_base = &WraptObjectProxy_Type;

src/wrapt/wrappers.py

@@ -440,7 +440,7 @@ class _FunctionWrapperBase(ObjectProxy):
         #
         # The distinguishing attribute which determines whether we are
         # being called in an unbound or bound wrapper is the parent
-        # attribute. If binding has never occured, then the parent will
+        # attribute. If binding has never occurred, then the parent will
         # be None.
         #
         # First therefore, is if we are called in an unbound wrapper. In
@@ -467,7 +467,7 @@ class _FunctionWrapperBase(ObjectProxy):
 
             return self
 
-        # Now we have the case of binding occuring a second time on what
+        # Now we have the case of binding occurring a second time on what
         # was already a bound function. In this case we would usually
         # return ourselves again. This mirrors what Python does.
         #
@@ -702,7 +702,7 @@ def resolve_path(module, name):
         # to work. For the case of a class we therefore access
         # the __dict__ directly. To cope though with the wrong
         # class being given to us, or a method being moved into
-        # a base class, we need to walk the class heirarchy to
+        # a base class, we need to walk the class hierarchy to
         # work out exactly which __dict__ the method was defined
         # in, as accessing it from __dict__ will fail if it was
         # not actually on the class given. Fallback to using