All I can say is you've obviously never built a large scale system in either a static or dynamic language... The number 1 correlation between bugs and code is the number of lines of code. More lines of code == more bugs. Always, every time. The fact that I can write the same thing in python in 1/5 or 1/7th the code vs Java or C++ means on average I'll have less bugs.
As someone who's spent the last year rebuilding in python the middle and frontend tiers of a large system that integrates a large number of C/C++ modules on the backend, I can tell you that the number of "dynamic" type issues that have leaked into QA (IE beyond automated test cases) are... 0
The number of null pointer dereferences, linking errors (which end up building successfully, but as soon as you try to call a function crash), and other various segfaults that have been found in the C/C++ modules.. well over 100
dynamic typing is *easy* to deal with compared to pointer math. Maybe if the C/C++ coders didn't have to spend all their time making sure they were passing char pointers instead of wchar pointers they could have spent a little time bounds checking arrays and verifying pointer math.
As to all the contentions that python isn't a "real" language, I would say the middle and frontend of this application are much better designed than anything that is in the backend. The code is clean, well documented, easily maintainable, much more flexible, modular, and for the most part 90%+ covered by automated tests. It is a solid OO design with a decent chunk of functional programming thrown in where it makes sense. The C code has a 75 page testing manual that must be run by hand after every QA build (takes 2-3 weeks)... I'm not surprised by this at all, because C requires you to spend all your time making trivial things work, so you don't have any time to actually do design. And once you get something "working" you can't touch it, because nothing is modular and everything is set in stone. I've written a decent amount of C in my life, I'm pretty fluent in it, and in writing python I've had to drop down to C to optimize a number of things. You do it when you have to, just like C coders used to drop to assembly when they had to.
Sure I'm generalizing in the paragraph above, I'm sure you *can* write well designed C, I've just never seen it in practice in the real world in 15 years of real life experience... I've seen "OK" designed C++, and well designed Java... I can recreate those designs in less than half the code in python, and VS java I'll use 1/10th the RAM, and vs C++ I won't have memory leaks or bad pointer math, and an average developer can read the code.
I believe Guido is spot on, in my experience the part of the code that has to be fast and isn't already a C module in python is tiny, and most of the time can be built in a day or two. Compare that to the 8 months I'm under budget building these middle and frontend tiers in python (they budgeted based on the last implementation which took 3 years in C++)... And I'd say python is a win, the interface is just as responsive, I'm well within all SLA metrics in the business logic tier, and in a number of places the python implementation is faster than the old C++ (just using better algorithms). I'm going to be at feature parity in the next month with the existing system... well except that now our system is 100% cross platform compatible (tested on OS X, Various linux flavors, Various bsd flavors, and Windows)... Vs the old C++ that made extensive use of win32 only functionality and was 100% windows only. Getting cross platform support was the reason for the redesign/rebuild... The fact that I built a prototype in python faster than the C++ guys could decide on a cross platform GUI toolkit gave my team the win to implement it in python.