Wanted to give some real quick feedback.
First, let me say thanks for providing this interface. It saves me from having to do it (I had actually already started - but you guys are much farther along) and I can assure you, your efforts are most appreciated.
While I've not done a lot with the API, I have played a little thus far. The network console interface is really, really, helpful. Since this project is currently sans documentation or even pydoc, allowing for introspection is a real life saver. I'm just throwing this out there, but I seem to recall ipython has an interface to allow for wrapping for network/interactive shells. I wouldn't swear to that though. You might want to see if this is a viable upgrade. Having something with the power of ipython as a console would be simply awesome. Then again, you guys might be considering the console as a short term solution for now.
I have noticed the interface in general is extremely fragile. This is already noted in the release notes but it doesn't hurt to reaffirm what you already know.
Parameter validation and exception/error handing would be a huge improvement over crashing Spring. In my opinion, this is the single largest obstacle to prevent wider acceptance of the python interface.
Here's what I'm working on. I've created an "AI" called, "RAIMI" (Remote AI Management Interface). This in turn uses Pyro (version 4 for now - for performance/simplification reasons). As the description implies, its really more of an interface for AIs rather than an AI proper. Then, "user AIs" make themselves known via the name server. On event from Spring, RAIMI looks up an AI for the team and passes the event to the AI. At any rate, RAIMI would be fairly static and generally not changed by would be AI authors. In turn, developers make their AI available via the name server whereby RAIMI is able to discover them. This glosses over various details because its both tedious and I'm working out some of the details and coding.
I fully expect RAIMI will do things like statistical analysis of the map, saving each remote AI from having to do so. None of which is remotely close to being coded yet. It of course, also acts as a synchronizing gateway for callbacks, back into the Spring engine; so as to insure single threadedness. This approach should reduce redundant work between multiple AIs as well as drastically improve performance for AI startup (metal mapping/analysis) without having to make a ton of AI calls to obtain such information (I assume).
In doing so I hope this approach allows each team AI to run on one or more CPUs on one or more computers. There are some very real questions yet to be answered which will determine if my approach has wings. If this works it means each AI can run on different machines/CPUs, independent of the game's CPU load.
If my approach pans out, and that's currently a big if, I intent to provide a complimentary library to aid in developing AIs such that the library helps with common tasks, asset tracking, basic strategies, etc. In doing so, I hope to allow people to concentrate on AI implementation rather than becoming mired in the many small details of AI game development.
I'll keep you guys updated as I continue to make progress.