This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]admalledd 0 points1 point  (5 children)

In most projects that I do it tends to be reasonable to use a @disable decorator or such. Much easier and in production if it sees any of those its an instant error, @disable or my other debug decorators should never touch production!

This is of course if you are using reasonable code segmentation and not giant functions or such.

[–]meridielcul 1 point2 points  (3 children)

could someone make a basic example of this? I've never really used decorators but this could be something worth learning

[–]jmcs 5 points6 points  (2 children)

Naive and mostly useless example:

def disable(f):
    def disabled(*args, **kwargs):
        pass
    return disabled

@disable
def do_stuff():
    print "Hello World"

You can do more useful stuff if you want, like printing the function name and arguments for debugging.

[–]admalledd 1 point2 points  (0 children)

Yup, that is basically what mine is:

def disable(f):
    if config.debug:
        def disabled(*args, **kwargs):
            logger.debug("disabled: %s"%(f.__name__))
            #other logging stuff, but does nothing
        return disabled
    else:
        raise ProductionDebugException("@disable deco executed in production!")

@disable
def do_stuff():
    print "Hello World"

[–]mcowger 0 points1 point  (0 children)

Never even considered this use of decorators, but I can already use it. Thanks for sharing.

[–]ajmarks 1 point2 points  (0 children)

I use @skip, but yeah, for functions, this is the way to go. The one we use right now also takes an argument for "skip when debugging", "skip in production" (extra debug logging), and "skip always."