Snippet List
as with all things related to monkeypatching, the caveat is to use things like these for good, and not for evil.
I wrote these decorators because I did not want to rewrite all of [PyAWS](http://github.com/IanLewis/pyaws) -- instead I use these to add some standard/useful methods to the Bag collection that PyAWS uses internally.
AN EXAMPLE:
class PatchMyMonkey:
pass
@monkeypatch(PatchMyMonkey)
def throwfecesat(self, who="nobody"):
print "Throwing Feces At: %s" % who
@monkeypatch(PatchMyMonkey)
def nicoderm(self, why="no reason"):
print "Trying To Quit Because: %s" % why
return {'why':str(why)}
trampstamp = PatchMyMonkey()
trampstamp.throwfecesat(who="another monkey")
print trampstamp.nicoderm(why="cigarettes are pricey")
A LESS SILLY EXAMPLE:
from pyaws import ecs
@monkeypatch(ecs.Bag, fname='get')
def get(self, param, *args, **kw):
return self.__dict__.get(param, *args, **kw)
@monkeypatch(ecs.Bag, fname='clearurls')
def clearurls(self, *args, **kw):
for k, v in self.__dict__.items():
if isinstance(self.__dict__[k], ecs.Bag):
self.__dict__[k].clearurls(*args, **kw)
if type(v) == type([]):
[ii.clearurls() for ii in self.__dict__[k]]
if type(v) == type(u''):
if self.__dict__[k].count(u'http://') > 0:
self.__dict__[k] = "<URL>"
(amazon's URLs are extremely long, and can muddle your test/log output, hence that last function.)
based on sample code from [here](http://pypi.python.org/pypi/decorator) and [here](http://mail.python.org/pipermail/python-dev/2008-January/076194.html).
- decorator
- monkeypatch
- decoratordecorator
- functionalprogramming
- usewithcare
In test code, it is sometimes useful to monkeypatch a Django method to have stubbed out behavior, so that you can simplify data setup. Even with decent data setup you might want to avoid execution of Django code that is not the target of your test.
The code snippet shown here illustrates a technique to limit the scope of your monkeypatches. It uses the Python "with" statement, which was introduced in 2.5.
[with statement](http://effbot.org/zone/python-with-statement.htm)
The key aspect of the "with" machinery is that you can set up an __exit__ method that gets called even if the code inside the "with" raises an exception. This guarantees that your monkeypatch gets un-monkeyed before any other code gets called.
I don't recommend monkeypatches in production, but if you HAVE to resort to a monkeypatch, I definitely advise using "with" to limit their scope.
The examples on the left illustrate how to suppress versions of reverse() and timesince()--look at the import statements to see which ones I am talking about. Obviously, monkeypatching is not for the faint of the heart, as you need to be able to find the code to monkeypatch in Django source, and you need to be sure there aren't decorators at play.
This code monkey-patches the default User model to rather use a primary key of UUIDField (see http://www.djangosnippets.org/snippets/1496/). This code also makes the email field required. This code is wildly dangerous, not completely future proof, and probably not advisable to use. If you do wish to use it, it will be easiest to implement on a fresh db with a syncdb. If you need to migrate existing user data the onus is on you to figure out an appropriate db migration plan.
I placed this code in a models.py, but it is probably more reliably placed in urls.py
- user
- auth
- uuid
- monkeypatch
3 snippets posted so far.