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
Python programs. Remember that for Python, as for most programming
languages, there are many different compilers, editors, GUIs, etc
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
is rather like Notepad--you can do editing here and type in a Python
We're asking you to type in the following lines, just like you'd do with
e.g. # Ludwig Snarf
# cs100 lab
# cs100 lab 6-1
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
executable code. In fact, your program would run just the same
comments (try it if you wish!). But in the real world,
absolutely vital for software. It lets you know who the author is
arise or if updates are needed, it lets your TA know whose code they
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
reader to understand what the code in the block is doing"? The
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
impossible. We have seen many students (and perhaps faculty!) who
they were saving a bit of time by omitting documentation pick up their
code a year or even a month after they had written it, and then have a
struggle trying to figure out what is going on. Think of it this
writing a block of code, first write down some short documentation
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
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
require fewer drafts! In term papers, as with writing code,
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
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.
part tells the compiler that we want something printed out--
normally to the screen (there are ways to arrange so that things go to
printer or to a file on your hard drive, etc. But in all cases,
for some output somewhere. All we want here is for something to
on your screen. The double quotes let the compiler know what you
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
IN ORDER. The order of
the print statements does matter--the computer
has translated these into machine code, and executes them
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
the flow of control, so that different things may be executed depending
data. Perhaps think of it this way. You have
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
prints out "Whoopee! It's the weekend!" The program is making a
based on the day of the week about what to print--the same code is NOT
executed each day--e.g. on Fridays the computer is NOT executing the
that prints to the screen "Remember you have class tomorrow!"