A very common situation is to take a script file apart and create a formal module of the definitions and a separate module of the script. If you refer back to your previous exercise scripts, you'll see that many of your files have definitions followed by a "main" script which demonstrates that your definitions actually work. When refactoring these, you'll need to separate the definitions from the test script.

Let's assume you have the following kind of script as the result of a previous exercise.

# Some Part 3 Exercise.
class X( object ):
 
does something

class Y( X ):
 
does something a little different

 
x1= X()
x1.someMethod()
y2= Y()
y2.someOtherMethod()

You'll need to create two files from this. The module will be the simplest to prepare, assume the file name is myModule.py

#!/usr/bin/env python
class X( object ):
 
does something

class Y( X ):
 
does something a little different

Your new new demonstation application will look like this because you will have to qualify the class and function names that are created by the module.

#!/usr/bin/env python
import myModule
x1= myModule.X()
x1.someMethod()
y2= myModule.Y()
y2.someOtherMethod()

Your original test script had an implicit assumption that the definitions and the test script were all in the same namespace. This will no longer be true. While you can finesse this by using from myNewModule import *, this is not the best programming style. It is better to rewrite the test script to explicitly qualify names with the module name.

There are a number of related class definitions in previous exercises that can be used to create modules.

Create a simple module file with some definitions. Preferrably, this is a solution to the section called "Refactor a Script". Install the definitional part into the PYTHONPATH. Be sure to rename or remove the local version of this file. Be sure to use each installation method.

There are a number of module installation scenarios; each of these will require a different technique. Compare and contrast these techniques from several points of view: cost to deploy, security of the deployment, ease of debugging, and control over what the user experiences.