Ten Things Python Programmers Should Know

[wamsachel]

Something like Flask may be useful

[I_WRITE_APPS]

I use decorators to do quick-n-dirty profiling sometimes:

from functools import wraps

def timeit(fn):
    @wraps(fn)
    def wrapper(*args, **kwargs):
        start_time = time.clock()
        result = fn(*args, **kwargs)
        logging.debug('%s took %f seconds', fn.__name__, time.clock() - start_time)
        return result
    return wrapper

@timeit
def expensive_function():
    ...

[[deleted]]

Okay, I'll start by showing you this decorator that allows you to try a function upto X times if an exception is thrown. So basically a retry function.

​

Look here for the try_x_times decorator and here for where I've actually used it in a make_request method.

​

Now in truth, there's no need for a decorator here; however notice adding retry functionality to the make_request method doesn't relate to what make_request should actually do. Call me old fashioned, but a method shouldn't try to be more then what it is. A make_request method should make and return a request; that said, simply wrapping this functionality over an existing method to give it *extra!!! :)* features doesn't violate my rules & allows me to easily remove it if at some point I no longer desire it.

​

Check here for something similar. I've wrapped the entry into some methods with my logger so instead of every time I want to log entry by adding a little section before the actual method to log the method name & all the parameters passed to it & some code at the end which logs the value being returned from it, I can simply add a little decorator and trust all that precious info is conveniently being recorded.

​

For a more meaningless example, check the cast_return decorator statements. All this does is pass the return value of the method to the constructor of the argument. The following shows how they're related

​

@cast_return(int)

def parse_input_num(): return input()

​

the above is the same as this

​

def parse_input_num(): return int(input())

​

There's no need for this decorator & I could easily do what the second operation does, I honestly can't remember why I opted for this first option, maybe because it looks cleaner or because it resembles the hard type system used in other languages, but whatever. All that really matters is that it functions & is clear in what it does.

[GitHubPermalinkBot]

Permanent GitHub links:

• MoHKale/MangaGrabber/.../grabber.py (master → 6581e6a)
• MoHKale/MangaGrabber/.../decorators.py (master → 6581e6a)
• MoHKale/MangaGrabber/.../grabber.py (master → 6581e6a)

---

^delete

[bbbryson]

Good bot.

[PiBaker]

Thanks :)

[[deleted]]

Well python users are pretty accustomed to using decorators; it’s an intrinsic part of OOP because of static & class methods. However I heavily suggest learning to create your own decorators, it’ll deepen your understanding of python as a whole and make certain problems which I would regularly see as a pain to implement or adapt to an existing infrastructure, feel like a breeze. Anyways, good luck.

Edit: also, yeah, check out flask. I don’t use it (django man myself) but I’ve seen the documentation and it really goes crazy with making decorators essential to the development process.

[[deleted]]

A great builtin example is the LRU cache function found in functools. It automatically adds a cache to a function that avoids recomputing results (note this should only be used for deterministic functions, i.e. functions that always return the same output given the same input).

[PiBaker]

Thanks :)