Perhaps the simplest way to run Python programs is to type them at Python’s interactive command line. There are a variety of ways to start this command line—in an IDE, from a system console, and so on. Assuming the interpreter is installed as an executable program on your system, the most platform-neutral way to start an interactive interpreter session is usually just to type python at your operating system’s prompt, without any arguments. For example:

% python
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>>

Typing the word “python” at your system shell prompt begins an interactive Python session (the “%” character stands for your system’s prompt, not input that you type yourself). The notion of a system shell prompt is generic, but exactly how you access the prompt varies by platform:

If you have not set your shell’s PATH environment variable to include Python’s install directory, you may need to replace the word “python” with the full path to the Python executable on your machine. On Windows, try typing C:Python25python (for version 2.5); on Unix and Linux, /usr/local/bin/python (or /usr/bin/python) will often suffice. Alternatively, you can run a change-directory command to go to Python’s install directory before typing “python” (try a cd c:python25 command on Windows, for instance).

The Python interactive session begins by printing two lines of informational text (which I’ll omit from this book’s examples to save space), then prompts for input with >>> when it’s waiting for you to type a new Python statement or expression. When working interactively, the results of your code are displayed after the >>> lines. Here are the results of two Python print statements:

% python
>>> print 'Hello world!'
Hello world!
>>> print 2 ** 8
256

Again, you don’t need to worry about the details of the print statements shown here yet (we’ll start digging into syntax in the next chapter). In short, they print a Python string and an integer, as shown by the output lines that appear after each >>> input line.

When working interactively like this, you can type as many Python commands as you like; each is run immediately after it’s entered. Moreover, because the interactive session automatically prints the results of expressions you type, you don’t usually need to say “print” explicitly at this prompt:

>>> lumberjack = 'okay'
>>> lumberjack
'okay'
>>> 2 ** 8
256
>>>                      # Use Ctrl-D or Ctrl-Z to exit
%

Here, the last two lines typed are expressions (lumberjack and 2 ** 8), and their results are displayed automatically. To exit an interactive session like this one and return to your system shell prompt, type Ctrl-D on Unix-like machines; on MS-DOS and Windows systems, type Ctrl-Z to exit. In the IDLE GUI discussed later, either type Ctrl-D or simply close the window.

Now, we didn’t do much in this session’s code—just typed some Python print and assignment statements, and a few expressions, which we’ll study in detail later. The main thing to notice is that the interpreter executes the code entered on each line immediately, when the Enter key is pressed.

For instance, when we typed the first print statement at the >>> prompt, the output (a Python string) was echoed back right away. There was no need to create a source-code file, and no need to run the code through a compiler and linker first, as you’d normally do when using a language such as C or C++. As you’ll see in later chapters, you can also run multiline statements at the interactive prompt; such a statement runs immediately after you’ve entered all of its lines.

Besides typing python in a shell window, you can also begin similar interactive sessions by starting IDLE’s main window or, on Windows, by selecting the “Python (command-line)” menu option from the Start button menu for Python, as shown in Figure 2-1. Both spawn a >>> prompt with equivalent functionality—code is run as it is typed.

Although the interactive prompt is great for experimenting and testing, it has one big disadvantage: programs you type there go away as soon as the Python interpreter executes them. The code you type interactively is never stored in a file, so you can’t run it again without retyping it from scratch. Cut-and-paste and command recall can help some here, but not much, especially when you start writing larger programs. To cut and paste code from an interactive session, you have to edit out Python prompts, program outputs, and so on.

To save programs permanently, you need to write your code in files, which are usually known as modules. Modules are simply text files containing Python statements. Once coded, you can ask the Python interpreter to execute the statements in such a file any number of times, and in a variety of ways—by system command lines, by file icon clicks, by options in the IDLE user interface, and more. Regardless of how it is run, Python executes all the code in a module file from top to bottom each time you run the file.

Terminology in this domain can vary somewhat. For instance, module files are often referred to as programs in Python—that is, a program is considered to be a series of precoded statements stored in a file for repeated execution. Module files that are run directly are also sometimes called scripts—an informal term meaning a top-level program file. Some reserve the term “module” for a file imported from another file. (More on the meaning of “top-level” and imports in a few moments.)

Whatever you call them, the next few sections explore ways to run code typed into module files. In this section, you’ll learn how to run files in the most basic way: by listing their names in a python command line entered at a system prompt. As a first example, start your favorite text editor (e.g., vi, Notepad, or the IDLE editor), and type two Python statements into a text file named spam.py:

print 2 ** 8                              # Raise to a power
print 'the bright side ' + 'of life'      # + means concatenation

This file contains two Python print statements, and some Python comments to the right. (Text after a # is simply ignored as a human-readable comment, and is not considered part of the statement’s syntax.) Again, ignore the syntax of the code in this file for now. The point to notice is that you’ve typed the code into a file, rather than at the interactive prompt. In the process, you’ve coded a fully functional Python script.

Once you’ve saved this text file, you can ask Python to run it by listing its full filename as the first argument to a python command, typed at the system shell prompt:

% python spam.py
256
the bright side of life

Here again, you will type such a system shell command in whatever your system provides for command-line entry—a Windows Command Prompt window, an xterm window, or similar. Remember to replace “python” with a full directory path if your PATH setting is not configured. The output of this little script shows up after the command is typed—it’s the result of the two print statements in the text file.

Notice that the module file is called spam.py. As for all top-level files, it could also be called simply spam, but files of code you want to import into a client have to end with a .py suffix. We’ll study imports later in this chapter.

Because you may want to import a file in the future, it’s a good idea to use .py suffixes for most Python files that you code. Also, some text editors detect Python files by their .py suffix; if the suffix is not present, you may not get features like syntax colorization and automatic indentation.

Because this scheme uses shell command lines to start Python programs, all the usual shell syntax applies. For instance, you can route the output of a Python script to a file to save it for later use or inspection by using special shell syntax:

% python spam.py > saveit.txt

In this case, the two output lines shown in the prior run are stored in the file saveit.txt instead of being printed. This is generally known as stream redirection; it works for input and output text, and it works on Windows and Unix-like systems. It also has little to do with Python (Python simply supports it), so we will skip further details on redirection here.

If you are working on a Windows platform, this example works the same, but the system prompt is normally different:

C:Python25> python spam.py
256
the bright side of life

As usual, be sure to type the full path to Python if you haven’t set your PATH environment variable, and haven’t run a change-directory command:

D:	emp> C:python25python spam.py
256
the bright side of life

On newer versions of Windows, you can also type just the name of your script, regardless of the directory in which you’re working. Because newer Windows systems use the Windows Registry to find a program with which to run a file, you don’t need to list it on the command line explicitly. The prior command, for example, could be simplified to this on a recent version of Windows:

D:	emp> spam.py

Finally, remember to give the full path to your script file if it lives in a different directory from the one in which you are working. For example, the following system command line, run from D:other, assumes Python is in your system path but runs a file located elsewhere:

D:other> python c:codemyscript.py

#!/usr/local/bin/python
print 'The Bright Side of Life...'         # Another comment here

% brian
The Bright Side of Life...

C:ook	ests> python brian
The Bright Side of Life...

#!/usr/bin/env python
...script goes here...

On Windows, the Registry makes opening files with icon clicks easy. Python automatically registers itself to be the program that opens Python program files when they are clicked. Because of that, it is possible to launch the Python programs you write by simply clicking (or double-clicking) on their file icons with your mouse.

On non-Windows systems, you will probably be able to perform a similar trick, but the icons, file explorer, navigation schemes, and more may differ slightly. On some Unix systems, for instance, you may need to register the .py extension with your file explorer GUI, make your script executable using the #! trick discussed in the prior section, or associate the file MIME type with an application or command by editing files, installing programs, or using other tools. See your file explorer’s documentation for more details if clicks do not work correctly right off the bat.

Clicking Icons on Windows

To illustrate, suppose you create the following program file with your text editor and save it as script4.py:

# A comment
import sys
print sys.platform
print 2 ** 100

There’s not much new here—just an import and two prints again (sys.platform is just a string that identifies the kind of computer you’re working on; it lives in a module called sys, which you must import to load). You can run this file from a system command line:

D:LP3EExamples> c:python25python script4.py
win32
1267650600228229401496703205376

However, icon clicks allow you to run the file without any typing at all. If you find this file’s icon—for instance, by selecting My Computer and working your way down on the D drive—you will get the file explorer picture captured in Figure 3-1 (Windows XP is being used here). In Python 2.5, source files show up with white backgrounds on Windows, and byte code files show up with black backgrounds. You will normally want to click (or otherwise run) the source code file, in order to pick up your most recent changes. To launch the file here, simply click on the icon for script4.py.

Figure 3-1. On Windows, Python program files show up as icons in file explorer windows, and can automatically be run with a double-click of the mouse (though you might not see printed output or error messages this way).

The raw_input Trick

Unfortunately, on Windows, the result of clicking on a file icon may not be incredibly satisfying. In fact, as it is, this example script generates a perplexing “flash” when clicked—not the sort of feedback that budding Python programmers usually hope for! This is not a bug, but it has to do with the way the Windows port handles printed output.

By default, Python generates a pop-up black DOS console window to serve as a clicked file’s input and output. If a script prints and exits, then, well, it just prints and exits—the console window appears, and text is printed there, but the console window closes and disappears on program exit. Unless you are very fast, or your machine is very slow, you won’t get to see your output at all. Although this is normal behavior, it’s probably not what you had in mind.

Luckily, it’s easy to work around this. If you need your script’s output to stick around when you launch it with an icon click, simply put a call to the built-in raw_input function at the very bottom of the script. For example:

# A comment
import sys
print sys.platform
print 2 ** 100
raw_input(  )             # ADDED

In general, raw_input reads the next line of standard input, waiting if there is none yet available. The net effect in this context will be to pause the script, thereby keeping the output window shown in Figure 3-2 open until you press the Enter key.

Figure 3-2. When you click a program’s icon on Windows, you will be able to see its printed output if you add a raw_input() call to the very end of the script. But you only need to do so in this context!

Now that I’ve shown you this trick, keep in mind that it is usually only required for Windows, and then only if your script prints text and exits, and only if you will launch the script by clicking its file icon. You should add this call to the bottom of your top-level files if and only if all of these three conditions apply. There is no reason to add this call in any other contexts.^[6]

Before we move ahead, note that the raw_input call applied here is the input counterpart of using the print statement for outputs. It is the simplest way to read user input, and it is more general than this example implies. For instance, raw_input:

• Optionally accepts a string that will be printed as a prompt (e.g., raw_input('Press Enter to exit'))

• Returns to your script the line of text read as a string (e.g., nextinput = raw_input( ))

• Supports input stream redirections at the system shell level (e.g., python spam.py < input.txt), just as the print statement does for output

We’ll use raw_input in more advanced ways later in this text; for instance, Chapter 10 will apply it in an interactive loop.

So far, I’ve been talking about “importing modules” without really explaining what this term means. We’ll study modules and larger program architecture in depth in Part V, but because imports are also a way to launch programs, this section will introduce enough module basics to get you started.

In simple terms, every file of Python source code whose name ends in a .py extension is a module. Other files can access the items a module defines by importing that module; import operations essentially load another file, and grant access to that file’s contents. The contents of a module are made available to the outside world through its attributes (a term I’ll define in the next section).

This module-based services model turns out to be the core idea behind program architecture in Python. Larger programs usually take the form of multiple module files, which import tools from other module files. One of the modules is designated as the main or top-level file, and is the one launched to start the entire program.

We’ll delve into such architectural issues in more detail later in this book. This chapter is mostly interested in the fact that import operations run the code in a file that is being loaded as a final step. Because of this, importing a file is yet another way to launch it.

For instance, if you start an interactive session (in IDLE, from a command line, or otherwise), you can run the script4.py file you created earlier with a simple import:

D:LP3EExamples> c:python25python
>>> import script4
win32
1267650600228229401496703205376

This works, but only once per session (really, process), by default. After the first import, later imports do nothing, even if you change and save the module’s source file again in another window:

>>> import script4
>>> import script4

This is by design; imports are too expensive an operation to repeat more than once per program run. As you’ll learn in Chapter 18, imports must find files, compile to byte code, and run the code.

If you really want to force Python to run the file again in the same session (without stopping and restarting the session), you need to instead call the built-in reload function:

>>> reload(script4)
win32
65536
<module 'script4' from 'script4.py'>
>>>

The reload function loads and runs the current version of your file’s code if you’ve changed it in another window. This allows you to edit and pick up new code on the fly within the current Python interactive session. In this session, for example, the second print statement in script4.py was changed in another window to print 2 ** 16 between the time of the first import and the reload call.

The reload function expects the name of an already loaded module object, so you have to have successfully imported a module once before you reload it. Notice that reload also expects parentheses around the module object name, whereas import does not. reload is a function that is called, and import is a statement. That’s why you must pass the module name to reload as an argument in parentheses, and that’s why you get back an extra output line when reloading. The last output line is just print’s representation of the reload call’s return value, a Python module object.

Functions will be discussed further in Chapter 15.

title = "The Meaning of Life"

% python# Start Python
>>> import myfile# Run file; load module as a whole
>>> print myfile.title# Use its attribute names: '.' to qualify
The Meaning of Life

% python# Start Python
>>> from myfile import title# Run file; copy its names
>>> print title# Use name directly: no need to qualify
The Meaning of Life

a = 'dead'                       # Define three attributes
b = 'parrot'                    # Exported to other files
c = 'sketch'
print a, b, c                      # Also used in this file

% python threenames.py
dead parrot sketch

% python
>>> import threenames# Grab the whole module
dead parrot sketch
>>>
>>> threenames.b, threenames.c
('parrot', 'sketch')
>>>
>>> from threenames import a, b, c# Copy multiple names
>>> b, c
('parrot', 'sketch')

>>> dir(threenames)
['_ _builtins_ _', '_ _doc_ _', '_ _file_ _', '_ _name_ _', 'a', 'b', 'c']

So far, we’ve seen how to run Python code with the interactive prompt, system command lines, icon clicks, and module imports. If you’re looking for something a bit more visual, IDLE provides a graphical user interface (GUI) for doing Python development, and it’s a standard and free part of the Python system. It is usually referred to as an integrated development environment (IDE), because it binds together various development tasks into a single view.^[8]

In short, IDLE is a GUI that lets you edit, run, browse, and debug Python programs, all from a single interface. Moreover, because IDLE is a Python program that uses the Tkinter GUI toolkit, it runs portably on most Python platforms, including Microsoft Windows, X Windows (for Linux, Unix, and Unix-like platforms), and the Mac OS (both Classic and OS X). For many, IDLE represents an easy-to-use alternative to typing command lines, and a less problem-prone alternative to clicking on icons.

IDLE Basics

Let’s jump right into an example. IDLE is easy to start under Windows—it has an entry in the Start button menu for Python (see Figure 2-1), and it can also be selected by right-clicking on a Python program icon. On some Unix-like systems, you may need to launch IDLE’s top-level script from a command line, or, alternatively, by clicking on the icon for the idle.pyw or idle.py file located in the idlelib subdirectory of Python’s Lib directory. (On Windows, IDLE is a Python script that currently lives in C:Python25Libidlelib.^[9])

Figure 3-3 shows the scene after starting IDLE on Windows. The Python shell window that opens initially is the main window, which runs an interactive session (notice the >>> prompt). This works like all interactive sessions—code you type here is run immediately after you type it—and serves as a testing tool.

Figure 3-3. The main Python shell window of the IDLE development GUI, shown here running on Windows. Use the File menu to begin (New Window), or change (Open ... ) a source file; use the file edit window’s Run menu to run the code in that window (Run Module).

IDLE uses familiar menus with keyboard shortcuts for most of its operations. To make (or edit) a source code file under IDLE, open a text edit window: in the main window, select the File pull-down menu, and pick New Window to open a text edit window (or Open . . . to edit an existing file). A new window will appear. This is an IDLE text edit window, where the code for the file you are creating or changing is entered and displayed.

Although it may not show up fully in this book, IDLE uses syntax-directed colorization for the code typed in both the main window and all text edit windows—keywords are one color, literals are another, and so on. This helps give you a better picture of the components in your code.

To run a file of code that you are editing in IDLE, select the file’s text edit window, pick that window’s Run pull-down menu, and choose the Run Module option listed there (or use the equivalent keyboard shortcut, given in the menu). Python will let you know that you need to save your file first if you’ve changed it since it was opened or last saved.

When run this way, the output of your script and any error messages it may generate show up back in the main interactive window (the Python shell window). In Figure 3-3, for example, the last three lines in the window reflect an execution of a script opened in a separate edit window; the “RESTART” message tells us that the user-code process was restarted to run the edited script, and serves to separate script output.

Tip

Hint of the day: if you want to repeat prior commands in IDLE’s main interactive window, you can use the Alt-P key combination to scroll backward through the command history, and Alt-N to scroll forward (on some Macs, try Ctrl-P and Ctrl-N instead). Your prior commands will be recalled and displayed, and may be edited and rerun. You can also recall commands by positioning the cursor on them, or use cut-and-paste operations, but these tend to be more work. Outside IDLE, you may be able to recall commands in an interactive session with the arrow keys on Windows.

Because IDLE is free, portable, and a standard part of Python, it’s a nice first development tool to become familiar with if you want to use an IDE at all. Again, I recommend that you use IDLE for this book’s exercises if you’re just starting out, unless you are already familiar with a command-line-based development mode. There are, however, a handful of alternative IDEs for Python developers, some of which are substantially more powerful and robust than IDLE. Here are some of the most commonly used IDEs:

At this point, we’ve seen how to run code typed interactively, and how to launch code saved in files with system command lines, Unix executable scripts, icon clicks, module imports, and IDEs like IDLE. That covers most of the cases you’ll see in this book.

But, in some specialized domains, Python code may also be run by an enclosing system. In such cases, we say that the Python programs are embedded in (i.e., run by) another program. The Python code itself may be entered into a text file, stored in a database, fetched from an HTML page, parsed from an XML document, and so on. But from an operational perspective, another system—not you—may tell Python to run the code you’ve created. Such an embedded execution mode is commonly used to support end user customization—a game program, for instance, might allow for play modifications by running user-accessible embedded Python code at strategic points in time.

As an example, it’s possible to create and run strings of Python code from a C program by calling functions in the Python runtime API (a set of services exported by the libraries created when Python is compiled on your machine):

#include <Python.h>
...
Py_Initialize(  );
PyRun_SimpleString("x = brave + sir + robin");

In this C code snippet, a program coded in the C language embeds the Python interpreter by linking in its libraries, and passes it a Python assignment statement string to run. C programs may also gain access to Python objects and process or execute them using other Python API tools.

This book isn’t about Python/C integration, but you should be aware that, depending on how your organization plans to use Python, you may or may not be the one who actually starts the Python programs you create.^[10] Regardless, you can still likely use the interactive and file-based launching techniques described here to test code in isolation from those enclosing systems that may eventually use it.

Frozen binary executables, described in the preceding chapter, are packages that combine your program’s byte code and the Python interpreter into a single executable program. With these, Python programs can be launched in the same ways that you would launch any other executable program (icon clicks, command lines, etc.). While this option works well for delivery of products, it is not really intended for use during program development. You normally freeze just before shipping (after development is finished). See the prior chapter for more on this option.

As mentioned previously, although not full-blown IDE GUIs, most programmer-friendly text editors have support for editing, and possibly running, Python programs. Such support may be built in or fetchable on the Web. For instance, if you are familiar with the Emacs text editor, you can do all your Python editing and launching from inside the text editor itself. See the text editor resources page at http://www.python.org/editors for more details, or search the Web for the phrase “Python editors.”

Depending on your platform, there may be additional ways that you can start Python programs. For instance, on some Macintosh systems, you may be able to drag Python program file icons onto the Python interpreter icon to make them execute. And on Windows, you can always start Python scripts with the Run ... option in the Start menu. Finally, the Python standard library has utilities that allow Python programs to be started by other Python programs (e.g., execfile, os.popen, os.system); however, these tools are beyond the scope of the present chapter.

Although this chapter reflects current practice, much of it has been both platform- and time-specific. Indeed, many of the execution and launch details presented arose during the shelf life of this book’s editions. As with program execution options, it’s not impossible that new program launch options may arise over time.

New operating systems, and new versions of existing systems, may also provide execution techniques beyond those outlined here. In general, because Python keeps pace with such changes, you should be able to launch Python programs in whatever way makes sense for the machines you use, both now and in the future—be that by drawing on tablet PCs or PDAs, grabbing icons in a virtual reality, or shouting a script’s name over your coworkers’ conversations.

Implementation changes may also impact launch schemes somewhat (e.g., a full compiler could produce normal executables that are launched much like frozen binaries today). If I knew what the future truly held, though, I would probably be talking to a stockbroker instead of writing these words!

With all these options, one question naturally arises: which one is best for me? In general, you should use the IDLE interface for development if you are just getting started with Python. It provides a user-friendly GUI environment, and can hide some of the underlying configuration details. It also comes with a platform-neutral text editor for coding your scripts, and it’s a standard and free part of the Python system.

If, on the other hand, you are an experienced programmer, you might be more comfortable with simply the text editor of your choice in one window, and another window for launching the programs you edit via system command lines and icon clicks (indeed, this is how your author develops Python programs, but he has a Unix-biased past). Because development environments are a very subjective choice, I can’t offer much more in the way of universal guidelines; in general, whatever environment you like to use will usually be the best for you to use.

In this chapter, we’ve looked at common ways to launch Python programs: by running code typed interactively, and by running code stored in files with system command lines, file-icon clicks, module imports, and IDE GUIs such as IDLE. We’ve covered a lot of pragmatic startup territory here. This chapter’s goal was to equip you with enough information that you can start working along with the code we’ll start writing in the next part of the book. There, we will start exploring the Python language itself, beginning with its core data types.

First, though, take the usual chapter quiz to exercise what you’ve learned here. Because this is the last chapter in this part of the book, it’s followed with a set of more complete exercises that test your mastery of this entire part’s topics. For help with the latter set of problems, or just for a refresher, turn to Appendix B.