I think it's mostly about maturity, of the runtime, of the language, and of the community.
For example, Ruby has backward incompatibility issues in minor releases that would never be permitted in Python. They had to jump to Python 3 for even fairly small things that wouldn't be accepted in the 2.x line. Even subtle incompatibilities between Python versions are taken seriously, and there's a documented process for deprecation that involves multiple releases and means when a feature is deprecated it'll probably still be available for years. There's cruft in the language as a result, but for people using Python seriously this is more than worth it.
I think the Python-Dev community is also more mature. Changes get serious review. Though there's not a formal "core", strong objections from certain people are enough to bring a new feature back to zero and require a restart (not because those people have special weight, but because they are respected and everyone kind of understands there's a benefit to listening to crotchedy naysayers if they are smart crotchedy naysayers).
The community is large enough that there's a lot of domain knowledge. Python is better at getting a canonical and complete solution to a domain problem than Ruby. WSGI discussions for instance involved some people with a very intimate knowledge of HTTP. People work hard to get 95% solutions instead of 80% solutions. In part because Python has been around a long time, and there's already at least an 80% solution for whatever problem you are looking at, and if you are going to throw your hat in the ring you ought to be ready to try harder. I think the more aesthetic tendencies of the Ruby community work against it here, as people are more likely to rewrite for aesthetic rather than functional reasons. (OTOH, when Python settled early on some 80% solutions, it's caused a lot of difficulties because it's been hard to overcome inertia to introduce a better solution, while it's hard to get really good adoption of the 80% solution; pydoc would be an example.)
Then there's simple maturity. The VM is more stable; it may not be a great VM, but it is predictable. There's lots of tools for writing extensions. There's code for dealing with large data sets, for dealing with images, for accessing system libraries, etc. For any one problem Ruby might work fine, but for the problems you don't yet know you'll have to solve it's less likely you'll hit a blocker with Python.
For example, Ruby has backward incompatibility issues in minor releases that would never be permitted in Python. They had to jump to Python 3 for even fairly small things that wouldn't be accepted in the 2.x line. Even subtle incompatibilities between Python versions are taken seriously, and there's a documented process for deprecation that involves multiple releases and means when a feature is deprecated it'll probably still be available for years. There's cruft in the language as a result, but for people using Python seriously this is more than worth it.
I think the Python-Dev community is also more mature. Changes get serious review. Though there's not a formal "core", strong objections from certain people are enough to bring a new feature back to zero and require a restart (not because those people have special weight, but because they are respected and everyone kind of understands there's a benefit to listening to crotchedy naysayers if they are smart crotchedy naysayers).
The community is large enough that there's a lot of domain knowledge. Python is better at getting a canonical and complete solution to a domain problem than Ruby. WSGI discussions for instance involved some people with a very intimate knowledge of HTTP. People work hard to get 95% solutions instead of 80% solutions. In part because Python has been around a long time, and there's already at least an 80% solution for whatever problem you are looking at, and if you are going to throw your hat in the ring you ought to be ready to try harder. I think the more aesthetic tendencies of the Ruby community work against it here, as people are more likely to rewrite for aesthetic rather than functional reasons. (OTOH, when Python settled early on some 80% solutions, it's caused a lot of difficulties because it's been hard to overcome inertia to introduce a better solution, while it's hard to get really good adoption of the 80% solution; pydoc would be an example.)
Then there's simple maturity. The VM is more stable; it may not be a great VM, but it is predictable. There's lots of tools for writing extensions. There's code for dealing with large data sets, for dealing with images, for accessing system libraries, etc. For any one problem Ruby might work fine, but for the problems you don't yet know you'll have to solve it's less likely you'll hit a blocker with Python.