Python for Ruby Programmers (LA RubyConf 2013)

It's so highly unlikely you'll get them, you should probably resign yourself (or use a different language, or try to approach it from the other direction: convert Python statements to expressions so you can use them in existing lambdas, after all Python's current lambdas are no more restricted than Haskell's, it's just that the rest of Python doesn't play nice with them)

To add to other comments, things the author could have expanded upon:

* vararg keyword arguments (kwargs)

* Keyword-only arguments (Python 3)

* help, vars, a few other nice introspective builtins

* Assignment unpacking (multiple names as left-hand side of an assignment)

* 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.

* No mention of generators? Also outer v inner iteration is a pretty big split between two otherwise similar languages.

Mistake-ish

* obj.__dict__ -> vars(obj)

* obj.__class__ -> type(obj)

* 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 http://codon.com/programming-with-nothing. For instance you can (although you should not) write:

    map(lambda num:
            0 if num % 3 == 0 else
            num * 2 if num % 4 == 0 else
            num,
        range(1, 6))

* Author talks about methods a lot. They're not methods, a method is part of an object. They're functions. Granular functions, inner functions, ...

* We generally don't say Python values "evaluate to False", we say they're falsy: they're never 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 way incomplete: any Python type defines its own "falsiness" by implementing __bool__ (or __nonzero__ in Python 2)

* 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

Odd comments:

* 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.

> Python's reflection and metaprogramming are roughly on par with Ruby's, their lack of use is more of a cultural artefact than a technical one.

+1 on everything you listed, but especially this. You _do_ see some examples of monkey-patching in Python, but at least in my very limited experience, it tends to be much less prevalent in Python than it does in Ruby. Any data to contradict this is welcome, however.

Good point! I know C# and I'm learning Ruby. Next I'll pick clojure for functional programming. We should learn a new language that will change the way of our thinking.

I would say you are right except in one case, which is scientific computing. The OP touched on it, but that is definitely the "killer app" of the Python ecosystem, IMHO. Not that the languages you mentioned don't have equivalents, but if you are a rubyist who just wants to do some heavy-duty scientific/data-intensive computing without stepping too far out of your comfort zone, I can see Python being an attractive option.