You fundamentally misunderstand my point. My point is that if a particular project has a particular rock-solid need for something that Python can't do, you shou

You fundamentally misunderstand my point. My point is that if a particular project has a particular rock-solid need for something that Python can't do, you shouldn't choose Python. You can stick any language in there for that. You name the language, I'll name a disqualifying need for it. (A really simple one is "I want to work on $PLATFORM". There's hardly a language that's a great choice for iPhone, Android, desktop app, and server. There's some languages that can at least do all four but they aren't generally a great choice for all four.) It is about matching the needs of a project to the implementation language, and neither blindly picking languages because they are "good", so they must be good at everything, nor blindly disqualifying languages because they are "bad", so they must be bad at everything. If you need to go fast, you shouldn't have chosen Python. You don't always need to go fast. In fact, many people greatly overestimate their need to go fast! But if you did have that need to go fast, you shouldn't have chosen Python. I observe that this bothers people, because they treat it as an emotional decision about who or what they are endorsing, or what team they are or are not part of. This is the wrong view. It is an engineering question, just like I would ask whether I use steel or plywood. There is no "team steel" and "team plywood", no "plywood is better at everything!" "no way dude, plywood rules, steel droolz!". Just tools that need to be analyzed.