3.3 Clicking Windows File Icons

On Windows, 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 Windows, icon clicks are made easy by the Windows registry. 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 of 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.

3.3.1 Clicking Icons on Windows

To illustrate, suppose we create the following program file with our text editor, and save it as filename 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 we must import to load). In fact, we can run this file from a system command line:

D:\OldVaio\LP-2ndEd\Examples>c:\python22\python script4.py
win32
1267650600228229401496703205376

Icon clicks allow us to run this file without any typing at all. If we find this file's icon—for instance, by selecting My Computer, and working our way down on the D drive—we will get the file explorer picture captured in Figure 3-1 and shown on Windows XP. Python source files show up as snakes on Windows, and byte code files as snakes with eyes closed (or with a reddish color in Version 2.3). 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. Python file icons on Windows

3.3.2 The raw_input Trick

Unfortunately, on Windows, the result of clicking on file icons may not be incredibly satisfying. In fact, as 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 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 launched with clicks, simply put a call to the built-in raw_input function at the very bottom of your 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, and waits 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 we press the Enter key.

Figure 3-2. Clicked program output with raw_input

Now that we'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 this script by clicking its file icon. You should only 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.^[2]

^[2] It is also possible to completely suppress the pop-up DOS console window for clicked files on Windows. Files whose names end in a .pyw extension will display only windows constructed by your script, not the default DOS console window. .pyw files are simply .py source files that have this special operational behavior on Windows. They are mostly used for Python-coded user interfaces that build windows of their own, and often in conjunction with various techniques for saving printed output and errors to files.

Before moving 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 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; see Chapter 10 for an example of using it in an interactive loop.

3.3.3 Other Icon Click Limitations

Even with the raw_input trick, clicking file icons is not without its perils. You also may not get to see Python error messages. If your script generates an error, the error message text is written to the pop-up console window—which then immediately disappears as before. Worse, adding a raw_input call to your file will not help this time, because your script will likely abort long before it reaches this call. In other words, you won't be able to tell what went wrong.

Because of these limitations, it is probably best to view icon clicks as a way to launch programs after they have been debugged. Especially when starting out, use other techniques, such as system command lines and IDLE (later in this chapter), so that you can see generated error messages, and view your normal output without resorting to coding tricks. When we meet exceptions later in this book, we'll also learn that it is possible to intercept and recover from errors, so that they do not terminate our programs. Watch for the discussion of the try statement later in this book for an alternative way to keep the console window from closing on errors.