I am just going to address the topic directly. I've been developing a roguelike in Python for the past six months. I've went from only knowing a bit about game design/roguelike development to being mildly competent in both areas. I am by no means a genius or programming wizard, so maybe I can speak "on your level" to help you understand some of the finer points of what you're getting into.
Python is great for a lot of different things. Quick scripts to scan log files, neat little programs to speed up boring tasks, etc. Of course, the introduction of things like PyGame have brought the language into a different area of programming that is mostly dominated by people who want to learn a language just to make a game. That's fine, but only to a certain extent.
My experience with Python was pretty traditional and didn't involve games, but I quickly learned about PyGame and went from there. I made all the usual games, like Snake, Pong, and a whole pile of different things, but time passed and I wanted something with more depth. About a year went by and I started creating my first roguelike.
Python can be fast, but it can also be very slow. Unfortunately, learning a language just to make small scripts and games doesn't exactly teach you to optimize much. I was learning at a very fast rate that I had picked up some terrible programming habits from those small scripts where speed didn't matter. Example: If you're crunching a 50-line file even the slowest code will get the job done. It's when that file is a thousand lines long that you notice how slow your code is.
Thanks to this, my first level generator took five seconds to finish. Take note that most generators take less than half a second to finish and crank out sprawling worlds/levels. Mine was making a dozen rooms spread about and struggled on high-end hardware. Scary, and very discouraging. It's a year later and my generator can make potentially hundreds of levels in the same amount of time the old generator took to make a single one. That's just one aspect of the game, though. We've yet to talk about A* or Dijkstra maps yet.
So what's the lesson in all of this? You're not going to make a roguelike in Python unless you're willing to learn how to optimize it. People learn Python because you can jump into it without much prior programming experience, then get confused when their simple Pong clone struggles to render any higher than 20 frames per second. It's a high-level language that needs a bit of taming before it will do what you want at the speed you want.
I'm not trying to discourage you. Your design seems great, but it's going to take quite a large sum of cash to get someone to do all that for you when you could do it yourself for free.
Back to my story: I've been working on a roguelike for quite a long time. It's been a rough experience, but overall a HUGE learning experience. There's been times where I've erased hundreds of lines at once because it was too slow or hard to read after spending a week away from it, and that's usually when I learn the most. I promise you'll do the same multiple times.
And for the past few hours, I've been trying to squeeze every bit of speed I can get out of my Dijkstra map function. Turns out you really, really notice a 0.1 second pause every frame. Yet, from what I've seen, games like Brogue can generate multiple Dijkstra maps each frame without any change in performance. That's not too surprising, considering C is one of the fastest languages out there.
I will link you to my code if you're up for seeing how a Python roguelike works. I will warn you that while the code is in a public repo, it's still very much "hackish" and has remnants of unused code in places, but I'm willing to clean it up if you'd like to take a look.
In summary: A roguelike in Python would be easy to get started, but would be hard to finish. Your mileage may vary.
