Essential Python Tips, Tricks, and Hacks

The article really has something against map and filter. Specifically:<p><pre><code> squares_under_10 = filter(lambda x: x &#60; 10, map(lambda x: x*x, numbers)) squares_under_10 = [number*number for number in numbers if number*number &#60; 10] </code></pre> Those two lines are functionally different; the second one (the one the article prefers) performs a costly multiplication twice.<p>I'm not saying list comprehensions are bad... I use them a ton. I just acknowledge that there are times where map and filter make a lot of sense. Even for trivial reasons like wrapping lines, using map allows you to break at commas instead of embedding backslashes in your code and trying to decide how it should all align.<p>If you haven't, check out the itertools standard library module. The power held in these functional, generator-based functions is amazing. Since I started using it, I don't know how many times I've used:<p><pre><code> imap(func, izip(somelist, repeat(somevalue))) </code></pre> and other such paradigms.<p>Hmm... more problems with the article:<p><pre><code> numbers = [1,10,100,1000,10000] if [number for number in numbers if number &#60; 10]: print 'Success' # Output: 'Success!' </code></pre> This is terrible. It may look nice all on one line, but it goes through the whole list when it doesn't need to. Better is:<p><pre><code> for number in numbers: if number &#60; 10: print "Success" break </code></pre> A problem with using the and ... or paradigm:<p><pre><code> result = test and 'Test is True' or 'Test is False' </code></pre> The page mentions that "Test is True" must evaluate to True or else it will always be skipped over even if test evaluates to True. It fails to mention, however that "Test is False" must also evaluate to True. Otherwise, if test evaluates to False, the entire expression returns False. Thus<p><pre><code> s = foo and "word: "+foo or "" </code></pre> will assign False to s instead of the desired "". In this case, it is quite clear that<p><pre><code> s = "word: "+foo if foo else "" </code></pre> is preferable.<p>I didn't find the article all that helpful, personally. It puts forward inefficient solutions as the recommended methods, and it doesn't offer much that I didn't already know. The two things that I learned, which I'm not sure that I'll ever use, are function decorators and the "string in substring" syntax.

An improvement on the switch-using-dictionaries example: instead of doing this...<p><pre><code> keycode = 2 functions = {1: key_1_pressed, 2: key_2_pressed, 3: key_3_pressed} if functions.has_key(keycode): functions[keycode]() else: unknown_key_pressed() </code></pre> you can save three lines by replacing the if-else block with:<p><pre><code> functions.get(keycode, unknown_key_pressed)()</code></pre>

5.1: I prefer to use the rule "don't mutate objects" instead. I would've defined the example as:<p><pre><code> def function(item, stuff=[]): print stuff + [item] </code></pre> Mutating the passed-in 'stuff' creates a leaky abstraction that then has to be documented. In rare cases this is what you want, but most of the time you're better off creating new objects and working with them. There's less to remember in the API, and fewer ways to screw up.<p>In particular, this code - which <i>looks</i> safe - blows up horribly with the article's function:<p><pre><code> MODULE_LEVEL_CONSTANT = ['foo', 'bar'] function('baz', MODULE_LEVEL_CONSTANT) function('quux', MODULE_LEVEL_CONSTANT) </code></pre> The second call will print ['foo', 'bar', 'baz', 'quux'] instead of the expected ['foo', 'bar', 'quux'].

Less syntax in languages, please. The problem with the Perlish "There's more than one way to do it!" is that one ends up expending extra cycles comprehending semantic equivalence. But equivalence should be a fulcrum -- these are things leveraged to be able to reduce the effective complexity of what we're looking at. Anything that obscures the visibility of equivalence is bad on the balance.

You know if you create an account on the site you can edit the article, like a wiki.