Common question about shell and program files. Interaction versus instruction. Save means something a bit different. Let's work through an exercise that will help us practice our Python and see how the different windows work.
Your textbook authors love real-world examples, including literature. Here is one.
A nursery rhyme:
As I was going to St. Ives, I met a man with seven wives. Every wife had seven sacks, and every sack had seven cats, and every cat had seven kittens. Kittens, cats, sacks, and wives, how many were going to St. Ives?For our purposes, assume that ecerything and everyone is headed to St. Ives. Write a Python program to calculate that total.
Use the shell to help us. 7 wives. 7 * 7 sacks. 7 * 7 * 7 cats. Using up-arrow to re-use an expression. 7*7*7*7 kittens. So our program can be as simple as:
7 + (7 * 7) + (7 * 7 * 7) + (7 * 7 * 7 * 7)
We execute it:
>>> 7 + (7 * 7) + (7 * 7 * 7) + (7 * 7 * 7 * 7)
2800
That is fine if all we need is an answer. But we could make the program a lot more expressive if it explained itself in more detail. How could we help readers understand this program more easily?
One way to make a program easier to understand is to give names to its parts. This program contains four numbers, each of which means something particular: wives, sacks, cats, and kittens, respectively. Let's name them:
>>> wives = 7
>>> sacks = 7 * 7
>>> cats = 7 * 7 * 7
>>> kittens = 7 * 7 * 7 * 7
>>> wives + sacks + cats + kittens
2800
That's a little clearer. But those * 7s also mean something. There is a relationships between the number of wives and the number of sacks, and between the number of sacks and the number of cats, and between the number of cats and the number of kittens. Our statements don't say that. Let's fix that.
Sidestep. We know how to calculate the correct answer. Typing expressions into the shell isn't helping us as much as it did in the beginning. Now is the time to "promote" our code into a program. [Copy the statements and paste them into a program window.] Where did the answer go?
Shell: a conversation with interpreter. Read, evaluate, print, do it again. Program: a set of instructions. To run is to evaluate. If we want to print, we have to print.
wives = 7
sacks = 7 * 7
cats = 7 * 7 * 7
kittens = 7 * 7 * 7 * 7
print(wives + sacks + cats + kittens)
There it is! Of course, we can put a label on our output to make the result easier to understand:
print("Number of travelers:", wives + sacks + cats + kittens)
Now, back to the program itself. Relationships exist in the situation we are describing, but our program doesn't show them explicitly. How many sacks are there? Seven for each wife:
sacks = 7 * wives
How many cats are there? How many kittens?
cats = 7 * sacks
kittens = 7 * cats
Now, that's a program. With a header block, you might even submit it for homework.
Extra challenge... Could we make our names better?
st-ives.py is our third program. Now that we know a bit more about Python, let's go back and look at our first two.
In Lab 1 last week, you typed in a series of expressions that led us to create the program circle.py. This program is human readable:
... Do we need more comments? How much is enough?
On Day 1 last week, I showed you a Python program that I whipped up for myself: mileage.py. How does this program stack up with regard to readability?
This program's output is not as human-friendly! I plead guilty. The program was just for me, and I knew what the output meant.
This program use two features of Python, lists and loops, that we will learn about in coming weeks. For now, don't worry about them.
Notice that, like st-ives.py, this program computes the answer to a specific problem. What happens when I ride the bike next and want to know the answer for a new problem? I have to edit the program!
... a specific *instance* of a problem. ... we write programs like this sometime -- scripts. ... we get a bigger return on our time investment if we can solve all instances of the same problem. --- generalize the program. How?
We will do both of these this semester as well.
Finally, let's go back to the opening challenge from Day 2. (Sorry for the delay...) Like today's opening exercise, this challenge can be solved using one line of arithmetic:
(int(hours) * 60 * 60) + (int(minutes) * 60) + int(seconds)
We have now seen, though, that when executing a program we need to print the answer explicitly. Perhaps then:
answer = (int(hours) * 60 * 60) + (int(minutes) * 60) + int(seconds)
print("There are", answer, "seconds left.")
This gives us something like seconds_left.py. Do I need the parentheses? Would giving names to some of the parts make this program better?
The textbook's authors like to write code that helps us see all the parts of a program as easily as possible. They might write this version of seconds_left.py.
You will see many Python programs in the next few months. Use these examples to help you write your own programs, both for the way we use features of Python to solve problems and for the way we organize and layout the program text.
Do it.
Lots of details. Can't memorize all. Need to memorize some (the ones we use frequently). Need to know that other things exist, so you can look them up when you need them.
Recipe for boring classes: me lecturing you on the minutia of Python operators and syntax. You can read.
The minutia of Python operators and syntax are not the hard part of programming. What is the hard part? Thinking about problems, and using the minutia to write your solution. Mastering your tools so that you are powerful when you use them, again so that you can use them effectively to create solutions.
I don't like to lecture on the minutia of Python operators and syntax. But you may still want some assistance with something after you read about it. Ask questions! I love to answer questions. I also love to discuss the ideas that come up when someone asks a question.
We have now seen a number of levels at which we can think of Python code. Roughly in order of size and complexity:
An expression is anything that has a value. Data objects such as numbers and strings. Names for data objects. Calls to a function, such as input(). (We will learn how to write our own functions soon.)
A statement is code that performs a task. It does not have a value. Assignment statements. Calls to some other functions, such as print().
Quick exercise: How can we tell that print() doesn't have a value? We see result when we call it... Try this:
>>> a = print(1)
>>> a
The assignment operator, =, can give a name to a value or change the value associated with a name:
>>> a = 10 # no value, so none printed
>>> a
>>> a + 1
>>> a
>>> a = a + 1
>>> a
Section 1.5 (pp. 49-52) talks about names, values, and assignments in some detail. It uses the word variable in place of "name". variable is one of the basic words of programming and programming languages.
A program is a sequence of statements that performs a larger task. It does not have a value in Python, either.
A module is a sequence of statements that define values and functions that are useful for a certain set of tasks. math. We can write our own modules, too (though probably not this semester).
All of the programs we have seen thus far follow the same simple pattern:
This is sometimes called IPO, for input, process, output. In some ways, you can say that it is the basic form all programs. It is certainly a pattern we will see and use a lot this semester.
What about mileage.py? Does it fit the pattern?
The first programs you write will all be obvious examples of IPO. Over time, the "P" will grow...
Growing a program from interactions in the shell.
The IPO pattern.