Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions

  




 

 

Module Exercises

Refactor a Script

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.

Install a New Module

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.

  1. Move the module file to the site-packages directory. Be sure that it is removed (or renamed) in your local directory.

  2. Move the module file to another directory and create a hard link (using the Linux ln or equivalent Windows utility) from site-packages to the other directory you created.

  3. Remove the hard link and put a .PTH file in the site-packages directory.

  4. Remove the .PTH file and update the PYTHONPATH environment variable to reference the new directory.

Planning for Maintenance and Upgrades

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.

  • You have to provide modules and an application on a number of desktop PC's. Python must be installed on each individual desktop. However, the application that uses Python could be put on a shared network drive. What are the pros and cons of installing a Python-based application locally versus on a network drive?

    • How would you handle the initial setup?

    • How would you handle an upgrade to Python itself? For example, how would you install Python 2.5 so as to preserve your modules and application?

    • How would you control an upgrade to a Python-based application? For example, you have a new module file that needs to be made available to all users.

  • You have to provide modules and an application on a server, shared by a number of users. Python is installed on the server, as is the Python-based application. What security considerations should be put into place?

    • How would you handle initial installation of Python and your server-based application?

    • How would you handle an upgrade to Python on this shared server?

    • How would you control an upgrade to the Python-based application on this shared server?


 
 
  Published under the terms of the Open Publication License Design by Interspire