You're just reinforcing the parent's point. Take this sentence:
> <PROGRAMMING_LANGUAGE> is not without it's shortcomings and hidden pitfalls. After all, there is a reason that any style guide for <PROGRAMMING_LANGUAGE> will include a large list of features that should not be used.
This holds true of pretty much any language. Take a look at Google's extensive style guide library [1]; they all contain language features that should be avoided for any language. It all just reflects the iterative nature of programming language design.
There is almost nothing in there that sounds like a landmine. Rather, some general guidance about "don't use global variables," "x may not be thread safe," and "don't write overly complex lambdas."
My favorite "gotcha" in Python is using e.g. a list as a default argument. That's in the guide, and it sucks, but Python has surprisingly few such problems for newcomers.
I can think of two landmines that make most C++ issues pale. First is things blowing up at run-time due to typos or syntax errors. Second (related) is that you can't safely refactor because you don't really know the types that functions take or where they're being called from. Sure C++ can be a pain but you can build and maintain very large software in C++. It's a lot harder to do in Python (without taking other considerations into account).
> <PROGRAMMING_LANGUAGE> is not without it's shortcomings and hidden pitfalls. After all, there is a reason that any style guide for <PROGRAMMING_LANGUAGE> will include a large list of features that should not be used.
This holds true of pretty much any language. Take a look at Google's extensive style guide library [1]; they all contain language features that should be avoided for any language. It all just reflects the iterative nature of programming language design.
[1] http://code.google.com/p/google-styleguide/