Program Arcade GamesWith Python And Pygame
Dutch - Nederlands
Hungarian - Magyar
Portuguese - Português
Russian - Русский
Spanish - Español
Turkish - Türkçe
A library is a collection of code for functions and classes. Often, these libraries are written by someone else and brought into the project so that the programmer does not have to “reinvent the wheel.” In Python the term used to describe a library of code is module.
By using import pygame and import random, the programs created so far have already used modules. A library can be made up of multiple modules that can be imported. Often a library only has one module, so these words can sometimes be used interchangeably.
Modules are often organized into groups of similar functionality. In this class programs have already used functions from the math module, the random module, and the pygame library. Modules can be organized so that individual modules contain other modules. For example, the pygame module contains submodules for pygame.draw, pygame.image, and pygame.mouse.
Modules are not loaded unless the program asks them to. This saves time and computer memory. This chapter shows how to create a module, and how to import and use that module.
There are three major reasons for a programmer to create his or her own libraries:
- It breaks the code into smaller, easier to use parts.
- It allows multiple people to work on a program at the same time.
- The code written can be easily shared with other programmers.
Some of the programs already created in this book have started to get rather long. By separating a large program into several smaller programs, it is easier to manage the code. For example, in the prior chapter's sprite example, a programmer could move the sprite class into a separate file. In a complex program, each sprite might be contained in its own file.
If multiple programmers work on the same project, it is nearly impossible to do so if all the code is in one file. However, by breaking the program into multiple pieces, it becomes easier. One programmer could work on developing an “Orc” sprite class. Another programmer could work on the “Goblin” sprite class. Since the sprites are in separate files, the programmers do not run into conflict.
Modern programmers rarely build programs from scratch. Often programs are built from parts of other programs that share the same functionality. If one programmer creates code that can handle a mortgage application form, that code will ideally go into a library. Then any other program that needs to manage a mortgage application form at that bank can call on that library.
In this example we will break apart a short program into multiple files. Here we have a function in a file named test.py, and a call to that function:
# Foo function def foo(): print("foo!") # Foo call foo()
Yes, this program is not too long to be in one file. But if both the function and the main program code were long, it would be different. If we had several functions, each 100 lines long, it would be time consuming to manage that large of a file. But for this example we will keep the code short for clarity.
We can move the foo function out of this file. Then this file would be left with only the main program code. (In this example there is no reason to separate them, aside from learning how to do so.)
To do this, create a new file and copy the foo function into it. Save the new file with the name my_functions.py. The file must be saved to the same directory as test.py.
# Foo function def foo(): print("foo!")
# Foo call that doesn't work foo()
Unfortunately it isn't as simple as this. The file test.py does not know to go and look at the my_functions.py file and import it. We have to add the command to import it:
# Import the my_functions.py file import my_functions # Foo call that still doesn't work foo()
That still doesn't work. What are we missing? Just like when we import pygame, we have to put the package name in front of the function. Like this:
# Import the my_functions.py file import my_functions # Foo call that does work my_functions.foo()
This works because my_functions. is prepended to the function call.
A program might have two library files that need to be used. What if the libraries had functions that were named the same? What if there were two functions named print_report, one that printed grades, and one that printed an account statement? For instance:
def print_report(): print("Student Grade Report:" )
def print_report(): print("Financial Report:" )
How do you get a program to specify which function to call? Well, that is pretty easy. You specify the namespace. The namespace is the work that appears before the function name in the code below:
import student_functions import financial_functions student_functions.print_report() financial_functions.print_report()
So now we can see why this might be needed. But what if you don't have name collisions? Typing in a namespace each and every time can be tiresome. You can get around this by importing the library into the local namespace. The local namespace is a list of functions, variables, and classes that you don't have to prepend with a namespace. Going back to the foo example, let's remove the original import and replace it with a new type of import:
# import foo from my_functions import * foo()
This works even without my_functions. prepended to the function call. The asterisk is a wildcard that will import all functions from my_functions. A programmer could import individual ones if desired by specifying the function name.
When working with Python, it is possible to use many libraries that are built into Python.
Take a look at all the libraries that are available here:
It is possible to download and install other libraries. There are libraries that work with the web, complex numbers, databases, and more.
- Pygame: The library used to create games.
- wxPython: Create GUI programs, with windows, menus, and more.
- pydot: Generate complex directed and non-directed graphs
- NumPy: Sophisticated library for working with matrices.
A wonderful list of Python libraries and links to installers for them is available
Going through lists of libraries that are available can help you brainstorm what types of programs you can create. Most programming involves assembling large parts, rather than writing everything from scratch.
You are not logged in. Log in here and track your progress.
|About||Buy the Book||Help Translate||My College||My Twitter||Updates|
English version by Paul Vincent Craven
Russian version by Vladimir Slav
Turkish version by Güray Yildirim
Dutch version by Frank Waegeman
Hungarian version by Nagy Attila
Portuguese version by Armando Marques Sobrinho and Tati Carvalho
Spanish version by Aitor Peinador and Antonio Rodríguez