openstack/deb-python-wrapt
Code Issues Proposed changes

Fix misspellings

Browse Source
This commit is contained in:
stepshal
2016-06-26 01:16:40 +07:00
parent 62920e53f1
commit dede3c67a8
6 changed files with 19 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -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. actually the ``__call__()`` method of the wrapper object which is invoked.
This in turn would then call the original wrapped function. 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 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 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 input arguments or the result as they pass through the wrapper. This is

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

@@ -1,7 +1,7 @@
The @synchronized decorator as context manager 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 and how I believe they are generally poorly implemented. It follows on from
the previous post titled [The missing @synchronized the previous post titled [The missing @synchronized
decorator](07-the-missing-synchronized-decorator.md), with the very first decorator](07-the-missing-synchronized-decorator.md), with the very first

16
blog/14-automatic-patching-of-python-applications.md
View File

@@ -14,7 +14,7 @@ where it has used:
from module import function 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 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. 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 This technique is still though dependent on the post import hook mechanism
itself being installed before any other code is effectively run. This means itself being installed before any other code is effectively run. This means
having to manually modify the main Python script file for an application, 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 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 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 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 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 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 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 they see it imported even if not used, so we will gate even that by the
presence of the environment variable. 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 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. 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 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 application script file. This is because of where in the Python interpreter
initialisation the parsing of .pth files is done. 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 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 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 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 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 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 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 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 process .pth files contained in a directory added by a .pth file, so our
custom .pth file would be skipped. custom .pth file would be skipped.
@@ -346,7 +346,7 @@ So to run the test do:
pip install autowrapt 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. minimum version.
Now run the command line interpreter as normal and at the prompt do: 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 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 but it shows that the monkey patch function was actually triggered when
expected. expected.

10
docs/changes.rst
View File

@@ -110,7 +110,7 @@ Version 1.10.1
then calling the method was causing an unwanted reference to the instance then calling the method was causing an unwanted reference to the instance
meaning that if the instance was transient, it would leak. 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. ``wrapt`` module was being used.
Version 1.10.0 Version 1.10.0
@@ -310,12 +310,12 @@ Version 1.6.0
even though the wrapped object didn't have one. Similarly, callable() even though the wrapped object didn't have one. Similarly, callable()
would always return True even if the wrapped object was not 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 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 may be called via the proxy object even if it may not turn out that
the wrapped object was callable. 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 callable() can sometimes be used to indirectly infer the type of an
object, this could cause issues. To ensure that this now doesn't 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 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 * 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 ObjectProxy class a reference count cycle was created that required
the Python garbage collector to kick in to break the cycle. This was 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. ObjectProxy class correctly.
Version 1.4.1 Version 1.4.1
@@ -509,7 +509,7 @@ Version 1.1.1
**Bugs Fixed** **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 object reference count in C implementation of object proxy when an
instance method was called via the class and the instance passed in instance method was called via the class and the instance passed in
explicitly. explicitly.

2
src/wrapt/_wrappers.c
View File

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

6
src/wrapt/wrappers.py
View File

@@ -440,7 +440,7 @@ class _FunctionWrapperBase(ObjectProxy):
# #
# The distinguishing attribute which determines whether we are # The distinguishing attribute which determines whether we are
# being called in an unbound or bound wrapper is the parent # 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. # be None.
# #
# First therefore, is if we are called in an unbound wrapper. In # First therefore, is if we are called in an unbound wrapper. In
@@ -467,7 +467,7 @@ class _FunctionWrapperBase(ObjectProxy):
return self 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 # was already a bound function. In this case we would usually
# return ourselves again. This mirrors what Python does. # 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 # to work. For the case of a class we therefore access
# the __dict__ directly. To cope though with the wrong # the __dict__ directly. To cope though with the wrong
# class being given to us, or a method being moved into # 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 # work out exactly which __dict__ the method was defined
# in, as accessing it from __dict__ will fail if it was # in, as accessing it from __dict__ will fail if it was
# not actually on the class given. Fallback to using # not actually on the class given. Fallback to using