But what is the benefit of not having a class for functions?
You pretty much covered it. The question is really why have a class if one doesn't make sense? Sometimes people will group related functions into a class definition, but that's precisely what a module (.py file) is for. If there is no logical class, don't force one on the situation.
Which I abbreviated to "custom = Custom.Custom()".
Right, but if no one will access anything in Custom (the module), but Custom (the class) doesn't have any data members (only functions), then just remove the class and put the functions in the module. I think what you might be missing is what a class really provides: data encapsulation.
For example, let's say you wanted to create your own List class. Sure, you can do things
to a list like get its length, append values, cut it in half, test if it's empty, etc. But that's only half the story. The really important bits are the data a class stores in each instance created from it.
The List class itself--the actual class definition--doesn't hold any data. It is merely the idea of a list. All it does is define functions. But when you
instantiate (create) a list, a spot in memory for its data values is created and its __init__() function is executed with self pointing to that memory. "self" is the class instance (object)--not the class itself.
Code:
class List:
def __init__(self):
self.size = 0
self.values = []
def getSize(self):
return self.size
def add(self, item)
self.values.append(item)
def isEmpty(self):
return self.getSize() == 0
All these "self"s refer to whatever List instance you happen to call the functions on.
Code:
foo = List()
foo.add("hello")
foo.add("world")
bar = List()
print bar.isEmpty()
> True
Inside the function calls on the first three lines, "self" points to the same object that "foo" points to. In the next two lines "self" refers to the object pointed to by "bar". You can also access the data values using foo and bar directly:
Code:
print foo.size
> 2
print foo.values[1]
> world
print bar.size
> 0
Think of a class instance as a container of values. The class defines functions that operate on those values through the passed-in "self" value. When I say that the value for "self" is provided automatically when calling a function through a reference, I mean that you don't place the value that goes into the "self" variable inside the ()s of the function. Instead, it goes in front of the function call.
"foo" points to a List instance. When this function executes its first parameter--"self"--gets assigned the same reference that foo has automatically by Python. The second parameter--value--gets assigned the string "hello", even though it looks like it's the first value being passed to add(). When you call the function through the class instead of through the foo instance you must pass in a value for self:
Code:
[B][COLOR="Red"]List[/COLOR][/B].add([B][COLOR="Red"]foo[/COLOR][/B], "hello")
Do you see the difference? Here you can see that foo is assigned to "self" inside the function.
Could I get away with this?
Code:
def foundCity(self, tCoords=(-1, -1), iCiv=iBarbarians, name=None, iCityCulture=0, lReligions=[], lBuildings=[], iPopulation=1):
So you could use this function to spawn barbarian cities without any arguments, then?
Yes, that would work, but then that function will be very complicated. It's better to have short functions that do specific things. Twenty lines of code for a single function is bordering on too long in my book. Sure, sometimes it's impractical to split apart a complex function, but it's much harder to understand a function later if it's very long. I target 5-10 lines of code per function for a lot of my coding. I don't count the function declaration itself (parameters) nor its documentation.
But to be clear, you understand the concept correctly.
This would pretty much make most of the functions I was planning on including in the stacking redundant!
As I just wrote, I think a nice API of small functions will be better for people to understand. They can learn bits and pieces as they need them, and it'll be easier for you to write and add to later.
But I don't see what good the asterisk is doing in the definition line.
It collects all of the parameters you pass to the function into the list. Let's say you wrote a similar multiply() function for two arguments:
Code:
def multiply(x, y):
return x * y
but you now what to allow 2 or 3 arguments:
Code:
def multiply(x, y, z=1):
return x * y * z
Okay, 2-4 arguments:
Code:
def multiply(x, y, z=1, a=1):
return x * y * z * a
You can see where this is going. Sure, you can leave off the * and make the caller put the arguments into a second set of parentheses:
Code:
def multiply(args):
for ...
print multiply((2, 3, 4))
But that looks ugly. There will be cases where you want to allow one argument here, and that forces the caller to make a tuple when one doesn't already exist:
Blech! By using the * it wraps all the arguments in a tuple for you--even if there's only one. Also you can have fixed parameters before it too. In any case, it's not commonly used. I mentioned it only because it can be handy when building highly-flexible APIs.
As for looping over lists, you can use the same loop construct over tuples (immutable lists), lists, sets, and dictionaries. Python makes dealing with standard collections very easy.
My problem was that I couldn't use len to determine how many sets of coordinates were in argsList, because the amount of entries was always 2. Like:
Code:
(x, y) or ((x, y), (x, y))
Ah, in this case you'd need to test the type of the elements in the tuple. You know you're already getting a tuple, but it might contain two integers or two more tuples.
Code:
def do(args):
if isinstance(args, tuple):
# two coordinate pairs
else:
# single coordinate pair
I probably have the args backwards in isinstance(). I always need to look them up when using it.
But what it does is check the type of a variable's value against one or more classes (types).
:
I also tried creating a hierarchy of classes with indentation (as I've seen done in PyHelpers) but that didn't do anything useful for me.
But things like PlayerUtil and TradeUtil (maybe) are better examples.
