Having recently started doing python full-time, I would say that by far the biggest problem with python is its propensity to explode in your face. Code written in python seems so fragile; except for the most blatant bugs like syntax errors or too few arguments, nothing gets caught. You end up having to write tons of unit tests, which often expose bugs that would be trivially caught with any kind of typing. Performance is great, but code reliability is much more important. With python you get neither - just rapid development (slowed down by having to write a ton of tests) and expressiveness (which is excellent).

Don't let its ease of use fool you, there are a lot of ways to shoot your foot off in Python. Typically, it's kind of like pulling the trigger (make the mistakes), only to see your foot get blown off a few months/years down the road. I find that your luck with larger Python projects is largely determined by two things:

* Experience with Python, and general experience in duck typed environments.

* Discipline. Not just your own, but anyone else working on your project.

There are certain mistakes that will make your life miserable down the road. These could be bad organizational conventions, inconsistent exception raising/handling policies, lacking a strategy for documentation, etc. If you make mistakes like this, you probably won't get bitten by it until later.

Writing good Python can be harder than writing good <X Language with more rigidity>. With experience and time, this gets a lot easier.

This was exactly my sentiment when I started doing Ruby full-time.

I appreciate all the niceties that dynamic-typing language like Ruby provides. But I am not sure the trade-offs are enough (all you already described).

CFFI is the latest trendy way to call C, compatible with PyPy ;)

"slowness" is not the problem here - it's "slow program startup". If your process only lasts for tens of milliseconds, you're not going to make it any faster by embedding C code because 99% of time is still going to be spent initializing the python VM.

So, effectively, Python is not enough - you and your team have to be experts in C/C++ too?

If your team can't write a few hundred lines of critical section code in another language, or at least pick it up in a week - especially when the syntaxes are very similar (this isn't going from closure to java here) - you have bigger issues with your team than their language choice.

Yep, no single language except C(/C++) is enough by itself (potential exception here is Java, but even there it's still useful).

C has become the lingua franca of computing. You can call everything (except Go) from C and you can call C from everything. So you want to actually reuse standard libraries, you will want to know C. And if you're a good C hacker you'll know C++. I'm not saying you'll necessarily use it, but you'll know it.

The vast majority of python programmers do not know how to call C/C++ code and are therefore limited to pure python libraries exclusively. They usually use writing to files and os.system() as an alternative. Needless to say, the performance of this approach can be questioned.