There is no x or y or even a pPlayer defined at the point you do it so "pPlayer.initCity(x, y)" can not possibly work.
About this, there is something called a "name space" where all the things that are defined in a program are stored. So if you assign a value to a variable - or define a function - then that name will be present in the name space and can't be shared with any other. (If defined anew it will actually be replaced.)
So there is a global name space for the entire module, but there are also local spaces for each function/method and so on. Each module has its own set of names - so every module can have whatever in its own name space without it conflicting with any other module. (But careless importing of modules will of course cause conflict with names.)
In your module, the names present from scratch are only the built-in functions (and methods) of the Python programming language. These include names like str, import and append - stuff that are part of Python. So you should be aware of these because you shouldn't be defining anything yourself with such a name - because this will confuse the interpreter!
You start by importing CvPythonExtensions to your module. You actually do it in a rather careless (but very convenient) way (again copying from others):
Code:
from CvPythonExtensins import *
What this does is it copies the entire Boost Python thingy from the SDK and adds it on top of your module's name space. This means that all classes, methods, functions, constants and whatnot are now available to your module - they are part of its global name space. This is why you can do the next thing:
The interpreter wouldn't be able to execute this assignment statement without there first being a CyGlobalContext class to initiate. This class is in fact part of CvPythonExtensions.
Another way of doing this - and even if its probably more correct I would advice against it - would be to import the CvPythonExtensions "module" but not make it's content part of your module's name space:
Code:
import CvPythonExtensions
gc = CvPythonExtensions.CyGlobalContext()
Less convenient but you'd be able to define your own CyGlobalContext as a variable, function, class of whatever in your module. (Not that you'd want to do that.) Or you could just import the bits you actually need, like the class itself:
Code:
from CvPythonExtensions import CyGlobalContext
gc = CyGlobalContext()
But this would mean that the interpreter wouldn't recognize the other stuff in CvPythonExtensions, like the CyPlayer or CyCity classes. So this is clearly inconvenient.
So gc is now defined as a global variable (constant) in your module. So if CvPythonExtensions added 1001 names (just making a figure up) you now have 1002 defined names.
The problem with the line:
Code:
pCity = pPlayer.initCity(x, y)
...is that while you're free to assign just about anything to the name pCity, the stuff that you're assigning to it should already be defined. Once again the interpreter won't know that that stuff is. The names pPlayer, x an y aren't defined anywhere. But if you do this instead:
Code:
x = 10
y = 34
pPlayer = gc.getActivePlayer()
pCity = pPlayer.initCity(x, y)
...then the interpreter will actually be able to make sense of it.
So firstly you would assign integer values to the x and y variable. Next you would assign the return value of the CyGlobalContext.getActivePlayer() method to the name pPlayer. You can do this only because both gc and getActivePlayer have already been defined in your script. (getActivePlayer is defined as a part of the CyGlobalContext class that you imported above, so the interpreter can't even recognize whether or not you've defined it in your module or not. Its part of it's name space - as simple as that.)
Now it would be valid to define pCity the way you did. Because the name pPlayer was defined and added to the name space on the above line. And the variables x and y actually point to valid integer values. (The initCity name was of course defined within the CyPlayer class and imported from the SDK.)
As a side note, you could do this instead:
Code:
pCity = gc.getActivePlayer().initCity(10, 34)
The point is that the interpreter can't see the difference. The only thing the sample code above added was some names that cluttered up the module's name space. It was easier for you and me to read, however, and this is why you probably shouldn't try to shorten things up like this. But still, all the variables used added no functionality to the script in themselves.
Regarding importing - you don't ever need to import the Event Manager to any other module. It actually works the other way around - all other modules should - in directly or indirectly - be imported to the Event Manager.
I can't shake the feeling that you're still thinking you can "figure" programming out by looking at sample code. While that can be very helpful, you should realize that you're basically wasting your time when you're "experimenting" with Python without knowing exactly what you're trying to do. Its all explained in plain English in the sources and there really is no reason to do anything in a random fashion. The debugging time could be used for actual learning instead. With your academic background you'd be able to learn the basics of Python in no time at all.
