From dede3c67a8d2149a7ef801f8f34cca31f29406c3 Mon Sep 17 00:00:00 2001 From: stepshal Date: Sun, 26 Jun 2016 01:16:40 +0700 Subject: [PATCH] Fix misspellings --- ...implemented-your-python-decorator-is-wrong.md | 2 +- ...-synchronized-decorator-as-context-manager.md | 2 +- ...-automatic-patching-of-python-applications.md | 16 ++++++++-------- docs/changes.rst | 10 +++++----- src/wrapt/_wrappers.c | 2 +- src/wrapt/wrappers.py | 6 +++--- 6 files changed, 19 insertions(+), 19 deletions(-) diff --git a/blog/01-how-you-implemented-your-python-decorator-is-wrong.md b/blog/01-how-you-implemented-your-python-decorator-is-wrong.md index 9155568..0b9ba3b 100644 --- a/blog/01-how-you-implemented-your-python-decorator-is-wrong.md +++ b/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 diff --git a/blog/08-the-synchronized-decorator-as-context-manager.md b/blog/08-the-synchronized-decorator-as-context-manager.md index 7713bd8..652c9d4 100644 --- a/blog/08-the-synchronized-decorator-as-context-manager.md +++ b/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 diff --git a/blog/14-automatic-patching-of-python-applications.md b/blog/14-automatic-patching-of-python-applications.md index 6951c6e..0dbc5bf 100644 --- a/blog/14-automatic-patching-of-python-applications.md +++ b/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. diff --git a/docs/changes.rst b/docs/changes.rst index a4b00ff..f1c5325 100644 --- a/docs/changes.rst +++ b/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. diff --git a/src/wrapt/_wrappers.c b/src/wrapt/_wrappers.c index 9194f54..ee608f1 100644 --- a/src/wrapt/_wrappers.c +++ b/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; diff --git a/src/wrapt/wrappers.py b/src/wrapt/wrappers.py index 1be4aba..42b8a53 100644 --- a/src/wrapt/wrappers.py +++ b/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