To add to other comments, things the author could have expanded upon:<p>* vararg keyword arguments (<i></i>kwargs)<p>* Keyword-only arguments (Python 3)<p>* help, vars, a few other nice introspective builtins<p>* Assignment unpacking (multiple names as left-hand side of an assignment)<p>* The strangest "first blush" difference between Ruby and Python, or at least the one which I found oddest when I first started switching, is that a new Ruby class is defined from the `class {Name}` line, the whole body executes in the context of the already-created class. Not so in Python, the class object will only exist once the body has finished executing.<p>* No mention of generators? Also outer v inner iteration is a pretty big split between two otherwise similar languages.<p>Mistake-ish<p>* obj.__dict__ -> vars(obj)<p>* obj.__class__ -> type(obj)<p>* Python's lambdas are not one-line, they're one-expression. The reason you "can't do [this] in Python" is that if:elif:else: is a statement, so doesn't fit in lambdas. But you can have arbitrary complex code in lambdas aside from that, by following <a href="http://codon.com/programming-with-nothing" rel="nofollow">http://codon.com/programming-with-nothing</a>. For instance you can (although you should not) write:<p><pre><code> map(lambda num:
0 if num % 3 == 0 else
num * 2 if num % 4 == 0 else
num,
range(1, 6))
</code></pre>
* Author talks about methods a lot. They're not methods, a method is part of an object. They're functions. Granular functions, inner functions, ...<p>* We generally don't say Python values "evaluate to False", we say they're falsy: they're <i>never</i> equal to False (outside of False and — for historical reasons — 0), they're just equivalent when evaluated in a boolean context (or passed to `bool()`). Also, the list is <i>way</i> incomplete: <i>any Python type defines its own "falsiness"</i> by implementing __bool__ (or __nonzero__ in Python 2)<p>* Python's reflection and metaprogramming are roughly on par with Ruby's, their lack of use is more of a cultural artefact (possibly historically motivated) than a technical one. Consider adding methods to existing types for instance. You can do it in Python (on python-defined types), you just very rarely do, it's not in the culture to do something like that. Same with using metaclasses, it's done but it generally isn't the first thing a Python developer will reach for, aside from things like registering classes on the fly/on definition<p>Odd comments:<p>* Ruby mixins, as far as I know, work by injecting the module in the inheritance chain somewhere above the new class. MI is clearer and just as powerful.