You're talking about the entire Universe and Empire modules here. All of these things (Empires, planets, fleets, systems) are shared by client and server. If you want to expose the universe and empire modules in python, then you need to re-write all of these.
No! Just as you don't need to rewrite your library if some program does link to it, we only need to define the interface to python, and we'd be able to create a new SpamProductionCenter by using something like
from Universe import ProdCenter
I wouldn't feel too good about inexperienced coders working with anything. We can let them help, but they shouldn't be tasked with writing large, important pieces of code unless we know they're capable of doing it well. You can introduce bugs no matter which language you're working in, and the inexperienced coders will always introduce more bugs than the experienced ones.
I agree completely with you in this matter. But theh fact that someone is coding in Python does not mean that he's an inexperienced coder.
I do not see what the difference is. A logic error is a logic error, whether it's coded in C++, python, Java, even LISP. It's perfectly easy to write game breaking errors in high level languages. Here's an example, in VB:
In this example the high-level language would raise an exception, and you could theoretically examine the code using the python console and continue working, C++ would coredump, and you'll have to use gdb to track the error down, and recompile everything.
Just because there are people who want to help but dont work well in C++ is not, in my mind, a good reason to complicate things by making the app bilingual.
The reason for using python is not to make development easier for newbies, it's the possibility to write working code faster, making mods easier is a nice side-effect. IMHO, this is well worth the effort. (Of course we need to specify which parts are written in python and which are not)
It is going to be much much much harder to debug a bilingual application, because when we code the C++ bindings to the interpretter, we'd essentially have to assume that we have no idea what that thing is going to be doing.
Hmm, I think I'm missing something here, but the same thing applies the C++ code that #includes something.
This is, I will admit, an advantage of python. This is actually my biggest complaint right now, as I have never seen a compiler work as slowly as DevC++ has been on my system. Once you build the entire app though, the time it takes to recompile one module and relink is significantly less.
Did you compile with the -O2 switch? It really slows down compile-time.
The core data structures (empire and universe stuff), should be in C++, because they're used in the client, and the client HAS to be in C++, because there's no way you're ever going to convince Zach to re-write GG in python
we wanted to, we could expose GG to Python without needing to change a single line of GG code.
The way things are now, a lot of the turn processing code for the universe side is stubbed out in the form of virtual methods in the objects themselves. For instance, Planet::PopulationGrowthPhase() (or whatever its called). If you want to move just the turn processing code to python, its going to involve recoding the universe in python, OR giving arbitrary python code access to the private sections of the universe objects to manipulate them, which in my mind is a flagrant sin against OO programming.
If the virtual PopulationGrowthPhase in a subclassed Planet don't have access to the private members, why should Python-subclasses?
I probably misunderstood something here...
If you recode the universe in python, it means you're going to have to either put a python interpretter in the client, or maintain two different universe versions in two different languages. Neither of these options are acceptable to me. We shouldn't have to put a python interpretter in the client just because the server has one, and I, for one, refuse to maintain anything that's duplicated in two languages.
OK, if you are against including a python interpreter into the client, there's nothing we can do. But why are you against it? Most of our users will probably also install the server along with the client, which already needs Python.dll, the client would simple use this.
What is your argument about including python into the client?