There is no clear cut killer feature for Ruby over Python in that context, and viceversa. Both are fairly good compared to the alternatives. The only true killer feature of Ruby is Rails, much better than Django and Web2py I had to work with in the last year, but that's out of the scope of your question. If your team knows Python you're likely to stay there.
I find Ruby to be much easier to read and understand than Python but I have 10 years of customers paying me to write Ruby vs one in Python. I assure you that it would be the other way around if I had worked in Python for 10 years.
I never picked Python for my own projects in all those years because I find many of its design choices weird and painful (I joke saying it's Ruby for the masochist), but that is very subjective. People liking Python consider good even what I find to be objective weaknesses of Python (example: only one line lambdas.) This means that probably both languages are good enough.
Good answer. Our discussion sort of touches on the ingrained biases organizations can have toward a particular language, whether for the good or bad. Ideally I would push towards learning new languages and approaches to problems, but organizations (mine included) push towards the principle of least astonishment and it can be difficult to break that barrier. There's good business sense in doing so. Or, to rephrase, if your organization is ingrained in doing things a particular way the tradeoff of attempting to adopt something newer and/or different had better be justified.
This is nothing particularly insightful on its own, of course, but this philosophy in terms of "what language do I write my code in" is worth a retread every now and then.
I have some experience using RoR but I'm considering Django for my next project. Could you elaborate on what you liked more about RoR compared to the later?
The answer could be extremely long but the single most important point is that the Python frameworks I used leave developers on their own to do architectural choices. Combined with some poor framework defaults [1] I always saw very poor project structures (my sample space is 3). I inherited projects with a single thousands line view (Django) or controller (Web2Py). Rails would basically force developers to create multiple controllers. Apparently developers using Django and Web2Py don't understand they should or can do the same.
If you're good at designing backends and the project is yours, no problem. You'll have to work more and reinvent some wheels but you'll get exactly what you want, no compromises.
If the project is for a customer and then you move on to another customer, do your best to leave a project that the next developer can understand easily. As every Django project can look very different, that's not granted.
On the other side every Rails project looks the same and every project I moved into was well organized. I'm a freelance and my customers call me to add features or fix things. They don't have time and budget for heavy refactoring so those multi thousand lines files are still there, minus some code I managed to extract.
[1] The poor defaults are that a single views.py and controller/default.py are almost all you need to run the app. Hence the 2670 lines default.py I'm wrestling against now. Luckily that was a small intranet backend.
I find Ruby to be much easier to read and understand than Python but I have 10 years of customers paying me to write Ruby vs one in Python. I assure you that it would be the other way around if I had worked in Python for 10 years.
I never picked Python for my own projects in all those years because I find many of its design choices weird and painful (I joke saying it's Ruby for the masochist), but that is very subjective. People liking Python consider good even what I find to be objective weaknesses of Python (example: only one line lambdas.) This means that probably both languages are good enough.