Which version of Python (multiprocessing)?

[EmpireOfCats]

Has anybody heard which version of Python will be used? There are two reasons why this is important.

First, Python 2.6 and later includes a new module for multiprocessing, which could go a long way towards fighting the speed problems that some mods and in Civ IV. Second, Python 3.1 is not backwards compatible and not installed by default on any system I know of, but gets rid of lots of problems like the terrible Unicode handling.

(Note that I am assuming that they will include Python because their moder base is used to it. I can't imagine that they force everybody to learn C++, a language that has gotten so complex that even Google is developing an alternative.)

 

[Decimatus]

Has anybody heard which version of Python will be used? There are two reasons why this is important.

First, Python 2.6 and later includes a new module for multiprocessing, which could go a long way towards fighting the speed problems that some mods and in Civ IV. Second, Python 3.1 is not backwards compatible and not installed by default on any system I know of, but gets rid of lots of problems like the terrible Unicode handling.

(Note that I am assuming that they will include Python because their moder base is used to it. I can't imagine that they force everybody to learn C++, a language that has gotten so complex that even Google is developing an alternative.)

I thought the devs said they wouldn't be using python for this game? I can't remember where I heard that but pretty sure it was an article or interview about how much better modding would be.

 

[Dale]

Python hasn't been confirmed or denied (literally no comments), but XML and DLL SDK have.

 

[Jawa'sRevenge]

I really hope there is no python, I can't write it worth anything

If they use it they will probably be using 3.1.1

 

[mathepic]

If your using Python, its going to be slow.

If you want them to speed it up, then the best way is to get rid of Python.

 

[mjs0]

Actually python has been mentioned once in an article I highlighted in this thread
It is another GDC Preview article, (this one at TheKartel.com.)

The game engine used in Civ V has been built from the ground up, but still boasts the straightforward python xml scripting and customization.

 

[LDiCesare]

If they don't use python, they should still provide some scripting language. If they only provide C++ and xml, they are just stupid because a scripting language is the most useful thing for modding.

 

[CanuckSoldier]

Yes but they use python in that sentence like it's an adjective for XML, so it may very well be a mistake. Since no other review or dev comment has mentioned python I would be sceptical.

Yes they need something easy for people to map custom map scripts, but python is very slow, so something else is probably better or maybe they will use C++ but make us a really nice front end

CS

 

[mjs0]

As I mention in the thread whoever wrote that review was clearly quite interested in some of the details (as a fan of the genre), more so than some of the other reviewers anyway, so who knows, maybe they picked up on something others had missed.

Still, that said, I'm inclined to agree...it's not a solid indication at all...I just had noticed the mention and wanted to make sure it was caught.

 

[Arizona_Steve]

Put a Java JVM in there. Faster than Python, and easier to handle than C++.

 

[PPQ_Purple]

I hope they dump python and do it all in C++.
Than I will finally have a leg up on the moding comunity.

 

[LDiCesare]

I hope they dump python and do it all in C++.
Than I will finally have a leg up on the moding comunity.

The point is not to have many people able to do mods. The point is C++ is not just harder to code but much harder to integrate. For instance, if I change 2 python files and another mod changes 3 python files, I can either use both without modification, or merge at most 2 files with a text editor and be done. If the mods are dll's, I suspect I'll have to recompile the dll just to merge the mods, even if there's no conflict between the modified files. There are ways around this issue, but it may become very painful to just install several mods and have them work together.
Also, it's a lot easier to crash a program with C++ than with python. Very easy to do some memory leaks for instance.
Whether it's python, lua, ruby or whatever, it doesn't really matter.
As for python being slow, I suspect boost:ython may not help, and I never had any speed problems with it in my mods. I think it was more the opening of the api

 

[civ_king]

Python is good, easy to learn

Probably best if they keep XML&Python&C++

 

[EmpireOfCats]

The clever thing would be to continue to support both. Python is easy to learn -- believe me, if I can, anybody can -- and will get people into the modding game quickly. C++ is hell to learn -- Google is inventing a whole new language because it's so crufty -- but fast and powerful. Once people are hooked, they can switch to C++ for the hardcore stuff.

If they go with Python 2.6, part of the speed problems can be made up for by using the new multiprocessing features, because those are not bound by the evil GIL lock anymore. That would be cool.

 

[Jawa'sRevenge]

I disagree, I can do C++, Java, and the like, but Python is still a complete mystery to me, I can't learn it at all.

 

[LDiCesare]

Google's go is not going to get wide acceptance soon. It doesn't run on windows to begin with. It's supposed to compile fast, but they say a few features might come in later and, you know, these are often the things that slow down compilation. And they rely on the case of the first letter of variables to infer whether they are public or not!

 

[Yakk]

Has anybody heard which version of Python will be used? There are two reasons why this is important.

First, Python 2.6 and later includes a new module for multiprocessing, which could go a long way towards fighting the speed problems that some mods and in Civ IV. Second, Python 3.1 is not backwards compatible and not installed by default on any system I know of, but gets rid of lots of problems like the terrible Unicode handling.

In Civ 4, Python was mainly used as "easy-write" code from hooks in the DLL, where they would ask the Python system if they wanted to replace the (faster) C++ code by overriding some option or not.

So the main engine ends up blocking and waiting for you to respond.

Hmm. If they have multiple C++ threads calling into python, having something like python multiprocessing around would help. But even there, in theory they could just make the python calls be functional and pass in explicit state (and read back explicit state) to marshal over in the C++ land that originates the calls?

(Note that I am assuming that they will include Python because their moder base is used to it. I can't imagine that they force everybody to learn C++, a language that has gotten so complex that even Google is developing an alternative.)

Google is all about throwing more brute at the problem. More brute makes code easier to debug? Google is in favour. (up to O-notation differences!)

Home computers don't have more brute. They are fixed in how much brute they have.

 

[Dale]

Google is inventing a whole new language because it's so crufty

- Doesn't run on Windows.
- Doesn't run on the Internet/Browser.
- Doesn't run on modern consoles.
- The compiler converts it to a mixture of C and assembler.
- The runtime is in C++ and doesn't run Go natively, must be C.
- Go binary is "nearly as fast as" C/C++ binaries.

If Go is so good, why's it converted into C and assembler? Shouldn't it just go to assembler only? Then you wouldn't really need a runtime.

Sounds like a script-kiddy play thing to me.

 

[EmpireOfCats]

Sounds like a script-kiddy play thing to me.

Your points are valid for us, but not for most people. Google doesn't care about Windows or consoles anyway, and it they say themselves that it is a brand-new language. The GC doesn't really work that well, either, it seems. There are no classes in the, uh, classic sense, which will put some people off.

What Go does do very, very well is concurrency, see here for a discussion:

Compared to Java, which I think is the main competitor to Go in this area, Go's goroutines and channels are just so much easier to work with than Java threads and locks, there's just absolutely no comparison at all. Go pretty much destroys the competition in this area.​

It is also a lot easier on the eyes, which seems to be the Python influence on the language (they should have gone whole hog and used significant whitespace instead of those stupid braces, but getting rid of semicolons is a step in the right direction).

We'll just have to wait and see -- and continue this discussion in the Civ VI forum in a few years .

 

[Chalks]

If Go is so good, why's it converted into C and assembler? Shouldn't it just go to assembler only?

I don't see why. If the C code is as optimal as possible when compiled, why would they reinvent the wheel? One would assume that they're only converting to assembly in situations where they think they can optimise better than C does natively.