There is also Stackless Python, which if memory serves is what Eve uses, which can let use us multiple threads too.

Yes, EvE uses stackless python. It does not, however, use multiple threads. It suffers from the GIL as well. It uses tasklets which are essentially microthreads which get run on a single thread. The "multithreading" behavior is cooperative.

Python is used quite extensively in EvE, both on the client and server. Most of the game simulation is actually run using python. The heavy math parts get offloaded to C++ modules, as do some other high performance modules (graphics for instance). Networking actually wraps IOCP up in channels to allow for asynchronous networking concurrent to the simulation.

I could wax on about python and eve for hours, but I'll stop there.

Washu hit on the key points for making sure that your game is fast when using Python, at least in my experience. Some parts should be offloaded to C++ modules. I always tended to look at it on the basis of abstraction. Some things operate best at a low level of abstraction. Bare-metal stuff, like physics and rendering. Other stuff works well at a higher level of abstraction, such as logic and AI. The logic and AI can live well inside Python, and in fact is very well served by living in Python, but the rendering, collision, physics and pathfinding stuff would probably be best handled by C++, built as a layer upon which the higher levels of abstraction can operate.

Many existing math libraries for python (such as numpy) are often implemented in C anyway.

if you can leverage optimized versions like CPython or IronPyhon

Yeah, about that. CPython is the reference version. IronPython is much faster though if the OP is willing to use .net (or mono), this would of course mean pyglet or pygame would be out of the window, SDL has a .net binding though which works from IronPython (pygame is also just an SDL binding).

IronPython would open the door to XNA or Monogame though.



Back onto the OP's original question:
Dwarf fortress is supposedly badly optimised, very badly, it also suffers from alot of features being added on that weren't originally planned for and so kludging them into the engine has impacted performance. If your feature list was set out more rigidly (or the engine designed for easier expansion) from the start and you optimise things nicely then any language should suffice. Python would be pushing it but its possible. One thing that could help performance a little, DF simulates injuries to each limb independantly and even internal bleeding, not really needed, can probably scrap that alongside several other things.

If I start going that route, why not just use c# directly then? I'm not the biggest fan of the Visual IDE and XNA, but I will go that route if it's very appealing. What sort of cross platform doors will be open to me if I do?

With XNA there is just Microsofts platforms allthough monogame looks "promising".
(You can use C# or IronPython with for example OpenTK instead though if you want to run on Mac, Linux, etc and there is Xamarin (commercial unfortunatly) if you want to target iOS and Android).

The main reason to use IronPython over C# is that IronPython is Python, just like the main reason to use C# over IronPython is that C# is C#. You probably get better IDE support with C#(atleast in visual studio) and the compiler might generate better MSIL code from C# than it does from Python (I havn't checked, both seem good enough for me) but unless there is a real issue with one of the languages you're best off going with the one you prefer working with.

Monogame is an attempt to exactly clone XNA but using openGL and other open source cross platform technologies as a backend. It can be used in IronPython. Monogame will be one of the only options for cross platform going down the IronPython or C# line.

A good IronPython IDE for .net development (although with some hacking you can fool it into using mono compilers instead) is SharpDevelop. I had issues using the various visual studio plugins to use IronPython. It also has features to convert code between C#, VB.net, IronPython and IronRuby, they work quite nicely.

IronPython vs C#, thats just a case of do you know how to use C# or not, IronPython is essentially identical to Python 2.6 (I think, might be 2.7 actually). Only difference is one extra module to enable importing of .net/mono assemblies instead. Most existing Python applications will compile under IronPython already. So really its just Python but faster and with more libraries available. Any existing python module that has sections implemented in C (such as pygame) unfortunately will not work, some of the standard library for Python had bits written in C aswell but they've been ported to be IronPython compatible instead. Most of the best python modules have .net counterparts that you can use instead.

Assuming you're comfortable with both C++ and Python, then once you've decided on a language the standard answer is just to use whichever of you have the most experience with. SFL or SFML for C++, or Pyglet or Pygame for Python.
[/quote]

I think you meant SDL. ;)
But he's right in my opinion. You can write whatever type of game you want in what ever language you want. It's just up to you to make you that you are writing clean efficient code in order to avoid performance issues. I'm actually writing a full-scale 2D action RPG in Python with Pygame right now and though I'm not too far into it, I haven't run into any big issues regarding performance. I think the biggest set back with using Python/Pygame or C++/SDL is going to be the both SDL and Pygame aren't hardware accelerated, so it would always be a good idea to use an OpenGL wrapper for rendering so you can have hardware accelerated graphics. That's what I plan on doing, Pygame for user input, sounds and music, PyOpenGL for rendering, and Python as the main programming language because that's what I enjoy and am most confident in.

But I would just use whatever language you are more comfortable with and have more fun programming in. After all, is is supposed to be fun right?