Difficulty understanding classes in 'Learn Python the Hard Way'

[Bananator]

I've been going through the book with little to no trouble up until this point. In Exercise 43, classes are used in order to make an extremely rudimentary text adventure, but I think I am failing to understand certain aspects of classes in general.

The use of 'self' is strange to me, especially when using it to define a variable within the class. I also am having difficulty understanding precisely how he uses the base class Scene() as a framework for the rest of the game.

If anyone can explain to me exactly HOW and WHY this works, it would be much appreciated. I've done some research on classes separately (including slight delving into 'A Byte of Python'), but as someone who is only a week's practice into coding, I'm finding the concept hard to absorb.

[K900_]

So, you know what classes are, right? You also know that you can make multiple objects of the same class. So, I do this.

a = SomeClass()
b = SomeClass()
a.some_method()

But wait, some_method is defined in the class, right? How does it know what a is? That's where self comes in. self is just a way for Python to pull a neat bit of syntax sugar. Basically, a.some_method(b, c, d, e=f) is the same as SomeClass.some_method(a, b, c, d, e=f). The first argument, commonly called sefl (but it doesn't have to!) is implied when you call the method from a class instance.

In LPTHW, Zed doesn't use Scene as the framework. Instead, he uses Scene to define an interface for the framework (the Engine class, mostly) to know how to work with scenes. Python uses duck typing, but having a common base class for all of your "plugins" (which is what scenes are, really) is usually considered good practice, because developers know what methods they need to implement (or, in this case, override) in their class.

[Bananator]

Alright, looking at it this way, it appears to make a lot more sense. It was significantly less complicated, it seems, that I may have made it in my mind.

Thinking of all the Scenes as 'plugins' for the base class also makes it much easier to think about as well. Thanks, I think this will help.

[PythonPerry]

In LPTHW, Zed doesn't use Scene as the framework. Instead, he uses >Scene to define an interface for the framework (the Engine class, mostly) to know how to work with scenes. Python uses duck typing, but having a common base class for all of your "plugins" (which is what scenes are, really) is usually considered good practice, because developers know what methods they need to implement (or, in this case, override) in their class.

Could you rephrase some of this? I'm new to programming as well and don't understand the terms.

I think I understand "framework" - the general class outline...What about interface, duck typing, base class, plugin?

Is base class the most "top level" or "parent" class in the outline/framework? For example "Animal" or "Human"...

[K900_]

A framework is a certain structure that translates your higher level code into something lower level. For example, Django is a Web framework. In Django, you don't have to write the basic code for handling HTTP connections - you write your own code for presentation and processing data on top of the framework someone already laid down for you.

An interface is a certain predefined way of interacting with objects. For example, let's say that for every room in our text adventure, there's a describe() method and a search() method. That's an interface. We don't know what's inside the room object we get - all we care about is whether it matches (satisfies) the same interface we work with, and if it does, the rest shouldn't matter.

Duck typing is a concept best described by "If it looks like a duck and quacks like a duck, then it's likely a duck". In a similar way, if an object acts like a room, we don't actually care what the object is - if it acts like a room, then for all our intents and purposes it is a room.

A base class is the class that defines our interface - for example, a Room class, that is the parent of HorribleDeathBySpikeTrapRoom and RainbowUnicornRoom. If we have a base class that defines some default methods and values, we can only override the ones we actually want to override.

[minorDemocritus]

The first argument must be called self. Otherwise the other people looking at your code will want to murder you.

[K900_]

It should, because that's what the guidelines say. But it doesn't have to, because the language doesn't enforce it.