Chapter 9: Classes

Each instance created from the Dog class will store a name and an age, and we’ll give each dog the ability to sit() and roll_over():

A function that’s part of a class is a method. Everything you learned about functions applies to methods as well; the only practical difference for now is the way we’ll call methods. The init() method is a special method that Python runs automatically whenever we create a new instance based on the Dog class. This method has two leading underscores and two trailing underscores, a convention that helps prevent Python’s default method names from conflicting with your method names. Make sure to use two underscores on each side of init(). If you use just one on each side, the method won’t be called automatically when you use your class, which can result in errors that are difficult to identify.

We define the init() method to have three parameters: self, name, and age. The self parameter is required in the method definition, and it must come first, before the other parameters. It must be included in the definition because when Python calls this method later (to create an instance of Dog), the method call will automatically pass the self argument. Every method call associated with an instance automatically passes self, which is a reference to the instance itself; it gives the individual instance access to the attributes and methods in the class. When we make an instance of Dog, Python will call the init() method from the Dog class. We’ll pass Dog() a name and an age as arguments; self is passed automatically, so we don’t need to pass it. Whenever we want to make an instance from the Dog class, we’ll provide values for only the last two parameters, name and age.

The two variables defined in the body of the init() method each have the prefix self. The line self.name = name takes the value associated with the parameter name and assigns it to the variable name, which is then attached to the instance being created. The same process happens with self.age = age.

The sit() and roll_over() methods don’t do much. They simply print a message saying the dog is sitting or rolling over. But the concept can be extended to realistic situations: if this class were part of a computer game, these methods would contain code to make an animated dog sit and roll over.

Think of a class as a set of instructions for how to make an instance. The Dog class is a set of instructions that tells Python how to make individual instances representing specific dogs.

Let’s make an instance representing a specific dog:

The output is a summary of what we know about my_dog:

9-1. Restaurant: Make a class called Restaurant. The init() method for Restaurant should store two attributes: a restaurant_name and a cuisine_type. Make a method called describe_restaurant() that prints these two pieces of information, and a method called open_restaurant() that prints a message indicating that the restaurant is open. Make an instance called restaurant from your class. Print the two attributes individually, and then call both methods.

9-2. Three Restaurants: Start with your class from Exercise 9-1. Create three different instances from the class, and call describe_restaurant() for each instance.

9-3. Users: Make a class called User. Create two attributes called first_name and last_name, and then create several other attributes that are typically stored in a user profile. Make a method called describe_user() that prints a summary of the user’s information. Make another method called greet_user() that prints a personalized greeting to the user. Create several instances representing different users, and call both methods for each user.

Let’s write a new class representing a car. Our class will store information about the kind of car we’re working with, and it will have a method that summarizes this information:

When an instance is created, attributes can be defined without being passed in as parameters. These attributes can be defined in the init() method, where they are assigned a default value.

Let’s add an attribute called odometer_reading that always starts with a value of 0. We’ll also add a method read_odometer() that helps us read each car’s odometer:

Our car starts with a mileage of 0:

You can change an attribute’s value in three ways: you can change the value directly through an instance, set the value through a method, or increment the value through a method. Let’s look at each of these approaches.

9-4. Number Served: Start with your program from Exercise 9-1. Add an attribute called number_served with a default value of 0. Create an instance called restaurant from this class. Print the number of customers the restaurant has served, and then change this value and print it again. Add a method called set_number_served() that lets you set the number of customers that have been served. Call this method with a new number and print the value again. Add a method called increment_number_served() that lets you increment the number of customers who’ve been served. Call this method with any number you like that could represent how many customers were served in, say, a day of business.

9-5. Login Attempts: Add an attribute called login_attempts to your User class from Exercise 9-3. Write a method called increment_login_attempts() that increments the value of login_attempts by 1. Write another method called reset_login_attempts() that resets the value of login_attempts to 0. Make an instance of the User class and call increment_login_attempts() several times. Print the value of login_attempts to make sure it was incremented properly, and then call reset_login_attempts(). Print login_attempts again to make sure it was reset to 0.

When you’re writing a new class based on an existing class, you’ll often want to call the init() method from the parent class. This will initialize any attributes that were defined in the parent init() method and make them available in the child class.

As an example, let’s model an electric car. An electric car is just a specific kind of car, so we can base our new ElectricCar class on the Car class we wrote earlier. Then we’ll only have to write code for the attributes and behaviors specific to electric cars.

Let’s start by making a simple version of the ElectricCar class, which does everything the Car class does:

The ElectricCar instance works just like an instance of Car, so now we can begin defining attributes and methods specific to electric cars.

Once you have a child class that inherits from a parent class, you can add any new attributes and methods necessary to differentiate the child class from the parent class.

Let’s add an attribute that’s specific to electric cars (a battery, for example) and a method to report on this attribute. We’ll store the battery size and write a method that prints a description of the battery:

There’s no limit to how much you can specialize the ElectricCar class. An attribute or method that could belong to any car, rather than one that’s specific to an electric car, should be added to the Car class instead of the ElectricCar class. Then anyone who uses the Car class will have that functionality available as well, and the ElectricCar class will only contain code for the information and behavior specific to electric vehicles.

You can override any method from the parent class that doesn’t fit what you’re trying to model with the child class. To do this, you define a method in the child class with the same name as the method you want to override in the parent class. Python will disregard the parent class method and only pay attention to the method you define in the child class.

Say the class Car had a method called fill_gas_tank(). This method is meaningless for an all-electric vehicle, so you might want to override this method. Here’s one way to do that:

Now if someone tries to call fill_gas_tank() with an electric car, Python will ignore the method fill_gas_tank() in Car and run this code instead. When you use inheritance, you can make your child classes retain what you need and override anything you don’t need from the parent class.

When modeling something from the real world in code, you may find that you’re adding more and more detail to a class. You’ll find that you have a growing list of attributes and methods and that your files are becoming lengthy. In these situations, you might recognize that part of one class can be written as a separate class. You can break your large class into smaller classes that work together; this approach is called composition.

For example, if we continue adding detail to the ElectricCar class, we might notice that we’re adding many attributes and methods specific to the car’s battery. When we see this happening, we can stop and move those attributes and methods to a separate class called Battery. Then we can use a Battery instance as an attribute in the ElectricCar class:

When we want to describe the battery, we need to work through the car’s battery attribute: my_leaf.battery.describe_battery(). This line tells Python to look at the instance my_leaf, find its battery attribute, and call the method describe_battery() that’s associated with the Battery instance assigned to the attribute.

The output is identical to what we saw previously:

Now we can describe the battery in as much detail as we want without cluttering the ElectricCar class. Let’s add another method to Battery that reports the range of the car based on the battery size:

As you begin to model more complicated things like electric cars, you’ll wrestle with interesting questions. Is the range of an electric car a property of the battery or of the car? If we’re only describing one car, it’s probably fine to maintain the association of the method get_range() with the Battery class. But if we’re describing a manufacturer’s entire line of cars, we probably want to move get_range() to the ElectricCar class. The get_range() method would still check the battery size before determining the range, but it would report a range specific to the kind of car it’s associated with.

This brings you to an interesting point in your growth as a programmer. When you wrestle with questions like these, you’re thinking at a higher logical level rather than a syntax-focused level. You’re thinking not about Python, but about how to represent the real world in code. When you reach this point, you’ll realize there are often no right or wrong approaches to modeling real-world situations. Some approaches are more efficient than others, but it takes practice to find the most efficient representations. If your code is working as you want it to, you’re doing well! Don’t be discouraged if you find you’re ripping apart your classes and rewriting them several times using different approaches. In the quest to write accurate, efficient code, everyone goes through this process.

9-6. Ice Cream Stand: An ice cream stand is a specific kind of restaurant. Write a class called IceCreamStand that inherits from the Restaurant class you wrote in Exercise 9-1 or Exercise 9-4. Either version of the class will work; just pick the one you like better. Add an attribute called flavors that stores a list of ice cream flavors. Write a method that displays these flavors. Create an instance of IceCreamStand, and call this method.

9-7. Admin: An administrator is a special kind of user. Write a class called Admin that inherits from the User class you wrote in Exercise 9-3 or Exercise 9-5. Add an attribute, privileges, that stores a list of strings like "can add post", "can delete post", "can ban user", and so on. Write a method called show_privileges() that lists the administrator’s set of privileges. Create an instance of Admin, and call your method.

9-8. Privileges: Write a separate Privileges class. The class should have one attribute, privileges, that stores a list of strings as described in Exercise 9-7. Move the show_privileges() method to this class. Make a Privileges instance as an attribute in the Admin class. Create a new instance of Admin and use your method to show its privileges.

9-9. Battery Upgrade: Use the final version of electric_car.py from this section. Add a method to the Battery class called upgrade_battery(). This method should check the battery size and set the capacity to 65 if it isn’t already. Make an electric car with a default battery size, call get_range() once, and then call get_range() a second time after upgrading the battery. You should see an increase in the car’s range.

Let’s create a module containing just the Car class. We’ll store the Car class in a module named car.py, replacing the car.py file we were previously using. Here’s car.py with just the code from the class Car:

Now we’ll make a separate file called my_car.py. This file imports the Car class and then creates an instance from that class:

Importing classes is an effective way to program. When you instead move the class to a module and import the module, you still get all the same functionality, but you keep your main program file clean and easy to read. You also store most of the logic in separate files; once your classes work as you want them to, you can leave those files alone and focus on the higher-level logic of your main program.

You can store as many classes as you need in a single module, although each class in a module should be related somehow. The classes Battery and ElectricCar both help represent cars, so let’s add them to the module car.py.

Now we can make a new file called my_electric_car.py, import the ElectricCar class, and make an electric car:

You can import as many classes as you need into a program file. If we want to make a regular car and an electric car in the same file, we need to import both classes, Car and ElectricCar:

You can also import an entire module and then access the classes you need using dot notation. This approach is simple and results in code that is easy to read. Because every call that creates an instance of a class includes the module name, you won’t have naming conflicts with any names used in the current file.

Here’s what it looks like to import the entire car module and then create a regular car and an electric car:

You can import every class from a module using the following syntax:

This method is not recommended for two reasons. First, it’s helpful to be able to read the import statements at the top of a file and get a clear sense of which classes a program uses. With this approach it’s unclear which classes you’re using from the module. This approach can also lead to confusion with names in the file. If you accidentally import a class with the same name as something else in your program file, you can create errors that are hard to diagnose.

If you need to import many classes from a module, you’re better off importing the entire module and using the module_name.ClassName syntax. You won’t see all the classes used at the top of the file, but you’ll see clearly where the module is used in the program.

Sometimes you’ll want to spread out your classes over several modules to keep any one file from growing too large and avoid storing unrelated classes in the same module. When you store your classes in several modules, you may find that a class in one module depends on a class in another module. When this happens, you can import the required class into the first module.

For example, let’s store the Car class in one module and the ElectricCar and Battery classes in a separate module. We’ll make a new module called electric_car.py and copy just the Battery and ElectricCar classes into this file:

The class ElectricCar needs access to its parent class Car, so we import Car directly into the module. If we forget this line, Python will raise an error when we try to import the electric_car module.

Now we can import from each module separately and create whatever kind of car we need:

As you saw in Chapter 8, aliases can be quite helpful when using modules to organize your projects' code. You can use aliases when importing classes as well.

As an example, consider a program where you want to make a bunch of electric cars. You can give ElectricCar an alias in the import statement:

Now you can use this alias whenever you want to make an electric car:

You can also give a module an alias. Here’s how to import the entire electric_car module using an alias:

Now you can use this module alias with the full class name:

As you can see, Python gives you many options for how to structure code in a large project. It’s important to know all these possibilities so you can determine the best ways to organize your projects as well as understand other people’s projects.

When you’re starting out, keep your code structure simple. Try doing everything in one file and moving your classes to separate modules once everything is working. If you like how modules and files interact, try storing your classes in modules when you start a project. Find an approach that lets you write code that works, and go from there.

9-10. Imported Restaurant: Using your latest Restaurant class, store it in a module. Make a separate file that imports Restaurant. Make a Restaurant instance, and call one of `Restaurant’s methods to show that the import statement is working properly.

9-11. Imported Admin: Start with your work from Exercise 9-8. Store the classes User, Privileges, and Admin in one module. Create a separate file, make an Admin instance, and call show_privileges() to show that everything is working correctly.

9-12. Multiple Modules: Store the User class in one module, and store the Privileges and Admin classes in a separate module. In a separate file, create an Admin instance and call show_privileges() to show that everything is still working correctly.

9-13. Dice: Make a class Die with one attribute called sides, which has a default value of 6. Write a method called roll_die() that prints a random number between 1 and the number of sides the die has. Make a 6-sided die and roll it 10 times. Make a 10-sided die and a 20-sided die. Roll each die 10 times.

9-14. Lottery: Make a list or tuple containing a series of 10 numbers and 5 letters. Randomly select 4 numbers or letters from the list and print a message saying that any ticket matching these 4 numbers or letters wins a prize.

9-15. Lottery Analysis: You can use a loop to see how hard it might be to win the kind of lottery you just modeled. Make a list or tuple called my_ticket. Write a loop that keeps pulling numbers until your ticket wins. Print a message reporting how many times the loop had to run to give you a winning ticket.

9-16. Python Module of the Week: One excellent resource for exploring the Python standard library is a site called Python Module of the Week. Go to pymotw.com and look at the table of contents. Find a module that looks interesting to you and read about it, perhaps starting with the random module.

D9-1. Node Class: Write a class called Node. The init() method should store hostname, role, and ip as attributes. Add a method called describe_node() that prints a formatted summary, and a method called ping_node() that prints Pinging: <hostname>…​. Create three instances representing different Domus Digitalis nodes and call both methods for each.

D9-2. Service Class: Write a class called Service. Store name, host, and port as attributes, and add a default attribute status = 'stopped'. Add a method start_service() that sets status to 'active' and prints Starting <name> on <host>:<port>. Add a method get_status() that prints the current status. Create instances for Vault, Wazuh, and Gitea. Call both methods for each.

D9-3. VirtualMachine Inherits Node: Write a class VirtualMachine that inherits from Node. Add attributes vcpus and ram_gb. Add a method describe_resources() that prints the vCPU and RAM. Override ping_node() to print Pinging VM: <hostname>. Create two VM instances and call all methods.

D9-4. BGPSession with Peer Attribute: Write a class BGPPeer with attributes name, asn, and tunnel_ip. Write a class BGPSession that takes a local_router and a BGPPeer instance as attributes. Add a method describe_session() that prints a formatted session summary including both the local router and peer details. Create a session and call the method.

D9-5. Node Module: Store your Node class in a module called domus_nodes.py. In a separate file, import Node and create three instances. Call describe_node() for each. Then use at least two different import styles from Chapter 8.

C9-1. ISENode Class: Write a class called ISENode. Store hostname, persona, version, and ip as attributes. Add a method describe_node() that prints a formatted summary, and a method check_health() that prints Health check: <hostname> — OK. Create at least two instances and call both methods.

C9-2. PolicySet Class: Write a class called PolicySet. Store name, auth_protocol, and result as attributes, with result defaulting to 'Allow'. Add methods describe_policy() and evaluate() that prints Evaluating: <name> using <auth_protocol> → <result>. Create three instances with different protocols and results.

C9-3. ManagedDevice Inherits ISENode: Write a class ManagedDevice that inherits from ISENode. Add attributes endpoint_group and vlan. Add a method describe_endpoint() that prints both new attributes. Override check_health() to print Device health: <hostname> in group <endpoint_group>. Create two instances and call all methods.

C9-4. MonadPipeline with Stage Attributes: Write a class PipelineStage with attributes name and log_types (a list). Write a class MonadPipeline that stores a list of PipelineStage instances. Add a method describe_pipeline() that loops through all stages and prints each stage name and its log types. Build a pipeline with at least three stages and call the method.

C9-5. ISE Module: Store your ISENode and PolicySet classes in a module called ise_classes.py. In a separate file, import both classes and create instances. Call methods on each instance. Use at least two different import styles.

L9-1. Server Class: Write a class called Server. Store hostname, os, and ip as attributes. Add a method describe_server() that prints a formatted summary, and a method reboot() that prints Rebooting: <hostname>…​. Create three instances representing different servers and call both methods for each.

L9-2. Package Class: Write a class called Package. Store name, version, and arch as attributes, and add a default attribute installed = False. Add a method install() that sets installed to True and prints Installing <name>-<version>. Add a method status() that prints whether the package is installed. Create instances for three packages and call both methods.

L9-3. Container Inherits Server: Write a class Container that inherits from Server. Add attributes image and cpu_limit. Add a method describe_container() that prints the image and CPU limit. Override reboot() to print Restarting container: <hostname>. Create two container instances and call all methods.

L9-4. CronJob with Schedule Attribute: Write a class Schedule with attributes expression and description. Write a class CronJob that stores name, a Schedule instance, and command. Add a method describe_job() that prints all details including the schedule expression and description. Create two cron job instances and call the method.

L9-5. Server Module: Store your Server class in a module called server_classes.py. In a separate file, import Server and create three instances. Call describe_server() for each. Use at least two different import styles.

E9-1. Vocabulary Entry Class: Write a class called VocabularyEntry. Store palabra, definicion, and capitulo as attributes. Add a method display() that prints a formatted entry, and a method quiz() that prints ¿Cómo se dice "<definicion>" en español?. Create at least four instances from Don Quijote vocabulary and call both methods.

E9-2. Chapter Class: Write a class called Chapter. Store number, tema, and personajes (a list) as attributes, with a default attribute leido = False. Add a method mark_read() that sets leido to True and prints Capítulo <number> marcado como leído. Add a method describe() that prints all attributes. Create three chapter instances and call both methods.

E9-3. DELECandidate Inherits User: Write a base class LanguageLearner with attributes name and target_language. Write a child class DELECandidate that adds target_level and exam_date. Add a method describe_candidate() that prints all attributes. Override a greet() method from the parent to print a Spanish greeting. Create two instances and call all methods.

E9-4. StudySession with Topic Attribute: Write a class StudyTopic with attributes nombre and dificultad (e.g., 'alta'). Write a class StudySession that stores a list of StudyTopic instances and a duracion_minutos attribute. Add a method describe_session() that prints the duration and loops through all topics printing each name and difficulty. Create a session with at least three topics and call the method.

E9-5. Vocabulary Module: Store your VocabularyEntry and Chapter classes in a module called donquijote_classes.py. In a separate file, import both classes and create instances. Call methods on each instance. Use at least two different import styles.