tudza (3) [Avatar] Offline
#1
Okay, I believe I understand the purpose of the (object) in the line

class Caves(object):

but only because I am familiar with the concept of inheritance. Many people reading this may not be, right?

I understand that __init__ is a marker for a special method within a class. This makes sense, but the meaning of the "self" of Python and "this" of Java have never taken a solid hold. You say it is so a method can "access variables and share state" I have no idea what you mean here. Which variables, share the state of what?

Finally, it is not at all clear to me what this if statement with __name__ and __main__ is doing. Where did __name__ come from? It is probably some other special class name like __init__, but what is it for?

The code seems to assume that __name__ is going to equal the string "__main__", why is that?

Can __name__ equal something besides "__main__" is some circumstance, or does it always equal that because we are talking about something that is an (object)?

Really, everything I've read on classes fails to go into enough details on the subject so far as I can tell and you haven't succeeded in improving on anything else I've read. Really, I think every author seems to expect people will just magically "get it".

Message was edited by:
tudza
anthony.briggs (30) [Avatar] Offline
#2
Re: Chapter 6 and ___name___ , -___main___ business
Hi Tudza,

Thanks for the feedback, and sorry that I've taken a while to get back to this.

I think the section of the book that you're referring to is the initial class-based version of the cave generator, at the start of the chapter. My description of __init__ goes something like this:

. #2 - Setting up variables within the class
. Most Python classes will have the __init__ method, which is responsible for setting up
. instances of the class when it's first created. Notice that we've gained a self argument
. in the method? That's so that a method can access variables and share state. All of
. the lists that we used in chapter 2 are here, but prefixed with self so that they refer to
. the variables in the instance.

I'm not sure exactly how to make this clearer - it seems obvious to me that the variables and state refer to the instance (which is what's generated from the class when you do something like caves = Caves(20)), but then I'm a) a programmer and b) wrote the paragraph in question. Perhaps if I reworded it so that it explicitly referred to the instance? Something like:

. #2 - Setting up variables within the class
. Most Python classes will have the __init__ method, which is responsible for setting up
. instances of the class when it's first created. Notice that we've gained a self argument
. in the method? That's so that a method knows which instance of Caves to refer to, and
. can access it's variables and shared state. All of the lists that we used in chapter 2 are
. created here, and stored within self so that other methods can access them.

I've also made the second sentence more 'concrete', in that it refers to how you're supposed to use self, instead of more theoretical description. Does this second version make more sense?


The (object) and inheritance part of Python's class system is covered in more detail later on in chapter 6, but it's not vitally important in the early stages, and in practice I find that inheritance is a reasonably limited part of understanding what Object Oriented programming is about.


The if __name__ == '__main__': thing is a Python "trick" to tell whether the program is being run directly, or called as a library. It's nothing to do with the class itself. If the program is a library, then __name__ will be the module name (eg. 'caves' if it's in caves.py and you've done an 'import caves'), but if it's run directly then __name__ will be the special name '__main__'. I did cover that part of things back in chapter 4, and used it in most of the scripts in chapter 5.


> Really, everything I've read on classes fails to go into enough details on the subject so far
> as I can tell and you haven't succeeded in improving on anything else I've read. Really,
> I think every author seems to expect people will just magically "get it".

I'm not expecting you to "magically get it" - far from it. If you haven't programmed in an Object Oriented fashion before it takes a profound shift in how you think about your programs, and you won't understand it just by reading a description of classes. I've found that it's hard to understand OO (and most other programming strategies) without something concrete to help you follow along.

That's the premise of chapter 6 - it starts off with the 'procedural' version of the caves used in Chapter 2 (Hunt the Wumpus), shows you how complex they can be and then converts them to an OO style. OO is about how to structure and design your programs as much as the nitty gritty syntax of how to create a class, so I think it's important to cover that in just as much detail. That's what that section is trying to do, and it might be what you're missing in terms of your mental model.

I hope that helps you,

Anthony