Python part 2

We'll start with the basics of the Python language. In the first Python lab
you'll learn how to use IDLE, which is a Python Graphical User Interface
(Python GUI). This GUI is designed to let you create/edit/modify/run
Python programs. Remember that for Python, as for most programming
languages, there are many different compilers, editors, GUIs, etc available.
With IDLE (which is a window) you can click on "file" on the top tab and
then click on "new window" which opens a new window. This new window
is rather like Notepad--you can do editing here and type in a Python
program.

We're asking you to type in the following lines, just like you'd do with
Notepad:

      # your name                                   e.g.    # Ludwig Snarf
      # cs100 lab 6-1                                         # cs100 lab 6-1
      print "Hello World!"                              print "Hello World!"

In Python, a line that starts with "#" is a comment or documentation. This
means that this line carries information to a human reading the program
(such as you or your lab TA). The compiler does not translate comments into
executable code. In fact, your program would run just the same without
comments (try it if you wish!). But in the real world, documentation is
absolutely vital for software. It lets you know who the author is if problems
arise or if updates are needed, it lets your TA know whose code they are looking
at. As you will see, documentation goes far beyond just indentfying the author.
In a typical program chunks/blocks of code are documented/commented to
explain what the block is trying to accomplish--this helps any reader to
understand what the code in the block is trying to do. Why not "helps the
reader to understand what the code in the block is doing"? The difference
may be subtle. The code in the block may compile successfully, but it may not
in fact accomplish what the author intended at all times. Trying to read code
(and understand the code) that is undocumented can be difficult or well-nigh
impossible. We have seen many students (and perhaps faculty!) who thought
they were saving a bit of time by omitting documentation pick up their own
code a year or even a month after they had written it, and then have a real
struggle trying to figure out what is going on. Think of it this way: before
writing a block of code, first write down some short documentation explaining
what it is you are trying to do and how you will be doing it. This would be like
writing a term paper for a history class, for example. In your first draft (or even
later drafts) you might pencil in a short explanation before each paragraph that
lays out what you'll be doing in the paragraph. Many or most of us don't do
this! But if we did, it might well make the whole paper better organized and
require fewer drafts! In term papers, as with writing code, remember:
If you can't explain what this is doing--don't write it! This may sound useless,
but we have seen lots of students who couldn't explain what their own code
blocks were trying to do.

NEXT: the print "Hello World!" No comment here: this line, since it is not
documentation, will get translated by the Python compiler into bytecode.
The print part tells the compiler that we want something printed out--
normally to the screen (there are ways to arrange so that things go to a laser
printer or to a file on your hard drive, etc. But in all cases, we're arranging
for some output somewhere. All we want here is for something to be printed
on your screen. The double quotes let the compiler know what you want
printed. If we instead of "Hello World!" had done "Goodbye!" or "!!!!!"
or "Hi there Luwig! You're a great guy!" those would work just fine as well.
Suppose we extend our program a bit:

     # Ludwig Snarf
     print "Hello there!"
     print "How are you doing, Luwig?"
     print "Go Vols!"

When you compile and run this program, it will print out those three lines
IN ORDER. The order of the print statements does matter--the computer
has translated these into machine code, and executes them sequentially. The
computer does NOT hop around at random in your code--the way you might
grab things off a large tray of assorted cookies. The sequence here is totally
straightforward--but as we will be seeing, there are mechanisms for altering
the flow of control, so that different things may be executed depending on the
data. Perhaps think of it this way. You have Tuesday-Thursday classes.
On Monday and Wednesday evenings your computer prints out on the screen
"Remember you have class tomorrow!!" On Thursday evening the computer
prints out (slightly prematurely) "TGIF!" And on Friday evening the computer
prints out "Whoopee! It's the weekend!" The program is making a decision
based on the day of the week about what to print--the same code is NOT being
executed each day--e.g. on Fridays the computer is NOT executing the code
that prints to the screen "Remember you have class tomorrow!"