Why are there so many negative comments? Maybe those posters are vastly underestimating how many people that just start out read HN. I think it's a pretty good post to read after something like "X in Y minutes - Python" to get a very quick grasp of what the language is like.<p>I'm also not ashamed to say that despite having written quite a few LOC of Python I wasn't aware of named slices for some reason and I think they can clear up some chunks of code I have produced (make it more readable)
Python's unpacking is a poor man's pattern matching. I'd really love to see them extend it to support user-defined patterns like Scala's extractors or F#'s active patterns.
I've been using Python and Ruby on and off for a couple years (largely because I haven't found the need to use it seriously day job or side projects).<p>One thing that strikes odd for me is how people describe Python/Ruby are way more readable than Java.<p>I felt that Python, while more readable than Ruby (because Python uses less symbols), still contain more nifty tricks compare to Java.<p>It's true that the resulting code is less code but behind that less line of code bugs might linger around because there might be plenty "intents" being hidden deep in the implementation of Python.<p>The Python way that is touted many times is "explicit is better than implicit" seems to correlate better with the much maligned "Java is too verbose".<p>Anyhow, the other day I was refreshing my Python skill and learned the default implicit methods that I can override ( those eq, gte, gt, lte, lt) and I wonder how overriding those resulted in less lines of code compare to Java overriding equals, hashCode, and implementing one Comparator method than can return -1, 0, 1 to cover the whole spectrum of gte, gt, lte, (and even equality, given the context).<p>I suppose everything is relative...
zip to unzip a dict is a very slow approach to do it<p>Instead of<p><pre><code> mi = dict(zip(m.values(), m.keys()))
</code></pre>
Do<p><pre><code> mi = {v: k for (k, v) in m.iteritems()}</code></pre>
I have two questions.<p>1. I'm unfamiliar with the term 'unpacking'. Is it any different from pattern matching in, say, Haskell (but perhaps not as feature-rich)?<p>2. Aren't slices pretty much a staple in Python? I didn't think using them was considered a 'trick'.
Coming from a long history of languages like BASIC and Pascal, I will bookmark this tutorial. It seems to open up a lot of interesting Python features that were, quite frankly, not always easy to understand when described in plain text, but now seem pretty simple when presented as examples.<p>I'll also think about the "collection of simple examples" next time I want to document something.
Nice reference.<p>1.29 happened to be exactly what I was looking for:<p><pre><code> for subset in itertools.chain(*(itertools.combinations(a, n) for n in range(len(a) + 1)))
</code></pre>
I spent <i>way</i> too much time writing a function to come up with these combinations.
Slice has always been a painful adventure for me. I always forget that [1:3] is not all inclusive. It's actually just range from 1 to 2.<p>I believe in 2.7 <i>zip</i> is still returning a list rather than an iterator (<i>izip</i> in Python 2, <i>zip</i> in Python 3+).<p>Another unappreciated stdlib is definitely <i>functools</i>. <i>mock</i> is also another awesome stdlib.<p><i>functools</i>, <i>collections</i> and <i>itertools</i> are definitely useful to make things faster. Also check out the list of stdlib. <a href="http://docs.python.org/2/library/" rel="nofollow">http://docs.python.org/2/library/</a>
Great list, I do several mini-tutorials of python at <a href="http://runnable.com/u/mamcx" rel="nofollow">http://runnable.com/u/mamcx</a>. I try to pick several tricks for each theme
I think this is great, I've been doing Python for a while and I knew many of the features but I also learned a few new ones.<p>I don't understand how this one to flatten lists works:<p><pre><code> a = [[1, 2], [3, 4], [5, 6]]
[x for l in a for x in l]
</code></pre>
Can somebody explain what the order of operations is here and what the variables refer to in the various stages of evaluation?
A good reference, to be sure, but man, do I resent the term “trick” in programming. It implies a deception, or something clever that you wouldn’t think to look for, like opening a wine bottle with a shoe. These aren’t tricks, they’re (largely) standard library features that you would simply <i>expect</i> to exist. But maybe I’m underestimating the NIH effect.
patterns / tricks = language deficiencies<p>Wake me up when Python will support tail call elimination and will get rid of GIL. For now this language is no better than PHP.