Learning Python (2013)
Part IX. Appendixes
Appendix A. Installation and Configuration
This appendix provides additional installation and configuration details as a resource for people new to these topics. It’s located here because not all readers will need to deal with these subjects up front. Because it covers some peripheral topics such as environment variables and command-line arguments, though, this material probably merits at least a quick scan for most readers.
Installing the Python Interpreter
Because you need the Python interpreter to run Python scripts, the first step in using Python is usually installing Python. Unless one is already available on your machine, you’ll need to fetch, install, and possibly configure a recent version of Python on your computer. You’ll only need to do this once per machine, and if you will be running a frozen binary (described in Chapter 2) or self-installing system, your setup tasks may be trivial or null.
Is Python Already Present?
Before you do anything else, check whether you already have a recent Python on your machine. If you are working on Linux, Mac OS X, or some Unix systems, Python is probably already installed on your computer, though it may be one or two releases behind the cutting edge. Here’s how to check:
§ On Windows 7 and earlier, check whether there is a Python entry in the Start button’s All Programs menu (at the bottom left of the screen). On Windows 8, look for Python in a Start screen tile, your Search tool, the “All apps” display on your Start screen, or a File Explorer in desktop mode (more on Windows 8 in an upcoming sidebar).
§ On Mac OS X, open a Terminal window (Applications→Utilities→Terminal) and type python at the prompt. Python, IDLE, and its tkinter GUI toolkit are standard components of this system.
§ On Linux and Unix, type python at a shell prompt (a.k.a. terminal window), and see what happens. Alternatively, try searching for “python” in the usual places—/usr/bin, /usr/local/bin, etc. As on Macs, Python is a standard part of Linux systems.
If you find a Python, make sure it’s a recent version. Although any recent Python will do for most of this text, this edition focuses on Python 3.3 and 2.7 specifically, so you may want to install one of these to run some of the examples in this book.
Speaking of versions, per the preface, I recommend starting out with Python 3.3 or later if you’re learning Python anew and don’t need to deal with existing 2.X code; otherwise, you should generally use Python 2.7. Some popular Python-based systems still use older releases, though (2.6 and even 2.5 are still widespread), so if you’re working with existing systems be sure to use a version relevant to your needs; the next section describes locations where you can fetch a variety of Python versions.
Where to Get Python
If there is no Python on your machine, you will need to install one yourself. The good news is that Python is an open source system that is freely available on the Web and very easy to install on most platforms.
You can always fetch the latest and greatest standard Python release from http://www.python.org, Python’s official website. Look for the Downloads link on that page, and choose a release for the platform on which you will be working. You’ll find prebuilt self-installer files for Windows (run to install), Installer Disk Images for Mac OS X (installed per Mac conventions), the full source code distribution (typically compiled on Linux, Unix, or OS X machines to generate an interpreter), and more.
Although Python is standard on Linux these days, you can also find RPMs for Linux on the Web (unpack them with rpm). Python’s website also has links to pages where versions for other platforms are maintained, either at Python.org (http://www.python.org) itself or offsite. For example, you can find third-party Python installers for Google’s Android, as well as apps to install Python on Apple’s iOS.
A Google web search is another great way to find Python installation packages. Among other platforms, you can find Python prebuilt for iPods, Palm handhelds, Nokia cell phones, PlayStation and PSP, Solaris, AS/400, and Windows Mobile, though some of these are typically a few releases behind the curve.
If you find yourself pining for a Unix environment on a Windows machine, you might also be interested in installing Cygwin and its version of Python (see http://www.cygwin.com). Cygwin is a GPL-licensed library and toolset that provides full Unix functionality on Windows machines, and it includes a prebuilt Python that makes use of all the Unix tools provided.
You can also find Python on CD-ROMs supplied with Linux distributions, included with some products and computer systems, and enclosed with some other Python books. These tend to lag behind the current release somewhat, but usually not seriously so.
In addition, you can find Python in some free and commercial development bundles. At this writing, this alternative distributions category includes:
A package that combines Python with extensions for scientific, Windows, and other development needs, including PyWin32 and the PythonWin IDE
Enthought Python Distribution
A combination of Python and a host of additional libraries and tools oriented toward scientific computing needs
A blend of Python and add-on packages configured to run directly from a portable device
A scientific-oriented Python distribution based on Qt and Spyder
Conceptive Python SDK
A bundle targeted at business, desktop, and database applications
A commercial distribution for numerical analysis
A distribution for analysis and visualization of large data sets
This set is prone to change, so search the Web for details on all of the above, and others. Some of these are free, some are not, and some have both free and nonfree versions. All combine the standard Python freely available at http://www.python.org with additional tools, but can simplify install tasks for many.
Finally, if you are interested in alternative Python implementations, run a web search to check out Jython (the Python port to the Java environment) and IronPython (Python for the C#/.NET world), both of which are described in Chapter 2. Installation of these systems is beyond the scope of this book.
Once you’ve downloaded Python, you need to install it. Installation steps are very platform-specific, but here are a few pointers for the major Python platforms (biased in volume toward Windows, only because that is the platform where most Python newcomers are likely to encounter the language first):
For Windows (including XP, Vista, 7, and 8), Python comes as a self-installer MSI program file—simply double-click on its file icon, and answer Yes or Next at every prompt to perform a default install. The default install includes Python’s documentation set and support for tkinter(Tkinter in Python 2.X) GUIs, shelve databases, and the IDLE development GUI. Python 3.3 and 2.7 are normally installed in the directories C:\Python33 and C:\Python27 though this can be changed at install time.
For convenience, on Windows 7 and earlier Python shows up after the install in the Start button’s All Programs menu (see ahead for Windows 8 notes). Python’s menu there has five entries that give quick access to common tasks: starting the IDLE user interface, reading module documentation, starting an interactive session, reading Python’s standard manuals, and uninstalling. Most of these options involve concepts explored in detail elsewhere in this text.
When installed on Windows, Python also automatically uses filename associations to register itself to be the program that opens Python files when their icons are clicked (a program launch technique described in Chapter 3). It is also possible to build Python from its source code on Windows, but this is not commonly done so we’ll skip the details here (see python.org).
Three additional install-related notes for Windows users: first, be sure to see the next appendix for an introduction to the new Windows launcher shipped with 3.3; it changes some of the rules for installation, file associations, and command lines, but can be an asset if you have multiple Python versions on your computer (e.g., both 2.X and 3.X). Per Appendix B, Python 3.3’s MSI installer also has an option to set your PATH variable to include Python’s directory.
Second, Windows 8 users should see the sidebar in this appendix Using Python on Windows 8. Standard Python installs and works the same on Windows 8, where it runs in desktop mode, but you won’t get the Start button menu described earlier, and the tablet interface on top is not yet directly supported.
Finally, some Windows Vista users may run into install issues related to security features. This seems to have been resolved over time (and Vista is relatively rare these days), but if running the MSI installer file directly doesn’t work as expected, it’s probably because MSI files are not true executables and do not correctly inherit administrator permissions (they run per the registry). To fix, run the installer from a command line with appropriate permissions: Select Command Prompt, choose “Run as administrator,” cd to the directory where your Python MSI file resides, and run the MSI installer with a command line of the form: msiexec /i python-2.5.1.msi.
For Linux, if Python or your desired flavor of it is not already present, you can probably obtain it as one or more RPM files, which you unpack in the usual way (consult the RPM manpage for details). Depending on which RPMs you download, there may be one for Python itself, and another that adds support for tkinter GUIs and the IDLE environment. Because Linux is a Unix-like system, the next paragraph applies as well.
For Unix systems, Python is usually compiled from its full C source code distribution. This usually only requires you to unpack the file and run simple config and make commands; Python configures its own build procedure automatically, according to the system on which it is being compiled. However, be sure to see the package’s README file for more details on this process. Because Python is open source, its source code may be used and distributed free of charge.
On other platforms the installation details can differ widely, but they generally follow the platform’s normal conventions. For example, installing the “Pippy” port of Python for PalmOS required a hotsync operation with your PDA, and Python for the Sharp Zaurus Linux-based PDA was one or more .ipk files, which you simply ran to install (these likely still work, though finding the devices today may be a logistical challenge!).
More recently, Python can be installed and used on Android and iOS platforms too, but installation and usage techniques are too platform-specific to cover here. For additional install procedures and the latest on available ports, try both Python’s website and a web search.
USING PYTHON ON WINDOWS 8
Windows 8 was released as this edition was being written. As mentioned in the preface, this book was developed on both Windows 7 and 8, but mostly under Windows 7 because the choice is irrelevant to almost everything in this book—both Python 2.X and 3.X presently work only in desktop mode on Windows 8, but install and run there the same as in Windows 7, Vista, XP, and others. Once you navigate past the tablet-like layer at the top, usage is almost entirely as before.
The only notable exception to this is Windows 8’s lack of a Start button menu in desktop mode. You don’t get the nice menu of Python options automatically, though you can simulate it manually. Although this story is prone to change (and you should take this sidebar as an early report), here are a few Windows 8 usage notes.
At this writing, the standard Python Windows MSI installer program installs Python on Windows 8 correctly, and exactly as in the past: you get the same filename associations for icon clicks, access from command lines, and so on. The installer also creates a Start screen button on Windows 8, but Python itself runs in Windows 8’s desktop mode, which is essentially the same as Windows 7 without a Start button menu. For example, the Windows 8 Start screen button created by the Python install simply switches control to desktop mode to open a Python interactive shell.
The upside to this is that all existing Python software works on Windows 8’s desktop just as before. One downside is that you’ll need to create shortcuts for the user-friendly Start button menu items created automatically on former Windows versions. This includes the former menu’s links to the IDLE GUI, PyDoc, Python’s command-line interface, and Python’s manuals set.
This isn’t a showstopper—you can emulate the former Start button menu’s items with either tiles on the Start screen or shortcuts on the desktop taskbar. To do so, you might look up these tools in a variety of ways:
§ By navigating to their corresponding filename in a File Explorer, opened by right-clicking the screen’s lower-left corner.
§ By searching for their name in the Search “charm,” opened by pulling down the screen’s top-right corner.
§ By finding their entry after right-clicking on the Start screen to open the All apps display, which is reminiscent of the former Start button menus.
§ By locating their tiles on your Start screen, if they have any.
For example, you can locate IDLE by navigating to the file idle.py in C:\Python33\Lib, by searching on “idle,” by finding IDLE in “All apps,” or by clicking a Start screen tile if one exists. You can find Python itself in the same ways (and probably others). This isn’t quite as nice as the original Start button menus out of the box, but it suffices.
Probably the bigger potential downside on Windows 8 is that while Python runs fine in desktop mode, it doesn’t yet have an official port to run as a Start screen style “app.” That is, standard Python does not yet run programs in the WinRT (formerly known as Metro) environment—the tile-based media consumption layer that appears first when you start Windows 8, and before you can click your way to the desktop. This may be a temporary state, though, as a number of options either already exist or are being actively explored.
On one front, it’s not impossible that Python’s installer may be enhanced for Windows 8’s nondesktop mode. There has already been work on porting Python to run as a Start screen “app,” though this may appear as a separate installer package due to differences in the underlying libraries (in short, WinRT runs programs in a classic “sandbox” model, with a restricted subset of the libraries available normally).
On other fronts, the C#/.NET-based IronPython system may offer additional Windows 8 “app” development options, and some of Python’s major GUI toolkits such as tkinter, wxPython, and PyQt could eventually provide portability to the Windows 8 “apps” environment as well. The Qt library underlying the latter of these seems to have already showed some progress in this department.
For now, existing Python software runs fine in Windows 8’s desktop mode unchanged. Developing or running Python code in the Start screen “apps” environment will likely require special handling and platform-specific APIs not unlike those required to run Python on other tablet- and phone-oriented platforms based on Google’s Android and Apple’s iOS (iPhone and iPad) operating systems.
Also note that much of this sidebar applies to Window 8, but not Windows RT. The latter does not run third-party desktop mode applications directly, and may need to await a sanctioned Python installer that supports the WinRT “app” API in general.
Then again, the Windows 8 story remains to be told. Be sure to watch for developments in both Windows and Python’s installer for it. For now, a simple tile click or Windows-key press to hop into desktop mode will allow most Python programmers on Windows to safely ignore the tablet-like interface on top—at least until “apps” trounce “programs” altogether.
 Lest that seem too sarcastic, I should note that Windows 8.1 may address some launch screen and Start button (if not menu) concerns per late-breaking rumors, and this edition’s new Windows 8 sidebar replaces one in prior editions that discussed a Windows Vista issue. Any similarities you might deduce from that are officially coincidental.
After you’ve installed Python, you may want to configure some system settings that impact the way Python runs your code. (If you are just getting started with the language, you can probably skip this section completely; there is usually no need to specify any system settings for basic programs.)
Generally speaking, parts of the Python interpreter’s behavior can be configured with environment variable settings and command-line options. In this section, we’ll take a brief look at both, but be sure to see other documentation sources for more details on the topics we introduce here.
Python Environment Variables
Environment variables—known to some as shell variables, or DOS variables—are system-wide settings that live outside Python and thus can be used to customize the interpreter’s behavior each time it is run on a given computer. Python recognizes a handful of environment variable settings, but only a few are used often enough to warrant explanation here. Table A-1 summarizes the main Python-related environment variable settings (you’ll find information on others in Python reference resources).
Table A-1. Important environment variables
PATH (or path)
System shell search path (for finding “python”)
Python module search path (for imports)
Path to Python interactive startup file
GUI extension variables (tkinter)
PY_PYTHON, PY_PYTHON3, PY_PYTHON2
Windows launcher defaults (see Appendix B)
These variables are straightforward to use, but here are a few pointers:
The PATH setting lists a set of directories that the operating system searches for executable programs, when they are invoked without a full directory path. It should normally include the directory where your Python interpreter lives (the python program on Unix, or the python.exe file on Windows).
You don’t need to set this variable at all if you are willing to work in the directory where Python resides, or type the full path to Python in command lines. On Windows, for instance, the PATH is irrelevant if you run a cd C:\Python33 before running any code (to change to the directory where Python lives—though you shouldn’t generally store your own code in this directory per Chapter 3), or always type C:\Python33\python instead of just python (giving a full path).
Also note that PATH settings are mostly for launching programs from command lines; they are usually irrelevant when launching via icon clicks and IDEs—the former uses filename associations, and the latter uses built-in mechanisms, and doesn’t generally require this configuration step. See also Appendix B for details on 3.3’s automatic PATH setting option at install time.
The PYTHONPATH setting serves a role similar to PATH: the Python interpreter consults the PYTHONPATH variable to locate module files when you import them in a program. If used, this variable is set to a platform-dependent list of directory names, separated by colons on Unix and semicolons on Windows. This list normally includes just your own source code directories. Its content is merged into the sys.path module import search path, along with the script’s container directory, any .pth path file settings, and standard library directories.
You don’t need to set this variable unless you will be performing cross-directory imports—because Python always searches the home directory of the program’s top-level file automatically, this setting is required only if a module needs to import another module that lives in a different directory. See also the discussion of .pth path files later in this appendix for an alternative to PYTHONPATH. For more on the module search path, refer to Chapter 22.
If PYTHONSTARTUP is set to the pathname of a file of Python code, Python executes the file’s code automatically whenever you start the interactive interpreter, as though you had typed it at the interactive command line. This is a rarely used but handy way to make sure you always load certain utilities when working interactively; it saves an import each time you start a Python session.
If you wish to use the tkinter GUI toolkit (named Tkinter in 2.X), you might have to set the two GUI variables in the last line of Table A-1 to the names of the source library directories of the Tcl and Tk systems (much like PYTHONPATH). However, these settings are not required on Windows systems (where tkinter support is installed alongside Python), and are usually not required on Mac OS X and Linux systems, unless the underlying Tcl and Tk libraries are either invalid or reside in nonstandard directories (see python.org’s Download page for more details).
PY_PYTHON, PY_PYTHON3, PY_PYTHON2
These settings are used to specify default Pythons when you are using the new (at this writing) Windows launcher that ships with Python 3.3 and is available separately for other versions. Since we’ll be exploring the launcher in Appendix B, I’ll postpone further details here.
Note that because these environment settings are external to Python itself, when you set them is usually irrelevant: this can be done before or after Python is installed, as long as they are set the way you require before Python is actually run—be sure to restart your Python IDEs and interactive sessions after making such changes if you want them to apply.
TKINTER AND IDLE GUIS ON LINUX AND MACS
The IDLE interface described in Chapter 3 is a Python tkinter GUI program. The tkinter module (named Tkinter in 2.X) is a GUI toolkit that is automatically installed with standard Python on Windows, and is an inherent part of Mac OS X and most Linux installations.
On some Linux systems, though, the underlying GUI library may not be a standard installed component. To add GUI support to your Python on Linux if needed, try running a command line of the form yum tkinter to automatically install tkinter’s underlying libraries. This should work on Linux distributions (and some other systems) on which the yum installation program is available; for others, see your platform’s installation documentation.
As also discussed in Chapter 3, on Mac OS X IDLE probably lives in the MacPython (or Python N.M) folder of your Applications folder (along with PythonLauncher, used for starting programs with clicks in Finder), but be sure to see the Download page at python.org if IDLE has problems; you may need to install an update on some OS X versions (see Chapter 3).
How to Set Configuration Options
The way to set Python-related environment variables, and what to set them to, depends on the type of computer you’re working on. And again, remember that you won’t necessarily have to set these at all right away; especially if you’re working in IDLE (described in Chapter 3) and save all your files in the same directory, configuration is probably not required up front.
But suppose, for illustration, that you have generally useful module files in directories called utilities and package1 somewhere on your machine, and you want to be able to import these modules from files located in other directories. That is, to load a file called spam.py in either the utilitiesor package1 directories, you want to be able to say this in another file in another directory:
To make this work, you’ll have to configure your module search path one way or another to include the directory containing spam.py. Here are a few tips on this process using PYTHONPATH as an example; do the same for other settings like PATH as needed (though 3.3 can set PATHautomatically: see Appendix B).
Unix/Linux shell variables
On Unix systems, the way to set environment variables depends on the shell you use. Under the csh shell, you might add a line like the following in your .cshrc or .login file to set the Python module search path:
setenv PYTHONPATH /usr/home/pycode/utilities:/usr/lib/pycode/package1
This tells Python to look for imported modules in two user-defined directories. Alternatively, if you’re using the ksh shell, the setting might instead appear in your .kshrc file and look like this:
Other shells may use different (but analogous) syntax.
DOS variables (and older Windows)
If you are using MS-DOS or some now fairly old flavors of Windows, you may need to add an environment variable configuration command to your C:\autoexec.bat file, and reboot your machine for the changes to take effect. The configuration command on such machines has a syntax unique to DOS:
You can type such a command in a DOS console window, too, but the setting will then be active only for that one console window. Changing your .bat file makes the change permanent and global to all programs, though this technique has been superseded in recent years by that described in the next section.
Windows environment variable GUI
On all recent versions of Windows (including XP, Vista, 7, and 8), you can instead set PYTHONPATH and other variables via the system environment variable GUI without having to edit files, type command lines, or reboot. Select the Control Panel (in your Start button in Windows 7 and earlier, and in the desktop mode’s Settings “charm” on Windows 8), choose the System icon, pick the Advanced settings tab or link, and click the Environment Variables button at the bottom to edit or add new variables (PYTHONPATH is usually a new user variable). Use the same variable name and values syntax shown in the DOS set command in the preceding section. On Vista you may have to verify operations along the way.
You do not need to reboot your machine after this, but be sure to restart Python if it’s open so that it picks up your changes—it configures its import search path at startup time only. If you’re working in a Windows Command Prompt window, you’ll probably need to restart that to pick up your changes as well.
If you are an experienced Windows user, you may also be able to configure the module search path by using the Windows Registry Editor. To open this tool, type regedit in the Start→Run... interface on some Windows, in the search field at the bottom of the Start button display on Windows 7, and in a Command Prompt window on Windows 8 and others (among other routes). Assuming the typical registry tool is available on your machine, you can then navigate to Python’s entries and make your changes. This is a delicate and error-prone procedure, though, so unless you’re familiar with the registry, I suggest using other options (indeed, this is akin to performing brain surgery on your computer, so be careful!).
Finally, if you choose to extend the module search path with a .pth path file instead of the PYTHONPATH variable, you might instead code a text file that looks like the following on Windows (e.g., file C:\Python33\mypath.pth):
Its contents will differ per platform, and its container directory may differ per both platform and Python release. Python locates this file automatically when it starts up.
Directory names in path files may be absolute, or relative to the directory containing the path file; multiple .pth files can be used (all their directories are added), and .pth files may appear in various automatically checked directories that are platform- and version-specific. In general, a Python release numbered Python N.M typically looks for path files in C:\PythonNM and C:\PythonNM\Lib\site-packages on Windows, and in /usr/local/lib/pythonN.M/site-packages and /usr/local/lib/site-python on Unix and Linux. See Chapter 22 for more on using path files to configure thesys.path import search path.
Because environment settings are often optional, and because this isn’t a book on operating system shells, I’ll defer to other sources for further details. Consult your system shell’s manpages or other documentation for more information, and if you have trouble figuring out what your settings should be, ask your system administrator or another local expert for help.
Python Command-Line Arguments
When you start Python from a system command line (a.k.a. a shell prompt, or Command Prompt window), you can pass in a variety of option flags to control how Python runs your code. Unlike the system-wide environment variables of the prior section, command-line arguments can be different each time you run a script. The complete form of a Python command-line invocation in 3.3 looks like this (2.7 is roughly the same, with a few differences described ahead):
python [-bBdEhiOqsSuvVWxX] [-c command | -m module-name | script | - ] [args]
The rest of this section briefly demonstrates some of Python’s most commonly used arguments. For more details on available command-line options not covered here, see the Python manuals or reference texts. Or better yet, ask Python itself—run a command line form like this:
C:\code> python -h
to request Python’s help display, which documents all available command-line options. If you deal with complex command lines, be sure to also check out the standard library modules in this domain: the original getop, the newer argparse, and the now-deprecated (since 3.2) optparse, which support more sophisticated command-line processing. Also see Python’s library manuals and other references for more on the pdb and profile modules the following tour deploys.
Running script files with arguments
Most command lines make use of only the script and args parts of the last section’s Python command-line format, to run a program’s source file with arguments to be used by the program itself. To illustrate, consider the following script—a text file named showargs.py, created in directory C:\code or another of your choosing—which prints the command-line arguments made available to the script as sys.argv, a Python list of Python strings (if you don’t yet know how to create or run Python script files, see the full coverage in Chapter 2 and Chapter 3; we’re interested only in command-line arguments here):
# File showargs.py
In the following command line, both python and showargs.py can also be complete directory paths—the former is assumed to be on your PATH here, and the latter is assumed to be in the current directory. The three arguments (a b –c) meant for the script show up in the sys.argv list and can be inspected by your script’s code there; the first item in sys.argv is always the script file’s name, when it is known:
C:\code> python showargs.py a b -c # Most common: run a script file
['showargs.py', 'a', 'b', '-c']
As covered elsewhere in this book, Python lists print in square brackets and strings display in quotes.
Running code given in arguments and standard input
Other code format specification options allow you to give Python code to be run on the command line itself (-c), and accept code to run from the standard input stream (a – means read from a pipe or redirected input stream file, terms also defined in full elsewhere in this text):
C:\code> python -c "print(2 ** 100)" # Read code from command argument
C:\code> python -c "import showargs" # Import a file to run its code
C:\code> python - < showargs.py a b -c # Read code from standard input
['-', 'a', 'b', '-c']
C:\code> python - a b -c < showargs.py # Same effect as prior line
['-', 'a', 'b', '-c']
Running modules on the search path
The –m code specification locates a module on Python’s module search path and then runs it as a top-level script (as module __main__). That is, it looks up a script the same way import operations do, using the directory list normally known as sys.path, which includes the current directory, PYTHONPATH settings, and standard libraries. Leave off the “.py” suffix here, as the filename is treated as a module.
C:\code> python -m showargs a b -c # Locate/run module as script
['c:\\code\\showargs.py', 'a', 'b', '-c']
The –m option also supports running tools, modules in packages with and without relative import syntax, and modules located in .zip archives. For instance, this switch is commonly used to run the pdb debugger and profile profiler modules from a command line for a script invocation, rather than interactively:
C:\code> python # Interactve debugger session
>>> import pdb
>>> pdb.run('import showargs')
...more omitted: see pdb docs
C:\code> python -m pdb showargs.py a b -c # Debugging a script (c=continue)
-> import sys
['showargs.py', 'a', 'b', '-c']
...more omitted: q to exit
The profiler runs and times your code; its output can vary per Python, operating system, and computer:
C:\code> python -m profile showargs.py a b -c # Profiling a script
['showargs.py', 'a', 'b', '-c']
9 function calls in 0.016 seconds
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
2 0.000 0.000 0.000 0.000 :0(charmap_encode)
1 0.000 0.000 0.000 0.000 :0(exec)
...more omitted: see profile docs
You might also use the -m switch to spawn Chapter 3’s IDLE GUI program located in the standard library from any other directory, and to start the pydoc and timeit tools modules with command lines as we do in this book in Chapter 15 and Chapter 21 (see those chapters for more details on the tools launched here):
c:\code> python -m idlelib.idle -n # Run IDLE in package, no subprocess
c:\code> python -m pydoc -b # Run pydoc and timeit tools modules
c:\code> python -m timeit -n 1000 -r 3 -s "L = [1,2,3,4,5]" "M = [x + 1 for x in L]"
Optimized and unbuffered modes
Immediately after the “python” and before the designation of code to be run, Python accepts additional arguments that control its own behavior. These arguments are consumed by Python itself and are not meant for the script being run. For example, -O runs Python in optimized mode and -uforces standard streams to be unbuffered—with the latter, any printed text will be finalized immediately, and won’t be delayed in a buffer:
C:\code> python -O showargs.py a b -c # Optimized: make/run ".pyo" byte code
C:\code> python -u showargs.py a b -c # Unbuffered standard output stream
Post-run interactive mode
Finally, the –i flag enters interactive mode after running a script—especially useful as a debugging tool, because you can print variables’ final values after a successful run to get more details:
C:\code> python -i showargs.py a b -c # Go to interactive mode on script exit
['showargs.py', 'a', 'b', '-c']
>>> sys # Final value of sys: imported module
<module 'sys' (built-in)>
You can also print variables this way after an exception shuts down your script to see what they looked like when the exception occurred, even if not running in debug mode—though you can start the debugger’s postmortem tool here as well (type is the Windows file display command; try acat or other elsewhere):
C:\code> type divbad.py
X = 0
print(1 / X)
C:\code> python divbad.py # Run the buggy script
...error text omitted
ZeroDivisionError: division by zero
C:\code> python -i divbad.py # Print variable values at error
...error text omitted
ZeroDivisionError: division by zero
>>> import pdb # Start full debugger session now
-> print(1 / X)
Python 2.X command-line arguments
Besides those just mentioned, Python 2.7 supports additional options that promote 3.X compatibility (−3 to warn about incompatibilities, and –Q to control division operator models) and detecting inconsistent tab indentation usage, which is always detected and reported in 3.X (-t; seeChapter 12). Again, you can always ask Python 2.X itself for more on the subject as needed:
C:\code> c:\python27\python -h
Python 3.3 Windows Launcher Command Lines
Technically, the preceding section described the arguments you can pass to the Python interpreter itself—the program usually named python.exe on Windows, and python on Linux (the .exe is normally omitted on Windows). As we’ll see in the next appendix, the Windows launcher shipped with Python 3.3 augments this story for users of 3.3 and later or the standalone launcher package. It adds new executables that accept Python version numbers as arguments in command lines used to start Python and your scripts (file what.py is listed and described in the next appendix, and simply prints the Python version number):
C:\code> py what.py # Windows launcher command lines
C:\code> py −2 what.py # Version number switch
C:\code> py −3.3 -i what.py -a -b -c # Arguments for all 3: py, python, script
In fact, as the last run of the preceding example shows, command lines using the launcher can give arguments for the launcher itself (−3.3), Python itself (-i), and your script (-a, -b, and -c). The launcher can also parse version numbers out of #! Unix lines at the top of script files instead. Because the next appendix is devoted to this launcher entirely, though, you’ll have to read on for the rest of this story.
For More Help
Python’s standard manual set today includes valuable pointers for usage on various platforms. The standard manual set is available in your Start button on Windows 7 and earlier after Python is installed (option “Python Manuals”), and online at http://www.python.org. Look for the manual set’s top-level section titled “Using Python” for more platform-specific pointers and hints, as well as up-to-date cross-platform environment and command-line details.
As always, the Web is your ally, too, especially in a field that often evolves faster than books like this can be updated. Given Python’s widespread adoption, chances are good that answers to any high-level usage questions you may have can be found with a web search.