It is time to put longer collections of instructions together. That is most easily done by creating a text file and running the Python interpreter on the file. Idle simplifies that process.
First you can put an existing file into an Idle Edit Window. Click on the Idle File menu and select Open. (Or as you see, you can use the shortcut Ctrl-O. That means holding down the Ctrl key, and pressing the letter O for Open.) You should get a file selection dialog. You should have the sample program madlib.py displayed in the list. Select it and open it. (If you do not see the program, then you either failed to download the example programs in Your Python Folder and Python Examples, or you did not start Idle in the proper folder in Starting Idle.)
You will see the source code again. Now run this program from inside of Idle: Go to the Run menu of that Edit window, and select Run Module. Notice the shortcut (F5).
If the Shell window does not automatically come to the foreground, select it. You should see a line saying RESTART and then the start of the execution of the Mad Lib program with the cursor waiting for your entry after the first prompt. Finish executing the program. Be sure to type the final requested Enter, so you get back to the interpreter prompt: >>>
Look at the editor window again. You should see that different parts of the code have different colors. String literals are likely green. The reserved words def are likely orange. Look at the last two lines, where the identifier tellStory is black, and the identifier input is likely purple. Only identifiers that are not predefined by Python are black. If you create an identifier name, make sure Idle shows it in black.
Luckily this bug was fixed for Python 3.3, but if for some reason you are using an older version and cannot update to the current version, read on:
When you execute a program from the Idle Editor, the interpreter gives a banner saying RESTART, meaning that all the things you defined in any shell session so far are wiped clean and the program you are running starts fresh. There is one egregious exception to that, that was still present at least in the version of Idle for Python 3.1 in Windows. We will try to demonstrate the bug. (A bug is an error in a program.)
Start running the Mad Lib program again by going to the Editor Window containing madlib.py, and start running the program again, but do not continue....
You should see a prompt for user input generated by the program. Ignore this prompt and go back to the Edit Window and start the Mad Lib program again.
If this bug is still present, you should see a difference in this restart: This time after the RESTART banner and the interpreter prompt: >>>, which looks innocent enough, but this program should show the program’s prompt string for input, and with the bug, Idle does not show the program’s prompt.
The problem only comes up because you interrupted the last execution when user input was being waited for. The restart was not complete here: The system is still looking for the pending user input from the last execution.
The fix is simple: Make sure the Interpreter Window is the currently selected window, and press return to terminate the lost user input. In some circumstances, you may need to press return a second time.
After that the program should start up normally with its prompt.
Watch out for this behavior, and remember the fix.
Make sure you have Idle started in your Python directory (in Windows with the provided Idle shortcut link), where you will store program files.
Do not start Idle from the Windows Start Menu!
If you just started Idle now, you may already have a blank Edit Window in front of you. If not, open a new window by going to the File menu and selecting New Window. This gives you a rather conventional text editing window with the mouse available, ability to cut and paste, plus a few special options for Python.
Type (or paste) the following into the editor window:
Save the file with the menu sequence File ‣ Save, and then enter the file name hello.py. Python program files should always be given a name ending in ”.py”, and you must enter the .py extension explicitly .
If you look in the editor, you should see that your text is color coded. The editor will color different parts of Python syntax in special colors.
Now that you have a complete, saved program, choose Run ‣ Run Module. You should see the program run in the Python Shell window.
You just wrote and executed a program. Unlike when you use the shell, this code is saved to a file in your Python folder. You can open and execute the file any time you want. (In Idle, use File ‣ Open.)
To the interpreter, a program source file is a Python module. We will tend to use the more general term: a program file is a module. Note the term from the menu when running the program.
Distinguish program code from Shell text: It is easy to confuse the Shell and the Edit windows. Make sure you keep them straight. The hello.py program is just the line
that you typed into the edit window and saved. When you ran the program in Idle, you saw results in the Shell. First came the Restart notice, the one-line output from the program saying hello, and a further Shell prompt:
>>> ================================ RESTART ======== >>> Hello world! >>>
You could also have typed this single printing line directly in the Shell in response to a Shell prompt. When you see >>>, you could enter the print function and get the exchange between you and the Shell:
>>> print('Hello world') Hello world! >>>
The three lines above are not a program you could save in a file and run. This is just an exchange in the Shell, with its >>> prompts, individual line to execute and the response.
Again, just the single line, with no >>>,
entered into the Edit window forms a program you can save and run.
We will shortly get to more interesting many-statement programs, where it is much more convenient to use the Edit window than the Shell!
The general assumption in this Tutorial will be that programs are run in Idle and the Idle Shell is the Shell referred to. It will be explicitly stated when you should run a program directly from the operating system.
In general it is fine to run our programs from a cmd console (Windows) or terminal (Mac).
Running the text based example programs in Windows, like birthday2.py, by selecting them to run from a file folder, will not work well: The program ends and the window automatically closes before you can see the final output.
On a Mac you get to explicitly close the terminal window created when you run a Python program from the Finder.
The program above is self evident, and shows how short and direct a program can be (unlike other languages such as Java). Still, right away, get used to documenting a program. Python has a special feature: If the beginning of a program is just a quoted string, that string is taken to be the program’s documentation string. Open the example file hello2.py in the Edit window:
'''A very simple program, showing how short a Python program can be! Authors: ___, ___ ''' print('Hello world!') #This is a stupid comment after the # mark
Most commonly, the initial documentation goes on for several lines, so a multi-line string delimiter is used (the triple quotes). Just for completeness of illustration in this program, another form of comment is also shown, a comment that starts with the symbol # and extends to the end of the line. The Python interpreter completely ignores this form of comment. Such a comment should only be included for better human understanding. Avoid making comments that do not really aid human understanding. (Do what I say, not what I did above.) Good introductory comment strings and appropriate names for the parts of your programs make fewer # symbol comments needed.
Run the program and see the documentation and comment make no difference in the result.
Of course you can arrange the windows on your computer screen any way that you like. A suggestion as you start to use the combination of the editor to write, the shell to run, and the tutorial to follow along: Make all three mostly visible your computer screen at once. Drag the editor window to the upper left. Place the Shell window to the lower left, and perhaps reduce its height a bit so there is not much overlap. If you are looking at the web version of the tutorial on the screen, make it go top to bottom on the right, but not overlap the Idle windows too much. The web page rendering should generally adapt to the width pretty well. You can always temporarily maximize the window. Before resizing the browser window, it is good to look for an unusual phrase on your page, and search for it after resizing, since resizing can totally mess up your location in the web page.
There is an alternative to maximization for the Idle editor window: It you want it to go top to bottom of the screen but not widen, you can toggle that state with Alt-2. Play with all this.