The question of "what language" has no real best answer, and it's largely due to the number of parameters involved and what you most care about. This is why wikipedia uses tables for all its comparison stuff. Tom Sloper talks a bit about decision tables (or something like that) in his site to illustrate the same concept. Some basic characteristics:
C++ has the best library support for gamedev tasks, bar none. If there's something you need, there's probably at least 20 libraries for it in C++, and most of them are actually worth a damn.
C# and Java are both MUCH easier to use (not just learn) than C++, and you WILL be more productive on a language level. You may take some level of productivity hit trying to work around the GC, but that depends a lot on use case.
Java is more mature and widely supported than C# over different platforms. Mono is around most relevant platforms now anyway, but it's less ubiquitous than a JVM runtime. C++ is technically more supported than both, but that runs aground with the whole productivity issue.
Then there's a giant infinite continuum of interop choices between two or more languages, and they carry their own benefits and drawbacks.
Ask yourself a few things:
1. How (logically) complex is my game? A game with a lot of complex logic (think RPGs and Simulations) at multiple layers of play often benefits from a higher level scripting language. Whether that's interop with a lower-level engine (with the scripting being "game logic") or just straight making a game in python for example depends on other factors. Unity uses C# for scripting along with other stuff precisely because it's more "scripty" than C++.
2. How (computationally) complex is my game? Python does not perform well. Neither does any other scripting language. When you put your languages choices into this question, the same thing applies: Java and C# are generally slower than C++ when both are written properly (and more importantly, idiomatically). I've seen benchmarks where Java is as fast or slightly faster than C/C++, but it is MUCH harder, and the productivity dimension totally flips on its head. If you need fancy physics or otherwise complex algorithms (and an indie CAN make a game that is computationally demanding), you may want to squeeze every bit of performance you can get. You probably won't, but it's worth thinking about.
3. How long do I want to spend making it? If you're making it for fun and have no problem working on it for a very long time, it matters far less what language you work with, since once you're decently skilled at a language it's just a matter of trudging through the details, which basically amounts to an investment->reward problem. If you don't want to spend the next five years developing a small game or actually need to make money, productivity becomes very important.
4. How much do I *really* know about my language of choice? You may think you know C++ well, but I highly doubt you actually know it as well as Java/C#. This isn't an attack or anything, that's just the way C++ is. Evaluate what you actually know as well as you can, and decide if learning a language some more is something you want to or are willing to do.
5. How much of my game do I actually want to make? Everyone is encouraged to not "reinvent the wheel", and while I think that's a good thing for learning purposes, it's not so much for actual development. C++ as stated above has the best library support around, but it's not as if there isn't *something* analogous in C#/Java. Whenever I work on something, I always pick the libraries I want to use first, then the language that supports them most readily. Language interop can be painful, and it's not something I like doing readily.
...And there's your wall of text response. Word economy was never my strong suit. In the end, it's really just a long-winded way of saying "it depends".
