On Mon, May 17, 2010 at 1:19 PM, Alex Hall <mehg...@gmail.com> wrote: > Hi all, > I am a bit confused about classes. What do you pass a class, since all > the actual information is passed to __init__? For example, say you > have a dog class. The dog object has a name, a size, and a color. I > believe you would say this: > > class dog(): > def __init__(self, name, size, color): > self.name=name > self.size=size > self.color=color > #end def > #end class > > What, then, gets passed to the class constructor? > class dog(whatGoesHere?): > Sometimes I see things passed to this. For example, if you create a > class for a wxPython frame, you will say: > class myapp(wx.App): > In this case you pass something. However, I have a class that I use in > one of my programs to create "contact" objects, which looks like this: > class contact(): > def __init__(self, name, email, status, service): > self.name=name > self.email=email > self.status=status > self.service=service > #end def > #end class > > Here, I do not pass anything to the class, only to __init__. What is going on?
There is no notion of "passing" stuff to classes (at least in the way you're thinking about it). The parentheses in these cases have nothing to do with function calls. `class Foo(Bar, Baz):` declares a new class with classes Bar and Baz as base classes (Python has multiple inheritance). `class Foo():` declares a new class with only the class `object` as its implicit base class. The parentheses can and almost always are omitted in such cases, so one would normally write `class Foo:` instead. There's some metaclass magic involved and the constructor of the metaclass is called (in the earlier case, with Bar and Baz among the parameters) behind the scenes to create the class Foo itself, but Foo itself isn't "called" when Foo is being created; indeed, that wouldn't even make sense, for how could the class possibly be called when it's still being defined? In other words, the parentheses in class declarations have nothing directly to do with function calls and it's probably best not to conceptualize it that way; they're used just to specify base classes (and the metaclass in recent Python versions with some extra syntax). > On a related note, is it horrible for resource usage to create a large > array, up to 500 or so, where each member is a small object? I am > thinking of, for example, a game board array where each member of the > array is a "square" object. A square might have a status, a color, and > other flags associated with it, so you could then say something like > board[i][j].hasGamePiece=True. Lookups and adjustments like this will > be going on a lot. Am I better off using an array of numbers where > each number means something different? Premature optimization is the root of all evil. Only *if* your program ends up using too much memory *and* memory profiling shows the board to be a significant contributor to the problem, *then* you would start looking into such memory optimizations. Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
