Minor nitpicking:
> unlike in Java, you can also call a class method on an instance
It's possible in Java, too. It's just considered bad practice.
Still, a very nice read!
A primer on Python decorators
11–20 of 45 posts
Re: A primer on Python decorators
#12Thanks, but my favorite explanation of decorators is still this stackoverflow answer (see the second answer)
http://stackoverflow.com/questions/739654/understanding-pyth...
Re: A primer on Python decorators
#13Love using Python, but still haven't got around to using decorators yet. I probably didn't understand the concept properly until now ...
You could say decorators are for the code that you want to put inside a function but that don't really belong to its logic. The memoization example shows that: if you have memoization logic inside the function it works but you should feel that there are two disjoint logics at works.
Re: A primer on Python decorators
#14Great primer, reading it gives a good sense for why the decorator syntax was made and the potential uses. Is this part of a wider series you are running?
Thanks! It is indeed the first in a series of Python posts that will be on the Thumbtack engineering blog.
Can you please email all future posts to me? ;p zackster@gmail.com -- I don't use RSS any more, and I'd hate to miss them.
Re: A primer on Python decorators
#15For an interesting use of Python decorators - event handling - have a look at Decovent on pypi
http://pypi.python.org/pypi/Decovent.
Re: A primer on Python decorators
#16To authors: I would avoid try except in this code snippet, a simple if else is more explicit. I would also avoid a = b = c statement. One line per statement is better most of the time.
Re: A primer on Python decorators
#17Minor nitpicking: > unlike in Java, you can also call a class method on an instance It's possible in Java, too. It's just considered bad practice. Still, a very nice read!
I'd say if you have to do that, it is most likely because you have a design problem somewhere. It is a code smell in Python as well.
Re: A primer on Python decorators
#18Thanks, but my favorite explanation of decorators is still this stackoverflow answer (see the second answer) http://stackoverflow.com/questions/739654/understanding-pyth...
Yes, I think this post is more informative.
Re: A primer on Python decorators
#19Thanks, but my favorite explanation of decorators is still this stackoverflow answer (see the second answer) http://stackoverflow.com/questions/739654/understanding-pyth...
Yes, I think this post is more informative.
Re: A primer on Python decorators
#20To authors: I would avoid try except in this code snippet, a simple if else is more explicit. I would also avoid a = b = c statement. One line per statement is better most of the time.
The Python community generally advocates an "it's easier to ask for forgiveness than permission" coding style. When faced with a condition of the form "if condition a holds, do b, else c", it's very often a better idea to do "let's try b, and do c in case b fails because condition a didn't hold".
In this case it's better because you can avoid computing an extra hash of the object in cases where it's already a key of the dictionary. This may seem like a silly optimization, but it can very easily add up if you're accessing existing elements most of the time--I once had a bit of code that went 60x faster when I replaced an if-else with a try-except.
In other cases it can be even more beneficial. Say you're opening a file. One approach to avoid errors would be to check if a file exists first. This is error-prone because the file might cease to exist in between the 'if' and the 'open' statements, and now you have no code written to handle the error. Using try-except will ensure that you actually handle the error intelligently.
This isn't to say there's never a good reason to use an 'if' to check things, just that if you can do it in one step instead of two, one is usually better.