Python's the utility / glue scripting language of choice precisely because it's READABLE - it doesn't have nine different ways to do everything like Perl does which makes it less expressive but more comprehensible and maintainable. You can definitely bang stuff out faster in Perl, but you can come back to the Python four years later and easily figure out what it's doing (just did that recently, fixed a large four year old 2.x script for new requirements and features and upgraded it to Python 3.x in a day, most of that testing), or grab someone else's Python and maintain it with reasonable effort unless they were seriously defective. Terrible programmers can write Perl in Python, and great programmers can write very maintainable code in Perl, but the language heavily skews the odds.
Remember when Ruby briefly seemed like a contender for Python? Well, it was neat, and decent enough (I used it), but it had too many perlisms (punctuation vomit syntax) which made it similarly not so readable, and then all the magpies flew away to the next hotness and I went back to Python as more maintainable - and more capable because of the strong library support. And now Ruby is just 'That language you use for Rails'.
Similarly, people like to bitch about the whitespace, but it forces readability. Perl people considered cramming 5 or more lines worth of Python on a single line a bragging point, and it was when vertical space was limited, but it's hell for readability and maintainability and we've got big monitors now. And if you have any code skills at all the whitespace is not a problem - I do Python, C#, C++, bash, Haskell, ASM, and VHDL - all wildly different, and the biggest problem is remembering how each does '# of items in a collection' (Count? count? Count()? Length? length? sizeof()?) - whitespace is not even on the radar.
A more valid complaint is that Python has relentlessly marched towards cleaning itself up even if that breaks compatibility - it is not afraid to clean up terrible mistakes it has made (usually on new features) rather than leaving them in forever for compatibility reasons like bash has to. I know that's a big sticking point - it can be jarring when old code breaks, but locking old code you don't have the time to maintain to a specific version has worked pretty well for us. Mostly that's just segregating things as 2.x or 3.x. Code we have kept up to latest version has improved as a result as the language improves.
Biggest weakness - the lack of compile time checks due to strong but dynamic typing continues to be an Achilles heel for any large project. Python (and other scripting languages) just aren't suited for that and we don't use it for that. Use something with static compile-time checking like C# or C++ - yes, after all my kvetching about readability we still use C++ for some things because nothing else fills its niche.