Which Option Should I Use?

With all these options, true beginners might naturally ask: which one is best for me? In general, you should give the IDLE interface a try if you are just getting started with Python. It provides a user-friendly GUI environment and hides 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 (in fact, this is how I develop Python programs, but I have a Unix-biased distant past). Because the choice of development environments is very subjective, I can’t offer much more in the way of universal guidelines. In general, whatever environment you like to use will be the best for you to use.

Debugging Python Code

Naturally, none of my readers or students ever have bugs in their code (insert smiley here), but for less fortunate friends of yours who may, here’s a quick review of the strategies commonly used by real-world Python programmers to debug code, for you to refer to as you start coding in earnest:

Do nothing. By this, I don’t mean that Python programmers don’t debug their code—but when you make a mistake in a Python program, you get a very useful and readable error message (you’ll get to see some soon, if you haven’t already). If you already know Python, and especially for your own code, this is often enough—read the error message, and go fix the tagged line and file. For many, this is debugging in Python. It may not always be ideal for larger systems you didn’t write, though.
Insert print statements. Probably the main way that Python programmers debug their code (and the way that I debug Python code) is to insert print statements and run again. Because Python runs immediately after changes, this is usually the quickest way to get more information than error messages provide. The print statements don’t have to be sophisticated—a simple “I am here” or display of variable values is usually enough to provide the context you need. Just remember to delete or comment out (i.e., add a # before) the debugging prints before you ship your code!
Use IDE GUI debuggers. For larger systems you didn’t write, and for beginners who want to trace code in more detail, most Python development GUIs have some sort of point-and-click debugging support. IDLE has a debugger too, but it doesn’t appear to be used very often in practice—perhaps because it has no command line, or perhaps because adding print statements is usually quicker than setting up a GUI debugging session. To learn more, see IDLE’s Help, or simply try it on your own; its basic interface is described in the section Advanced IDLE Tools. Other IDEs, such as Eclipse, NetBeans, Komodo, and Wing IDE, offer advanced point-and-click debuggers as well; see their documentation if you use them.
Use the pdb command-line debugger. For ultimate control, Python comes with a source code debugger named pdb, available as a module in Python’s standard library. In pdb, you type commands to step line by line, display variables, set and clear breakpoints, continue to a breakpoint or error, and so on. You can launch pdb interactively by importing it, or as a top-level script. Either way, because you can type commands to control the session, it provides a powerful debugging tool. pdb also includes a postmortem function (pdb.pm()) that you can run after an exception occurs, to get information from the time of the error. See the Python library manual and Chapter 36 for more details on pdb, and Appendix A for an example or running pdb as a script with Python’s –m command argument.
Use Python’s –i command-line argument. Short of adding prints or running under pdb, you can still see what went wrong on errors. If you run your script from a command line and pass a -i argument between python and the name of your script (e.g., python –i m.py), Python will enter into its interactive interpreter mode (the >>> prompt) when your script exits, whether it ends successfully or runs into an error. At this point, you can print the final values of variables to get more details about what happened in your code because they are in the top-level namespace. You can also then import and run the pdb debugger for even more context; its postmortem mode will let you inspect the latest error if your script failed. Appendix A also shows -i in action.
Other options. For more specific debugging requirements, you can find additional tools in the open source domain, including support for multithreaded programs, embedded code, and process attachment. The Winpdb system, for example, is a standalone debugger with advanced debugging support and cross-platform GUI and console interfaces.

These options will become more important as we start writing larger scripts. Probably the best news on the debugging front, though, is that errors are detected and reported in Python, rather than passing silently or crashing the system altogether. In fact, errors themselves are a well-defined mechanism known as exceptions, which you can catch and process (more on exceptions in Part VII). Making mistakes is never fun, of course, but take it from someone who recalls when debugging meant getting out a hex calculator and poring over piles of memory dump printouts: Python’s debugging support makes errors much less painful than they might otherwise be.