Created
October 20, 2020 19:12
-
-
Save redbrain/2fed660a3e42f3baae55b0e5b287e115 to your computer and use it in GitHub Desktop.
Think Python (the texbook) as a LaTeX file. Directly from the repo AllenDowney/ThinkPython, but I needed it as a gist.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
% LaTeX source for ``Think Python: How to Think Like a Computer Scientist'' | |
% Copyright (c) 2012 Allen B. Downey. | |
% License: Creative Commons Attribution-NonCommercial 3.0 Unported License. | |
% http://creativecommons.org/licenses/by-nc/3.0/ | |
% | |
%\documentclass[10pt,b5paper]{book} | |
\documentclass[10pt]{book} | |
\usepackage[width=5.5in,height=8.5in, | |
hmarginratio=3:2,vmarginratio=1:1]{geometry} | |
% for some of these packages, you might have to install | |
% texlive-latex-extra (in Ubuntu) | |
\usepackage[T1]{fontenc} | |
\usepackage{textcomp} | |
\usepackage{mathpazo} | |
\usepackage{url} | |
\usepackage{fancyhdr} | |
\usepackage{graphicx} | |
\usepackage{amsmath} | |
\usepackage{amsthm} | |
%\usepackage{amssymb} | |
\usepackage{exercise} % texlive-latex-extra | |
\usepackage{makeidx} | |
\usepackage{setspace} | |
\usepackage{hevea} | |
\usepackage{upquote} | |
\usepackage{appendix} | |
\usepackage[bookmarks]{hyperref} | |
\title{Think Python} | |
\author{Allen B. Downey} | |
\newcommand{\thetitle}{Think Python: How to Think Like a Computer Scientist} | |
\newcommand{\theversion}{2.0.17} | |
\newcommand{\thedate}{} | |
% these styles get translated in CSS for the HTML version | |
\newstyle{a:link}{color:black;} | |
\newstyle{p+p}{margin-top:1em;margin-bottom:1em} | |
\newstyle{img}{border:0px} | |
% change the arrows | |
\setlinkstext | |
{\imgsrc[ALT="Previous"]{back.png}} | |
{\imgsrc[ALT="Up"]{up.png}} | |
{\imgsrc[ALT="Next"]{next.png}} | |
\makeindex | |
\newif\ifplastex | |
\plastexfalse | |
\begin{document} | |
\frontmatter | |
% PLASTEX ONLY | |
\ifplastex | |
\usepackage{localdef} | |
\maketitle | |
\newcount\anchorcnt | |
\newcommand*{\Anchor}[1]{% | |
\@bsphack% | |
\Hy@GlobalStepCount\anchorcnt% | |
\edef\@currentHref{anchor.\the\anchorcnt}% | |
\Hy@raisedlink{\hyper@anchorstart{\@currentHref}\hyper@anchorend}% | |
\M@gettitle{}\label{#1}% | |
\@esphack% | |
} | |
\else | |
% skip the following for plastex | |
\newtheorem{exercise}{Exercise}[chapter] | |
% LATEXONLY | |
\input{latexonly} | |
\begin{latexonly} | |
\renewcommand{\blankpage}{\thispagestyle{empty} \quad \newpage} | |
%\blankpage | |
%\blankpage | |
% TITLE PAGES FOR LATEX VERSION | |
%-half title-------------------------------------------------- | |
\thispagestyle{empty} | |
\begin{flushright} | |
\vspace*{2.0in} | |
\begin{spacing}{3} | |
{\huge Think Python}\\ | |
{\Large How to Think Like a Computer Scientist} | |
\end{spacing} | |
\vspace{0.25in} | |
Version \theversion | |
\thedate | |
\vfill | |
\end{flushright} | |
%--verso------------------------------------------------------ | |
\blankpage | |
\blankpage | |
%\clearemptydoublepage | |
%\pagebreak | |
%\thispagestyle{empty} | |
%\vspace*{6in} | |
%--title page-------------------------------------------------- | |
\pagebreak | |
\thispagestyle{empty} | |
\begin{flushright} | |
\vspace*{2.0in} | |
\begin{spacing}{3} | |
{\huge Think Python}\\ | |
{\Large How to Think Like a Computer Scientist} | |
\end{spacing} | |
\vspace{0.25in} | |
Version \theversion | |
\thedate | |
\vspace{1in} | |
{\Large | |
Allen Downey\\ | |
} | |
\vspace{0.5in} | |
{\Large Green Tea Press} | |
{\small Needham, Massachusetts} | |
%\includegraphics[width=1in]{figs/logo1.pdf} | |
\vfill | |
\end{flushright} | |
%--copyright-------------------------------------------------- | |
\pagebreak | |
\thispagestyle{empty} | |
{\small | |
Copyright \copyright ~2012 Allen Downey. | |
\vspace{0.2in} | |
\begin{flushleft} | |
Green Tea Press \\ | |
9 Washburn Ave \\ | |
Needham MA 02492 | |
\end{flushleft} | |
Permission is granted to copy, distribute, and/or modify this document | |
under the terms of the Creative Commons Attribution-NonCommercial 3.0 Unported | |
License, which is available at \url{http://creativecommons.org/licenses/by-nc/3.0/}. | |
The original form of this book is \LaTeX\ source code. Compiling this | |
\LaTeX\ source has the effect of generating a device-independent | |
representation of a textbook, which can be converted to other formats | |
and printed. | |
The \LaTeX\ source for this book is available from | |
\url{http://www.thinkpython.com} | |
\vspace{0.2in} | |
} % end small | |
\end{latexonly} | |
% HTMLONLY | |
\begin{htmlonly} | |
% TITLE PAGE FOR HTML VERSION | |
{\Large \thetitle} | |
{\large Allen B. Downey} | |
Version \theversion | |
\thedate | |
\setcounter{chapter}{-1} | |
\end{htmlonly} | |
\fi | |
% END OF THE PART WE SKIP FOR PLASTEX | |
\chapter{Preface} | |
\section*{The strange history of this book} | |
In January 1999 I was preparing to teach an introductory programming | |
class in Java. I had taught it three times and I was getting | |
frustrated. The failure rate in the class was too high and, even for | |
students who succeeded, the overall level of achievement was too low. | |
One of the problems I saw was the books. | |
They were too big, with too much unnecessary detail about Java, and | |
not enough high-level guidance about how to program. And they all | |
suffered from the trap door effect: they would start out easy, | |
proceed gradually, and then somewhere around Chapter 5 the bottom would | |
fall out. The students would get too much new material, too fast, | |
and I would spend the rest of the semester picking up the pieces. | |
Two weeks before the first day of classes, I decided to write my | |
own book. | |
My goals were: | |
\begin{itemize} | |
\item Keep it short. It is better for students to read 10 pages | |
than not read 50 pages. | |
\item Be careful with vocabulary. I tried to minimize the jargon | |
and define each term at first use. | |
\item Build gradually. To avoid trap doors, I took the most difficult | |
topics and split them into a series of small steps. | |
\item Focus on programming, not the programming language. I included | |
the minimum useful subset of Java and left out the rest. | |
\end{itemize} | |
I needed a title, so on a whim I chose {\em How to Think Like | |
a Computer Scientist}. | |
My first version was rough, but it worked. Students did the reading, | |
and they understood enough that I could spend class time on the hard | |
topics, the interesting topics and (most important) letting the | |
students practice. | |
I released the book under the GNU Free Documentation License, | |
which allows users to copy, modify, and distribute the book. | |
\index{GNU Free Documentation License} | |
\index{Free Documentation License, GNU} | |
What happened next is the cool part. Jeff Elkner, a high school | |
teacher in Virginia, adopted my book and translated it into | |
Python. He sent me a copy of his translation, and I had the | |
unusual experience of learning Python by reading my own book. | |
As Green Tea Press, I published the first Python version in 2001. | |
\index{Elkner, Jeff} | |
In 2003 I started teaching at Olin College and I got to teach | |
Python for the first time. The contrast with Java was striking. | |
Students struggled less, learned more, worked on more interesting | |
projects, and generally had a lot more fun. | |
\index{Olin College} | |
Over the last nine years I continued to develop the book, | |
correcting errors, improving some of the examples and | |
adding material, especially exercises. | |
The result is this book, now with the less grandiose title | |
{\em Think Python}. Some of the changes are: | |
\begin{itemize} | |
\item I added a section about debugging at the end of each chapter. | |
These sections present general techniques for finding and avoiding | |
bugs, and warnings about Python pitfalls. | |
\item I added more exercises, ranging from short tests of | |
understanding to a few substantial projects. And I wrote | |
solutions for most of them. | |
\item I added a series of case studies---longer examples with | |
exercises, solutions, and discussion. Some are based on | |
Swampy, a suite of Python programs I wrote for use in my classes. | |
Swampy, code examples, and some solutions are available from | |
\url{http://thinkpython.com}. | |
\item I expanded the discussion of program development plans | |
and basic design patterns. | |
\item I added appendices about debugging, analysis of algorithms, and | |
UML diagrams with Lumpy. | |
\end{itemize} | |
I hope you enjoy working with this book, and that it helps | |
you learn to program and think, at least a little bit, like | |
a computer scientist. | |
Allen B. Downey \\ | |
Needham MA\\ | |
Allen Downey is a Professor of Computer Science at | |
the Franklin W. Olin College of Engineering. | |
\section*{Acknowledgments} | |
Many thanks to Jeff Elkner, who | |
translated my Java book into Python, which got this project | |
started and introduced me to what has turned out to be my | |
favorite language. | |
\index{Elkner, Jeff} | |
Thanks also to Chris Meyers, who contributed several sections | |
to {\em How to Think Like a Computer Scientist}. | |
\index{Meyers, Chris} | |
Thanks to the Free Software Foundation for developing | |
the GNU Free Documentation License, which helped make | |
my collaboration with Jeff and Chris possible, and Creative | |
Commons for the license I am using now. | |
\index{GNU Free Documentation License} | |
\index{Free Documentation License, GNU} | |
\index{Creative Commons} | |
Thanks to the editors at Lulu who worked on | |
{\em How to Think Like a Computer Scientist}. | |
Thanks to all the students who worked with earlier | |
versions of this book and all the contributors (listed | |
below) who sent in corrections and suggestions. | |
\section*{Contributor List} | |
\index{contributors} | |
More than 100 sharp-eyed and thoughtful readers have sent in | |
suggestions and corrections over the past few years. Their | |
contributions, and enthusiasm for this project, have been a | |
huge help. | |
If you have a suggestion or correction, please send email to | |
{\tt [email protected]}. If I make a change based on your | |
feedback, I will add you to the contributor list | |
(unless you ask to be omitted). | |
If you include at least part of the sentence the | |
error appears in, that makes it easy for me to search. Page and | |
section numbers are fine, too, but not quite as easy to work with. | |
Thanks! | |
\begin{itemize} | |
\small | |
\item Lloyd Hugh Allen sent in a correction to Section 8.4. | |
\item Yvon Boulianne sent in a correction of a semantic error in | |
Chapter 5. | |
\item Fred Bremmer submitted a correction in Section 2.1. | |
\item Jonah Cohen wrote the Perl scripts to convert the | |
LaTeX source for this book into beautiful HTML. | |
\item Michael Conlon sent in a grammar correction in Chapter 2 | |
and an improvement in style in Chapter 1, and he initiated discussion | |
on the technical aspects of interpreters. | |
\item Benoit Girard sent in a | |
correction to a humorous mistake in Section 5.6. | |
\item Courtney Gleason and Katherine Smith wrote {\tt horsebet.py}, | |
which was used as a case study in an earlier version of the book. Their | |
program can now be found on the website. | |
\item Lee Harr submitted more corrections than we have room to list | |
here, and indeed he should be listed as one of the principal editors | |
of the text. | |
\item James Kaylin is a student using the text. He has submitted | |
numerous corrections. | |
\item David Kershaw fixed the broken {\tt catTwice} function in Section | |
3.10. | |
\item Eddie Lam has sent in numerous corrections to Chapters | |
1, 2, and 3. | |
He also fixed the Makefile so that it creates an index the first time it is | |
run and helped us set up a versioning scheme. | |
\item Man-Yong Lee sent in a correction to the example code in | |
Section 2.4. | |
\item David Mayo pointed out that the word ``unconsciously" | |
in Chapter 1 needed | |
to be changed to ``subconsciously". | |
\item Chris McAloon sent in several corrections to Sections 3.9 and | |
3.10. | |
\item Matthew J. Moelter has been a long-time contributor who sent | |
in numerous corrections and suggestions to the book. | |
\item Simon Dicon Montford reported a missing function definition and | |
several typos in Chapter 3. He also found errors in the {\tt increment} | |
function in Chapter 13. | |
\item John Ouzts corrected the definition of ``return value" | |
in Chapter 3. | |
\item Kevin Parks sent in valuable comments and suggestions as to how | |
to improve the distribution of the book. | |
\item David Pool sent in a typo in the glossary of Chapter 1, as well | |
as kind words of encouragement. | |
\item Michael Schmitt sent in a correction to the chapter on files | |
and exceptions. | |
\item Robin Shaw pointed out an error in Section 13.1, where the | |
printTime function was used in an example without being defined. | |
\item Paul Sleigh found an error in Chapter 7 and a bug in Jonah Cohen's | |
Perl script that generates HTML from LaTeX. | |
\item Craig T. Snydal is testing the text in a course at Drew | |
University. He has contributed several valuable suggestions and corrections. | |
\item Ian Thomas and his students are using the text in a programming | |
course. They are the first ones to test the chapters in the latter half | |
of the book, and they have made numerous corrections and suggestions. | |
\item Keith Verheyden sent in a correction in Chapter 3. | |
\item Peter Winstanley let us know about a longstanding error in | |
our Latin in Chapter 3. | |
\item Chris Wrobel made corrections to the code in the chapter on | |
file I/O and exceptions. | |
\item Moshe Zadka has made invaluable contributions to this project. | |
In addition to writing the first draft of the chapter on Dictionaries, he | |
provided continual guidance in the early stages of the book. | |
\item Christoph Zwerschke sent several corrections and | |
pedagogic suggestions, and explained the difference between {\em gleich} | |
and {\em selbe}. | |
\item James Mayer sent us a whole slew of spelling and | |
typographical errors, including two in the contributor list. | |
\item Hayden McAfee caught a potentially confusing inconsistency | |
between two examples. | |
\item Angel Arnal is part of an international team of translators | |
working on the Spanish version of the text. He has also found several | |
errors in the English version. | |
\item Tauhidul Hoque and Lex Berezhny created the illustrations | |
in Chapter 1 and improved many of the other illustrations. | |
\item Dr. Michele Alzetta caught an error in Chapter 8 and sent | |
some interesting pedagogic comments and suggestions about Fibonacci | |
and Old Maid. | |
\item Andy Mitchell caught a typo in Chapter 1 and a broken example | |
in Chapter 2. | |
\item Kalin Harvey suggested a clarification in Chapter 7 and | |
caught some typos. | |
\item Christopher P. Smith caught several typos and helped us | |
update the book for Python 2.2. | |
\item David Hutchins caught a typo in the Foreword. | |
\item Gregor Lingl is teaching Python at a high school in Vienna, | |
Austria. He is working on a German translation of the book, | |
and he caught a couple of bad errors in Chapter 5. | |
\item Julie Peters caught a typo in the Preface. | |
\item Florin Oprina sent in an improvement in {\tt makeTime}, | |
a correction in {\tt printTime}, and a nice typo. | |
\item D.~J.~Webre suggested a clarification in Chapter 3. | |
\item Ken found a fistful of errors in Chapters 8, 9 and 11. | |
\item Ivo Wever caught a typo in Chapter 5 and suggested a clarification | |
in Chapter 3. | |
\item Curtis Yanko suggested a clarification in Chapter 2. | |
\item Ben Logan sent in a number of typos and problems with translating | |
the book into HTML. | |
\item Jason Armstrong saw the missing word in Chapter 2. | |
\item Louis Cordier noticed a spot in Chapter 16 where the code | |
didn't match the text. | |
\item Brian Cain suggested several clarifications in Chapters 2 and 3. | |
\item Rob Black sent in a passel of corrections, including some | |
changes for Python 2.2. | |
\item Jean-Philippe Rey at Ecole Centrale | |
Paris sent a number of patches, including some updates for Python 2.2 | |
and other thoughtful improvements. | |
\item Jason Mader at George Washington University made a number | |
of useful suggestions and corrections. | |
\item Jan Gundtofte-Bruun reminded us that ``a error'' is an error. | |
\item Abel David and Alexis Dinno reminded us that the plural of | |
``matrix'' is ``matrices'', not ``matrixes''. This error was in the | |
book for years, but two readers with the same initials reported it on | |
the same day. Weird. | |
\item Charles Thayer encouraged us to get rid of the semi-colons | |
we had put at the ends of some statements and to clean up our | |
use of ``argument'' and ``parameter''. | |
\item Roger Sperberg pointed out a twisted piece of logic in Chapter 3. | |
\item Sam Bull pointed out a confusing paragraph in Chapter 2. | |
\item Andrew Cheung pointed out two instances of ``use before def.'' | |
\item C. Corey Capel spotted the missing word in the Third Theorem | |
of Debugging and a typo in Chapter 4. | |
\item Alessandra helped clear up some Turtle confusion. | |
\item Wim Champagne found a brain-o in a dictionary example. | |
\item Douglas Wright pointed out a problem with floor division in | |
{\tt arc}. | |
\item Jared Spindor found some jetsam at the end of a sentence. | |
\item Lin Peiheng sent a number of very helpful suggestions. | |
\item Ray Hagtvedt sent in two errors and a not-quite-error. | |
\item Torsten H\"{u}bsch pointed out an inconsistency in Swampy. | |
\item Inga Petuhhov corrected an example in Chapter 14. | |
\item Arne Babenhauserheide sent several helpful corrections. | |
\item Mark E. Casida is is good at spotting repeated words. | |
\item Scott Tyler filled in a that was missing. And then sent in | |
a heap of corrections. | |
\item Gordon Shephard sent in several corrections, all in separate | |
emails. | |
\item Andrew Turner {\tt spot}ted an error in Chapter 8. | |
\item Adam Hobart fixed a problem with floor division in {\tt arc}. | |
\item Daryl Hammond and Sarah Zimmerman pointed out that I served | |
up {\tt math.pi} too early. And Zim spotted a typo. | |
\item George Sass found a bug in a Debugging section. | |
\item Brian Bingham suggested Exercise~\ref{exrotatepairs}. | |
\item Leah Engelbert-Fenton pointed out that I used {\tt tuple} | |
as a variable name, contrary to my own advice. And then found | |
a bunch of typos and a ``use before def.'' | |
\item Joe Funke spotted a typo. | |
\item Chao-chao Chen found an inconsistency in the Fibonacci example. | |
\item Jeff Paine knows the difference between space and spam. | |
\item Lubos Pintes sent in a typo. | |
\item Gregg Lind and Abigail Heithoff suggested Exercise~\ref{checksum}. | |
\item Max Hailperin has sent in a number of corrections and | |
suggestions. Max is one of the authors of the extraordinary {\em | |
Concrete Abstractions}, which you might want to read when you are | |
done with this book. | |
\item Chotipat Pornavalai found an error in an error message. | |
\item Stanislaw Antol sent a list of very helpful suggestions. | |
\item Eric Pashman sent a number of corrections for Chapters 4--11. | |
\item Miguel Azevedo found some typos. | |
\item Jianhua Liu sent in a long list of corrections. | |
\item Nick King found a missing word. | |
\item Martin Zuther sent a long list of suggestions. | |
\item Adam Zimmerman found an inconsistency in my instance | |
of an ``instance'' and several other errors. | |
\item Ratnakar Tiwari suggested a footnote explaining degenerate | |
triangles. | |
\item Anurag Goel suggested another solution for \verb"is_abecedarian" | |
and sent some additional corrections. And he knows how to | |
spell Jane Austen. | |
\item Kelli Kratzer spotted one of the typos. | |
\item Mark Griffiths pointed out a confusing example in Chapter 3. | |
\item Roydan Ongie found an error in my Newton's method. | |
\item Patryk Wolowiec helped me with a problem in the HTML version. | |
\item Mark Chonofsky told me about a new keyword in Python 3. | |
\item Russell Coleman helped me with my geometry. | |
\item Wei Huang spotted several typographical errors. | |
\item Karen Barber spotted the the oldest typo in the book. | |
\item Nam Nguyen found a typo and pointed out that I used the Decorator | |
pattern but didn't mention it by name. | |
\item St\'{e}phane Morin sent in several corrections and suggestions. | |
\item Paul Stoop corrected a typo in \verb+uses_only+. | |
\item Eric Bronner pointed out a confusion in the discussion of the | |
order of operations. | |
\item Alexandros Gezerlis set a new standard for the number and | |
quality of suggestions he submitted. We are deeply grateful! | |
\item Gray Thomas knows his right from his left. | |
\item Giovanni Escobar Sosa sent a long list of corrections and | |
suggestions. | |
\item Alix Etienne fixed one of the URLs. | |
\item Kuang He found a typo. | |
\item Daniel Neilson corrected an error about the order of operations. | |
\item Will McGinnis pointed out that {\tt polyline} was defined | |
differently in two places. | |
\item Swarup Sahoo spotted a missing semi-colon. | |
\item Frank Hecker pointed out an exercise that was under-specified, and | |
some broken links. | |
\item Animesh B helped me clean up a confusing example. | |
\item Martin Caspersen found two round-off errors. | |
\item Gregor Ulm sent several corrections and suggestions. | |
\item Dimitrios Tsirigkas suggested I clarify an exercise. | |
\item Carlos Tafur sent a page of corrections and suggestions. | |
\item Martin Nordsletten found a bug in an exercise solution. | |
\item Lars O.D. Christensen found a broken reference. | |
\item Victor Simeone found a typo. | |
\item Sven Hoexter pointed out that a variable named {\tt input} | |
shadows a build-in function. | |
\item Viet Le found a typo. | |
\item Stephen Gregory pointed out the problem with {\tt cmp} | |
in Python 3. | |
\item Matthew Shultz let me know about a broken link. | |
\item Lokesh Kumar Makani let me know about some broken links and some | |
changes in error messages. | |
\item Ishwar Bhat corrected my statement of Fermat's last theorem. | |
\item Brian McGhie suggested a clarification. | |
\item Andrea Zanella translated the book into Italian, and sent a | |
number of corrections along the way. | |
% ENDCONTRIB | |
\end{itemize} | |
\normalsize | |
\clearemptydoublepage | |
% TABLE OF CONTENTS | |
\begin{latexonly} | |
\tableofcontents | |
\clearemptydoublepage | |
\end{latexonly} | |
% START THE BOOK | |
\mainmatter | |
\chapter{The way of the program} | |
The goal of this book is to teach you to think like a | |
computer scientist. This way of thinking combines some of the best features | |
of mathematics, engineering, and natural science. Like mathematicians, | |
computer scientists use formal languages to denote ideas (specifically | |
computations). Like engineers, they design things, assembling components | |
into systems and evaluating tradeoffs among alternatives. Like scientists, | |
they observe the behavior of complex systems, form hypotheses, and test | |
predictions. | |
\index{problem solving} | |
The single most important skill for a computer scientist is {\bf | |
problem solving}. Problem solving means the ability to formulate | |
problems, think creatively about solutions, and express a solution clearly | |
and accurately. As it turns out, the process of learning to program is an | |
excellent opportunity to practice problem-solving skills. That's why | |
this chapter is called, ``The way of the program.'' | |
On one level, you will be learning to program, a useful | |
skill by itself. On another level, you will use programming as a means to | |
an end. As we go along, that end will become clearer. | |
\section{The Python programming language} | |
\index{programming language} | |
\index{language!programming} | |
The programming language you will learn is Python. Python is | |
an example of a {\bf high-level language}; other high-level languages | |
you might have heard of are C, C++, Perl, and Java. | |
There are | |
also {\bf low-level languages}, sometimes referred to as ``machine | |
languages'' or ``assembly languages.'' Loosely speaking, computers | |
can only run programs written in low-level languages. So | |
programs written in a high-level language have to be processed before | |
they can run. This extra processing takes some time, which is a small | |
disadvantage of high-level languages. | |
\index{portability} | |
\index{high-level language} | |
\index{low-level language} | |
\index{language!high-level} | |
\index{language!low-level} | |
The advantages are enormous. First, it is much easier to program | |
in a high-level language. Programs written in a high-level language | |
take less time to write, they are shorter and easier to read, and they | |
are more likely to be correct. Second, high-level languages are {\bf | |
portable}, meaning that they can run on different kinds of computers | |
with few or no modifications. Low-level programs can run on only one | |
kind of computer and have to be rewritten to run on another. | |
Due to these advantages, almost all programs are written in high-level | |
languages. Low-level languages are used only for a few specialized | |
applications. | |
\index{compile} | |
\index{interpret} | |
Two kinds of programs process high-level languages into low-level | |
languages: {\bf interpreters} and {\bf compilers}. An interpreter | |
reads a high-level program and executes it, meaning that it does what | |
the program says. It processes the program a little at a time, | |
alternately reading lines and performing computations. | |
Figure~\ref{fig.interpret} shows the structure of an interpreter. | |
\index{source code} | |
\index{object code} | |
\index{executable} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.9]{figs/interpret.pdf}} | |
\caption{An interpreter processes the program a little at a time, | |
alternately reading lines and performing computations.} | |
\label{fig.interpret} | |
\end{figure} | |
A compiler reads the program and translates it completely before the | |
program starts running. In this context, the high-level program is | |
called the {\bf source code}, and the translated program is called the | |
{\bf object code} or the {\bf executable}. Once a program is | |
compiled, you can execute it repeatedly without further translation. | |
Figure~\ref{fig.compile} shows the structure of a compiler. | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.9]{figs/compile.pdf}} | |
\caption{A compiler translates source code into object code, which is | |
run by a hardware executor.} | |
\label{fig.compile} | |
\end{figure} | |
Python is considered an interpreted language because Python programs | |
are executed by an interpreter. There are two ways to use the | |
interpreter: {\bf interactive mode} and {\bf script mode}. In | |
interactive mode, you type Python programs and the interpreter displays | |
the result: | |
\index{interactive mode} | |
\index{script mode} | |
\begin{verbatim} | |
>>> 1 + 1 | |
2 | |
\end{verbatim} | |
% | |
The chevron, \verb">>>", is the | |
{\bf prompt} the interpreter uses to indicate that it is ready. If | |
you type {\tt 1 + 1}, the interpreter replies {\tt 2}. | |
\index{prompt} | |
Alternatively, you can store code in a file and use the interpreter to | |
execute the contents of the file, which is called a {\bf script}. By | |
convention, Python scripts have names that end with {\tt .py}. | |
\index{script} | |
To execute the script, you have to tell the interpreter the name of | |
the file. If you have a script named {\tt dinsdale.py} and you are | |
working in a UNIX command window, you type {\tt python | |
dinsdale.py}. In other development environments, the details of | |
executing scripts are different. You can find instructions for | |
your environment at the Python website \url{http://python.org}. | |
\index{testing!interactive mode} | |
Working in interactive mode is convenient for testing small pieces of | |
code because you can type and execute them immediately. But for | |
anything more than a few lines, you should save your code | |
as a script so you can modify and execute it in the future. | |
\section{What is a program?} | |
A {\bf program} is a sequence of instructions that specifies how to | |
perform a computation. The computation might be something | |
mathematical, such as solving a system of equations or finding the | |
roots of a polynomial, but it can also be a symbolic computation, such | |
as searching and replacing text in a document or (strangely enough) | |
compiling a program. | |
\index{program} | |
The details look different in different languages, but a few basic | |
instructions appear in just about every language: | |
\begin{description} | |
\item[input:] Get data from the keyboard, a file, or some | |
other device. | |
\item[output:] Display data on the screen or send data to a | |
file or other device. | |
\item[math:] Perform basic mathematical operations like addition and | |
multiplication. | |
\item[conditional execution:] Check for certain conditions and | |
execute the appropriate code. | |
\item[repetition:] Perform some action repeatedly, usually with | |
some variation. | |
\end{description} | |
Believe it or not, that's pretty much all there is to it. Every | |
program you've ever used, no matter how complicated, is made up of | |
instructions that look pretty much like these. So you can think of | |
programming as the process of breaking a large, complex task | |
into smaller and smaller subtasks until the subtasks are | |
simple enough to be performed with one of these basic instructions. | |
\index{algorithm} | |
That may be a little vague, but we will come back to this topic | |
when we talk about {\bf algorithms}. | |
\section{What is debugging?} | |
\index{debugging} | |
\index{bug} | |
Programming is error-prone. For whimsical reasons, programming errors | |
are called {\bf bugs} and the process of tracking them down is called | |
{\bf debugging}. | |
\index{debugging} | |
\index{bug} | |
Three kinds of errors can occur in a program: syntax errors, runtime | |
errors, and semantic errors. It is useful | |
to distinguish between them in order to track them down more quickly. | |
\subsection{Syntax errors} | |
\index{syntax error} | |
\index{error!syntax} | |
\index{error message} | |
Python can only execute a program if the syntax is | |
correct; otherwise, the interpreter displays an error message. | |
{\bf Syntax} refers to the structure of a program and the rules about | |
that structure. | |
For example, parentheses have to come in matching pairs, so | |
{\tt (1 + 2)} is legal, but {\tt 8)} is a {\bf syntax error}. | |
\index{syntax} | |
\index{parentheses!matching} | |
\index{syntax} | |
\index{cummings, e. e.} | |
In English, readers can tolerate most syntax errors, which is why we | |
can read the poetry of e. e. cummings without spewing error messages. | |
Python is not so forgiving. If there is a single syntax error | |
anywhere in your program, Python will display an error message and quit, | |
and you will not be able to run your program. During the first few | |
weeks of your programming career, you will probably spend a lot of | |
time tracking down syntax errors. As you gain experience, you will | |
make fewer errors and find them faster. | |
\subsection{Runtime errors} | |
\label{runtime} | |
The second type of error is a runtime error, so called because the | |
error does not appear until after the program has started running. | |
These errors are also called {\bf exceptions} because they usually | |
indicate that something exceptional (and bad) has happened. | |
\index{runtime error} | |
\index{error!runtime} | |
\index{exception} | |
\index{safe language} | |
\index{language!safe} | |
Runtime errors are rare in the simple programs you will see in the | |
first few chapters, so it might be a while before you encounter one. | |
\subsection{Semantic errors} | |
\index{semantics} | |
\index{semantic error} | |
\index{error!semantic} | |
\index{error message} | |
The third type of error is the {\bf semantic error}. If there is a | |
semantic error in your program, it will run successfully in the sense | |
that the computer will not generate any error messages, but it will | |
not do the right thing. It will do something else. Specifically, it | |
will do what you told it to do. | |
The problem is that the program you wrote is not the program you | |
wanted to write. The meaning of the program (its semantics) is wrong. | |
Identifying semantic errors can be tricky because it requires you to work | |
backward by looking at the output of the program and trying to figure | |
out what it is doing. | |
\subsection{Experimental debugging} | |
One of the most important skills you will acquire is debugging. | |
Although it can be frustrating, debugging is one of the most | |
intellectually rich, challenging, and interesting parts of | |
programming. | |
\index{experimental debugging} | |
\index{debugging!experimental} | |
In some ways, debugging is like detective work. You are confronted | |
with clues, and you have to infer the processes and events that led | |
to the results you see. | |
Debugging is also like an experimental science. Once you have an idea | |
about what is going wrong, you modify your program and try again. If | |
your hypothesis was correct, then you can predict the result of the | |
modification, and you take a step closer to a working program. If | |
your hypothesis was wrong, you have to come up with a new one. As | |
Sherlock Holmes pointed out, ``When you have eliminated the | |
impossible, whatever remains, however improbable, must be the truth.'' | |
(A. Conan Doyle, {\em The Sign of Four}) | |
\index{Holmes, Sherlock} | |
\index{Doyle, Arthur Conan} | |
For some people, programming and debugging are the same thing. That | |
is, programming is the process of gradually debugging a program until | |
it does what you want. The idea is that you should start with a | |
program that does {\em something} and make small modifications, | |
debugging them as you go, so that you always have a working program. | |
For example, Linux is an operating system that contains thousands of | |
lines of code, but it started out as a simple program Linus Torvalds | |
used to explore the Intel 80386 chip. According to Larry Greenfield, | |
``One of Linus's earlier projects was a program that would switch | |
between printing AAAA and BBBB. This later evolved to Linux.'' | |
({\em The Linux Users' Guide} Beta Version 1). | |
\index{Linux} | |
Later chapters will make more suggestions about debugging and other | |
programming practices. | |
\section{Formal and natural languages} | |
\index{formal language} | |
\index{natural language} | |
\index{language!formal} | |
\index{language!natural} | |
{\bf Natural languages} are the languages people speak, | |
such as English, Spanish, and French. They were not designed | |
by people (although people try to impose some order on them); | |
they evolved naturally. | |
{\bf Formal languages} are languages that are designed by people for | |
specific applications. For example, the notation that mathematicians | |
use is a formal language that is particularly good at denoting | |
relationships among numbers and symbols. Chemists use a formal | |
language to represent the chemical structure of molecules. And | |
most importantly: | |
\begin{quote} | |
{\bf Programming languages are formal languages that have been | |
designed to express computations.} | |
\end{quote} | |
Formal languages tend to have strict rules about syntax. For example, | |
$3 + 3 = 6$ is a syntactically correct mathematical statement, but | |
$3 + = 3 \mbox{\$} 6$ is not. | |
$H_2O$ is a syntactically correct | |
chemical formula, but $_2Zz$ is not. | |
Syntax rules come in two flavors, pertaining to {\bf tokens} and | |
structure. Tokens are the basic elements of the language, such as | |
words, numbers, and chemical elements. One of the problems with | |
$3 + = 3 \mbox{\$} 6$ is that \( \$ \) is not a legal token in mathematics | |
(at least as far as I know). Similarly, $_2Zz$ is not legal because | |
there is no element with the abbreviation $Zz$. | |
\index{token} | |
\index{structure} | |
The second type of syntax rule pertains to the structure of a | |
statement; that is, the way the tokens are arranged. The statement | |
$3 + = 3$ is illegal because even though $+$ and $=$ are | |
legal tokens, you can't have one right after the other. Similarly, | |
in a chemical formula the subscript comes after the element name, not | |
before. | |
\begin{exercise} | |
Write a well-structured English | |
sentence with invalid tokens in it. Then write another sentence | |
with all valid tokens but with invalid structure. | |
\end{exercise} | |
When you read a sentence in English or a statement in a formal | |
language, you have to figure out what the structure of the sentence is | |
(although in a natural language you do this subconsciously). This | |
process is called {\bf parsing}. | |
\index{parse} | |
For example, when you hear the sentence, ``The penny dropped,'' you | |
understand that ``the penny'' is the subject and ``dropped'' is the | |
predicate. Once you have parsed a sentence, you can figure out what it | |
means, or the semantics of the sentence. Assuming that you know | |
what a penny is and what it means to drop, you will understand the | |
general implication of this sentence. | |
Although formal and natural languages have many features in | |
common---tokens, structure, syntax, and semantics---there are some | |
differences: | |
\index{ambiguity} | |
\index{redundancy} | |
\index{literalness} | |
\begin{description} | |
\item[ambiguity:] Natural languages are full of ambiguity, which | |
people deal with by using contextual clues and other information. | |
Formal languages are designed to be nearly or completely unambiguous, | |
which means that any statement has exactly one meaning, | |
regardless of context. | |
\item[redundancy:] In order to make up for ambiguity and reduce | |
misunderstandings, natural languages employ lots of | |
redundancy. As a result, they are often verbose. Formal languages | |
are less redundant and more concise. | |
\item[literalness:] Natural languages are full of idiom and metaphor. | |
If I say, ``The penny dropped,'' there is probably no penny and | |
nothing dropping (this idiom means that someone realized something | |
after a period of confusion). Formal languages | |
mean exactly what they say. | |
\end{description} | |
People who grow up speaking a natural language---everyone---often have a | |
hard time adjusting to formal languages. In some ways, the difference | |
between formal and natural language is like the difference between | |
poetry and prose, but more so: | |
\index{poetry} | |
\index{prose} | |
\begin{description} | |
\item[Poetry:] Words are used for their sounds as well as for | |
their meaning, and the whole poem together creates an effect or | |
emotional response. Ambiguity is not only common but often | |
deliberate. | |
\item[Prose:] The literal meaning of words is more important, | |
and the structure contributes more meaning. Prose is more amenable to | |
analysis than poetry but still often ambiguous. | |
\item[Programs:] The meaning of a computer program is unambiguous | |
and literal, and can be understood entirely by analysis of the | |
tokens and structure. | |
\end{description} | |
Here are some suggestions for reading programs (and other formal | |
languages). First, remember that formal languages are much more dense | |
than natural languages, so it takes longer to read them. Also, the | |
structure is very important, so it is usually not a good idea to read | |
from top to bottom, left to right. Instead, learn to parse the | |
program in your head, identifying the tokens and interpreting the | |
structure. Finally, the details matter. Small errors in | |
spelling and punctuation, which you can get away | |
with in natural languages, can make a big difference in a formal | |
language. | |
\section{The first program} | |
\label{hello} | |
\index{Hello, World} | |
Traditionally, the first program you write in a new language | |
is called ``Hello, World!'' because all it does is display the | |
words ``Hello, World!''. In Python, it looks like this: | |
\begin{verbatim} | |
print 'Hello, World!' | |
\end{verbatim} | |
% | |
This is an example of a {\bf print statement}, which | |
doesn't actually print anything on paper. It displays a value on the | |
screen. In this case, the result is the words | |
\begin{verbatim} | |
Hello, World! | |
\end{verbatim} | |
% | |
The quotation marks in the program mark the beginning and end | |
of the text to be displayed; they don't appear in the result. | |
\index{quotation mark} | |
\index{print statement} | |
\index{statement!print} | |
In Python 3, the syntax for printing is slightly different: | |
\begin{verbatim} | |
print('Hello, World!') | |
\end{verbatim} | |
% | |
The parentheses indicate that {\tt print} is a function. We'll get | |
to functions in Chapter~\ref{funcchap}. | |
\index{function} \index{print function} \index{Python 3} | |
For the rest of this book, I'll use the print statement. If you | |
are using Python 3, you will have to translate. But other than | |
that, there are very few differences we have to worry about. | |
\section{Debugging} | |
\index{debugging} | |
It is a good idea to read this book in front of a computer so you can | |
try out the examples as you go. You can run most of the examples in | |
interactive mode, but if you put the code in a script, it is easier | |
to try out variations. | |
Whenever you are experimenting with a new feature, you should try | |
to make mistakes. For example, in the ``Hello, world!'' program, | |
what happens if you leave out one of the quotation marks? What | |
if you leave out both? What if you spell {\tt print} wrong? | |
\index{error message} | |
This kind of experiment helps you remember what you read; it also helps | |
with debugging, because you get to know what the error messages mean. | |
It is better to make mistakes now and on purpose than later | |
and accidentally. | |
Programming, and especially debugging, sometimes brings out strong | |
emotions. If you are struggling with a difficult bug, you might | |
feel angry, despondent or embarrassed. | |
There is evidence that people naturally respond to computers as if | |
they were people. When they work well, we think | |
of them as teammates, and when they are obstinate or rude, we | |
respond to them the same way we respond to rude, | |
obstinate people (Reeves and Nass, {\it The Media | |
Equation: How People Treat Computers, Television, and New Media | |
Like Real People and Places}). | |
\index{debugging!emotional response} | |
\index{emotional debugging} | |
Preparing for these reactions might help you deal with them. | |
One approach is to think of the computer as an employee with | |
certain strengths, like speed and precision, and | |
particular weaknesses, like lack of empathy and inability | |
to grasp the big picture. | |
Your job is to be a good manager: find ways to take advantage | |
of the strengths and mitigate the weaknesses. And find ways | |
to use your emotions to engage with the problem, | |
without letting your reactions interfere with your ability | |
to work effectively. | |
Learning to debug can be frustrating, but it is a valuable skill | |
that is useful for many activities beyond programming. At the | |
end of each chapter there is a debugging section, like this one, | |
with my thoughts about debugging. I hope they help! | |
\section{Glossary} | |
\begin{description} | |
\item[problem solving:] The process of formulating a problem, finding | |
a solution, and expressing the solution. | |
\index{problem solving} | |
\item[high-level language:] A programming language like Python that | |
is designed to be easy for humans to read and write. | |
\index{high-level language} | |
\item[low-level language:] A programming language that is designed | |
to be easy for a computer to execute; also called ``machine language'' or | |
``assembly language.'' | |
\index{low-level language} | |
\item[portability:] A property of a program that can run on more | |
than one kind of computer. | |
\index{portability} | |
\item[interpret:] To execute a program in a high-level language | |
by translating it one line at a time. | |
\index{interpret} | |
\item[compile:] To translate a program written in a high-level language | |
into a low-level language all at once, in preparation for later | |
execution. | |
\index{compile} | |
\item[source code:] A program in a high-level language before | |
being compiled. | |
\index{source code} | |
\item[object code:] The output of the compiler after it translates | |
the program. | |
\index{object code} | |
\item[executable:] Another name for object code that is ready | |
to be executed. | |
\index{executable} | |
\item[prompt:] Characters displayed by the interpreter to indicate | |
that it is ready to take input from the user. | |
\index{prompt} | |
\item[script:] A program stored in a file (usually one that will be | |
interpreted). | |
\index{script} | |
\item[interactive mode:] A way of using the Python interpreter by | |
typing commands and expressions at the prompt. | |
\index{interactive mode} | |
\item[script mode:] A way of using the Python interpreter to read | |
and execute statements in a script. | |
\index{script mode} | |
\item[program:] A set of instructions that specifies a computation. | |
\index{program} | |
\item[algorithm:] A general process for solving a category of | |
problems. | |
\index{algorithm} | |
\item[bug:] An error in a program. | |
\index{bug} | |
\item[debugging:] The process of finding and removing any of the | |
three kinds of programming errors. | |
\index{debugging} | |
\item[syntax:] The structure of a program. | |
\index{syntax} | |
\item[syntax error:] An error in a program that makes it impossible | |
to parse (and therefore impossible to interpret). | |
\index{syntax error} | |
\item[exception:] An error that is detected while the program is running. | |
\index{exception} | |
\item[semantics:] The meaning of a program. | |
\index{semantics} | |
\item[semantic error:] An error in a program that makes it do something | |
other than what the programmer intended. | |
\index{semantic error} | |
\item[natural language:] Any one of the languages that people speak that | |
evolved naturally. | |
\index{natural language} | |
\item[formal language:] Any one of the languages that people have designed | |
for specific purposes, such as representing mathematical ideas or | |
computer programs; all programming languages are formal languages. | |
\index{formal language} | |
\item[token:] One of the basic elements of the syntactic structure of | |
a program, analogous to a word in a natural language. | |
\index{token} | |
\item[parse:] To examine a program and analyze the syntactic structure. | |
\index{parse} | |
\item[print statement:] An instruction that causes the Python | |
interpreter to display a value on the screen. | |
\index{print statement} | |
\index{statement!print} | |
\end{description} | |
\section{Exercises} | |
\begin{exercise} | |
Use a web browser to go to the Python website \url{http://python.org}. | |
This page contains information about Python and links | |
to Python-related pages, and it gives you the ability to search | |
the Python documentation. | |
For example, if you enter {\tt print} in the search window, the | |
first link that appears is the documentation of the {\tt print} | |
statement. At this point, not all of it will make sense to you, | |
but it is good to know where it is. | |
\index{documentation} | |
\index{python.org} | |
\end{exercise} | |
\begin{exercise} | |
Start the Python interpreter and type {\tt help()} to start the online | |
help utility. Or you can type \verb"help('print')" to get information | |
about the {\tt print} statement. | |
If this example doesn't work, you | |
may need to install additional Python documentation or set an | |
environment variable; the details depend on your operating system and | |
version of Python. | |
\index{help utility} | |
\end{exercise} | |
\begin{exercise} | |
Start the Python interpreter and use it as a calculator. | |
Python's syntax for math operations is almost the same as | |
standard mathematical notation. For example, the symbols | |
{\tt +}, {\tt -} and {\tt /} denote addition, subtraction | |
and division, as you would expect. The symbol for | |
multiplication is {\tt *}. | |
If you run a 10 kilometer race in 43 minutes 30 seconds, what is your | |
average time per mile? What is your average speed in miles per hour? | |
(Hint: there are 1.61 kilometers in a mile). | |
\index{calculator} | |
\index{running pace} | |
\end{exercise} | |
\chapter{Variables, expressions and statements} | |
\section{Values and types} | |
\index{value} | |
\index{type} | |
\index{string} | |
A {\bf value} is one of the basic things a program works with, | |
like a letter or a | |
number. The values we have seen so far | |
are {\tt 1}, {\tt 2}, and | |
\verb"'Hello, World!'". | |
These values belong to different {\bf types}: | |
{\tt 2} is an integer, and \verb"'Hello, World!'" is a {\bf string}, | |
so-called because it contains a ``string'' of letters. | |
You (and the interpreter) can identify | |
strings because they are enclosed in quotation marks. | |
\index{quotation mark} | |
If you are not sure what type a value has, the interpreter can tell you. | |
\begin{verbatim} | |
>>> type('Hello, World!') | |
<type 'str'> | |
>>> type(17) | |
<type 'int'> | |
\end{verbatim} | |
% | |
Not surprisingly, strings belong to the type {\tt str} and | |
integers belong to the type {\tt int}. Less obviously, numbers | |
with a decimal point belong to a type called {\tt float}, | |
because these numbers are represented in a | |
format called {\bf floating-point}. | |
\index{type} | |
\index{string type} | |
\index{type!str} | |
\index{int type} | |
\index{type!int} | |
\index{float type} | |
\index{type!float} | |
\begin{verbatim} | |
>>> type(3.2) | |
<type 'float'> | |
\end{verbatim} | |
% | |
What about values like \verb"'17'" and \verb"'3.2'"? | |
They look like numbers, but they are in quotation marks like | |
strings. | |
\index{quotation mark} | |
\begin{verbatim} | |
>>> type('17') | |
<type 'str'> | |
>>> type('3.2') | |
<type 'str'> | |
\end{verbatim} | |
% | |
They're strings. | |
When you type a large integer, you might be tempted to use commas | |
between groups of three digits, as in {\tt 1,000,000}. This is not a | |
legal integer in Python, but it is legal: | |
\begin{verbatim} | |
>>> 1,000,000 | |
(1, 0, 0) | |
\end{verbatim} | |
% | |
Well, that's not what we expected at all! Python interprets {\tt | |
1,000,000} as a comma-separated sequence of integers. | |
This is the first example we have seen of a semantic error: the code | |
runs without producing an error message, but it doesn't do the | |
``right'' thing. | |
\index{semantic error} | |
\index{error!semantic} | |
\index{error message} | |
\section{Variables} | |
\label{variables} | |
\index{variable} | |
\index{assignment statement} | |
\index{statement!assignment} | |
One of the most powerful features of a programming language is the | |
ability to manipulate {\bf variables}. A variable is a name that | |
refers to a value. | |
An {\bf assignment statement} creates new variables and gives | |
them values: | |
\begin{verbatim} | |
>>> message = 'And now for something completely different' | |
>>> n = 17 | |
>>> pi = 3.1415926535897932 | |
\end{verbatim} | |
% | |
This example makes three assignments. The first assigns a string | |
to a new variable named {\tt message}; | |
the second gives the integer {\tt 17} to {\tt n}; the third | |
assigns the (approximate) value of $\pi$ to {\tt pi}. | |
\index{state diagram} | |
\index{diagram!state} | |
A common way to represent variables on paper is to write the name with | |
an arrow pointing to the variable's value. This kind of figure is | |
called a {\bf state diagram} because it shows what state each of the | |
variables is in (think of it as the variable's state of mind). | |
Figure~\ref{fig.state2} shows the result of the previous example. | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/state2.pdf}} | |
\caption{State diagram.} | |
\label{fig.state2} | |
\end{figure} | |
The type of a variable is the type of the value it refers to. | |
\begin{verbatim} | |
>>> type(message) | |
<type 'str'> | |
>>> type(n) | |
<type 'int'> | |
>>> type(pi) | |
<type 'float'> | |
\end{verbatim} | |
\section{Variable names and keywords} | |
\index{keyword} | |
Programmers generally choose names for their variables that | |
are meaningful---they document what the variable is used for. | |
Variable names can be arbitrarily long. They can contain | |
both letters and numbers, but they have to begin with a letter. | |
It is legal to use uppercase letters, but it is a good idea | |
to begin variable names with a lowercase letter (you'll | |
see why later). | |
The underscore character, \verb"_", can appear in a name. | |
It is often used in names with multiple words, such as | |
\verb"my_name" or \verb"airspeed_of_unladen_swallow". | |
\index{underscore character} | |
If you give a variable an illegal name, you get a syntax error: | |
\begin{verbatim} | |
>>> 76trombones = 'big parade' | |
SyntaxError: invalid syntax | |
>>> more@ = 1000000 | |
SyntaxError: invalid syntax | |
>>> class = 'Advanced Theoretical Zymurgy' | |
SyntaxError: invalid syntax | |
\end{verbatim} | |
% | |
{\tt 76trombones} is illegal because it does not begin with a letter. | |
{\tt more@} is illegal because it contains an illegal character, {\tt | |
@}. But what's wrong with {\tt class}? | |
It turns out that {\tt class} is one of Python's {\bf keywords}. The | |
interpreter uses keywords to recognize the structure of the program, | |
and they cannot be used as variable names. | |
\index{keyword} | |
Python 2 has 31 keywords: | |
\begin{verbatim} | |
and del from not while | |
as elif global or with | |
assert else if pass yield | |
break except import print | |
class exec in raise | |
continue finally is return | |
def for lambda try | |
\end{verbatim} | |
% | |
In Python 3, {\tt exec} is no longer a keyword, but {\tt nonlocal} is. | |
You might want to keep this list handy. If the interpreter complains | |
about one of your variable names and you don't know why, see if it | |
is on this list. | |
\section{Operators and operands} | |
\index{operator, arithmetic} | |
\index{arithmetic operator} | |
\index{operand} | |
\index{expression} | |
{\bf Operators} are special symbols that represent computations like | |
addition and multiplication. The values the operator is applied to | |
are called {\bf operands}. | |
The operators {\tt +}, {\tt -}, {\tt *}, {\tt /} and {\tt **} | |
perform addition, subtraction, multiplication, division and | |
exponentiation, as in the following examples: | |
\begin{verbatim} | |
20+32 hour-1 hour*60+minute minute/60 5**2 (5+9)*(15-7) | |
\end{verbatim} | |
% | |
In some other languages, \verb"^" is used for exponentiation, but | |
in Python it is a bitwise operator called XOR. I won't cover | |
bitwise operators in this book, but you can read about | |
them at \url{http://wiki.python.org/moin/BitwiseOperators}. | |
\index{bitwise operator} | |
\index{operator!bitwise} | |
In Python 2, the division operator might not do what you expect: | |
\begin{verbatim} | |
>>> minute = 59 | |
>>> minute/60 | |
0 | |
\end{verbatim} | |
% | |
The value of {\tt minute} is 59, and in conventional arithmetic 59 | |
divided by 60 is 0.98333, not 0. The reason for the discrepancy is | |
that Python is performing {\bf floor division}. | |
When both of the operands are integers, the result is also an | |
integer; floor division chops off the fraction | |
part, so in this example it rounds down to zero. | |
In Python 3, the result of this division is a {\tt float}. The new operator | |
{\tt //} performs floor division. | |
\index{Python 3} | |
\index{floor division} | |
\index{floating-point division} | |
\index{division!floor} | |
\index{division!floating-point} | |
If either of the operands is a floating-point number, Python performs | |
floating-point division, and the result is a {\tt float}: | |
\begin{verbatim} | |
>>> minute/60.0 | |
0.98333333333333328 | |
\end{verbatim} | |
\section{Expressions and statements} | |
An {\bf expression} is a combination of values, variables, and operators. | |
A value all by itself is considered an expression, and so is | |
a variable, so the following are all legal expressions | |
(assuming that the variable {\tt x} has been assigned a value): | |
\index{expression} | |
\index{evaluate} | |
\begin{verbatim} | |
17 | |
x | |
x + 17 | |
\end{verbatim} | |
% | |
A {\bf statement} is a unit of code that the Python interpreter can | |
execute. We have seen two kinds of statement: print and | |
assignment. | |
Technically an expression is also a statement, but it is probably | |
simpler to think of them as different things. The important difference | |
is that an expression has a value; a statement does not. | |
\section{Interactive mode and script mode} | |
One of the benefits of working with an interpreted language is that | |
you can test bits of code in interactive mode before you put them | |
in a script. But there are differences between interactive mode | |
and script mode that can be confusing. | |
\index{interactive mode} | |
\index{script mode} | |
For example, if you are using Python as a calculator, you might type | |
\begin{verbatim} | |
>>> miles = 26.2 | |
>>> miles * 1.61 | |
42.182 | |
\end{verbatim} | |
The first line assigns a value to {\tt miles}, but it has no visible | |
effect. The second line is an expression, so the interpreter | |
evaluates it and displays the result. So we learn that a marathon is | |
about 42 kilometers. | |
But if you type the same code into a script and run it, you get no | |
output at all. In script mode an expression, all by itself, has no | |
visible effect. Python actually evaluates the expression, but it doesn't | |
display the value unless you tell it to: | |
\begin{verbatim} | |
miles = 26.2 | |
print miles * 1.61 | |
\end{verbatim} | |
This behavior can be confusing at first. | |
A script usually contains a sequence of statements. If there | |
is more than one statement, the results appear one at a time | |
as the statements execute. | |
For example, the script | |
\begin{verbatim} | |
print 1 | |
x = 2 | |
print x | |
\end{verbatim} | |
% | |
produces the output | |
\begin{verbatim} | |
1 | |
2 | |
\end{verbatim} | |
% | |
The assignment statement produces no output. | |
\begin{exercise} | |
Type the following statements in the Python interpreter to see | |
what they do: | |
\begin{verbatim} | |
5 | |
x = 5 | |
x + 1 | |
\end{verbatim} | |
% | |
Now put the same statements into a script and run it. What | |
is the output? Modify the script by transforming each | |
expression into a print statement and then run it again. | |
\end{exercise} | |
\section{Order of operations} | |
\index{order of operations} | |
\index{rules of precedence} | |
\index{PEMDAS} | |
When more than one operator appears in an expression, the order of | |
evaluation depends on the {\bf rules of precedence}. For | |
mathematical operators, Python follows mathematical convention. | |
The acronym {\bf PEMDAS} is a useful way to | |
remember the rules: | |
\index{parentheses!overriding precedence} | |
\begin{itemize} | |
\item {\bf P}arentheses have the highest precedence and can be used | |
to force an expression to evaluate in the order you want. Since | |
expressions in parentheses are evaluated first, {\tt 2 * (3-1)} is 4, | |
and {\tt (1+1)**(5-2)} is 8. You can also use parentheses to make an | |
expression easier to read, as in {\tt (minute * 100) / 60}, even | |
if it doesn't change the result. | |
\item {\bf E}xponentiation has the next highest precedence, so | |
{\tt 2**1+1} is 3, not 4, and {\tt 3*1**3} is 3, not 27. | |
\item {\bf M}ultiplication and {\bf D}ivision have the same precedence, | |
which is higher than {\bf A}ddition and {\bf S}ubtraction, which also | |
have the same precedence. So {\tt 2*3-1} is 5, not 4, and | |
{\tt 6+4/2} is 8, not 5. | |
\item Operators with the same precedence are evaluated from left to | |
right (except exponentiation). So in the expression {\tt degrees / | |
2 * pi}, the division happens first and the result is multiplied | |
by {\tt pi}. To divide by $2 \pi$, you can use parentheses or write | |
{\tt degrees / 2 / pi}. | |
\end{itemize} | |
I don't work very hard to remember rules of precedence for other | |
operators. If I can't tell by looking at the expression, I use | |
parentheses to make it obvious. | |
\section{String operations} | |
\index{string!operation} | |
\index{operator!string} | |
In general, you can't perform mathematical operations on strings, even | |
if the strings look like numbers, so the following are illegal: | |
\begin{verbatim} | |
'2'-'1' 'eggs'/'easy' 'third'*'a charm' | |
\end{verbatim} | |
% | |
The {\tt +} operator works with strings, but it | |
might not do what you expect: it performs | |
{\bf concatenation}, which means joining the strings by | |
linking them end-to-end. For example: | |
\index{concatenation} | |
\begin{verbatim} | |
first = 'throat' | |
second = 'warbler' | |
print first + second | |
\end{verbatim} | |
% | |
The output of this program is {\tt throatwarbler}. | |
The {\tt *} operator also works on strings; it performs repetition. | |
For example, \verb"'Spam'*3" is \verb"'SpamSpamSpam'". If one of the operands | |
is a string, the other has to be an integer. | |
This use of {\tt +} and {\tt *} makes sense by | |
analogy with addition and multiplication. Just as {\tt 4*3} is | |
equivalent to {\tt 4+4+4}, we expect \verb"'Spam'*3" to be the same as | |
\verb"'Spam'+'Spam'+'Spam'", and it is. On the other hand, there is a | |
significant way in which string concatenation and repetition are | |
different from integer addition and multiplication. | |
Can you think of a property that addition has | |
that string concatenation does not? | |
\index{commutativity} | |
\section{Comments} | |
\index{comment} | |
As programs get bigger and more complicated, they get more difficult | |
to read. Formal languages are dense, and it is often difficult to | |
look at a piece of code and figure out what it is doing, or why. | |
For this reason, it is a good idea to add notes to your programs to explain | |
in natural language what the program is doing. These notes are called | |
{\bf comments}, and they start with the \verb"#" symbol: | |
\begin{verbatim} | |
# compute the percentage of the hour that has elapsed | |
percentage = (minute * 100) / 60 | |
\end{verbatim} | |
% | |
In this case, the comment appears on a line by itself. You can also put | |
comments at the end of a line: | |
\begin{verbatim} | |
percentage = (minute * 100) / 60 # percentage of an hour | |
\end{verbatim} | |
% | |
Everything from the {\tt \#} to the end of the line is ignored---it | |
has no effect on the program. | |
Comments are most useful when they document non-obvious features of | |
the code. It is reasonable to assume that the reader can figure out | |
{\em what} the code does; it is much more useful to explain {\em why}. | |
This comment is redundant with the code and useless: | |
\begin{verbatim} | |
v = 5 # assign 5 to v | |
\end{verbatim} | |
% | |
This comment contains useful information that is not in the code: | |
\begin{verbatim} | |
v = 5 # velocity in meters/second. | |
\end{verbatim} | |
% | |
Good variable names can reduce the need for comments, but | |
long names can make complex expressions hard to read, so there is | |
a tradeoff. | |
\section{Debugging} | |
\index{debugging} | |
At this point the syntax error you are most likely to make is | |
an illegal variable name, like {\tt class} and {\tt yield}, which | |
are keywords, or \verb"odd~job" and \verb"US$", which contain | |
illegal characters. | |
\index{syntax error} | |
\index{error!syntax} | |
If you put a space in a variable name, Python thinks it is two | |
operands without an operator: | |
\begin{verbatim} | |
>>> bad name = 5 | |
SyntaxError: invalid syntax | |
\end{verbatim} | |
% | |
For syntax errors, the error messages don't help much. | |
The most common messages are {\tt SyntaxError: invalid syntax} and | |
{\tt SyntaxError: invalid token}, neither of which is very informative. | |
\index{error message} | |
\index{use before def} | |
\index{exception} | |
\index{runtime error} | |
\index{error!runtime} | |
The runtime error you are most likely to make is a ``use before | |
def;'' that is, trying to use a variable before you have assigned | |
a value. This can happen if you spell a variable name wrong: | |
\begin{verbatim} | |
>>> principal = 327.68 | |
>>> interest = principle * rate | |
NameError: name 'principle' is not defined | |
\end{verbatim} | |
% | |
Variables names are case sensitive, so {\tt LaTeX} is not the | |
same as {\tt latex}. | |
\index{case-sensitivity, variable names} | |
\index{semantic error} | |
\index{error!semantic} | |
At this point the most likely cause of a semantic error is | |
the order of operations. For example, to evaluate | |
$\frac{1}{2 \pi}$, | |
you might be tempted to write | |
\begin{verbatim} | |
>>> 1.0 / 2.0 * pi | |
\end{verbatim} | |
% | |
But the division happens first, so you would get $\pi / 2$, which | |
is not the same thing! There is no way for Python | |
to know what you meant to write, so in this case you don't | |
get an error message; you just get the wrong answer. | |
\index{order of operations} | |
\section{Glossary} | |
\begin{description} | |
\item[value:] One of the basic units of data, like a number or string, | |
that a program manipulates. | |
\index{value} | |
\item[type:] A category of values. The types we have seen so far | |
are integers (type {\tt int}), floating-point numbers (type {\tt | |
float}), and strings (type {\tt str}). | |
\index{type} | |
\item[integer:] A type that represents whole numbers. | |
\index{integer} | |
\item[floating-point:] A type that represents numbers with fractional | |
parts. | |
\index{floating-point} | |
\item[string:] A type that represents sequences of characters. | |
\index{string} | |
\item[variable:] A name that refers to a value. | |
\index{variable} | |
\item[statement:] A section of code that represents a command or action. So | |
far, the statements we have seen are assignments and print statements. | |
\index{statement} | |
\item[assignment:] A statement that assigns a value to a variable. | |
\index{assignment} | |
\item[state diagram:] A graphical representation of a set of variables and the | |
values they refer to. | |
\index{state diagram} | |
\item[keyword:] A reserved word that is used by the compiler to parse a | |
program; you cannot use keywords like {\tt if}, {\tt def}, and {\tt while} as | |
variable names. | |
\index{keyword} | |
\item[operator:] A special symbol that represents a simple computation like | |
addition, multiplication, or string concatenation. | |
\index{operator} | |
\item[operand:] One of the values on which an operator operates. | |
\index{operand} | |
\item[floor division:] The operation that divides two numbers and chops off | |
the fraction part. | |
\index{floor division} | |
\item[expression:] A combination of variables, operators, and values that | |
represents a single result value. | |
\index{expression} | |
\item[evaluate:] To simplify an expression by performing the operations | |
in order to yield a single value. | |
\item[rules of precedence:] The set of rules governing the order in which | |
expressions involving multiple operators and operands are evaluated. | |
\index{rules of precedence} | |
\index{precedence} | |
\item[concatenate:] To join two operands end-to-end. | |
\index{concatenation} | |
\item[comment:] Information in a program that is meant for other | |
programmers (or anyone reading the source code) and has no effect on the | |
execution of the program. | |
\index{comment} | |
\end{description} | |
\section{Exercises} | |
\begin{exercise} | |
Assume that we execute the following assignment statements: | |
\begin{verbatim} | |
width = 17 | |
height = 12.0 | |
delimiter = '.' | |
\end{verbatim} | |
For each of the following expressions, write the value of the | |
expression and the type (of the value of the expression). | |
\begin{enumerate} | |
\item {\tt width/2} | |
\item {\tt width/2.0} | |
\item {\tt height/3} | |
\item {\tt 1 + 2 * 5} | |
\item {\tt delimiter * 5} | |
\end{enumerate} | |
Use the Python interpreter to check your answers. | |
\end{exercise} | |
\begin{exercise} | |
Practice using the Python interpreter as a calculator: | |
\index{calculator} | |
\begin{enumerate} | |
\item The volume of a sphere with radius $r$ is $\frac{4}{3} \pi r^3$. | |
What is the volume of a sphere with radius 5? Hint: 392.7 is wrong! | |
\item Suppose the cover price of a book is \$24.95, but bookstores get a | |
40\% discount. Shipping costs \$3 for the first copy and 75 cents | |
for each additional copy. What is the total wholesale cost for | |
60 copies? | |
\item If I leave my house at 6:52 am and run 1 mile at an easy pace | |
(8:15 per mile), then 3 miles at tempo (7:12 per mile) and 1 mile at | |
easy pace again, what time do I get home for breakfast? | |
\index{running pace} | |
\end{enumerate} | |
\end{exercise} | |
\chapter{Functions} | |
\label{funcchap} | |
\section{Function calls} | |
\label{functionchap} | |
\index{function call} | |
In the context of programming, a {\bf function} is a named sequence of | |
statements that performs a computation. When you define a function, | |
you specify the name and the sequence of statements. Later, you can | |
``call'' the function by name. | |
We have already seen one example of a {\bf function call}: | |
\begin{verbatim} | |
>>> type(32) | |
<type 'int'> | |
\end{verbatim} | |
% | |
The name of the function is {\tt type}. The expression in parentheses | |
is called the {\bf argument} of the function. The result, for this | |
function, is the type of the argument. | |
\index{parentheses!argument in} | |
It is common to say that a function ``takes'' an argument and ``returns'' | |
a result. The result is called the {\bf return value}. | |
\index{argument} | |
\index{return value} | |
\section{Type conversion functions} | |
\index{conversion!type} | |
\index{type conversion} | |
% from Elkner: | |
% comment on whether these things are _really_ functions? | |
% use max as an example of a built-in? | |
% my reply: | |
% they are on the list of ``built-in functions'' so I am | |
% willing to call them functions. | |
Python provides built-in functions that convert values | |
from one type to another. The {\tt int} function takes any value and | |
converts it to an integer, if it can, or complains otherwise: | |
\index{int function} | |
\index{function!int} | |
\begin{verbatim} | |
>>> int('32') | |
32 | |
>>> int('Hello') | |
ValueError: invalid literal for int(): Hello | |
\end{verbatim} | |
% | |
{\tt int} can convert floating-point values to integers, but it | |
doesn't round off; it chops off the fraction part: | |
\begin{verbatim} | |
>>> int(3.99999) | |
3 | |
>>> int(-2.3) | |
-2 | |
\end{verbatim} | |
% | |
{\tt float} converts integers and strings to floating-point | |
numbers: | |
\index{float function} | |
\index{function!float} | |
\begin{verbatim} | |
>>> float(32) | |
32.0 | |
>>> float('3.14159') | |
3.14159 | |
\end{verbatim} | |
% | |
Finally, {\tt str} converts its argument to a string: | |
\index{str function} | |
\index{function!str} | |
\begin{verbatim} | |
>>> str(32) | |
'32' | |
>>> str(3.14159) | |
'3.14159' | |
\end{verbatim} | |
% | |
\section{Math functions} | |
\index{math function} | |
\index{function, math} | |
Python has a math module that provides most of the familiar | |
mathematical functions. A {\bf module} is a file that contains a | |
collection of related functions. | |
\index{module} | |
\index{module object} | |
Before we can use the module, we have to import it: | |
\begin{verbatim} | |
>>> import math | |
\end{verbatim} | |
% | |
This statement creates a {\bf module object} named math. If | |
you print the module object, you get some information about it: | |
\begin{verbatim} | |
>>> print math | |
<module 'math' (built-in)> | |
\end{verbatim} | |
% | |
The module object contains the functions and variables defined in the | |
module. To access one of the functions, you have to specify the name | |
of the module and the name of the function, separated by a dot (also | |
known as a period). This format is called {\bf dot notation}. | |
\index{dot notation} | |
\begin{verbatim} | |
>>> ratio = signal_power / noise_power | |
>>> decibels = 10 * math.log10(ratio) | |
>>> radians = 0.7 | |
>>> height = math.sin(radians) | |
\end{verbatim} | |
% | |
The first example uses \verb"log10" to compute | |
a signal-to-noise ratio in decibels (assuming that \verb"signal_power" and | |
\verb"noise_power" are defined). The math module also provides {\tt log}, | |
which computes logarithms base {\tt e}. | |
\index{log function} | |
\index{function!log} | |
\index{sine function} | |
\index{radian} | |
\index{trigonometric function} | |
\index{function, trigonometric} | |
The second example finds the sine of {\tt radians}. The name of the | |
variable is a hint that {\tt sin} and the other trigonometric | |
functions ({\tt cos}, {\tt tan}, etc.) take arguments in radians. To | |
convert from degrees to radians, divide by 360 and multiply by | |
$2 \pi$: | |
\begin{verbatim} | |
>>> degrees = 45 | |
>>> radians = degrees / 360.0 * 2 * math.pi | |
>>> math.sin(radians) | |
0.707106781187 | |
\end{verbatim} | |
% | |
The expression {\tt math.pi} gets the variable {\tt pi} from the math | |
module. The value of this variable is an approximation | |
of $\pi$, accurate to about 15 digits. | |
\index{pi} | |
If you know | |
your trigonometry, you can check the previous result by comparing it to | |
the square root of two divided by two: | |
\index{sqrt function} | |
\index{function!sqrt} | |
\begin{verbatim} | |
>>> math.sqrt(2) / 2.0 | |
0.707106781187 | |
\end{verbatim} | |
% | |
\section{Composition} | |
\index{composition} | |
So far, we have looked at the elements of a program---variables, | |
expressions, and statements---in isolation, without talking about how to | |
combine them. | |
One of the most useful features of programming languages is their | |
ability to take small building blocks and {\bf compose} them. For | |
example, the argument of a function can be any kind of expression, | |
including arithmetic operators: | |
\begin{verbatim} | |
x = math.sin(degrees / 360.0 * 2 * math.pi) | |
\end{verbatim} | |
% | |
And even function calls: | |
\begin{verbatim} | |
x = math.exp(math.log(x+1)) | |
\end{verbatim} | |
% | |
Almost anywhere you can put a value, you can put an arbitrary | |
expression, with one exception: the left side of an assignment | |
statement has to be a variable name. Any other expression on the left | |
side is a syntax error (we will see exceptions to this rule | |
later). | |
\begin{verbatim} | |
>>> minutes = hours * 60 # right | |
>>> hours * 60 = minutes # wrong! | |
SyntaxError: can't assign to operator | |
\end{verbatim} | |
% | |
\index{SyntaxError} | |
\index{exception!SyntaxError} | |
\section{Adding new functions} | |
So far, we have only been using the functions that come with Python, | |
but it is also possible to add new functions. | |
A {\bf function definition} specifies the name of a new function and | |
the sequence of statements that execute when the function is called. | |
\index{function} | |
\index{function definition} | |
\index{definition!function} | |
Here is an example: | |
\begin{verbatim} | |
def print_lyrics(): | |
print "I'm a lumberjack, and I'm okay." | |
print "I sleep all night and I work all day." | |
\end{verbatim} | |
% | |
{\tt def} is a keyword that indicates that this is a function | |
definition. The name of the function is \verb"print_lyrics". The | |
rules for function names are the same as for variable names: letters, | |
numbers and some punctuation marks are legal, but the first character | |
can't be a number. You can't use a keyword as the name of a function, | |
and you should avoid having a variable and a function with the same | |
name. | |
\index{def keyword} | |
\index{keyword!def} | |
\index{argument} | |
The empty parentheses after the name indicate that this function | |
doesn't take any arguments. | |
\index{parentheses!empty} | |
\index{header} | |
\index{body} | |
\index{indentation} | |
\index{colon} | |
The first line of the function definition is called the {\bf header}; | |
the rest is called the {\bf body}. The header has to end with a colon | |
and the body has to be indented. By convention, the indentation is | |
always four spaces (see Section~\ref{editor}). The body can contain | |
any number of statements. | |
The strings in the print statements are enclosed in double | |
quotes. Single quotes and double quotes do the same thing; | |
most people use single quotes except in cases like this where | |
a single quote (which is also an apostrophe) appears in the string. | |
\index{ellipses} | |
If you type a function definition in interactive mode, the interpreter | |
prints ellipses ({\em ...}) to let you know that the definition | |
isn't complete: | |
\begin{verbatim} | |
>>> def print_lyrics(): | |
... print "I'm a lumberjack, and I'm okay." | |
... print "I sleep all night and I work all day." | |
... | |
\end{verbatim} | |
% | |
To end the function, you have to enter an empty line (this is | |
not necessary in a script). | |
Defining a function creates a variable with the same name. | |
\begin{verbatim} | |
>>> print print_lyrics | |
<function print_lyrics at 0xb7e99e9c> | |
>>> type(print_lyrics) | |
<type 'function'> | |
\end{verbatim} | |
% | |
The value of \verb"print_lyrics" is a {\bf function object}, which | |
has type \verb"'function'". | |
\index{function object} | |
\index{object!function} | |
The syntax for calling the new function is the same as | |
for built-in functions: | |
\begin{verbatim} | |
>>> print_lyrics() | |
I'm a lumberjack, and I'm okay. | |
I sleep all night and I work all day. | |
\end{verbatim} | |
% | |
Once you have defined a function, you can use it inside another | |
function. For example, to repeat the previous refrain, we could write | |
a function called \verb"repeat_lyrics": | |
\begin{verbatim} | |
def repeat_lyrics(): | |
print_lyrics() | |
print_lyrics() | |
\end{verbatim} | |
% | |
And then call \verb"repeat_lyrics": | |
\begin{verbatim} | |
>>> repeat_lyrics() | |
I'm a lumberjack, and I'm okay. | |
I sleep all night and I work all day. | |
I'm a lumberjack, and I'm okay. | |
I sleep all night and I work all day. | |
\end{verbatim} | |
% | |
But that's not really how the song goes. | |
\section{Definitions and uses} | |
\index{function definition} | |
Pulling together the code fragments from the previous section, the | |
whole program looks like this: | |
\begin{verbatim} | |
def print_lyrics(): | |
print "I'm a lumberjack, and I'm okay." | |
print "I sleep all night and I work all day." | |
def repeat_lyrics(): | |
print_lyrics() | |
print_lyrics() | |
repeat_lyrics() | |
\end{verbatim} | |
% | |
This program contains two function definitions: \verb"print_lyrics" and | |
\verb"repeat_lyrics". Function definitions get executed just like other | |
statements, but the effect is to create function objects. The statements | |
inside the function do not get executed until the function is called, and | |
the function definition generates no output. | |
\index{use before def} | |
As you might expect, you have to create a function before you can | |
execute it. In other words, the function definition has to be | |
executed before the first time it is called. | |
\begin{exercise} | |
Move the last line of this program | |
to the top, so the function call appears before the definitions. Run | |
the program and see what error | |
message you get. | |
\end{exercise} | |
\begin{exercise} | |
Move the function call back to the bottom | |
and move the definition of \verb"print_lyrics" after the definition of | |
\verb"repeat_lyrics". What happens when you run this program? | |
\end{exercise} | |
\section{Flow of execution} | |
\index{flow of execution} | |
In order to ensure that a function is defined before its first use, | |
you have to know the order in which statements are executed, which is | |
called the {\bf flow of execution}. | |
Execution always begins at the first statement of the program. | |
Statements are executed one at a time, in order from top to bottom. | |
Function definitions do not alter the flow of execution of the | |
program, but remember that statements inside the function are not | |
executed until the function is called. | |
A function call is like a detour in the flow of execution. Instead of | |
going to the next statement, the flow jumps to the body of | |
the function, executes all the statements there, and then comes back | |
to pick up where it left off. | |
That sounds simple enough, until you remember that one function can | |
call another. While in the middle of one function, the program might | |
have to execute the statements in another function. But while | |
executing that new function, the program might have to execute yet | |
another function! | |
Fortunately, Python is good at keeping track of where it is, so each | |
time a function completes, the program picks up where it left off in | |
the function that called it. When it gets to the end of the program, | |
it terminates. | |
What's the moral of this sordid tale? When you read a program, you | |
don't always want to read from top to bottom. Sometimes it makes | |
more sense if you follow the flow of execution. | |
\section{Parameters and arguments} | |
\label{parameters} | |
\index{parameter} | |
\index{function parameter} | |
\index{argument} | |
\index{function argument} | |
Some of the built-in functions we have seen require arguments. For | |
example, when you call {\tt math.sin} you pass a number | |
as an argument. Some functions take more than one argument: | |
{\tt math.pow} takes two, the base and the exponent. | |
Inside the function, the arguments are assigned to | |
variables called {\bf parameters}. Here is an example of a | |
user-defined function that takes an argument: | |
\index{parentheses!parameters in} | |
\begin{verbatim} | |
def print_twice(bruce): | |
print bruce | |
print bruce | |
\end{verbatim} | |
% | |
This function assigns the argument to a parameter | |
named {\tt bruce}. When the function is called, it prints the value of | |
the parameter (whatever it is) twice. | |
This function works with any value that can be printed. | |
\begin{verbatim} | |
>>> print_twice('Spam') | |
Spam | |
Spam | |
>>> print_twice(17) | |
17 | |
17 | |
>>> print_twice(math.pi) | |
3.14159265359 | |
3.14159265359 | |
\end{verbatim} | |
% | |
The same rules of composition that apply to built-in functions also | |
apply to user-defined functions, so we can use any kind of expression | |
as an argument for \verb"print_twice": | |
\index{composition} | |
\begin{verbatim} | |
>>> print_twice('Spam '*4) | |
Spam Spam Spam Spam | |
Spam Spam Spam Spam | |
>>> print_twice(math.cos(math.pi)) | |
-1.0 | |
-1.0 | |
\end{verbatim} | |
% | |
The argument is evaluated before the function is called, so | |
in the examples the expressions \verb"'Spam '*4" and | |
{\tt math.cos(math.pi)} are only evaluated once. | |
\index{argument} | |
You can also use a variable as an argument: | |
\begin{verbatim} | |
>>> michael = 'Eric, the half a bee.' | |
>>> print_twice(michael) | |
Eric, the half a bee. | |
Eric, the half a bee. | |
\end{verbatim} | |
% | |
The name of the variable we pass as an argument ({\tt michael}) has | |
nothing to do with the name of the parameter ({\tt bruce}). It | |
doesn't matter what the value was called back home (in the caller); | |
here in \verb"print_twice", we call everybody {\tt bruce}. | |
\section{Variables and parameters are local} | |
\index{local variable} | |
\index{variable!local} | |
When you create a variable inside a function, it is {\bf local}, | |
which means that it only | |
exists inside the function. For example: | |
\index{parentheses!parameters in} | |
\begin{verbatim} | |
def cat_twice(part1, part2): | |
cat = part1 + part2 | |
print_twice(cat) | |
\end{verbatim} | |
% | |
This function takes two arguments, concatenates them, and prints | |
the result twice. Here is an example that uses it: | |
\index{concatenation} | |
\begin{verbatim} | |
>>> line1 = 'Bing tiddle ' | |
>>> line2 = 'tiddle bang.' | |
>>> cat_twice(line1, line2) | |
Bing tiddle tiddle bang. | |
Bing tiddle tiddle bang. | |
\end{verbatim} | |
% | |
When \verb"cat_twice" terminates, the variable {\tt cat} | |
is destroyed. If we try to print it, we get an exception: | |
\index{NameError} | |
\index{exception!NameError} | |
\begin{verbatim} | |
>>> print cat | |
NameError: name 'cat' is not defined | |
\end{verbatim} | |
% | |
Parameters are also local. | |
For example, outside \verb"print_twice", there is no | |
such thing as {\tt bruce}. | |
\index{parameter} | |
\section{Stack diagrams} | |
\label{stackdiagram} | |
\index{stack diagram} | |
\index{function frame} | |
\index{frame} | |
To keep track of which variables can be used where, it is sometimes | |
useful to draw a {\bf stack diagram}. Like state diagrams, stack | |
diagrams show the value of each variable, but they also show the | |
function each variable belongs to. | |
\index{stack diagram} | |
\index{diagram!stack} | |
Each function is represented by a {\bf frame}. A frame is a box | |
with the name of a function | |
beside it and the parameters and variables of the function inside it. | |
The stack diagram for the | |
previous example is shown in Figure~\ref{fig.stack}. | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/stack.pdf}} | |
\caption{Stack diagram.} | |
\label{fig.stack} | |
\end{figure} | |
The frames are arranged in a stack that indicates which function | |
called which, and so on. In this example, \verb"print_twice" | |
was called by \verb"cat_twice", and \verb"cat_twice" was called by | |
\verb"__main__", which is a special name for the topmost frame. When | |
you create a variable outside of any function, it belongs to | |
\verb"__main__". | |
Each parameter refers to the same value as its corresponding | |
argument. So, {\tt part1} has the same value as | |
{\tt line1}, {\tt part2} has the same value as {\tt line2}, | |
and {\tt bruce} has the same value as {\tt cat}. | |
If an error occurs during a function call, Python prints the | |
name of the function, and the name of the function that called | |
it, and the name of the function that called {\em that}, all the | |
way back to \verb"__main__". | |
For example, if you try to access {\tt cat} from within | |
\verb"print_twice", you get a {\tt NameError}: | |
\begin{verbatim} | |
Traceback (innermost last): | |
File "test.py", line 13, in __main__ | |
cat_twice(line1, line2) | |
File "test.py", line 5, in cat_twice | |
print_twice(cat) | |
File "test.py", line 9, in print_twice | |
print cat | |
NameError: name 'cat' is not defined | |
\end{verbatim} | |
% | |
This list of functions is called a {\bf traceback}. It tells you what | |
program file the error occurred in, and what line, and what functions | |
were executing at the time. It also shows the line of code that | |
caused the error. | |
\index{traceback} | |
The order of the functions in the traceback is the same as the | |
order of the frames in the stack diagram. The function that is | |
currently running is at the bottom. | |
\section{Fruitful functions and void functions} | |
\index{fruitful function} | |
\index{void function} | |
\index{function, fruitful} | |
\index{function, void} | |
Some of the functions we are using, such as the math functions, yield | |
results; for lack of a better name, I call them {\bf fruitful | |
functions}. Other functions, like \verb"print_twice", perform an | |
action but don't return a value. They are called {\bf void | |
functions}. | |
When you call a fruitful function, you almost always | |
want to do something with the result; for example, you might | |
assign it to a variable or use it as part of an expression: | |
\begin{verbatim} | |
x = math.cos(radians) | |
golden = (math.sqrt(5) + 1) / 2 | |
\end{verbatim} | |
% | |
When you call a function in interactive mode, Python displays | |
the result: | |
\begin{verbatim} | |
>>> math.sqrt(5) | |
2.2360679774997898 | |
\end{verbatim} | |
% | |
But in a script, if you call a fruitful function all by itself, | |
the return value is lost forever! | |
\begin{verbatim} | |
math.sqrt(5) | |
\end{verbatim} | |
% | |
This script computes the square root of 5, but since it doesn't store | |
or display the result, it is not very useful. | |
\index{interactive mode} | |
\index{script mode} | |
Void functions might display something on the screen or have some | |
other effect, but they don't have a return value. If you try to | |
assign the result to a variable, you get a special value called | |
{\tt None}. | |
\index{None special value} | |
\index{special value!None} | |
\begin{verbatim} | |
>>> result = print_twice('Bing') | |
Bing | |
Bing | |
>>> print result | |
None | |
\end{verbatim} | |
% | |
The value {\tt None} is not the same as the string \verb"'None'". | |
It is a special value that has its own type: | |
\begin{verbatim} | |
>>> print type(None) | |
<type 'NoneType'> | |
\end{verbatim} | |
% | |
The functions we have written so far are all void. We will start | |
writing fruitful functions in a few chapters. | |
\section{Why functions?} | |
\index{function, reasons for} | |
It may not be clear why it is worth the trouble to divide | |
a program into functions. There are several reasons: | |
\begin{itemize} | |
\item Creating a new function gives you an opportunity to name a group | |
of statements, which makes your program easier to read and debug. | |
\item Functions can make a program smaller by eliminating repetitive | |
code. Later, if you make a change, you only have | |
to make it in one place. | |
\item Dividing a long program into functions allows you to debug the | |
parts one at a time and then assemble them into a working whole. | |
\item Well-designed functions are often useful for many programs. | |
Once you write and debug one, you can reuse it. | |
\end{itemize} | |
\section{Importing with {\tt from}} | |
Python provides two ways to import modules; we have already seen one: | |
\begin{verbatim} | |
>>> import math | |
>>> print math | |
<module 'math' (built-in)> | |
>>> print math.pi | |
3.14159265359 | |
\end{verbatim} | |
% | |
If you import {\tt math}, you get a module object named {\tt math}. | |
The module object contains constants like {\tt pi} and functions | |
like {\tt sin} and {\tt exp}. | |
But if you try to access {\tt pi} directly, you get an error. | |
\begin{verbatim} | |
>>> print pi | |
Traceback (most recent call last): | |
File "<stdin>", line 1, in <module> | |
NameError: name 'pi' is not defined | |
\end{verbatim} | |
% | |
As an alternative, you can import an object from a module like this: | |
\begin{verbatim} | |
>>> from math import pi | |
\end{verbatim} | |
% | |
Now you can access {\tt pi} directly, without dot notation. | |
\index{dot notation} | |
\begin{verbatim} | |
>>> print pi | |
3.14159265359 | |
\end{verbatim} | |
% | |
Or you can use the star operator to import {\it everything} from the | |
module: | |
\begin{verbatim} | |
>>> from math import * | |
>>> cos(pi) | |
-1.0 | |
\end{verbatim} | |
The advantage of importing everything from the math module is that your | |
code can be more concise. The disadvantage is that there might be | |
conflicts between names defined in different modules, or between | |
a name from a module and one of your variables. | |
\section{Debugging} | |
\label{editor} | |
\index{debugging} | |
If you are using a text editor to write your scripts, you might | |
run into problems with spaces and tabs. The best way to avoid | |
these problems is to use spaces exclusively (no tabs). Most text | |
editors that know about Python do this by default, but some | |
don't. | |
\index{whitespace} | |
Tabs and spaces are usually invisible, which makes them | |
hard to debug, so try to find an editor that manages indentation | |
for you. | |
Also, don't forget to save your program before you run it. Some | |
development environments do this automatically, but some don't. | |
In that case the program you are looking at in the text editor | |
is not the same as the program you are running. | |
Debugging can take a long time if you keep running the same, | |
incorrect, program over and over! | |
Make sure that the code you are looking at is the code you are running. | |
If you're not sure, put something like \verb"print 'hello'" at the | |
beginning of the program and run it again. If you don't see | |
\verb"hello", you're not running the right program! | |
\section{Glossary} | |
\begin{description} | |
\item[function:] A named sequence of statements that performs some | |
useful operation. Functions may or may not take arguments and may or | |
may not produce a result. | |
\index{function} | |
\item[function definition:] A statement that creates a new function, | |
specifying its name, parameters, and the statements it executes. | |
\index{function definition} | |
\item[function object:] A value created by a function definition. | |
The name of the function is a variable that refers to a function | |
object. | |
\index{function definition} | |
\item[header:] The first line of a function definition. | |
\index{header} | |
\item[body:] The sequence of statements inside a function definition. | |
\index{body} | |
\item[parameter:] A name used inside a function to refer to the value | |
passed as an argument. | |
\index{parameter} | |
\item[function call:] A statement that executes a function. It | |
consists of the function name followed by an argument list. | |
\index{function call} | |
\item[argument:] A value provided to a function when the function is called. | |
This value is assigned to the corresponding parameter in the function. | |
\index{argument} | |
\item[local variable:] A variable defined inside a function. A local | |
variable can only be used inside its function. | |
\index{local variable} | |
\item[return value:] The result of a function. If a function call | |
is used as an expression, the return value is the value of | |
the expression. | |
\index{return value} | |
\item[fruitful function:] A function that returns a value. | |
\index{fruitful function} | |
\item[void function:] A function that doesn't return a value. | |
\index{void function} | |
\item[module:] A file that contains a | |
collection of related functions and other definitions. | |
\index{module} | |
\item[import statement:] A statement that reads a module file and creates | |
a module object. | |
\index{import statement} | |
\index{statement!import} | |
\item[module object:] A value created by an {\tt import} statement | |
that provides access to the values defined in a module. | |
\index{module} | |
\item[dot notation:] The syntax for calling a function in another | |
module by specifying the module name followed by a dot (period) and | |
the function name. | |
\index{dot notation} | |
\item[composition:] Using an expression as part of a larger expression, | |
or a statement as part of a larger statement. | |
\index{composition} | |
\item[flow of execution:] The order in which statements are executed during | |
a program run. | |
\index{flow of execution} | |
\item[stack diagram:] A graphical representation of a stack of functions, | |
their variables, and the values they refer to. | |
\index{stack diagram} | |
\item[frame:] A box in a stack diagram that represents a function call. | |
It contains the local variables and parameters of the function. | |
\index{function frame} | |
\index{frame} | |
\item[traceback:] A list of the functions that are executing, | |
printed when an exception occurs. | |
\index{traceback} | |
\end{description} | |
\section{Exercises} | |
\begin{exercise} | |
\index{len function} | |
\index{function!len} | |
Python provides a built-in function called {\tt len} that | |
returns the length of a string, so the value of \verb"len('allen')" is 5. | |
Write a function named \verb"right_justify" that takes a string | |
named {\tt s} as a parameter and prints the string with enough | |
leading spaces so that the last letter of the string is in column 70 | |
of the display. | |
\begin{verbatim} | |
>>> right_justify('allen') | |
allen | |
\end{verbatim} | |
\end{exercise} | |
\begin{exercise} | |
\index{function object} | |
\index{object!function} | |
A function object is a value you can assign to a variable | |
or pass as an argument. For example, \verb"do_twice" is a function | |
that takes a function object as an argument and calls it twice: | |
\begin{verbatim} | |
def do_twice(f): | |
f() | |
f() | |
\end{verbatim} | |
Here's an example that uses \verb"do_twice" to call a function | |
named \verb"print_spam" twice. | |
\begin{verbatim} | |
def print_spam(): | |
print 'spam' | |
do_twice(print_spam) | |
\end{verbatim} | |
\begin{enumerate} | |
\item Type this example into a script and test it. | |
\item Modify \verb"do_twice" so that it takes two arguments, a | |
function object and a value, and calls the function twice, | |
passing the value as an argument. | |
\item Write a more general version of \verb"print_spam", called | |
\verb"print_twice", that takes a string as a parameter and prints | |
it twice. | |
\item Use the modified version of \verb"do_twice" to call | |
\verb"print_twice" twice, passing \verb"'spam'" as an argument. | |
\item Define a new function called | |
\verb"do_four" that takes a function object and a value | |
and calls the function four times, passing the value | |
as a parameter. There should be only | |
two statements in the body of this function, not four. | |
\end{enumerate} | |
Solution: \url{http://thinkpython.com/code/do_four.py}. | |
\end{exercise} | |
\begin{exercise} | |
This exercise can be | |
done using only the statements and other features we have learned so | |
far. | |
\begin{enumerate} | |
\item Write a function that draws a grid like the following: | |
\index{grid} | |
\begin{verbatim} | |
+ - - - - + - - - - + | |
| | | | |
| | | | |
| | | | |
| | | | |
+ - - - - + - - - - + | |
| | | | |
| | | | |
| | | | |
| | | | |
+ - - - - + - - - - + | |
\end{verbatim} | |
% | |
Hint: to print more than one value on a line, you can print | |
a comma-separated sequence: | |
\begin{verbatim} | |
print '+', '-' | |
\end{verbatim} | |
% | |
If the sequence ends with a comma, Python leaves the line unfinished, | |
so the value printed next appears on the same line. | |
\begin{verbatim} | |
print '+', | |
print '-' | |
\end{verbatim} | |
% | |
The output of these statements is \verb"'+ -'". | |
A {\tt print} statement all by itself ends the current line and | |
goes to the next line. | |
\item Write a function that draws a similar grid | |
with four rows and four columns. | |
\end{enumerate} | |
Solution: \url{http://thinkpython.com/code/grid.py}. | |
Credit: This exercise is based on an exercise in Oualline, {\em | |
Practical C Programming, Third Edition}, O'Reilly Media, 1997. | |
\end{exercise} | |
\chapter{Case study: interface design} | |
\label{turtlechap} | |
Code examples from this chapter are available from | |
\url{http://thinkpython.com/code/polygon.py}. | |
\section{TurtleWorld} | |
\label{turtleworld} | |
\index{TurtleWorld} | |
\index{Swampy} | |
To accompany this book, I have written a package called Swampy. | |
You can download Swampy from \url{http://thinkpython.com/swampy}; | |
follow the instructions there to install Swampy on your system. | |
A {\bf package} is a collection of modules; one of the modules in | |
Swampy is {\tt TurtleWorld}, which provides a set of functions for | |
drawing lines by steering turtles around the screen. | |
\index{package} | |
If Swampy is installed as a package on your system, you can import | |
{\tt TurtleWorld} like this: | |
\begin{verbatim} | |
from swampy.TurtleWorld import * | |
\end{verbatim} | |
If you downloaded the Swampy modules but did not install them as a | |
package, you can either work in the directory that contains the Swampy | |
files, or add that directory to Python's search path. Then you can import | |
{\tt TurtleWorld} like this: | |
\begin{verbatim} | |
from TurtleWorld import * | |
\end{verbatim} | |
The details of the installation process and setting Python's search | |
path depend on your system, so rather than include those details here, | |
I will try to maintain current information for several systems | |
at \url{http://thinkpython.com/swampy} | |
Create a file named {\tt mypolygon.py} and type in the following | |
code: | |
\begin{verbatim} | |
from swampy.TurtleWorld import * | |
world = TurtleWorld() | |
bob = Turtle() | |
print bob | |
wait_for_user() | |
\end{verbatim} | |
% | |
The first line imports everything from the {\tt TurtleWorld} module | |
in the {\tt swampy} package. | |
\index{import statement} | |
\index{statement!import} | |
The next lines create a TurtleWorld assigned to {\tt world} and | |
a Turtle assigned to {\tt bob}. Printing {\tt bob} yields something | |
like: | |
\begin{verbatim} | |
<TurtleWorld.Turtle instance at 0xb7bfbf4c> | |
\end{verbatim} | |
% | |
This means that {\tt bob} refers to | |
an {\bf instance} of a Turtle | |
as defined in module {\tt TurtleWorld}. In this context, | |
``instance'' means a member of a set; | |
this Turtle is one of the set of possible Turtles. | |
\index{instance} | |
\verb"wait_for_user" tells TurtleWorld to wait for the user | |
to do something, although in this case there's not much for | |
the user to do except close the window. | |
TurtleWorld provides several | |
turtle-steering functions: {\tt fd} and {\tt bk} for | |
forward and backward, and {\tt lt} and {\tt rt} for left and | |
right turns. Also, each Turtle is holding a pen, which is | |
either down or up; if the pen is down, the Turtle leaves | |
a trail when it moves. The functions {\tt pu} and {\tt pd} | |
stand for ``pen up'' and ``pen down.'' | |
To draw a right angle, add these lines to the program | |
(after creating {\tt bob} and before calling \verb"wait_for_user"): | |
\begin{verbatim} | |
fd(bob, 100) | |
lt(bob) | |
fd(bob, 100) | |
\end{verbatim} | |
% | |
The first line tells {\tt bob} to take 100 steps | |
forward. The second line tells him to turn left. | |
When you run this program, you should see {\tt bob} move east and then | |
north, leaving two line segments behind. | |
Now modify the program to draw a square. Don't go on until | |
you've got it working! | |
%\newpage | |
\section{Simple repetition} | |
\label{repetition} | |
\index{repetition} | |
Chances are you wrote something like this (leaving out the code | |
that creates TurtleWorld and waits for the user): | |
\begin{verbatim} | |
fd(bob, 100) | |
lt(bob) | |
fd(bob, 100) | |
lt(bob) | |
fd(bob, 100) | |
lt(bob) | |
fd(bob, 100) | |
\end{verbatim} | |
% | |
We can do the same thing more concisely with a {\tt for} statement. | |
Add this example to {\tt mypolygon.py} and run it again: | |
\index{for loop} | |
\index{loop!for} | |
\index{statement!for} | |
\begin{verbatim} | |
for i in range(4): | |
print 'Hello!' | |
\end{verbatim} | |
% | |
You should see something like this: | |
\begin{verbatim} | |
Hello! | |
Hello! | |
Hello! | |
Hello! | |
\end{verbatim} | |
% | |
This is the simplest use of the {\tt for} statement; we will see | |
more later. But that should be enough to let you rewrite your | |
square-drawing program. Don't go on until you do. | |
Here is a {\tt for} statement that draws a square: | |
\begin{verbatim} | |
for i in range(4): | |
fd(bob, 100) | |
lt(bob) | |
\end{verbatim} | |
% | |
The syntax of a {\tt for} statement is similar to a function | |
definition. It has a header that ends with a colon and an indented | |
body. The body can contain any number of statements. | |
\index{loop} | |
A {\tt for} statement is sometimes called a {\bf loop} because | |
the flow of execution runs through the body and then loops back | |
to the top. In this case, it runs the body four times. | |
This version is actually a little different from the previous | |
square-drawing code because it makes another turn after | |
drawing the last side of the square. The extra turn takes a little | |
more time, but it simplifies the code if we do the same thing | |
every time through the loop. This version also has the effect | |
of leaving the turtle back in the starting position, facing in | |
the starting direction. | |
\section{Exercises} | |
The following is a series of exercises using TurtleWorld. They | |
are meant to be fun, but they have a point, too. While you are | |
working on them, think about what the point is. | |
The following sections have solutions to the exercises, so | |
don't look until you have finished (or at least tried). | |
\begin{enumerate} | |
\item Write a function called {\tt square} that takes a parameter | |
named {\tt t}, which is a turtle. It should use the turtle to draw | |
a square. | |
Write a function call that passes {\tt bob} as an argument to | |
{\tt square}, and then run the program again. | |
\item Add another parameter, named {\tt length}, to {\tt square}. | |
Modify the body so length of the sides is {\tt length}, and then | |
modify the function call to provide a second argument. Run the | |
program again. Test your program with a range of values for {\tt | |
length}. | |
\item The functions {\tt lt} and {\tt rt} make 90-degree turns by | |
default, but you can provide a second argument that specifies the | |
number of degrees. For example, {\tt lt(bob, 45)} turns {\tt bob} 45 | |
degrees to the left. | |
Make a copy of {\tt square} and change the name to {\tt polygon}. Add | |
another parameter named {\tt n} and modify the body so it draws an | |
n-sided regular polygon. Hint: The exterior angles of an n-sided regular | |
polygon are $360/n$ degrees. | |
\index{polygon function} | |
\index{function!polygon} | |
\item Write a function called {\tt circle} that takes a turtle, {\tt t}, | |
and radius, {\tt r}, as parameters and that draws an approximate circle | |
by invoking {\tt polygon} with an appropriate length and number of | |
sides. Test your function with a range of values of {\tt r}. | |
\index{circle function} | |
\index{function!circle} | |
Hint: figure out the circumference of the circle and make sure that | |
{\tt length * n = circumference}. | |
Another hint: if {\tt bob} is too slow for you, you can speed | |
him up by changing {\tt bob.delay}, which is the time between moves, | |
in seconds. {\tt bob.delay = 0.01} ought to get him moving. | |
% change this to world.delay | |
\item Make a more general version of {\tt circle} called {\tt arc} | |
that takes an additional parameter {\tt angle}, which determines | |
what fraction of a circle to draw. {\tt angle} is in units of | |
degrees, so when {\tt angle=360}, {\tt arc} should draw a complete | |
circle. | |
\index{arc function} | |
\index{function!arc} | |
\end{enumerate} | |
\section{Encapsulation} | |
The first exercise asks you to put your square-drawing code | |
into a function definition and then call the function, passing | |
the turtle as a parameter. Here is a solution: | |
\begin{verbatim} | |
def square(t): | |
for i in range(4): | |
fd(t, 100) | |
lt(t) | |
square(bob) | |
\end{verbatim} | |
% | |
The innermost statements, {\tt fd} and {\tt lt} are | |
indented twice to show that they are inside the {\tt for} loop, | |
which is inside the function definition. The next line, | |
{\tt square(bob)}, is flush with the left margin, so that is the | |
end of both the {\tt for} loop and the function definition. | |
Inside the function, {\tt t} refers to the same turtle {\tt bob} | |
refers to, so {\tt lt(t)} has the same effect as {\tt lt(bob)}. | |
So why not call the parameter {\tt bob}? The idea is that {\tt t} | |
can be any turtle, not just {\tt bob}, so you could create | |
a second turtle and pass it as an argument to {\tt square}: | |
\begin{verbatim} | |
ray = Turtle() | |
square(ray) | |
\end{verbatim} | |
% | |
Wrapping a piece of code up in a function is called {\bf | |
encapsulation}. One of the benefits of encapsulation is that it | |
attaches a name to the code, which serves as a kind of documentation. | |
Another advantage is that if you re-use the code, it is more concise | |
to call a function twice than to copy and paste the body! | |
\index{encapsulation} | |
\section{Generalization} | |
The next step is to add a {\tt length} parameter to {\tt square}. | |
Here is a solution: | |
\begin{verbatim} | |
def square(t, length): | |
for i in range(4): | |
fd(t, length) | |
lt(t) | |
square(bob, 100) | |
\end{verbatim} | |
% | |
Adding a parameter to a function is called {\bf generalization} | |
because it makes the function more general: in the previous | |
version, the square is always the same size; in this version | |
it can be any size. | |
\index{generalization} | |
The next step is also a generalization. Instead of drawing | |
squares, {\tt polygon} draws regular polygons with any number of | |
sides. Here is a solution | |
:rule | |
\begin{verbatim} | |
def polygon(t, n, length): | |
angle = 360.0 / n | |
for i in range(n): | |
fd(t, length) | |
lt(t, angle) | |
polygon(bob, 7, 70) | |
\end{verbatim} | |
% | |
This draws a 7-sided polygon with side length 70. If you have | |
more than a few numeric arguments, it is easy to forget what they | |
are, or what order they should be in. It is legal, and sometimes | |
helpful, to include the names of the parameters in the argument | |
list: | |
\begin{verbatim} | |
polygon(bob, n=7, length=70) | |
\end{verbatim} | |
% | |
These are called {\bf keyword arguments} because they include | |
the parameter names as ``keywords'' (not to be confused with | |
Python keywords like {\tt while} and {\tt def}). | |
\index{keyword argument} | |
\index{argument!keyword} | |
This syntax makes the program more readable. It is also a reminder | |
about how arguments and parameters work: when you call a function, the | |
arguments are assigned to the parameters. | |
\section{Interface design} | |
The next step is to write {\tt circle}, which takes a radius, | |
{\tt r}, as a parameter. Here is a simple solution that uses | |
{\tt polygon} to draw a 50-sided polygon: | |
\begin{verbatim} | |
def circle(t, r): | |
circumference = 2 * math.pi * r | |
n = 50 | |
length = circumference / n | |
polygon(t, n, length) | |
\end{verbatim} | |
% | |
The first line computes the circumference of a circle with radius | |
{\tt r} using the formula $2 \pi r$. Since we use {\tt math.pi}, we | |
have to import {\tt math}. By convention, {\tt import} statements | |
are usually at the beginning of the script. | |
{\tt n} is the number of line segments in our approximation of a circle, | |
so {\tt length} is the length of each segment. Thus, {\tt polygon} | |
draws a 50-sides polygon that approximates a circle with radius {\tt r}. | |
One limitation of this solution is that {\tt n} is a constant, which | |
means that for very big circles, the line segments are too long, and | |
for small circles, we waste time drawing very small segments. One | |
solution would be to generalize the function by taking {\tt n} as | |
a parameter. This would give the user (whoever calls {\tt circle}) | |
more control, but the interface would be less clean. | |
\index{interface} | |
The {\bf interface} of a function is a summary of how it is used: what | |
are the parameters? What does the function do? And what is the return | |
value? An interface is ``clean'' if it is ``as simple as | |
possible, but not simpler. (Einstein)'' | |
\index{Einstein, Albert} | |
In this example, {\tt r} belongs in the interface because it | |
specifies the circle to be drawn. {\tt n} is less appropriate | |
because it pertains to the details of {\em how} the circle should | |
be rendered. | |
Rather than clutter up the interface, it is better | |
to choose an appropriate value of {\tt n} | |
depending on {\tt circumference}: | |
\begin{verbatim} | |
def circle(t, r): | |
circumference = 2 * math.pi * r | |
n = int(circumference / 3) + 1 | |
length = circumference / n | |
polygon(t, n, length) | |
\end{verbatim} | |
% | |
Now the number of segments is (approximately) {\tt circumference/3}, | |
so the length of each segment is (approximately) 3, which is small | |
enough that the circles look good, but big enough to be efficient, | |
and appropriate for any size circle. | |
\section{Refactoring} | |
\label{refactoring} | |
\index{refactoring} | |
When I wrote {\tt circle}, I was able to re-use {\tt polygon} | |
because a many-sided polygon is a good approximation of a circle. | |
But {\tt arc} is not as cooperative; we can't use {\tt polygon} | |
or {\tt circle} to draw an arc. | |
One alternative is to start with a copy | |
of {\tt polygon} and transform it into {\tt arc}. The result | |
might look like this: | |
\begin{verbatim} | |
def arc(t, r, angle): | |
arc_length = 2 * math.pi * r * angle / 360 | |
n = int(arc_length / 3) + 1 | |
step_length = arc_length / n | |
step_angle = float(angle) / n | |
for i in range(n): | |
fd(t, step_length) | |
lt(t, step_angle) | |
\end{verbatim} | |
% | |
The second half of this function looks like {\tt polygon}, but we | |
can't re-use {\tt polygon} without changing the interface. We could | |
generalize {\tt polygon} to take an angle as a third argument, | |
but then {\tt polygon} would no longer be an appropriate name! | |
Instead, let's call the more general function {\tt polyline}: | |
\begin{verbatim} | |
def polyline(t, n, length, angle): | |
for i in range(n): | |
fd(t, length) | |
lt(t, angle) | |
\end{verbatim} | |
% | |
Now we can rewrite {\tt polygon} and {\tt arc} to use {\tt polyline}: | |
\begin{verbatim} | |
def polygon(t, n, length): | |
angle = 360.0 / n | |
polyline(t, n, length, angle) | |
def arc(t, r, angle): | |
arc_length = 2 * math.pi * r * angle / 360 | |
n = int(arc_length / 3) + 1 | |
step_length = arc_length / n | |
step_angle = float(angle) / n | |
polyline(t, n, step_length, step_angle) | |
\end{verbatim} | |
% | |
Finally, we can rewrite {\tt circle} to use {\tt arc}: | |
\begin{verbatim} | |
def circle(t, r): | |
arc(t, r, 360) | |
\end{verbatim} | |
% | |
This process---rearranging a program to improve function | |
interfaces and facilitate code re-use---is called {\bf refactoring}. | |
In this case, we noticed that there was similar code in {\tt arc} and | |
{\tt polygon}, so we ``factored it out'' into {\tt polyline}. | |
\index{refactoring} | |
If we had planned ahead, we might have written {\tt polyline} first | |
and avoided refactoring, but often you don't know enough at the | |
beginning of a project to design all the interfaces. Once you start | |
coding, you understand the problem better. Sometimes refactoring is a | |
sign that you have learned something. | |
\section{A development plan} | |
\index{development plan!encapsulation and generalization} | |
A {\bf development plan} is a process for writing programs. | |
The process we used | |
in this case study is ``encapsulation and | |
generalization.'' The steps of this process are: | |
\begin{enumerate} | |
\item Start by writing a small program with no function definitions. | |
\item Once you get the program working, encapsulate it in a function | |
and give it a name. | |
\item Generalize the function by adding appropriate parameters. | |
\item Repeat steps 1--3 until you have a set of working functions. | |
Copy and paste working code to avoid retyping (and re-debugging). | |
\item Look for opportunities to improve the program by refactoring. | |
For example, if you have similar code in several places, consider | |
factoring it into an appropriately general function. | |
\end{enumerate} | |
This process has some drawbacks---we will see alternatives later---but | |
it can be useful if you don't know ahead of time how to divide the | |
program into functions. This approach lets you design as you go | |
along. | |
\section{docstring} | |
\label{docstring} | |
\index{docstring} | |
A {\bf docstring} is a string at the beginning of a function that | |
explains the interface (``doc'' is short for ``documentation''). Here | |
is an example: | |
\begin{verbatim} | |
def polyline(t, n, length, angle): | |
"""Draws n line segments with the given length and | |
angle (in degrees) between them. t is a turtle. | |
""" | |
for i in range(n): | |
fd(t, length) | |
lt(t, angle) | |
\end{verbatim} | |
% | |
This docstring is a triple-quoted string, also known | |
as a multiline string because the triple quotes allow the string | |
to span more than one line. | |
\index{quotation mark} | |
\index{triple-quoted string} | |
\index{string!triple-quoted} | |
\index{multiline string} | |
\index{string!multiline} | |
It is terse, but it contains the essential information | |
someone would need to use this function. It explains concisely what | |
the function does (without getting into the details of how it does | |
it). It explains what effect each parameter has on the behavior of | |
the function and what type each parameter should be (if it is not | |
obvious). | |
Writing this kind of documentation is an important part of interface | |
design. A well-designed interface should be simple to explain; | |
if you are having a hard time explaining one of your functions, | |
that might be a sign that the interface could be improved. | |
\section{Debugging} | |
\index{debugging} | |
\index{interface} | |
An interface is like a contract between a function and a caller. | |
The caller agrees to provide certain parameters and the function | |
agrees to do certain work. | |
For example, {\tt polyline} requires four arguments: {\tt t} has to be | |
a Turtle; {\tt n} is the number of line segments, so it has to be an | |
integer; {\tt length} should be a positive number; and {\tt | |
angle} has to be a number, which is understood to be in degrees. | |
These requirements are called {\bf preconditions} because they | |
are supposed to be true before the function starts executing. | |
Conversely, conditions at the end of the function are | |
{\bf postconditions}. Postconditions include the intended | |
effect of the function (like drawing line segments) and any | |
side effects (like moving the Turtle or making other changes | |
in the World). | |
\index{precondition} | |
\index{postcondition} | |
Preconditions are the responsibility of the caller. If the caller | |
violates a (properly documented!) precondition and the function | |
doesn't work correctly, the bug is in the caller, not the function. | |
% Removing this because we haven't seen conditionals yet! | |
%However, for purposes of debugging it is often a good idea for | |
%functions to check their preconditions rather than assume they are | |
%true. If every function checks its preconditions before starting, | |
%then if something goes wrong, you will know which function to blame. | |
\section{Glossary} | |
\begin{description} | |
\item[instance:] A member of a set. The TurtleWorld in this | |
chapter is a member of the set of TurtleWorlds. | |
\index{instance} | |
\item[loop:] A part of a program that can execute repeatedly. | |
\index{loop} | |
\item[encapsulation:] The process of transforming a sequence of | |
statements into a function definition. | |
\index{encapsulation} | |
\item[generalization:] The process of replacing something | |
unnecessarily specific (like a number) with something appropriately | |
general (like a variable or parameter). | |
\index{generalization} | |
\item[keyword argument:] An argument that includes the name of | |
the parameter as a ``keyword.'' | |
\index{keyword argument} | |
\index{argument!keyword} | |
\item[interface:] A description of how to use a function, including | |
the name and descriptions of the arguments and return value. | |
\index{interface} | |
\item[refactoring:] The process of modifying a working program to | |
improve function interfaces and other qualities of the code. | |
\index{refactoring} | |
\item[development plan:] A process for writing programs. | |
\index{development plan} | |
\item[docstring:] A string that appears in a function definition | |
to document the function's interface. | |
\index{docstring} | |
\item[precondition:] A requirement that should be satisfied by | |
the caller before a function starts. | |
\index{precondition} | |
\item[postcondition:] A requirement that should be satisfied by | |
the function before it ends. | |
\index{precondition} | |
\end{description} | |
\section{Exercises} | |
\begin{exercise} | |
Download the code in this chapter from | |
\url{http://thinkpython.com/code/polygon.py}. | |
\begin{enumerate} | |
\item Write appropriate docstrings for {\tt polygon}, {\tt arc} and | |
{\tt circle}. | |
\index{stack diagram} | |
\item Draw a stack diagram that shows the state of the program | |
while executing {\tt circle(bob, radius)}. You can do the | |
arithmetic by hand or add {\tt print} statements to the code. | |
\item The version of {\tt arc} in Section~\ref{refactoring} is not | |
very accurate because the linear approximation of the | |
circle is always outside the true circle. As a result, | |
the turtle ends up a few units away from the correct | |
destination. My solution shows a way to reduce | |
the effect of this error. Read the code and see if it makes | |
sense to you. If you draw a diagram, you might see how it works. | |
\end{enumerate} | |
\end{exercise} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/flowers.pdf}} | |
\caption{Turtle flowers.} | |
\label{fig.flowers} | |
\end{figure} | |
\begin{exercise} | |
\index{flower} | |
Write an appropriately general set of functions that | |
can draw flowers as in Figure~\ref{fig.flowers}. | |
Solution: \url{http://thinkpython.com/code/flower.py}, | |
also requires \url{http://thinkpython.com/code/polygon.py}. | |
\end{exercise} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/pies.pdf}} | |
\caption{Turtle pies.} | |
\label{fig.pies} | |
\end{figure} | |
\begin{exercise} | |
\index{pie} | |
Write an appropriately general set of functions that | |
can draw shapes as in Figure~\ref{fig.pies}. | |
Solution: \url{http://thinkpython.com/code/pie.py}. | |
\end{exercise} | |
\begin{exercise} | |
\index{alphabet} | |
\index{turtle typewriter} | |
\index{typewriter, turtle} | |
The letters of the alphabet can be constructed from a moderate number | |
of basic elements, like vertical and horizontal lines and a few | |
curves. Design a font that can be drawn with a minimal number of | |
basic elements and then write functions that draw letters of the | |
alphabet. | |
You should write one function for each letter, with names | |
\verb"draw_a", \verb"draw_b", etc., and put your functions | |
in a file named {\tt letters.py}. You can download a | |
``turtle typewriter'' from \url{http://thinkpython.com/code/typewriter.py} | |
to help you test your code. | |
Solution: \url{http://thinkpython.com/code/letters.py}, also requires | |
\url{http://thinkpython.com/code/polygon.py}. | |
\end{exercise} | |
\begin{exercise} | |
Read about spirals at \url{http://en.wikipedia.org/wiki/Spiral}; then | |
write a program that draws an Archimedian spiral (or one of the other | |
kinds). Solution: \url{http://thinkpython.com/code/spiral.py}. | |
\index{spiral} | |
\index{Archimedian spiral} | |
\end{exercise} | |
\chapter{Conditionals and recursion} | |
\section{Modulus operator} | |
\index{modulus operator} | |
\index{operator!modulus} | |
The {\bf modulus operator} works on integers and yields the remainder | |
when the first operand is divided by the second. In Python, the | |
modulus operator is a percent sign (\verb"%"). The syntax is the same | |
as for other operators: | |
\begin{verbatim} | |
>>> quotient = 7 / 3 | |
>>> print quotient | |
2 | |
>>> remainder = 7 % 3 | |
>>> print remainder | |
1 | |
\end{verbatim} | |
% | |
So 7 divided by 3 is 2 with 1 left over. | |
The modulus operator turns out to be surprisingly useful. For | |
example, you can check whether one number is divisible by another---if | |
{\tt x \% y} is zero, then {\tt x} is divisible by {\tt y}. | |
\index{divisibility} | |
Also, you can extract the right-most digit | |
or digits from a number. For example, {\tt x \% 10} yields the | |
right-most digit of {\tt x} (in base 10). Similarly {\tt x \% 100} | |
yields the last two digits. | |
\section{Boolean expressions} | |
\index{boolean expression} | |
\index{expression!boolean} | |
\index{logical operator} | |
\index{operator!logical} | |
A {\bf boolean expression} is an expression that is either true | |
or false. The following examples use the | |
operator {\tt ==}, which compares two operands and produces | |
{\tt True} if they are equal and {\tt False} otherwise: | |
\begin{verbatim} | |
>>> 5 == 5 | |
True | |
>>> 5 == 6 | |
False | |
\end{verbatim} | |
% | |
{\tt True} and {\tt False} are special | |
values that belong to the type {\tt bool}; they are not strings: | |
\index{True special value} | |
\index{False special value} | |
\index{special value!True} | |
\index{special value!False} | |
\index{bool type} | |
\index{type!bool} | |
\begin{verbatim} | |
>>> type(True) | |
<type 'bool'> | |
>>> type(False) | |
<type 'bool'> | |
\end{verbatim} | |
% | |
The {\tt ==} operator is one of the {\bf relational operators}; the | |
others are: | |
\begin{verbatim} | |
x != y # x is not equal to y | |
x > y # x is greater than y | |
x < y # x is less than y | |
x >= y # x is greater than or equal to y | |
x <= y # x is less than or equal to y | |
\end{verbatim} | |
% | |
Although these operations are probably familiar to you, the Python | |
symbols are different from the mathematical symbols. A common error | |
is to use a single equal sign ({\tt =}) instead of a double equal sign | |
({\tt ==}). Remember that {\tt =} is an assignment operator and | |
{\tt ==} is a relational operator. There is no such thing as | |
{\tt =<} or {\tt =>}. | |
\index{relational operator} | |
\index{operator!relational} | |
\section {Logical operators} | |
\index{logical operator} | |
\index{operator!logical} | |
There are three {\bf logical operators}: {\tt and}, {\tt | |
or}, and {\tt not}. The semantics (meaning) of these operators is | |
similar to their meaning in English. For example, | |
{\tt x > 0 and x < 10} is true only if {\tt x} is greater than 0 | |
{\em and} less than 10. | |
\index{and operator} | |
\index{or operator} | |
\index{not operator} | |
\index{operator!and} | |
\index{operator!or} | |
\index{operator!not} | |
{\tt n\%2 == 0 or n\%3 == 0} is true if {\em either} of the conditions | |
is true, that is, if the number is divisible by 2 {\em or} 3. | |
Finally, the {\tt not} operator negates a boolean | |
expression, so {\tt not (x > y)} is true if {\tt x > y} is false, | |
that is, if {\tt x} is less than or equal to {\tt y}. | |
Strictly speaking, the operands of the logical operators should be | |
boolean expressions, but Python is not very strict. | |
Any nonzero number is interpreted as ``true.'' | |
\begin{verbatim} | |
>>> 17 and True | |
True | |
\end{verbatim} | |
% | |
This flexibility can be useful, but there are some subtleties to | |
it that might be confusing. You might want to avoid it (unless | |
you know what you are doing). | |
\section{Conditional execution} | |
\label{conditional.execution} | |
\index{conditional statement} | |
\index{statement!conditional} | |
\index{if statement} | |
\index{statement!if} | |
\index{conditional execution} | |
In order to write useful programs, we almost always need the ability | |
to check conditions and change the behavior of the program | |
accordingly. {\bf Conditional statements} give us this ability. The | |
simplest form is the {\tt if} statement: | |
\begin{verbatim} | |
if x > 0: | |
print 'x is positive' | |
\end{verbatim} | |
% | |
The boolean expression after {\tt if} is | |
called the {\bf condition}. If it is true, then the indented | |
statement gets executed. If not, nothing happens. | |
\index{condition} | |
\index{compound statement} | |
\index{statement!compound} | |
{\tt if} statements have the same structure as function definitions: | |
a header followed by an indented body. Statements like this are | |
called {\bf compound statements}. | |
There is no limit on the number of statements that can appear in | |
the body, but there has to be at least one. | |
Occasionally, it is useful to have a body with no statements (usually | |
as a place keeper for code you haven't written yet). In that | |
case, you can use the {\tt pass} statement, which does nothing. | |
\index{pass statement} | |
\index{statement!pass} | |
\begin{verbatim} | |
if x < 0: | |
pass # need to handle negative values! | |
\end{verbatim} | |
% | |
\section{Alternative execution} | |
\label{alternative.execution} | |
\index{alternative execution} | |
\index{else keyword} | |
\index{keyword!else} | |
A second form of the {\tt if} statement is {\bf alternative execution}, | |
in which there are two possibilities and the condition determines | |
which one gets executed. The syntax looks like this: | |
\begin{verbatim} | |
if x%2 == 0: | |
print 'x is even' | |
else: | |
print 'x is odd' | |
\end{verbatim} | |
% | |
If the remainder when {\tt x} is divided by 2 is 0, then we | |
know that {\tt x} is even, and the program displays a message to that | |
effect. If the condition is false, the second set of statements is | |
executed. Since the condition must be true or false, exactly one of | |
the alternatives will be executed. The alternatives are called | |
{\bf branches}, because they are branches in the flow of execution. | |
\index{branch} | |
\section{Chained conditionals} | |
\index{chained conditional} | |
\index{conditional!chained} | |
Sometimes there are more than two possibilities and we need more than | |
two branches. One way to express a computation like that is a {\bf | |
chained conditional}: | |
\begin{verbatim} | |
if x < y: | |
print 'x is less than y' | |
elif x > y: | |
print 'x is greater than y' | |
else: | |
print 'x and y are equal' | |
\end{verbatim} | |
% | |
{\tt elif} is an abbreviation of ``else if.'' Again, exactly one | |
branch will be executed. There is no limit on the number of {\tt | |
elif} statements. If there is an {\tt else} clause, it has to be | |
at the end, but there doesn't have to be one. | |
\index{elif keyword} | |
\index{keyword!elif} | |
\begin{verbatim} | |
if choice == 'a': | |
draw_a() | |
elif choice == 'b': | |
draw_b() | |
elif choice == 'c': | |
draw_c() | |
\end{verbatim} | |
% | |
Each condition is checked in order. If the first is false, | |
the next is checked, and so on. If one of them is | |
true, the corresponding branch executes, and the statement | |
ends. Even if more than one condition is true, only the | |
first true branch executes. | |
\section{Nested conditionals} | |
\index{nested conditional} | |
\index{conditional!nested} | |
One conditional can also be nested within another. We could have | |
written the trichotomy example like this: | |
\begin{verbatim} | |
if x == y: | |
print 'x and y are equal' | |
else: | |
if x < y: | |
print 'x is less than y' | |
else: | |
print 'x is greater than y' | |
\end{verbatim} | |
% | |
The outer conditional contains two branches. The | |
first branch contains a simple statement. The second branch | |
contains another {\tt if} statement, which has two branches of its | |
own. Those two branches are both simple statements, | |
although they could have been conditional statements as well. | |
Although the indentation of the statements makes the structure | |
apparent, {\bf nested conditionals} become difficult to read very | |
quickly. In general, it is a good idea to avoid them when you can. | |
Logical operators often provide a way to simplify nested conditional | |
statements. For example, we can rewrite the following code using a | |
single conditional: | |
\begin{verbatim} | |
if 0 < x: | |
if x < 10: | |
print 'x is a positive single-digit number.' | |
\end{verbatim} | |
% | |
The {\tt print} statement is executed only if we make it past both | |
conditionals, so we can get the same effect with the {\tt and} operator: | |
\begin{verbatim} | |
if 0 < x and x < 10: | |
print 'x is a positive single-digit number.' | |
\end{verbatim} | |
\section{Recursion} | |
\label{recursion} | |
\index{recursion} | |
It is legal for one function to call another; | |
it is also legal for a function to call itself. It may not be obvious | |
why that is a good thing, but it turns out to be one of the most | |
magical things a program can do. | |
For example, look at the following function: | |
\begin{verbatim} | |
def countdown(n): | |
if n <= 0: | |
print 'Blastoff!' | |
else: | |
print n | |
countdown(n-1) | |
\end{verbatim} | |
% | |
If {\tt n} is 0 or negative, it outputs the word, ``Blastoff!'' | |
Otherwise, it outputs {\tt n} and then calls a function named {\tt | |
countdown}---itself---passing {\tt n-1} as an argument. | |
What happens if we call this function like this? | |
\begin{verbatim} | |
>>> countdown(3) | |
\end{verbatim} | |
% | |
The execution of {\tt countdown} begins with {\tt n=3}, and since | |
{\tt n} is greater than 0, it outputs the value 3, and then calls itself... | |
\begin{quote} | |
The execution of {\tt countdown} begins with {\tt n=2}, and since | |
{\tt n} is greater than 0, it outputs the value 2, and then calls itself... | |
\begin{quote} | |
The execution of {\tt countdown} begins with {\tt n=1}, and since | |
{\tt n} is greater than 0, it outputs the value 1, and then calls itself... | |
\begin{quote} | |
The execution of {\tt countdown} begins with {\tt n=0}, and since {\tt | |
n} is not greater than 0, it outputs the word, ``Blastoff!'' and then | |
returns. | |
\end{quote} | |
The {\tt countdown} that got {\tt n=1} returns. | |
\end{quote} | |
The {\tt countdown} that got {\tt n=2} returns. | |
\end{quote} | |
The {\tt countdown} that got {\tt n=3} returns. | |
And then you're back in \verb"__main__". So, the | |
total output looks like this: | |
\begin{verbatim} | |
3 | |
2 | |
1 | |
Blastoff! | |
\end{verbatim} | |
% | |
A function that calls itself is {\bf recursive}; the process is | |
called {\bf recursion}. | |
\index{recursion} | |
\index{function!recursive} | |
As another example, we can write a function that prints a | |
string {\tt n} times. | |
\begin{verbatim} | |
def print_n(s, n): | |
if n <= 0: | |
return | |
print s | |
print_n(s, n-1) | |
\end{verbatim} | |
% | |
If {\tt n <= 0} the {\tt return} statement exits the function. The | |
flow of execution immediately returns to the caller, and the remaining | |
lines of the function are not executed. | |
\index{return statement} | |
\index{statement!return} | |
The rest of the function is similar to {\tt countdown}: if {\tt n} is | |
greater than 0, it displays {\tt s} and then calls itself to display | |
{\tt s} $n-1$ additional times. So the number of lines of output | |
is {\tt 1 + (n - 1)}, which adds up to | |
{\tt n}. | |
For simple examples like this, it is probably easier to use a {\tt | |
for} loop. But we will see examples later that are hard to write | |
with a {\tt for} loop and easy to write with recursion, so it is | |
good to start early. | |
\section{Stack diagrams for recursive functions} | |
\label{recursive.stack} | |
\index{stack diagram} | |
\index{function frame} | |
\index{frame} | |
In Section~\ref{stackdiagram}, we used a stack diagram to represent | |
the state of a program during a function call. The same kind of | |
diagram can help interpret a recursive function. | |
Every time a function gets called, Python creates a new function | |
frame, which contains the function's local variables and parameters. | |
For a recursive function, there might be more than one frame on the | |
stack at the same time. | |
Figure~\ref{fig.stack2} shows a stack diagram for {\tt countdown} called with | |
{\tt n = 3}. | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/stack2.pdf}} | |
\caption{Stack diagram.} | |
\label{fig.stack2} | |
\end{figure} | |
As usual, the top of the stack is the frame for \verb"__main__". | |
It is empty because we did not create any variables in | |
\verb"__main__" or pass any arguments to it. | |
\index{base case} | |
\index{recursion!base case} | |
The four {\tt countdown} frames have different values for the | |
parameter {\tt n}. The bottom of the stack, where {\tt n=0}, is | |
called the {\bf base case}. It does not make a recursive call, so | |
there are no more frames. | |
\begin{exercise} | |
Draw a stack diagram for \verb"print_n" called with | |
\verb"s = 'Hello'" and {\tt n=2}. | |
\end{exercise} | |
\begin{exercise} | |
Write a function called \verb"do_n" that takes a function | |
object and a number, {\tt n}, as arguments, and that calls | |
the given function {\tt n} times. | |
\end{exercise} | |
\section{Infinite recursion} | |
\index{infinite recursion} | |
\index{recursion!infinite} | |
\index{runtime error} | |
\index{error!runtime} | |
\index{traceback} | |
If a recursion never reaches a base case, it goes on making | |
recursive calls forever, and the program never terminates. This is | |
known as {\bf infinite recursion}, and it is generally not | |
a good idea. Here is a minimal program with an infinite recursion: | |
\begin{verbatim} | |
def recurse(): | |
recurse() | |
\end{verbatim} | |
% | |
In most programming environments, a program with infinite recursion | |
does not really run forever. Python reports an error | |
message when the maximum recursion depth is reached: | |
\index{exception!RuntimeError} | |
\index{RuntimeError} | |
\begin{verbatim} | |
File "<stdin>", line 2, in recurse | |
File "<stdin>", line 2, in recurse | |
File "<stdin>", line 2, in recurse | |
. | |
. | |
. | |
File "<stdin>", line 2, in recurse | |
RuntimeError: Maximum recursion depth exceeded | |
\end{verbatim} | |
% | |
This traceback is a little bigger than the one we saw in the | |
previous chapter. When the error occurs, there are 1000 | |
{\tt recurse} frames on the stack! | |
\section{Keyboard input} | |
\index{keyboard input} | |
The programs we have written so far are a bit rude in the sense that | |
they accept no input from the user. They just do the same thing every | |
time. | |
Python 2 provides a built-in function called \verb"raw_input" that gets | |
input from the keyboard. In Python 3, it is called | |
{\tt input}. When this function is called, the program stops and | |
waits for the user to type something. When the user presses {\sf | |
Return} or {\sf Enter}, the program resumes and \verb"raw_input" | |
returns what the user typed as a string. | |
\index{Python 3} | |
\index{raw\_input function} | |
\index{function!raw\_input} | |
\begin{verbatim} | |
>>> text = raw_input() | |
What are you waiting for? | |
>>> print text | |
What are you waiting for? | |
\end{verbatim} | |
% | |
Before getting input from the user, it is a good idea to print a | |
prompt telling the user what to input. \verb"raw_input" can take a | |
prompt as an argument: | |
\index{prompt} | |
\begin{verbatim} | |
>>> name = raw_input('What...is your name?\n') | |
What...is your name? | |
Arthur, King of the Britons! | |
>>> print name | |
Arthur, King of the Britons! | |
\end{verbatim} | |
% | |
The sequence \verb"\n" at the end of the prompt represents a {\bf newline}, | |
which is a special character that causes a line break. | |
That's why the user's input appears below the prompt. | |
\index{newline} | |
If you expect the user to type an integer, you can try to convert | |
the return value to {\tt int}: | |
\begin{verbatim} | |
>>> prompt = 'What...is the airspeed velocity of an unladen swallow?\n' | |
>>> speed = raw_input(prompt) | |
What...is the airspeed velocity of an unladen swallow? | |
17 | |
>>> int(speed) | |
17 | |
\end{verbatim} | |
% | |
But if the user types something other than a string of digits, | |
you get an error: | |
\begin{verbatim} | |
>>> speed = raw_input(prompt) | |
What...is the airspeed velocity of an unladen swallow? | |
What do you mean, an African or a European swallow? | |
>>> int(speed) | |
ValueError: invalid literal for int() with base 10 | |
\end{verbatim} | |
% | |
We will see how to handle this kind of error later. | |
\index{ValueError} | |
\index{exception!ValueError} | |
\section{Debugging} | |
\label{whitespace} | |
\index{debugging} | |
\index{traceback} | |
The traceback Python displays when an error occurs contains | |
a lot of information, but it can be overwhelming, especially | |
when there are many frames on the stack. The most | |
useful parts are usually: | |
\begin{itemize} | |
\item What kind of error it was, and | |
\item Where it occurred. | |
\end{itemize} | |
Syntax errors are usually easy to find, but there are a few | |
gotchas. Whitespace errors can be tricky because spaces and | |
tabs are invisible and we are used to ignoring them. | |
\index{whitespace} | |
\begin{verbatim} | |
>>> x = 5 | |
>>> y = 6 | |
File "<stdin>", line 1 | |
y = 6 | |
^ | |
IndentationError: unexpected indent | |
\end{verbatim} | |
% | |
In this example, the problem is that the second line is indented by | |
one space. But the error message points to {\tt y}, which is | |
misleading. In general, error messages indicate where the problem was | |
discovered, but the actual error might be earlier in the code, | |
sometimes on a previous line. | |
\index{error!runtime} | |
\index{runtime error} | |
The same is true of runtime errors. | |
Suppose you are trying | |
to compute a signal-to-noise ratio in decibels. The formula | |
is $SNR_{db} = 10 \log_{10} (P_{signal} / P_{noise})$. In Python, | |
you might write something like this: | |
\begin{verbatim} | |
import math | |
signal_power = 9 | |
noise_power = 10 | |
ratio = signal_power / noise_power | |
decibels = 10 * math.log10(ratio) | |
print decibels | |
\end{verbatim} | |
% | |
But when you run it in Python 2, you get an error message. | |
\index{exception!OverflowError} | |
\index{OverflowError} | |
\begin{verbatim} | |
Traceback (most recent call last): | |
File "snr.py", line 5, in ? | |
decibels = 10 * math.log10(ratio) | |
ValueError: math domain error | |
\end{verbatim} | |
% | |
The error message indicates line 5, but there is nothing | |
wrong with that line. To find the real error, it might be | |
useful to print the value of {\tt ratio}, which turns out to | |
be 0. The problem is in line 4, because dividing two integers | |
does floor division. The solution is to represent signal power | |
and noise power with floating-point values. | |
\index{floor division} | |
\index{division!floor} | |
In general, error messages tell you where the problem was discovered, | |
but that is often not where it was caused. | |
In Python 3, this example does not cause an error; the division operator | |
performs floating-point division even with integer operands. | |
\section{Glossary} | |
\begin{description} | |
\item[modulus operator:] An operator, denoted with a percent sign | |
({\tt \%}), that works on integers and yields the remainder when one | |
number is divided by another. | |
\index{modulus operator} | |
\index{operator!modulus} | |
\item[boolean expression:] An expression whose value is either | |
{\tt True} or {\tt False}. | |
\index{boolean expression} | |
\index{expression!boolean} | |
\item[relational operator:] One of the operators that compares | |
its operands: {\tt ==}, {\tt !=}, {\tt >}, {\tt <}, {\tt >=}, and {\tt <=}. | |
\item[logical operator:] One of the operators that combines boolean | |
expressions: {\tt and}, {\tt or}, and {\tt not}. | |
\item[conditional statement:] A statement that controls the flow of | |
execution depending on some condition. | |
\index{conditional statement} | |
\index{statement!conditional} | |
\item[condition:] The boolean expression in a conditional statement | |
that determines which branch is executed. | |
\index{condition} | |
\item[compound statement:] A statement that consists of a header | |
and a body. The header ends with a colon (:). The body is indented | |
relative to the header. | |
\index{compound statement} | |
\item[branch:] One of the alternative sequences of statements in | |
a conditional statement. | |
\index{branch} | |
\item[chained conditional:] A conditional statement with a series | |
of alternative branches. | |
\index{chained conditional} | |
\index{conditional!chained} | |
\item[nested conditional:] A conditional statement that appears | |
in one of the branches of another conditional statement. | |
\index{nested conditional} | |
\index{conditional!nested} | |
\item[recursion:] The process of calling the function that is | |
currently executing. | |
\index{recursion} | |
\item[base case:] A conditional branch in a | |
recursive function that does not make a recursive call. | |
\index{base case} | |
\item[infinite recursion:] A recursion that doesn't have a | |
base case, or never reaches it. Eventually, an infinite recursion | |
causes a runtime error. | |
\index{infinite recursion} | |
\end{description} | |
\section{Exercises} | |
\begin{exercise} | |
\index{Fermat's Last Theorem} | |
Fermat's Last Theorem says that there are no positive integers | |
$a$, $b$, and $c$ such that | |
\[ a^n + b^n = c^n \] | |
% | |
for any values of $n$ greater than 2. | |
\begin{enumerate} | |
\item Write a function named \verb"check_fermat" that takes four | |
parameters---{\tt a}, {\tt b}, {\tt c} and {\tt n}---and | |
that checks to see if Fermat's theorem holds. If | |
$n$ is greater than 2 and it turns out to be true that | |
\[a^n + b^n = c^n \] | |
% | |
the program should print, ``Holy smokes, Fermat was wrong!'' | |
Otherwise the program should print, ``No, that doesn't work.'' | |
\item Write a function that prompts the user to input values | |
for {\tt a}, {\tt b}, {\tt c} and {\tt n}, converts them to | |
integers, and uses \verb"check_fermat" to check whether they | |
violate Fermat's theorem. | |
\end{enumerate} | |
\end{exercise} | |
\begin{exercise} | |
\index{triangle} | |
If you are given three sticks, you may or may not be able to arrange | |
them in a triangle. For example, if one of the sticks is 12 inches | |
long and the other two are one inch long, it is clear that you will | |
not be able to get the short sticks to meet in the middle. For any | |
three lengths, there is a simple test to see if it is possible to form | |
a triangle: | |
\begin{quotation} | |
If any of the three lengths is greater than the sum of the other | |
two, then you cannot form a triangle. Otherwise, you | |
can. (If the sum of two lengths equals the third, they form | |
what is called a ``degenerate'' triangle.) | |
\end{quotation} | |
\begin{enumerate} | |
\item Write a function named \verb"is_triangle" that takes three | |
integers as arguments, and that prints either ``Yes'' or ``No,'' depending | |
on whether you can or cannot form a triangle from sticks with the | |
given lengths. | |
\item Write a function that prompts the user to input three stick | |
lengths, converts them to integers, and uses \verb"is_triangle" to | |
check whether sticks with the given lengths can form a triangle. | |
\end{enumerate} | |
\end{exercise} | |
The following exercises use TurtleWorld from Chapter~\ref{turtlechap}: | |
\index{TurtleWorld} | |
\begin{exercise} | |
Read the following function and see if you can figure out | |
what it does. Then run it (see the examples in Chapter~\ref{turtlechap}). | |
\begin{verbatim} | |
def draw(t, length, n): | |
if n == 0: | |
return | |
angle = 50 | |
fd(t, length*n) | |
lt(t, angle) | |
draw(t, length, n-1) | |
rt(t, 2*angle) | |
draw(t, length, n-1) | |
lt(t, angle) | |
bk(t, length*n) | |
\end{verbatim} | |
\end{exercise} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/koch.pdf}} | |
\caption{A Koch curve.} | |
\label{fig.koch} | |
\end{figure} | |
\begin{exercise} | |
\index{Koch curve} | |
The Koch curve is a fractal that looks something like | |
Figure~\ref{fig.koch}. To draw a Koch curve with length $x$, all you | |
have to do is | |
\begin{enumerate} | |
\item Draw a Koch curve with length $x/3$. | |
\item Turn left 60 degrees. | |
\item Draw a Koch curve with length $x/3$. | |
\item Turn right 120 degrees. | |
\item Draw a Koch curve with length $x/3$. | |
\item Turn left 60 degrees. | |
\item Draw a Koch curve with length $x/3$. | |
\end{enumerate} | |
The exception is if $x$ is less than 3: in that case, | |
you can just draw a straight line with length $x$. | |
\begin{enumerate} | |
\item Write a function called {\tt koch} that takes a turtle and | |
a length as parameters, and that uses the turtle to draw a Koch | |
curve with the given length. | |
\item Write a function called {\tt snowflake} that draws three | |
Koch curves to make the outline of a snowflake. | |
Solution: \url{http://thinkpython.com/code/koch.py}. | |
\item The Koch curve can be generalized in several ways. See | |
\url{http://en.wikipedia.org/wiki/Koch_snowflake} for examples and | |
implement your favorite. | |
\end{enumerate} | |
\end{exercise} | |
\chapter{Fruitful functions} | |
\label{fruitchap} | |
\section{Return values} | |
\index{return value} | |
Some of the built-in functions we have used, such as the math | |
functions, produce results. Calling the function generates a | |
value, which we usually assign to a variable or use as part of an | |
expression. | |
\begin{verbatim} | |
e = math.exp(1.0) | |
height = radius * math.sin(radians) | |
\end{verbatim} | |
% | |
All of the functions we have written so far are void; they print | |
something or move turtles around, but their return value is {\tt | |
None}. | |
In this chapter, we are (finally) going to write fruitful functions. | |
The first example is {\tt area}, which returns the area of a circle | |
with the given radius: | |
\begin{verbatim} | |
def area(radius): | |
temp = math.pi * radius**2 | |
return temp | |
\end{verbatim} | |
% | |
We have seen the {\tt return} statement before, but in a fruitful | |
function the {\tt return} statement includes | |
an expression. This statement means: ``Return immediately from | |
this function and use the following expression as a return value.'' | |
The expression can be arbitrarily complicated, so we could | |
have written this function more concisely: | |
\index{return statement} | |
\index{statement!return} | |
\begin{verbatim} | |
def area(radius): | |
return math.pi * radius**2 | |
\end{verbatim} | |
% | |
On the other hand, {\bf temporary variables} like {\tt temp} often make | |
debugging easier. | |
\index{temporary variable} | |
\index{variable!temporary} | |
Sometimes it is useful to have multiple return statements, one in each | |
branch of a conditional: | |
\begin{verbatim} | |
def absolute_value(x): | |
if x < 0: | |
return -x | |
else: | |
return x | |
\end{verbatim} | |
% | |
Since these {\tt return} statements are in an alternative conditional, | |
only one will be executed. | |
As soon as a return statement executes, the function | |
terminates without executing any subsequent statements. | |
Code that appears after a {\tt return} statement, or any other place | |
the flow of execution can never reach, is called {\bf dead code}. | |
\index{dead code} | |
In a fruitful function, it is a good idea to ensure | |
that every possible path through the program hits a | |
{\tt return} statement. For example: | |
\begin{verbatim} | |
def absolute_value(x): | |
if x < 0: | |
return -x | |
if x > 0: | |
return x | |
\end{verbatim} | |
% | |
This function is incorrect because if {\tt x} happens to be 0, | |
neither condition is true, and the function ends without hitting a | |
{\tt return} statement. If the flow of execution gets to the end | |
of a function, the return value is {\tt None}, which is not | |
the absolute value of 0. | |
\index{None special value} | |
\index{special value!None} | |
\begin{verbatim} | |
>>> print absolute_value(0) | |
None | |
\end{verbatim} | |
% | |
By the way, Python provides a built-in function called | |
{\tt abs} that computes absolute values. | |
\index{abs function} | |
\index{function!abs} | |
\begin{exercise} | |
\index{compare function} | |
\index{function!compare} | |
Write a {\tt compare} function | |
that returns {\tt 1} if {\tt x > y}, | |
{\tt 0} if {\tt x == y}, and {\tt -1} if {\tt x < y}. | |
\end{exercise} | |
\section{Incremental development} | |
\label{incremental.development} | |
\index{development plan!incremental} | |
As you write larger functions, you might find yourself | |
spending more time debugging. | |
To deal with increasingly complex programs, | |
you might want to try a process called | |
{\bf incremental development}. The goal of incremental development | |
is to avoid long debugging sessions by adding and testing only | |
a small amount of code at a time. | |
\index{testing!incremental development} | |
\index{Pythagorean theorem} | |
As an example, suppose you want to find the distance between two | |
points, given by the coordinates $(x_1, y_1)$ and $(x_2, y_2)$. | |
By the Pythagorean theorem, the distance is: | |
\begin{displaymath} | |
\mathrm{distance} = \sqrt{(x_2 - x_1)^2 + (y_2 - y_1)^2} | |
\end{displaymath} | |
% | |
The first step is to consider what a {\tt distance} function should | |
look like in Python. In other words, what are the inputs (parameters) | |
and what is the output (return value)? | |
In this case, the inputs are two points, which you can represent | |
using four numbers. The return value is the distance, which is | |
a floating-point value. | |
Already you can write an outline of the function: | |
\begin{verbatim} | |
def distance(x1, y1, x2, y2): | |
return 0.0 | |
\end{verbatim} | |
% | |
Obviously, this version doesn't compute distances; it always returns | |
zero. But it is syntactically correct, and it runs, which means that | |
you can test it before you make it more complicated. | |
To test the new function, call it with sample arguments: | |
\begin{verbatim} | |
>>> distance(1, 2, 4, 6) | |
0.0 | |
\end{verbatim} | |
% | |
I chose these values so that the horizontal distance is 3 and the | |
vertical distance is 4; that way, the result is 5 | |
(the hypotenuse of a 3-4-5 triangle). When testing a function, it is | |
useful to know the right answer. | |
\index{testing!knowing the answer} | |
At this point we have confirmed that the function is syntactically | |
correct, and we can start adding code to the body. | |
A reasonable next step is to find the differences | |
$x_2 - x_1$ and $y_2 - y_1$. The next version stores those values in | |
temporary variables and prints them. | |
\begin{verbatim} | |
def distance(x1, y1, x2, y2): | |
dx = x2 - x1 | |
dy = y2 - y1 | |
print 'dx is', dx | |
print 'dy is', dy | |
return 0.0 | |
\end{verbatim} | |
% | |
If the function is working, it should display \verb"'dx is 3'" and {\tt | |
'dy is 4'}. If so, we know that the function is getting the right | |
arguments and performing the first computation correctly. If not, | |
there are only a few lines to check. | |
Next we compute the sum of squares of {\tt dx} and {\tt dy}: | |
\begin{verbatim} | |
def distance(x1, y1, x2, y2): | |
dx = x2 - x1 | |
dy = y2 - y1 | |
dsquared = dx**2 + dy**2 | |
print 'dsquared is: ', dsquared | |
return 0.0 | |
\end{verbatim} | |
% | |
Again, you would run the program at this stage and check the output | |
(which should be 25). | |
Finally, you can use {\tt math.sqrt} to compute and return the result: | |
\index{sqrt} | |
\index{function!sqrt} | |
\begin{verbatim} | |
def distance(x1, y1, x2, y2): | |
dx = x2 - x1 | |
dy = y2 - y1 | |
dsquared = dx**2 + dy**2 | |
result = math.sqrt(dsquared) | |
return result | |
\end{verbatim} | |
% | |
If that works correctly, you are done. Otherwise, you might | |
want to print the value of {\tt result} before the return | |
statement. | |
The final version of the function doesn't display anything when it | |
runs; it only returns a value. The {\tt print} statements we wrote | |
are useful for debugging, but once you get the function working, you | |
should remove them. Code like that is called {\bf scaffolding} | |
because it is helpful for building the program but is not part of the | |
final product. | |
\index{scaffolding} | |
When you start out, you should add only a line or two of code at a | |
time. As you gain more experience, you might find yourself writing | |
and debugging bigger chunks. Either way, incremental development | |
can save you a lot of debugging time. | |
The key aspects of the process are: | |
\begin{enumerate} | |
\item Start with a working program and make small incremental changes. | |
At any point, if there is an error, you should have a good idea | |
where it is. | |
\item Use temporary variables to hold intermediate values so you can | |
display and check them. | |
\item Once the program is working, you might want to remove some of | |
the scaffolding or consolidate multiple statements into compound | |
expressions, but only if it does not make the program difficult to | |
read. | |
\end{enumerate} | |
\begin{exercise} | |
\index{hypotenuse} | |
Use incremental development to write a function | |
called {\tt hypotenuse} that returns the length of the hypotenuse of a | |
right triangle given the lengths of the two legs as arguments. | |
Record each stage of the development process as you go. | |
\end{exercise} | |
\section{Composition} | |
\index{composition} | |
\index{function composition} | |
As you should expect by now, you can call one function from | |
within another. This ability is called {\bf composition}. | |
As an example, we'll write a function that takes two points, | |
the center of the circle and a point on the perimeter, and computes | |
the area of the circle. | |
Assume that the center point is stored in the variables {\tt xc} and | |
{\tt yc}, and the perimeter point is in {\tt xp} and {\tt yp}. The | |
first step is to find the radius of the circle, which is the distance | |
between the two points. We just wrote a function, {\tt | |
distance}, that does that: | |
\begin{verbatim} | |
radius = distance(xc, yc, xp, yp) | |
\end{verbatim} | |
% | |
The next step is to find the area of a circle with that radius; | |
we just wrote that, too: | |
\begin{verbatim} | |
result = area(radius) | |
\end{verbatim} | |
% | |
Encapsulating these steps in a function, we get: | |
\index{encapsulation} | |
\begin{verbatim} | |
def circle_area(xc, yc, xp, yp): | |
radius = distance(xc, yc, xp, yp) | |
result = area(radius) | |
return result | |
\end{verbatim} | |
% | |
The temporary variables {\tt radius} and {\tt result} are useful for | |
development and debugging, but once the program is working, we can | |
make it more concise by composing the function calls: | |
\begin{verbatim} | |
def circle_area(xc, yc, xp, yp): | |
return area(distance(xc, yc, xp, yp)) | |
\end{verbatim} | |
% | |
\section{Boolean functions} | |
\label{boolean} | |
Functions can return booleans, which is often convenient for hiding | |
complicated tests inside functions. \index{boolean function} | |
For example: | |
\begin{verbatim} | |
def is_divisible(x, y): | |
if x % y == 0: | |
return True | |
else: | |
return False | |
\end{verbatim} | |
% | |
It is common to give boolean functions names that sound like yes/no | |
questions; \verb"is_divisible" returns either {\tt True} or {\tt False} | |
to indicate whether {\tt x} is divisible by {\tt y}. | |
Here is an example: | |
\begin{verbatim} | |
>>> is_divisible(6, 4) | |
False | |
>>> is_divisible(6, 3) | |
True | |
\end{verbatim} | |
% | |
The result of the {\tt ==} operator is a boolean, so we can write the | |
function more concisely by returning it directly: | |
\begin{verbatim} | |
def is_divisible(x, y): | |
return x % y == 0 | |
\end{verbatim} | |
% | |
Boolean functions are often used in conditional statements: | |
\index{conditional statement} | |
\index{statement!conditional} | |
\begin{verbatim} | |
if is_divisible(x, y): | |
print 'x is divisible by y' | |
\end{verbatim} | |
% | |
It might be tempting to write something like: | |
\begin{verbatim} | |
if is_divisible(x, y) == True: | |
print 'x is divisible by y' | |
\end{verbatim} | |
% | |
But the extra comparison is unnecessary. | |
\begin{exercise} | |
Write a function \verb"is_between(x, y, z)" that | |
returns {\tt True} if $x \le y \le z$ or {\tt False} otherwise. | |
\end{exercise} | |
\section{More recursion} | |
\label{more.recursion} | |
\index{recursion} | |
\index{Turing complete language} | |
\index{language!Turing complete} | |
\index{Turing, Alan} | |
\index{Turing Thesis} | |
We have only covered a small subset of Python, but you might | |
be interested to know that this subset is a {\em complete} | |
programming language, which means that anything that can be | |
computed can be expressed in this language. Any program ever written | |
could be rewritten using only the language features you have learned | |
so far (actually, you would need a few commands to control devices | |
like the keyboard, mouse, disks, etc., but that's all). | |
Proving that claim is a nontrivial exercise first accomplished by Alan | |
Turing, one of the first computer scientists (some would argue that he | |
was a mathematician, but a lot of early computer scientists started as | |
mathematicians). Accordingly, it is known as the Turing Thesis. | |
For a more complete (and accurate) discussion of the Turing Thesis, | |
I recommend Michael Sipser's book {\em Introduction to the | |
Theory of Computation}. | |
To give you an idea of what you can do with the tools you have learned | |
so far, we'll evaluate a few recursively defined mathematical | |
functions. A recursive definition is similar to a circular | |
definition, in the sense that the definition contains a reference to | |
the thing being defined. A truly circular definition is not very | |
useful: | |
\begin{description} | |
\item[vorpal:] An adjective used to describe something that is vorpal. | |
\index{vorpal} | |
\index{circular definition} | |
\index{definition!circular} | |
\end{description} | |
If you saw that definition in the dictionary, you might be annoyed. On | |
the other hand, if you looked up the definition of the factorial | |
function, denoted with the symbol $!$, you might get something like | |
this: | |
% | |
\begin{eqnarray*} | |
&& 0! = 1 \\ | |
&& n! = n (n-1)! | |
\end{eqnarray*} | |
% | |
This definition says that the factorial of 0 is 1, and the factorial | |
of any other value, $n$, is $n$ multiplied by the factorial of $n-1$. | |
So $3!$ is 3 times $2!$, which is 2 times $1!$, which is 1 times | |
$0!$. Putting it all together, $3!$ equals 3 times 2 times 1 times 1, | |
which is 6. | |
\index{factorial function} | |
\index{function!factorial} | |
\index{recursive definition} | |
If you can write a recursive definition of something, you can usually | |
write a Python program to evaluate it. The first step is to decide | |
what the parameters should be. In this case it should be clear | |
that {\tt factorial} takes an integer: | |
\begin{verbatim} | |
def factorial(n): | |
\end{verbatim} | |
% | |
If the argument happens to be 0, all we have to do is return 1: | |
\begin{verbatim} | |
def factorial(n): | |
if n == 0: | |
return 1 | |
\end{verbatim} | |
% | |
Otherwise, and this is the interesting part, we have to make a | |
recursive call to find the factorial of $n-1$ and then multiply it by | |
$n$: | |
\begin{verbatim} | |
def factorial(n): | |
if n == 0: | |
return 1 | |
else: | |
recurse = factorial(n-1) | |
result = n * recurse | |
return result | |
\end{verbatim} | |
% | |
The flow of execution for this program is similar to the flow of {\tt | |
countdown} in Section~\ref{recursion}. If we call {\tt factorial} | |
with the value 3: | |
Since 3 is not 0, we take the second branch and calculate the factorial | |
of {\tt n-1}... | |
\begin{quote} | |
Since 2 is not 0, we take the second branch and calculate the factorial of | |
{\tt n-1}... | |
\begin{quote} | |
Since 1 is not 0, we take the second branch and calculate the factorial | |
of {\tt n-1}... | |
\begin{quote} | |
Since 0 {\em is} 0, we take the first branch and return 1 | |
without making any more recursive calls. | |
\end{quote} | |
The return value (1) is multiplied by $n$, which is 1, and the | |
result is returned. | |
\end{quote} | |
The return value (1) is multiplied by $n$, which is 2, and the | |
result is returned. | |
\end{quote} | |
The return value (2) is multiplied by $n$, which is 3, and the result, 6, | |
becomes the return value of the function call that started the whole | |
process. | |
\index{stack diagram} | |
Figure~\ref{fig.stack3} shows what the stack diagram looks like for | |
this sequence of function calls. | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/stack3.pdf}} | |
\caption{Stack diagram.} | |
\label{fig.stack3} | |
\end{figure} | |
The return values are shown being passed back up the stack. In each | |
frame, the return value is the value of {\tt result}, which is the | |
product of {\tt n} and {\tt recurse}. | |
\index{function frame} | |
\index{frame} | |
In the last frame, the local | |
variables {\tt recurse} and {\tt result} do not exist, because | |
the branch that creates them does not execute. | |
\section{Leap of faith} | |
\index{recursion} | |
\index{leap of faith} | |
Following the flow of execution is one way to read programs, but | |
it can quickly become labyrinthine. An | |
alternative is what I call the ``leap of faith.'' When you come to a | |
function call, instead of following the flow of execution, you {\em | |
assume} that the function works correctly and returns the right | |
result. | |
In fact, you are already practicing this leap of faith when you use | |
built-in functions. When you call {\tt math.cos} or {\tt math.exp}, | |
you don't examine the bodies of those functions. You just | |
assume that they work because the people who wrote the built-in | |
functions were good programmers. | |
The same is true when you call one of your own functions. For | |
example, in Section~\ref{boolean}, we wrote a function called | |
\verb"is_divisible" that determines whether one number is divisible by | |
another. Once we have convinced ourselves that this function is | |
correct---by examining the code and testing---we can use the function | |
without looking at the body again. | |
\index{testing!leap of faith} | |
The same is true of recursive programs. When you get to the recursive | |
call, instead of following the flow of execution, you should assume | |
that the recursive call works (yields the correct result) and then ask | |
yourself, ``Assuming that I can find the factorial of $n-1$, can I | |
compute the factorial of $n$?'' In this case, it is clear that you | |
can, by multiplying by $n$. | |
Of course, it's a bit strange to assume that the function works | |
correctly when you haven't finished writing it, but that's why | |
it's called a leap of faith! | |
\section{One more example} | |
\label{one.more.example} | |
\index{fibonacci function} | |
\index{function!fibonacci} | |
After {\tt factorial}, the most common example of a recursively | |
defined mathematical function is {\tt fibonacci}, which has the | |
following definition (see | |
\url{http://en.wikipedia.org/wiki/Fibonacci_number}): | |
% | |
\begin{eqnarray*} | |
&& \mathrm{fibonacci}(0) = 0 \\ | |
&& \mathrm{fibonacci}(1) = 1 \\ | |
&& \mathrm{fibonacci}(n) = \mathrm{fibonacci}(n-1) + \mathrm{fibonacci}(n-2) | |
\end{eqnarray*} | |
% | |
Translated into Python, it looks like this: | |
\begin{verbatim} | |
def fibonacci (n): | |
if n == 0: | |
return 0 | |
elif n == 1: | |
return 1 | |
else: | |
return fibonacci(n-1) + fibonacci(n-2) | |
\end{verbatim} | |
% | |
If you try to follow the flow of execution here, even for fairly | |
small values of $n$, your head explodes. But according to the | |
leap of faith, if you assume that the two recursive calls | |
work correctly, then it is clear that you get | |
the right result by adding them together. | |
\index{flow of execution} | |
\section{Checking types} | |
\label{guardian} | |
What happens if we call {\tt factorial} and give it 1.5 as an argument? | |
\index{type checking} | |
\index{error checking} | |
\index{factorial function} | |
\index{RuntimeError} | |
\begin{verbatim} | |
>>> factorial(1.5) | |
RuntimeError: Maximum recursion depth exceeded | |
\end{verbatim} | |
% | |
It looks like an infinite recursion. But how can that be? There is a | |
base case---when {\tt n == 0}. But if {\tt n} is not an integer, | |
we can {\em miss} the base case and recurse forever. | |
\index{infinite recursion} | |
\index{recursion!infinite} | |
In the first recursive call, the value of {\tt n} is 0.5. | |
In the next, it is -0.5. From there, it gets smaller | |
(more negative), but it will never be 0. | |
We have two choices. We can try to generalize the {\tt factorial} | |
function to work with floating-point numbers, or we can make {\tt | |
factorial} check the type of its argument. The first option is | |
called the gamma function and it's a | |
little beyond the scope of this book. So we'll go for the second. | |
\index{gamma function} | |
We can use the built-in function {\tt isinstance} to verify the type | |
of the argument. While we're at it, we can also make sure the | |
argument is positive: | |
\index{isinstance function} | |
\index{function!isinstance} | |
\begin{verbatim} | |
def factorial (n): | |
if not isinstance(n, int): | |
print 'Factorial is only defined for integers.' | |
return None | |
elif n < 0: | |
print 'Factorial is not defined for negative integers.' | |
return None | |
elif n == 0: | |
return 1 | |
else: | |
return n * factorial(n-1) | |
\end{verbatim} | |
% | |
The first base case handles nonintegers; the | |
second catches negative integers. In both cases, the program prints | |
an error message and returns {\tt None} to indicate that something | |
went wrong: | |
\begin{verbatim} | |
>>> factorial('fred') | |
Factorial is only defined for integers. | |
None | |
>>> factorial(-2) | |
Factorial is not defined for negative integers. | |
None | |
\end{verbatim} | |
% | |
If we get past both checks, then we know that $n$ is positive or | |
zero, so we can prove that the recursion terminates. | |
\index{guardian pattern} | |
\index{pattern!guardian} | |
This program demonstrates a pattern sometimes called a {\bf guardian}. | |
The first two conditionals act as guardians, protecting the code that | |
follows from values that might cause an error. The guardians make it | |
possible to prove the correctness of the code. | |
In Section~\ref{raise} we will see a more flexible alternative to printing | |
an error message: raising an exception. | |
\section{Debugging} | |
\label{factdebug} | |
Breaking a large program into smaller functions creates natural | |
checkpoints for debugging. \index{debugging} | |
If a function is not working, there are | |
three possibilities to consider: | |
\begin{itemize} | |
\item There is something wrong with the arguments the function | |
is getting; a precondition is violated. | |
\item There is something wrong with the function; a postcondition | |
is violated. | |
\item There is something wrong with the return value or the | |
way it is being used. | |
\end{itemize} | |
To rule out the first possibility, you can add a {\tt print} statement | |
at the beginning of the function and display the values of the | |
parameters (and maybe their types). Or you can write code | |
that checks the preconditions explicitly. | |
\index{precondition} | |
\index{postcondition} | |
If the parameters look good, add a {\tt print} statement before each | |
{\tt return} statement that displays the return value. If | |
possible, check the result by hand. Consider calling the | |
function with values that make it easy to check the result | |
(as in Section~\ref{incremental.development}). | |
If the function seems to be working, look at the function call | |
to make sure the return value is being used correctly (or used | |
at all!). | |
\index{flow of execution} | |
Adding print statements at the beginning and end of a function | |
can help make the flow of execution more visible. | |
For example, here is a version of {\tt factorial} with | |
print statements: | |
\begin{verbatim} | |
def factorial(n): | |
space = ' ' * (4 * n) | |
print space, 'factorial', n | |
if n == 0: | |
print space, 'returning 1' | |
return 1 | |
else: | |
recurse = factorial(n-1) | |
result = n * recurse | |
print space, 'returning', result | |
return result | |
\end{verbatim} | |
% | |
{\tt space} is a string of space characters that controls the | |
indentation of the output. Here is the result of {\tt factorial(5)} : | |
\begin{verbatim} | |
factorial 5 | |
factorial 4 | |
factorial 3 | |
factorial 2 | |
factorial 1 | |
factorial 0 | |
returning 1 | |
returning 1 | |
returning 2 | |
returning 6 | |
returning 24 | |
returning 120 | |
\end{verbatim} | |
% | |
If you are confused about the flow of execution, this kind of | |
output can be helpful. It takes some time to develop effective | |
scaffolding, but a little bit of scaffolding can save a lot of debugging. | |
\section{Glossary} | |
\begin{description} | |
\item[temporary variable:] A variable used to store an intermediate value in | |
a complex calculation. | |
\index{temporary variable} | |
\index{variable!temporary} | |
\item[dead code:] Part of a program that can never be executed, often because | |
it appears after a {\tt return} statement. | |
\index{dead code} | |
\item[{\tt None}:] A special value returned by functions that | |
have no return statement or a return statement without an argument. | |
\index{None special value} | |
\index{special value!None} | |
\item[incremental development:] A program development plan intended to | |
avoid debugging by adding and testing only | |
a small amount of code at a time. | |
\index{incremental development} | |
\item[scaffolding:] Code that is used during program development but is | |
not part of the final version. | |
\index{scaffolding} | |
\item[guardian:] A programming pattern that uses a conditional | |
statement to check for and handle circumstances that | |
might cause an error. | |
\index{guardian pattern} | |
\index{pattern!guardian} | |
\end{description} | |
\section{Exercises} | |
\begin{exercise} | |
Draw a stack diagram for the following program. What does the program print? | |
Solution: \url{http://thinkpython.com/code/stack_diagram.py}. | |
\index{stack diagram} | |
\begin{verbatim} | |
def b(z): | |
prod = a(z, z) | |
print z, prod | |
return prod | |
def a(x, y): | |
x = x + 1 | |
return x * y | |
def c(x, y, z): | |
total = x + y + z | |
square = b(total)**2 | |
return square | |
x = 1 | |
y = x + 1 | |
print c(x, y+3, x+y) | |
\end{verbatim} | |
\end{exercise} | |
\begin{exercise} | |
\label{ackermann} | |
The Ackermann function, $A(m, n)$, is defined: | |
\begin{eqnarray*} | |
A(m, n) = \begin{cases} | |
n+1 & \mbox{if } m = 0 \\ | |
A(m-1, 1) & \mbox{if } m > 0 \mbox{ and } n = 0 \\ | |
A(m-1, A(m, n-1)) & \mbox{if } m > 0 \mbox{ and } n > 0. | |
\end{cases} | |
\end{eqnarray*} | |
% | |
See \url{http://en.wikipedia.org/wiki/Ackermann_function}. | |
Write a function named {\tt ack} that evaluates Ackermann's function. | |
Use your function to evaluate {\tt ack(3, 4)}, which should be 125. | |
What happens for larger values of {\tt m} and {\tt n}? | |
Solution: \url{http://thinkpython.com/code/ackermann.py}. | |
\index{Ackermann function} | |
\index{function!ack} | |
\end{exercise} | |
\begin{exercise} | |
\label{palindrome} | |
A palindrome is a word that is spelled the same backward and | |
forward, like ``noon'' and ``redivider''. Recursively, a word | |
is a palindrome if the first and last letters are the same | |
and the middle is a palindrome. | |
\index{palindrome} | |
The following are functions that take a string argument and | |
return the first, last, and middle letters: | |
\begin{verbatim} | |
def first(word): | |
return word[0] | |
def last(word): | |
return word[-1] | |
def middle(word): | |
return word[1:-1] | |
\end{verbatim} | |
% | |
We'll see how they work in Chapter~\ref{strings}. | |
\begin{enumerate} | |
\item Type these functions into a file named {\tt palindrome.py} | |
and test them out. What happens if you call {\tt middle} with | |
a string with two letters? One letter? What about the empty | |
string, which is written \verb"''" and contains no letters? | |
\item Write a function called \verb"is_palindrome" that takes | |
a string argument and returns {\tt True} if it is a palindrome | |
and {\tt False} otherwise. Remember that you can use the | |
built-in function {\tt len} to check the length of a string. | |
\end{enumerate} | |
Solution: \url{http://thinkpython.com/code/palindrome_soln.py}. | |
\end{exercise} | |
\begin{exercise} | |
A number, $a$, is a power of $b$ if it is divisible by $b$ | |
and $a/b$ is a power of $b$. Write a function called | |
\verb"is_power" that takes parameters {\tt a} and {\tt b} | |
and returns {\tt True} if {\tt a} is a power of {\tt b}. | |
Note: you will have to think about the base case. | |
\end{exercise} | |
\begin{exercise} | |
\index{greatest common divisor (GCD)} | |
\index{GCD (greatest common divisor)} | |
The greatest common divisor (GCD) of $a$ and $b$ is the largest number | |
that divides both of them with no remainder. | |
One way to find the GCD of two numbers is based on the observation | |
that if $r$ is the remainder when $a$ is divided by $b$, then $gcd(a, | |
b) = gcd(b, r)$. As a base case, we can use $gcd(a, 0) = a$. | |
Write a function called | |
\verb"gcd" that takes parameters {\tt a} and {\tt b} | |
and returns their greatest common divisor. | |
Credit: This exercise is based on an example from Abelson and | |
Sussman's {\em Structure and Interpretation of Computer Programs}. | |
\end{exercise} | |
\chapter{Iteration} | |
\section{Multiple assignment} | |
\index{assignment} | |
\index{statement!assignment} | |
\index{multiple assignment} | |
As you may have discovered, it is legal to | |
make more than one assignment to the same variable. A | |
new assignment makes an existing variable refer to a new | |
value (and stop referring to the old value). | |
\begin{verbatim} | |
bruce = 5 | |
print bruce, | |
bruce = 7 | |
print bruce | |
\end{verbatim} | |
% | |
The output of this program is {\tt 5 7}, because the first time | |
{\tt bruce} is printed, its value is 5, and the second time, its | |
value is 7. The | |
comma at the end of the first {\tt print} statement suppresses | |
the newline, which is why both outputs | |
appear on the same line. | |
\index{newline} | |
Figure~\ref{fig.assign2} shows what {\bf multiple assignment} looks | |
like in a state diagram. \index{state diagram} \index{diagram!state} | |
With multiple assignment it is especially important to distinguish | |
between an assignment operation and a statement of equality. Because | |
Python uses the equal sign ({\tt =}) for assignment, it is tempting to | |
interpret a statement like {\tt a = b} as a statement of equality. It | |
is not! | |
\index{equality and assignment} | |
First, equality is a symmetric relation and assignment is not. For | |
example, in mathematics, if $a=7$ then $7=a$. But in Python, the | |
statement {\tt a = 7} is legal and {\tt 7 = a} is not. | |
Furthermore, in mathematics, a statement of equality is either true or | |
false, for all time. If $a=b$ now, then $a$ will always equal $b$. | |
In Python, an assignment statement can make two variables equal, but | |
they don't have to stay that way: | |
\begin{verbatim} | |
a = 5 | |
b = a # a and b are now equal | |
a = 3 # a and b are no longer equal | |
\end{verbatim} | |
% | |
The third line changes the value of {\tt a} but does not change the | |
value of {\tt b}, so they are no longer equal. | |
Although multiple assignment is frequently helpful, you should use it | |
with caution. If the values of variables change frequently, it can | |
make the code difficult to read and debug. | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/assign2.pdf}} | |
\caption{State diagram.} | |
\label{fig.assign2} | |
\end{figure} | |
\section{Updating variables} | |
\label{update} | |
\index{update} | |
\index{variable!updating} | |
One of the most common forms of multiple assignment is an {\bf update}, | |
where the new value of the variable depends on the old. | |
\begin{verbatim} | |
x = x+1 | |
\end{verbatim} | |
% | |
This means ``get the current value of {\tt x}, add one, and then | |
update {\tt x} with the new value.'' | |
If you try to update a variable that doesn't exist, you get an | |
error, because Python evaluates the right side before it assigns | |
a value to {\tt x}: | |
\begin{verbatim} | |
>>> x = x+1 | |
NameError: name 'x' is not defined | |
\end{verbatim} | |
% | |
Before you can update a variable, you have to {\bf initialize} | |
it, usually with a simple assignment: | |
\index{initialization (before update)} | |
\begin{verbatim} | |
>>> x = 0 | |
>>> x = x+1 | |
\end{verbatim} | |
% | |
Updating a variable by adding 1 is called an {\bf increment}; | |
subtracting 1 is called a {\bf decrement}. | |
\index{increment} | |
\index{decrement} | |
\section{The {\tt while} statement} | |
\index{statement!while} | |
\index{while loop} | |
\index{loop!while} | |
\index{iteration} | |
Computers are often used to automate repetitive tasks. Repeating | |
identical or similar tasks without making errors is something that | |
computers do well and people do poorly. | |
We have seen two programs, {\tt countdown} and \verb"print_n", that | |
use recursion to perform repetition, which is also called {\bf | |
iteration}. Because iteration is so common, Python provides several | |
language features to make it easier. One is the {\tt for} statement | |
we saw in Section~\ref{repetition}. We'll get back to that later. | |
Another is the {\tt while} statement. Here is a version of {\tt | |
countdown} that uses a {\tt while} statement: | |
\begin{verbatim} | |
def countdown(n): | |
while n > 0: | |
print n | |
n = n-1 | |
print 'Blastoff!' | |
\end{verbatim} | |
% | |
You can almost read the {\tt while} statement as if it were English. | |
It means, ``While {\tt n} is greater than 0, | |
display the value of {\tt n} and then reduce the value of | |
{\tt n} by 1. When you get to 0, display the word {\tt Blastoff!}'' | |
\index{flow of execution} | |
More formally, here is the flow of execution for a {\tt while} statement: | |
\begin{enumerate} | |
\item Evaluate the condition, yielding {\tt True} or {\tt False}. | |
\item If the condition is false, exit the {\tt while} statement | |
and continue execution at the next statement. | |
\item If the condition is true, execute the | |
body and then go back to step 1. | |
\end{enumerate} | |
This type of flow is called a {\bf loop} because the third step | |
loops back around to the top. | |
\index{condition} | |
\index{loop} | |
\index{body} | |
The body of the loop should change the value of one or more variables | |
so that eventually the condition becomes false and the loop | |
terminates. Otherwise the loop will repeat forever, which is called | |
an {\bf infinite loop}. An endless source of amusement for computer | |
scientists is the observation that the directions on shampoo, | |
``Lather, rinse, repeat,'' are an infinite loop. | |
\index{infinite loop} | |
\index{loop!infinite} | |
In the case of {\tt countdown}, we can prove that the loop | |
terminates because we know that the value of {\tt n} is finite, and we | |
can see that the value of {\tt n} gets smaller each time through the | |
loop, so eventually we have to get to 0. In other | |
cases, it is not so easy to tell: | |
\begin{verbatim} | |
def sequence(n): | |
while n != 1: | |
print n, | |
if n%2 == 0: # n is even | |
n = n/2 | |
else: # n is odd | |
n = n*3+1 | |
\end{verbatim} | |
% | |
The condition for this loop is {\tt n != 1}, so the loop will continue | |
until {\tt n} is {\tt 1}, which makes the condition false. | |
Each time through the loop, the program outputs the value of {\tt n} | |
and then checks whether it is even or odd. If it is even, {\tt n} is | |
divided by 2. If it is odd, the value of {\tt n} is replaced with | |
{\tt n*3+1}. For example, if the argument passed | |
to {\tt sequence} is 3, the resulting sequence is 3, 10, 5, 16, 8, 4, 2, 1. | |
Since {\tt n} sometimes increases and sometimes decreases, there is no | |
obvious proof that {\tt n} will ever reach 1, or that the program | |
terminates. For some particular values of {\tt n}, we can prove | |
termination. For example, if the starting value is a power of two, | |
then the value of {\tt n} will be even each time through the loop | |
until it reaches 1. The previous example ends with such a sequence, | |
starting with 16. | |
\index{Collatz conjecture} | |
The hard question is whether we can prove that this program terminates | |
for {\em all positive values} of {\tt n}. So far, no one has | |
been able to prove it {\em or} disprove it! (See | |
\url{http://en.wikipedia.org/wiki/Collatz_conjecture}.) | |
\begin{exercise} | |
Rewrite the function \verb"print_n" from | |
Section~\ref{recursion} using iteration instead of recursion. | |
\end{exercise} | |
\section{{\tt break}} | |
\index{break statement} | |
\index{statement!break} | |
Sometimes you don't know it's time to end a loop until you get half | |
way through the body. In that case you can use the {\tt break} | |
statement to jump out of the loop. | |
For example, suppose you want to take input from the user until they | |
type {\tt done}. You could write: | |
\begin{verbatim} | |
while True: | |
line = raw_input('> ') | |
if line == 'done': | |
break | |
print line | |
print 'Done!' | |
\end{verbatim} | |
% | |
The loop condition is {\tt True}, which is always true, so the | |
loop runs until it hits the break statement. | |
Each time through, it prompts the user with an angle bracket. | |
If the user types {\tt done}, the {\tt break} statement exits | |
the loop. Otherwise the program echoes whatever the user types | |
and goes back to the top of the loop. Here's a sample run: | |
\begin{verbatim} | |
> not done | |
not done | |
> done | |
Done! | |
\end{verbatim} | |
% | |
This way of writing {\tt while} loops is common because you | |
can check the condition anywhere in the loop (not just at the | |
top) and you can express the stop condition affirmatively | |
(``stop when this happens'') rather than negatively (``keep going | |
until that happens.''). | |
\section{Square roots} | |
\label{squareroot} | |
\index{square root} | |
Loops are often used in programs that compute | |
numerical results by starting with an approximate answer and | |
iteratively improving it. | |
\index{Newton's method} | |
For example, one way of computing square roots is Newton's method. | |
Suppose that you want to know the square root of $a$. If you start | |
with almost any estimate, $x$, you can compute a better | |
estimate with the following formula: | |
\[ y = \frac{x + a/x}{2} \] | |
% | |
For example, if $a$ is 4 and $x$ is 3: | |
\begin{verbatim} | |
>>> a = 4.0 | |
>>> x = 3.0 | |
>>> y = (x + a/x) / 2 | |
>>> print y | |
2.16666666667 | |
\end{verbatim} | |
% | |
Which is closer to the correct answer ($\sqrt{4} = 2$). If we | |
repeat the process with the new estimate, it gets even closer: | |
\begin{verbatim} | |
>>> x = y | |
>>> y = (x + a/x) / 2 | |
>>> print y | |
2.00641025641 | |
\end{verbatim} | |
% | |
After a few more updates, the estimate is almost exact: | |
\index{update} | |
\begin{verbatim} | |
>>> x = y | |
>>> y = (x + a/x) / 2 | |
>>> print y | |
2.00001024003 | |
>>> x = y | |
>>> y = (x + a/x) / 2 | |
>>> print y | |
2.00000000003 | |
\end{verbatim} | |
% | |
In general we don't know ahead of time how many steps it takes | |
to get to the right answer, but we know when we get there | |
because the estimate | |
stops changing: | |
\begin{verbatim} | |
>>> x = y | |
>>> y = (x + a/x) / 2 | |
>>> print y | |
2.0 | |
>>> x = y | |
>>> y = (x + a/x) / 2 | |
>>> print y | |
2.0 | |
\end{verbatim} | |
% | |
When {\tt y == x}, we can stop. Here is a loop that starts | |
with an initial estimate, {\tt x}, and improves it until it | |
stops changing: | |
\begin{verbatim} | |
while True: | |
print x | |
y = (x + a/x) / 2 | |
if y == x: | |
break | |
x = y | |
\end{verbatim} | |
% | |
For most values of {\tt a} this works fine, but in general it is | |
dangerous to test {\tt float} equality. | |
Floating-point values are only approximately right: | |
most rational numbers, like $1/3$, and irrational numbers, like | |
$\sqrt{2}$, can't be represented exactly with a {\tt float}. | |
\index{floating-point} | |
\index{epsilon} | |
Rather than checking whether {\tt x} and {\tt y} are exactly equal, it | |
is safer to use the built-in function {\tt abs} to compute the | |
absolute value, or magnitude, of the difference between them: | |
\begin{verbatim} | |
if abs(y-x) < epsilon: | |
break | |
\end{verbatim} | |
% | |
Where \verb"epsilon" has a value like {\tt 0.0000001} that | |
determines how close is close enough. | |
\begin{exercise} | |
Encapsulate this loop in a function called \verb"square_root" | |
that takes {\tt a} as a parameter, chooses a reasonable | |
value of {\tt x}, and returns an estimate of the square root | |
of {\tt a}. | |
\index{encapsulation} | |
\end{exercise} | |
\section{Algorithms} | |
\index{algorithm} | |
Newton's method is an example of an {\bf algorithm}: it is a | |
mechanical process for solving a category of problems (in this | |
case, computing square roots). | |
It is not easy to define an algorithm. It might help to start | |
with something that is not an algorithm. When you learned | |
to multiply single-digit numbers, you probably memorized the | |
multiplication table. In effect, you memorized 100 specific solutions. | |
That kind of knowledge is not algorithmic. | |
But if you were ``lazy,'' you probably cheated by learning a few | |
tricks. For example, to find the product of $n$ and 9, you can | |
write $n-1$ as the first digit and $10-n$ as the second | |
digit. This trick is a general solution for multiplying any | |
single-digit number by 9. That's an algorithm! | |
\index{addition with carrying} | |
\index{carrying, addition with} | |
\index{subtraction!with borrowing} | |
\index{borrowing, subtraction with} | |
Similarly, the techniques you learned for addition with carrying, | |
subtraction with borrowing, and long division are all algorithms. One | |
of the characteristics of algorithms is that they do not require any | |
intelligence to carry out. They are mechanical processes in which | |
each step follows from the last according to a simple set of rules. | |
In my opinion, it is embarrassing that humans spend so much time in | |
school learning to execute algorithms that, quite literally, require | |
no intelligence. | |
On the other hand, the process of designing algorithms is interesting, | |
intellectually challenging, and a central part of what we call | |
programming. | |
Some of the things that people do naturally, without difficulty or | |
conscious thought, are the hardest to express algorithmically. | |
Understanding natural language is a good example. We all do it, but | |
so far no one has been able to explain {\em how} we do it, at least | |
not in the form of an algorithm. | |
\section{Debugging} | |
As you start writing bigger programs, you might find yourself | |
spending more time debugging. More code means more chances to | |
make an error and more place for bugs to hide. | |
\index{debugging!by bisection} | |
\index{bisection, debugging by} | |
One way to cut your debugging time is ``debugging by bisection.'' | |
For example, if there are 100 lines in your program and you | |
check them one at a time, it would take 100 steps. | |
Instead, try to break the problem in half. Look at the middle | |
of the program, or near it, for an intermediate value you | |
can check. Add a {\tt print} statement (or something else | |
that has a verifiable effect) and run the program. | |
If the mid-point check is incorrect, there must be a problem in the | |
first half of the program. If it is correct, the problem is | |
in the second half. | |
Every time you perform a check like this, you halve the number of | |
lines you have to search. After six steps (which is fewer than 100), | |
you would be down to one or two lines of code, at least in theory. | |
In practice it is not always clear what | |
the ``middle of the program'' is and not always possible to | |
check it. It doesn't make sense to count lines and find the | |
exact midpoint. Instead, think about places | |
in the program where there might be errors and places where it | |
is easy to put a check. Then choose a spot where you | |
think the chances are about the same that the bug is before | |
or after the check. | |
\section{Glossary} | |
\begin{description} | |
\item[multiple assignment:] Making more than one assignment to the same | |
variable during the execution of a program. | |
\index{multiple assignment} | |
\index{assignment!multiple} | |
\item[update:] An assignment where the new value of the variable | |
depends on the old. | |
\index{update} | |
\item[initialization:] An assignment that gives an initial value to | |
a variable that will be updated. | |
\index{initialization!variable} | |
\item[increment:] An update that increases the value of a variable | |
(often by one). | |
\index{increment} | |
\item[decrement:] An update that decreases the value of a variable. | |
\index{decrement} | |
\item[iteration:] Repeated execution of a set of statements using | |
either a recursive function call or a loop. | |
\index{iteration} | |
\item[infinite loop:] A loop in which the terminating condition is | |
never satisfied. | |
\index{infinite loop} | |
\end{description} | |
\section{Exercises} | |
\begin{exercise} | |
\index{algorithm!square root} | |
To test the square root algorithm in this chapter, you could compare | |
it with {\tt math.sqrt}. Write a function named \verb"test_square_root" | |
that prints a table like this: | |
\begin{verbatim} | |
1.0 1.0 1.0 0.0 | |
2.0 1.41421356237 1.41421356237 2.22044604925e-16 | |
3.0 1.73205080757 1.73205080757 0.0 | |
4.0 2.0 2.0 0.0 | |
5.0 2.2360679775 2.2360679775 0.0 | |
6.0 2.44948974278 2.44948974278 0.0 | |
7.0 2.64575131106 2.64575131106 0.0 | |
8.0 2.82842712475 2.82842712475 4.4408920985e-16 | |
9.0 3.0 3.0 0.0 | |
\end{verbatim} | |
% | |
The first column is a number, $a$; the second column is | |
the square root of $a$ computed with the function from | |
Section~\ref{squareroot}; the third column is the square root computed | |
by {\tt math.sqrt}; the fourth column is the absolute value | |
of the difference between the two estimates. | |
\end{exercise} | |
\begin{exercise} | |
\index{eval function} | |
\index{function!eval} | |
The built-in function {\tt eval} takes a string and evaluates | |
it using the Python interpreter. For example: | |
\begin{verbatim} | |
>>> eval('1 + 2 * 3') | |
7 | |
>>> import math | |
>>> eval('math.sqrt(5)') | |
2.2360679774997898 | |
>>> eval('type(math.pi)') | |
<type 'float'> | |
\end{verbatim} | |
% | |
Write a function called \verb"eval_loop" that iteratively | |
prompts the user, takes the resulting input and evaluates | |
it using {\tt eval}, and prints the result. | |
It should continue until the user enters \verb"'done'", and then | |
return the value of the last expression it evaluated. | |
\end{exercise} | |
\begin{exercise} | |
\index{Ramanujan, Srinivasa} | |
The mathematician Srinivasa Ramanujan found an | |
infinite series | |
that can be used to generate a numerical | |
approximation of $1 / \pi$: | |
\index{pi} | |
\[ \frac{1}{\pi} = \frac{2\sqrt{2}}{9801} | |
\sum^\infty_{k=0} \frac{(4k)!(1103+26390k)}{(k!)^4 396^{4k}} \] | |
Write a function called \verb"estimate_pi" that uses this formula | |
to compute and return an estimate of $\pi$. It should use a {\tt while} | |
loop to compute terms of the summation until the last term is | |
smaller than {\tt 1e-15} (which is Python notation for $10^{-15}$). | |
You can check the result by comparing it to {\tt math.pi}. | |
Solution: \url{http://thinkpython.com/code/pi.py}. | |
\end{exercise} | |
\chapter{Strings} | |
\label{strings} | |
\section{A string is a sequence} | |
\index{sequence} | |
\index{character} | |
\index{bracket operator} | |
\index{operator!bracket} | |
A string is a {\bf sequence} of characters. | |
You can access the characters one at a time with the | |
bracket operator: | |
\begin{verbatim} | |
>>> fruit = 'banana' | |
>>> letter = fruit[1] | |
\end{verbatim} | |
% | |
The second statement selects character number 1 from {\tt | |
fruit} and assigns it to {\tt letter}. | |
\index{index} | |
The expression in brackets is called an {\bf index}. | |
The index indicates which character in the sequence you | |
want (hence the name). | |
But you might not get what you expect: | |
\begin{verbatim} | |
>>> print letter | |
a | |
\end{verbatim} | |
% | |
For most people, the first letter of \verb"'banana'" is {\tt b}, not | |
{\tt a}. But for computer scientists, the index is an offset from the | |
beginning of the string, and the offset of the first letter is zero. | |
\begin{verbatim} | |
>>> letter = fruit[0] | |
>>> print letter | |
b | |
\end{verbatim} | |
% | |
So {\tt b} is the 0th letter (``zero-eth'') of \verb"'banana'", {\tt a} | |
is the 1th letter (``one-eth''), and {\tt n} is the 2th (``two-eth'') | |
letter. | |
\index{index!starting at zero} | |
\index{zero, index starting at} | |
You can use any expression, including variables and operators, as an | |
index, but the value of the index has to be an integer. Otherwise you | |
get: | |
\index{index} | |
\index{exception!TypeError} | |
\index{TypeError} | |
\begin{verbatim} | |
>>> letter = fruit[1.5] | |
TypeError: string indices must be integers, not float | |
\end{verbatim} | |
% | |
\section{{\tt len}} | |
\index{len function} | |
\index{function!len} | |
{\tt len} is a built-in function that returns the number of characters | |
in a string: | |
\begin{verbatim} | |
>>> fruit = 'banana' | |
>>> len(fruit) | |
6 | |
\end{verbatim} | |
% | |
To get the last letter of a string, you might be tempted to try something | |
like this: | |
\index{exception!IndexError} | |
\index{IndexError} | |
\begin{verbatim} | |
>>> length = len(fruit) | |
>>> last = fruit[length] | |
IndexError: string index out of range | |
\end{verbatim} | |
% | |
The reason for the {\tt IndexError} is that there is no letter in {\tt | |
'banana'} with the index 6. Since we started counting at zero, the | |
six letters are numbered 0 to 5. To get the last character, you have | |
to subtract 1 from {\tt length}: | |
\begin{verbatim} | |
>>> last = fruit[length-1] | |
>>> print last | |
a | |
\end{verbatim} | |
% | |
Alternatively, you can use negative indices, which count backward from | |
the end of the string. The expression {\tt fruit[-1]} yields the last | |
letter, {\tt fruit[-2]} yields the second to last, and so on. | |
\index{index!negative} | |
\index{negative index} | |
\section{Traversal with a {\tt for} loop} | |
\label{for} | |
\index{traversal} | |
\index{loop!traversal} | |
\index{for loop} | |
\index{loop!for} | |
\index{statement!for} | |
\index{traversal} | |
A lot of computations involve processing a string one character at a | |
time. Often they start at the beginning, select each character in | |
turn, do something to it, and continue until the end. This pattern of | |
processing is called a {\bf traversal}. One way to write a traversal | |
is with a {\tt while} loop: | |
\begin{verbatim} | |
index = 0 | |
while index < len(fruit): | |
letter = fruit[index] | |
print letter | |
index = index + 1 | |
\end{verbatim} | |
% | |
This loop traverses the string and displays each letter on a line by | |
itself. The loop condition is {\tt index < len(fruit)}, so | |
when {\tt index} is equal to the length of the string, the | |
condition is false, and the body of the loop is not executed. The | |
last character accessed is the one with the index {\tt len(fruit)-1}, | |
which is the last character in the string. | |
\begin{exercise} | |
Write a function that takes a string as an argument | |
and displays the letters backward, one per line. | |
\end{exercise} | |
Another way to write a traversal is with a {\tt for} loop: | |
\begin{verbatim} | |
for char in fruit: | |
print char | |
\end{verbatim} | |
% | |
Each time through the loop, the next character in the string is assigned | |
to the variable {\tt char}. The loop continues until no characters are | |
left. | |
\index{concatenation} | |
\index{abecedarian} | |
\index{McCloskey, Robert} | |
The following example shows how to use concatenation (string addition) | |
and a {\tt for} loop to generate an abecedarian series (that is, in | |
alphabetical order). In Robert McCloskey's book {\em Make | |
Way for Ducklings}, the names of the ducklings are Jack, Kack, Lack, | |
Mack, Nack, Ouack, Pack, and Quack. This loop outputs these names in | |
order: | |
\begin{verbatim} | |
prefixes = 'JKLMNOPQ' | |
suffix = 'ack' | |
for letter in prefixes: | |
print letter + suffix | |
\end{verbatim} | |
% | |
The output is: | |
\begin{verbatim} | |
Jack | |
Kack | |
Lack | |
Mack | |
Nack | |
Oack | |
Pack | |
Qack | |
\end{verbatim} | |
% | |
Of course, that's not quite right because ``Ouack'' and | |
``Quack'' are misspelled. | |
\begin{exercise} | |
Modify the program to fix this error. | |
\end{exercise} | |
\section{String slices} | |
\label{slice} | |
\index{slice operator} | |
\index{operator!slice} | |
\index{index!slice} | |
\index{string!slice} | |
\index{slice!string} | |
A segment of a string is called a {\bf slice}. Selecting a slice is | |
similar to selecting a character: | |
\begin{verbatim} | |
>>> s = 'Monty Python' | |
>>> print s[0:5] | |
Monty | |
>>> print s[6:12] | |
Python | |
\end{verbatim} | |
% | |
The operator {\tt [n:m]} returns the part of the string from the | |
``n-eth'' character to the ``m-eth'' character, including the first but | |
excluding the last. This behavior is counterintuitive, but it might | |
help to imagine the indices pointing {\em between} the | |
characters, as in Figure~\ref{fig.banana}. | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/banana.pdf}} | |
\caption{Slice indices.} | |
\label{fig.banana} | |
\end{figure} | |
If you omit the first index (before the colon), the slice starts at | |
the beginning of the string. If you omit the second index, the slice | |
goes to the end of the string: | |
\begin{verbatim} | |
>>> fruit = 'banana' | |
>>> fruit[:3] | |
'ban' | |
>>> fruit[3:] | |
'ana' | |
\end{verbatim} | |
% | |
If the first index is greater than or equal to the second the result | |
is an {\bf empty string}, represented by two quotation marks: | |
\index{quotation mark} | |
\begin{verbatim} | |
>>> fruit = 'banana' | |
>>> fruit[3:3] | |
'' | |
\end{verbatim} | |
% | |
An empty string contains no characters and has length 0, but other | |
than that, it is the same as any other string. | |
\begin{exercise} | |
Given that {\tt fruit} is a string, what does | |
{\tt fruit[:]} mean? | |
\index{copy!slice} | |
\index{slice!copy} | |
\end{exercise} | |
\section{Strings are immutable} | |
\index{mutability} | |
\index{immutability} | |
\index{string!immutable} | |
It is tempting to use the {\tt []} operator on the left side of an | |
assignment, with the intention of changing a character in a string. | |
For example: | |
\index{TypeError} | |
\index{exception!TypeError} | |
\begin{verbatim} | |
>>> greeting = 'Hello, world!' | |
>>> greeting[0] = 'J' | |
TypeError: 'str' object does not support item assignment | |
\end{verbatim} | |
% | |
The ``object'' in this case is the string and the ``item'' is | |
the character you tried to assign. For now, an {\bf object} is | |
the same thing as a value, but we will refine that definition | |
later. An {\bf item} is one of the values in a sequence. | |
\index{object} | |
\index{item assignment} | |
\index{assignment!item} | |
\index{immutability} | |
The reason for the error is that | |
strings are {\bf immutable}, which means you can't change an | |
existing string. The best you can do is create a new string | |
that is a variation on the original: | |
\begin{verbatim} | |
>>> greeting = 'Hello, world!' | |
>>> new_greeting = 'J' + greeting[1:] | |
>>> print new_greeting | |
Jello, world! | |
\end{verbatim} | |
% | |
This example concatenates a new first letter onto | |
a slice of {\tt greeting}. It has no effect on | |
the original string. | |
\index{concatenation} | |
\section{Searching} | |
\label{find} | |
What does the following function do? | |
\index{find function} | |
\index{function!find} | |
\begin{verbatim} | |
def find(word, letter): | |
index = 0 | |
while index < len(word): | |
if word[index] == letter: | |
return index | |
index = index + 1 | |
return -1 | |
\end{verbatim} | |
% | |
In a sense, {\tt find} is the opposite of the {\tt []} operator. | |
Instead of taking an index and extracting the corresponding character, | |
it takes a character and finds the index where that character | |
appears. If the character is not found, the function returns {\tt | |
-1}. | |
This is the first example we have seen of a {\tt return} statement | |
inside a loop. If {\tt word[index] == letter}, the function breaks | |
out of the loop and returns immediately. | |
If the character doesn't appear in the string, the program | |
exits the loop normally and returns {\tt -1}. | |
This pattern of computation---traversing a sequence and returning | |
when we find what we are looking for---is called a {\bf search}. | |
\index{traversal} | |
\index{search pattern} | |
\index{pattern!search} | |
\begin{exercise} | |
Modify {\tt find} so that it has a | |
third parameter, the index in {\tt word} where it should start | |
looking. | |
\end{exercise} | |
\section{Looping and counting} | |
\label{counter} | |
\index{counter} | |
\index{counting and looping} | |
\index{looping and counting} | |
\index{looping!with strings} | |
The following program counts the number of times the letter {\tt a} | |
appears in a string: | |
\begin{verbatim} | |
word = 'banana' | |
count = 0 | |
for letter in word: | |
if letter == 'a': | |
count = count + 1 | |
print count | |
\end{verbatim} | |
% | |
This program demonstrates another pattern of computation called a {\bf | |
counter}. The variable {\tt count} is initialized to 0 and then | |
incremented each time an {\tt a} is found. | |
When the loop exits, {\tt count} | |
contains the result---the total number of {\tt a}'s. | |
\begin{exercise} | |
\index{encapsulation} | |
Encapsulate this code in a function named {\tt | |
count}, and generalize it so that it accepts the string and the | |
letter as arguments. | |
\end{exercise} | |
\begin{exercise} | |
Rewrite this function so that instead of | |
traversing the string, it uses the three-parameter version of {\tt | |
find} from the previous section. | |
\end{exercise} | |
\section{String methods} | |
A {\bf method} is similar to a function---it takes arguments and | |
returns a value---but the syntax is different. For example, the | |
method {\tt upper} takes a string and returns a new string with | |
all uppercase letters: | |
\index{method} | |
\index{string!method} | |
Instead of the function syntax {\tt upper(word)}, it uses | |
the method syntax {\tt word.upper()}. | |
\index{dot notation} | |
\begin{verbatim} | |
>>> word = 'banana' | |
>>> new_word = word.upper() | |
>>> print new_word | |
BANANA | |
\end{verbatim} | |
% | |
This form of dot notation specifies the name of the method, {\tt | |
upper}, and the name of the string to apply the method to, {\tt | |
word}. The empty parentheses indicate that this method takes no | |
argument. | |
\index{parentheses!empty} | |
A method call is called an {\bf invocation}; in this case, we would | |
say that we are invoking {\tt upper} on the {\tt word}. | |
\index{invocation} | |
As it turns out, there is a string method named {\tt find} that | |
is remarkably similar to the function we wrote: | |
\begin{verbatim} | |
>>> word = 'banana' | |
>>> index = word.find('a') | |
>>> print index | |
1 | |
\end{verbatim} | |
% | |
In this example, we invoke {\tt find} on {\tt word} and pass | |
the letter we are looking for as a parameter. | |
Actually, the {\tt find} method is more general than our function; | |
it can find substrings, not just characters: | |
\begin{verbatim} | |
>>> word.find('na') | |
2 | |
\end{verbatim} | |
% | |
It can take as a second argument the index where it should start: | |
\index{optional argument} | |
\index{argument!optional} | |
\begin{verbatim} | |
>>> word.find('na', 3) | |
4 | |
\end{verbatim} | |
% | |
And as a third argument the index where it should stop: | |
\begin{verbatim} | |
>>> name = 'bob' | |
>>> name.find('b', 1, 2) | |
-1 | |
\end{verbatim} | |
% | |
This search fails because {\tt b} does not | |
appear in the index range from {\tt 1} to {\tt 2} (not including {\tt | |
2}). | |
\begin{exercise} | |
\index{count method} | |
\index{method!count} | |
There is a string method called {\tt count} that is similar | |
to the function in the previous exercise. Read the documentation | |
of this method | |
and write an invocation that counts the number of {\tt a}s | |
in \verb"'banana'". | |
\end{exercise} | |
\begin{exercise} | |
\index{string method} | |
\index{method!string} | |
Read the documentation of the string methods at | |
\url{http://docs.python.org/2/library/stdtypes.html#string-methods}. | |
You might want to experiment with some of them to make sure you | |
understand how they work. {\tt strip} and {\tt replace} are | |
particularly useful. | |
The documentation uses a syntax that might be confusing. | |
For example, in \verb"find(sub[, start[, end]])", the brackets | |
indicate optional arguments. So {\tt sub} is required, but | |
{\tt start} is optional, and if you include {\tt start}, | |
then {\tt end} is optional. | |
\end{exercise} | |
\section{The {\tt in} operator} | |
\label{inboth} | |
\index{in operator} | |
\index{operator!in} | |
\index{boolean operator} | |
\index{operator!boolean} | |
The word {\tt in} is a boolean operator that takes two strings and | |
returns {\tt True} if the first appears as a substring in the second: | |
\begin{verbatim} | |
>>> 'a' in 'banana' | |
True | |
>>> 'seed' in 'banana' | |
False | |
\end{verbatim} | |
% | |
For example, the following function prints all the | |
letters from {\tt word1} that also appear in {\tt word2}: | |
\begin{verbatim} | |
def in_both(word1, word2): | |
for letter in word1: | |
if letter in word2: | |
print letter | |
\end{verbatim} | |
% | |
With well-chosen variable names, | |
Python sometimes reads like English. You could read | |
this loop, ``for (each) letter in (the first) word, if (the) letter | |
(appears) in (the second) word, print (the) letter.'' | |
Here's what you get if you compare apples and oranges: | |
\begin{verbatim} | |
>>> in_both('apples', 'oranges') | |
a | |
e | |
s | |
\end{verbatim} | |
% | |
\section{String comparison} | |
\index{string!comparison} | |
\index{comparison!string} | |
The relational operators work on strings. To see if two strings are equal: | |
\begin{verbatim} | |
if word == 'banana': | |
print 'All right, bananas.' | |
\end{verbatim} | |
% | |
Other relational operations are useful for putting words in alphabetical | |
order: | |
\begin{verbatim} | |
if word < 'banana': | |
print 'Your word,' + word + ', comes before banana.' | |
elif word > 'banana': | |
print 'Your word,' + word + ', comes after banana.' | |
else: | |
print 'All right, bananas.' | |
\end{verbatim} | |
% | |
Python does not handle uppercase and lowercase letters the same way | |
that people do. All the uppercase letters come before all the | |
lowercase letters, so: | |
\begin{verbatim} | |
Your word, Pineapple, comes before banana. | |
\end{verbatim} | |
% | |
A common way to address this problem is to convert strings to a | |
standard format, such as all lowercase, before performing the | |
comparison. Keep that in mind in case you have to defend yourself | |
against a man armed with a Pineapple. | |
\section{Debugging} | |
\index{debugging} | |
\index{traversal} | |
When you use indices to traverse the values in a sequence, | |
it is tricky to get the beginning and end of the traversal | |
right. Here is a function that is supposed to compare two | |
words and return {\tt True} if one of the words is the reverse | |
of the other, but it contains two errors: | |
\begin{verbatim} | |
def is_reverse(word1, word2): | |
if len(word1) != len(word2): | |
return False | |
i = 0 | |
j = len(word2) | |
while j > 0: | |
if word1[i] != word2[j]: | |
return False | |
i = i+1 | |
j = j-1 | |
return True | |
\end{verbatim} | |
% | |
The first {\tt if} statement checks whether the words are the | |
same length. If not, we can return {\tt False} immediately | |
and then, for the rest of the function, we can assume that the words | |
are the same length. This is an example of the guardian pattern | |
in Section~\ref{guardian}. | |
\index{guardian pattern} | |
\index{pattern!guardian} | |
\index{index} | |
{\tt i} and {\tt j} are indices: {\tt i} traverses {\tt word1} | |
forward while {\tt j} traverses {\tt word2} backward. If we find | |
two letters that don't match, we can return {\tt False} immediately. | |
If we get through the whole loop and all the letters match, we | |
return {\tt True}. | |
If we test this function with the words ``pots'' and ``stop'', we | |
expect the return value {\tt True}, but we get an IndexError: | |
\index{IndexError} | |
\index{exception!IndexError} | |
\begin{verbatim} | |
>>> is_reverse('pots', 'stop') | |
... | |
File "reverse.py", line 15, in is_reverse | |
if word1[i] != word2[j]: | |
IndexError: string index out of range | |
\end{verbatim} | |
% | |
For debugging this kind of error, my first move is to | |
print the values of the indices immediately before the line | |
where the error appears. | |
\begin{verbatim} | |
while j > 0: | |
print i, j # print here | |
if word1[i] != word2[j]: | |
return False | |
i = i+1 | |
j = j-1 | |
\end{verbatim} | |
% | |
Now when I run the program again, I get more information: | |
\begin{verbatim} | |
>>> is_reverse('pots', 'stop') | |
0 4 | |
... | |
IndexError: string index out of range | |
\end{verbatim} | |
% | |
The first time through the loop, the value of {\tt j} is 4, | |
which is out of range for the string \verb"'pots'". | |
The index of the last character is 3, so the | |
initial value for {\tt j} should be {\tt len(word2)-1}. | |
\index{semantic error} | |
\index{error!semantic} | |
If I fix that error and run the program again, I get: | |
\begin{verbatim} | |
>>> is_reverse('pots', 'stop') | |
0 3 | |
1 2 | |
2 1 | |
True | |
\end{verbatim} | |
% | |
This time we get the right answer, but it looks like the loop only ran | |
three times, which is suspicious. To get a better idea of what is | |
happening, it is useful to draw a state diagram. During the first | |
iteration, the frame for \verb"is_reverse" is shows in Figure~\ref{fig.state4}. | |
\index{state diagram} | |
\index{diagram!state} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/state4.pdf}} | |
\caption{State diagram.} | |
\label{fig.state4} | |
\end{figure} | |
I took a little license by arranging the variables in the frame | |
and adding dotted lines to show that the values of {\tt i} and | |
{\tt j} indicate characters in {\tt word1} and {\tt word2}. | |
\begin{exercise} | |
\label{isreverse} | |
Starting with this diagram, execute the program on paper, changing the | |
values of {\tt i} and {\tt j} during each iteration. Find and fix the | |
second error in this function. | |
\end{exercise} | |
\section{Glossary} | |
\begin{description} | |
\item[object:] Something a variable can refer to. For now, | |
you can use ``object'' and ``value'' interchangeably. | |
\index{object} | |
\item[sequence:] An ordered set; that is, a set of | |
values where each value is identified by an integer index. | |
\index{sequence} | |
\item[item:] One of the values in a sequence. | |
\index{item} | |
\item[index:] An integer value used to select an item in | |
a sequence, such as a character in a string. | |
\index{index} | |
\item[slice:] A part of a string specified by a range of indices. | |
\index{slice} | |
\item[empty string:] A string with no characters and length 0, represented | |
by two quotation marks. | |
\index{empty string} | |
\item[immutable:] The property of a sequence whose items cannot | |
be assigned. | |
\index{immutability} | |
\item[traverse:] To iterate through the items in a sequence, | |
performing a similar operation on each. | |
\index{traversal} | |
\item[search:] A pattern of traversal that stops | |
when it finds what it is looking for. | |
\index{search pattern} | |
\index{pattern!search} | |
\item[counter:] A variable used to count something, usually initialized | |
to zero and then incremented. | |
\index{counter} | |
\item[method:] A function that is associated with an object and called | |
using dot notation. | |
\index{method} | |
\item[invocation:] A statement that calls a method. | |
\index{invocation} | |
\end{description} | |
\section{Exercises} | |
\begin{exercise} | |
\index{step size} | |
\index{slice operator} | |
\index{operator!slice} | |
A string slice can take a third index that specifies the ``step | |
size;'' that is, the number of spaces between successive characters. | |
A step size of 2 means every other character; 3 means every third, | |
etc. | |
\begin{verbatim} | |
>>> fruit = 'banana' | |
>>> fruit[0:5:2] | |
'bnn' | |
\end{verbatim} | |
A step size of -1 goes through the word backwards, so | |
the slice \verb"[::-1]" generates a reversed string. | |
\index{palindrome} | |
Use this idiom to write a one-line version of \verb"is_palindrome" | |
from Exercise~\ref{palindrome}. | |
\end{exercise} | |
\begin{exercise} | |
The following functions are all {\em intended} to check whether a | |
string contains any lowercase letters, but at least some of them are | |
wrong. For each function, describe what the function actually does | |
(assuming that the parameter is a string). | |
\begin{verbatim} | |
def any_lowercase1(s): | |
for c in s: | |
if c.islower(): | |
return True | |
else: | |
return False | |
def any_lowercase2(s): | |
for c in s: | |
if 'c'.islower(): | |
return 'True' | |
else: | |
return 'False' | |
def any_lowercase3(s): | |
for c in s: | |
flag = c.islower() | |
return flag | |
def any_lowercase4(s): | |
flag = False | |
for c in s: | |
flag = flag or c.islower() | |
return flag | |
def any_lowercase5(s): | |
for c in s: | |
if not c.islower(): | |
return False | |
return True | |
\end{verbatim} | |
\end{exercise} | |
\begin{exercise} | |
\index{letter rotation} | |
\index{rotation, letter} | |
\label{exrotate} | |
ROT13 is a weak form of encryption that involves ``rotating'' each | |
letter in a word by 13 places. To rotate a letter means | |
to shift it through the alphabet, wrapping around to the beginning if | |
necessary, so 'A' shifted by 3 is 'D' and 'Z' shifted by 1 is 'A'. | |
Write a function called \verb"rotate_word" | |
that takes a string and an integer as parameters, and that returns | |
a new string that contains the letters from the original string | |
``rotated'' by the given amount. | |
For example, ``cheer'' rotated by 7 is ``jolly'' and ``melon'' rotated | |
by -10 is ``cubed''. | |
%For example ``sleep'' | |
%rotated by 9 is ``bunny'' and ``latex'' rotated by 7 is ``shale''. | |
You might want to use the built-in functions {\tt ord}, which converts | |
a character to a numeric code, and {\tt chr}, which converts numeric | |
codes to characters. | |
Potentially offensive jokes on the Internet are sometimes encoded | |
in ROT13. If you are not easily offended, find and decode some | |
of them. Solution: \url{http://thinkpython.com/code/rotate.py}. | |
\end{exercise} | |
\chapter{Case study: word play} | |
\section{Reading word lists} | |
\label{wordlist} | |
For the exercises in this chapter we need a list of English words. | |
There are lots of word lists available on the Web, but the one most | |
suitable for our purpose is one of the word lists collected and | |
contributed to the public domain by Grady Ward as part of the Moby | |
lexicon project (see \url{http://wikipedia.org/wiki/Moby_Project}). It | |
is a list of 113,809 official crosswords; that is, words that are | |
considered valid in crossword puzzles and other word games. In the | |
Moby collection, the filename is {\tt 113809of.fic}; you can download | |
a copy, with the simpler name {\tt words.txt}, from | |
\url{http://thinkpython.com/code/words.txt}. | |
\index{Moby Project} | |
\index{crosswords} | |
This file is in plain text, so you can open it with a text | |
editor, but you can also read it from Python. The built-in | |
function {\tt open} takes the name of the file as a parameter | |
and returns a {\bf file object} you can use to read the file. | |
\index{open function} | |
\index{function!open} | |
\index{plain text} | |
\index{text!plain} | |
\index{object!file} | |
\index{file object} | |
\begin{verbatim} | |
>>> fin = open('words.txt') | |
>>> print fin | |
<open file 'words.txt', mode 'r' at 0xb7f4b380> | |
\end{verbatim} | |
% | |
{\tt fin} is a common name for a file object used for | |
input. Mode \verb"'r'" indicates that this file is open for | |
reading (as opposed to \verb"'w'" for writing). | |
\index{readline method} | |
\index{method!readline} | |
The file object provides several methods for reading, including | |
{\tt readline}, which reads characters from the file | |
until it gets to a newline and returns the result as a | |
string: | |
\begin{verbatim} | |
>>> fin.readline() | |
'aa\r\n' | |
\end{verbatim} | |
% | |
The first word in this particular list is ``aa,'' which is a kind of | |
lava. The sequence \verb"\r\n" represents two whitespace characters, | |
a carriage return and a newline, that separate this word from the | |
next. | |
The file object keeps track of where it is in the file, so | |
if you call {\tt readline} again, you get the next word: | |
\begin{verbatim} | |
>>> fin.readline() | |
'aah\r\n' | |
\end{verbatim} | |
% | |
The next word is ``aah,'' which is a perfectly legitimate | |
word, so stop looking at me like that. | |
Or, if it's the whitespace that's bothering you, | |
we can get rid of it with the string method {\tt strip}: | |
\index{strip method} | |
\index{method!strip} | |
\begin{verbatim} | |
>>> line = fin.readline() | |
>>> word = line.strip() | |
>>> print word | |
aahed | |
\end{verbatim} | |
% | |
You can also use a file object as part of a {\tt for} loop. | |
This program reads {\tt words.txt} and prints each word, one | |
per line: | |
\index{open function} | |
\index{function!open} | |
\begin{verbatim} | |
fin = open('words.txt') | |
for line in fin: | |
word = line.strip() | |
print word | |
\end{verbatim} | |
% | |
\begin{exercise} | |
Write a program that reads {\tt words.txt} and prints only the | |
words with more than 20 characters (not counting whitespace). | |
\index{whitespace} | |
\end{exercise} | |
\section{Exercises} | |
There are solutions to these exercises in the next section. | |
You should at least attempt each one before you read the solutions. | |
\begin{exercise} | |
In 1939 Ernest Vincent Wright published a 50,000 word novel called | |
{\em Gadsby} that does not contain the letter ``e.'' Since ``e'' is | |
the most common letter in English, that's not easy to do. | |
In fact, it is difficult to construct a solitary thought without using | |
that most common symbol. It is slow going at first, but with caution | |
and hours of training you can gradually gain facility. | |
All right, I'll stop now. | |
Write a function called \verb"has_no_e" that returns {\tt True} if | |
the given word doesn't have the letter ``e'' in it. | |
Modify your program from the previous section to print only the words | |
that have no ``e'' and compute the percentage of the words in the list | |
have no ``e.'' | |
\index{lipogram} | |
\end{exercise} | |
\begin{exercise} | |
Write a function named {\tt avoids} | |
that takes a word and a string of forbidden letters, and | |
that returns {\tt True} if the word doesn't use any of the forbidden | |
letters. | |
Modify your program to prompt the user to enter a string | |
of forbidden letters and then print the number of words that | |
don't contain any of them. | |
Can you find a combination of 5 forbidden letters that | |
excludes the smallest number of words? | |
\end{exercise} | |
\begin{exercise} | |
Write a function named \verb"uses_only" that takes a word and a | |
string of letters, and that returns {\tt True} if the word contains | |
only letters in the list. Can you make a sentence using only the | |
letters {\tt acefhlo}? Other than ``Hoe alfalfa?'' | |
\end{exercise} | |
\begin{exercise} | |
Write a function named \verb"uses_all" that takes a word and a | |
string of required letters, and that returns {\tt True} if the word | |
uses all the required letters at least once. How many words are there | |
that use all the vowels {\tt aeiou}? How about {\tt aeiouy}? | |
\end{exercise} | |
\begin{exercise} | |
Write a function called \verb"is_abecedarian" that returns | |
{\tt True} if the letters in a word appear in alphabetical order | |
(double letters are ok). | |
How many abecedarian words are there? | |
\index{abecedarian} | |
\end{exercise} | |
%\begin{exercise} | |
%\label{palindrome} | |
%A palindrome is a word that reads the same | |
%forward and backward, like ``rotator'' and ``noon.'' | |
%Write a boolean function named \verb"is_palindrome" that | |
%takes a string as a parameter and returns {\tt True} if it is | |
%a palindrome. | |
%Modify your program from the previous section to print all | |
%of the palindromes in the word list and then print the total | |
%number of palindromes. | |
%\end{exercise} | |
\section{Search} | |
\index{search pattern} | |
\index{pattern!search} | |
All of the exercises in the previous section have something | |
in common; they can be solved with the search pattern we saw | |
in Section~\ref{find}. The simplest example is: | |
\begin{verbatim} | |
def has_no_e(word): | |
for letter in word: | |
if letter == 'e': | |
return False | |
return True | |
\end{verbatim} | |
% | |
The {\tt for} loop traverses the characters in {\tt word}. If we find | |
the letter ``e'', we can immediately return {\tt False}; otherwise we | |
have to go to the next letter. If we exit the loop normally, that | |
means we didn't find an ``e'', so we return {\tt True}. | |
\index{traversal} | |
% Removing this because we haven't seen the in operator yet. | |
%\index{in operator} | |
%\index{operator!in} | |
%You could write this function more concisely using the {\tt in} | |
%operator, but I started with this version because it | |
%demonstrates the logic of the search pattern. | |
\index{generalization} | |
{\tt avoids} is a more general version of \verb"has_no_e" but it | |
has the same structure: | |
\begin{verbatim} | |
def avoids(word, forbidden): | |
for letter in word: | |
if letter in forbidden: | |
return False | |
return True | |
\end{verbatim} | |
% | |
We can return {\tt False} as soon as we find a forbidden letter; | |
if we get to the end of the loop, we return {\tt True}. | |
\verb"uses_only" is similar except that the sense of the condition | |
is reversed: | |
\begin{verbatim} | |
def uses_only(word, available): | |
for letter in word: | |
if letter not in available: | |
return False | |
return True | |
\end{verbatim} | |
% | |
Instead of a list of forbidden letters, we have a list of available | |
letters. If we find a letter in {\tt word} that is not in | |
{\tt available}, we can return {\tt False}. | |
\verb"uses_all" is similar except that we reverse the role | |
of the word and the string of letters: | |
\begin{verbatim} | |
def uses_all(word, required): | |
for letter in required: | |
if letter not in word: | |
return False | |
return True | |
\end{verbatim} | |
% | |
Instead of traversing the letters in {\tt word}, the loop | |
traverses the required letters. If any of the required letters | |
do not appear in the word, we can return {\tt False}. | |
\index{traversal} | |
If you were really thinking like a computer scientist, you would | |
have recognized that \verb"uses_all" was an instance of a | |
previously-solved problem, and you would have written: | |
\begin{verbatim} | |
def uses_all(word, required): | |
return uses_only(required, word) | |
\end{verbatim} | |
% | |
This is an example of a program development method called {\bf problem | |
recognition}, which means that you recognize the problem you are | |
working on as an instance of a previously-solved problem, and apply a | |
previously-developed solution. | |
\index{problem recognition} | |
\index{development plan!problem recognition} | |
\section{Looping with indices} | |
\index{looping!with indices} | |
\index{index!looping with} | |
I wrote the functions in the previous section with {\tt for} | |
loops because I only needed the characters in the strings; I didn't | |
have to do anything with the indices. | |
For \verb"is_abecedarian" we have to compare adjacent letters, | |
which is a little tricky with a {\tt for} loop: | |
\begin{verbatim} | |
def is_abecedarian(word): | |
previous = word[0] | |
for c in word: | |
if c < previous: | |
return False | |
previous = c | |
return True | |
\end{verbatim} | |
An alternative is to | |
use recursion: | |
\begin{verbatim} | |
def is_abecedarian(word): | |
if len(word) <= 1: | |
return True | |
if word[0] > word[1]: | |
return False | |
return is_abecedarian(word[1:]) | |
\end{verbatim} | |
Another option is to use a {\tt while} loop: | |
\begin{verbatim} | |
def is_abecedarian(word): | |
i = 0 | |
while i < len(word)-1: | |
if word[i+1] < word[i]: | |
return False | |
i = i+1 | |
return True | |
\end{verbatim} | |
% | |
The loop starts at {\tt i=0} and ends when {\tt i=len(word)-1}. Each | |
time through the loop, it compares the $i$th character (which you can | |
think of as the current character) to the $i+1$th character (which you | |
can think of as the next). | |
If the next character is less than (alphabetically before) the current | |
one, then we have discovered a break in the abecedarian trend, and | |
we return {\tt False}. | |
If we get to the end of the loop without finding a fault, then the | |
word passes the test. To convince yourself that the loop ends | |
correctly, consider an example like \verb"'flossy'". The | |
length of the word is 6, so | |
the last time the loop runs is when {\tt i} is 4, which is the | |
index of the second-to-last character. On the last iteration, | |
it compares the second-to-last character to the last, which is | |
what we want. | |
\index{palindrome} | |
Here is a version of \verb"is_palindrome" (see | |
Exercise~\ref{palindrome}) that uses two indices; one starts at the | |
beginning and goes up; the other starts at the end and goes down. | |
\begin{verbatim} | |
def is_palindrome(word): | |
i = 0 | |
j = len(word)-1 | |
while i<j: | |
if word[i] != word[j]: | |
return False | |
i = i+1 | |
j = j-1 | |
return True | |
\end{verbatim} | |
Or, if you noticed that this is an instance of a previously-solved | |
problem, you might have written: | |
\begin{verbatim} | |
def is_palindrome(word): | |
return is_reverse(word, word) | |
\end{verbatim} | |
\index{problem recognition} | |
\index{development plan!problem recognition} | |
Assuming you did Exercise~\ref{isreverse}. | |
\section{Debugging} | |
\index{debugging} | |
\index{testing!is hard} | |
\index{program testing} | |
Testing programs is hard. The functions in this chapter are | |
relatively easy to test because you can check the results by hand. | |
Even so, it is somewhere between difficult and impossible to choose a | |
set of words that test for all possible errors. | |
Taking \verb"has_no_e" as an example, there are two obvious | |
cases to check: words that have an 'e' should return {\tt False}; | |
words that don't should return {\tt True}. You should have no | |
trouble coming up with one of each. | |
Within each case, there are some less obvious subcases. Among the | |
words that have an ``e,'' you should test words with an ``e'' at the | |
beginning, the end, and somewhere in the middle. You should test long | |
words, short words, and very short words, like the empty string. The | |
empty string is an example of a {\bf special case}, which is one of | |
the non-obvious cases where errors often lurk. | |
\index{special case} | |
In addition to the test cases you generate, you can also test | |
your program with a word list like {\tt words.txt}. By scanning | |
the output, you might be able to catch errors, but be careful: | |
you might catch one kind of error (words that should not be | |
included, but are) and not another (words that should be included, | |
but aren't). | |
In general, testing can help you find bugs, but it is not easy to | |
generate a good set of test cases, and even if you do, you can't | |
be sure your program is correct. | |
\index{testing!and absence of bugs} | |
According to a legendary computer scientist: | |
\begin{quote} | |
Program testing can be used to show the presence of bugs, but never to | |
show their absence! | |
--- Edsger W. Dijkstra | |
\end{quote} | |
\index{Dijkstra, Edsger} | |
\section{Glossary} | |
\begin{description} | |
\item[file object:] A value that represents an open file. | |
\index{file object} | |
\index{object!file} | |
\item[problem recognition:] A way of solving a problem by | |
expressing it as an instance of a previously-solved problem. | |
\index{problem recognition} | |
\item[special case:] A test case that is atypical or non-obvious | |
(and less likely to be handled correctly). | |
\index{special case} | |
\end{description} | |
\section{Exercises} | |
\begin{exercise} | |
\index{Car Talk} | |
\index{Puzzler} | |
\index{double letters} | |
This question is based on a Puzzler that was broadcast on the radio | |
program {\em Car Talk} | |
(\url{http://www.cartalk.com/content/puzzlers}): | |
\begin{quote} | |
Give me a word with three consecutive double letters. I'll give you a | |
couple of words that almost qualify, but don't. For example, the word | |
committee, c-o-m-m-i-t-t-e-e. It would be great except for the `i' that | |
sneaks in there. Or Mississippi: M-i-s-s-i-s-s-i-p-p-i. If you could | |
take out those i's it would work. But there is a word that has three | |
consecutive pairs of letters and to the best of my knowledge this may | |
be the only word. Of course there are probably 500 more but I can only | |
think of one. What is the word? | |
\end{quote} | |
Write a program to find it. Solution: \url{http://thinkpython.com/code/cartalk1.py}. | |
\end{exercise} | |
\begin{exercise} | |
Here's another {\em Car Talk} | |
Puzzler (\url{http://www.cartalk.com/content/puzzlers}): | |
\index{Car Talk} | |
\index{Puzzler} | |
\index{odometer} | |
\index{palindrome} | |
\begin{quote} | |
``I was driving on the highway the other day and I happened to | |
notice my odometer. Like most odometers, it shows six digits, | |
in whole miles only. So, if my car had 300,000 | |
miles, for example, I'd see 3-0-0-0-0-0. | |
``Now, what I saw that day was very interesting. I noticed that the | |
last 4 digits were palindromic; that is, they read the same forward as | |
backward. For example, 5-4-4-5 is a palindrome, so my odometer | |
could have read 3-1-5-4-4-5. | |
``One mile later, the last 5 numbers were palindromic. For example, it | |
could have read 3-6-5-4-5-6. One mile after that, the middle 4 out of | |
6 numbers were palindromic. And you ready for this? One mile later, | |
all 6 were palindromic! | |
``The question is, what was on the odometer when I first looked?'' | |
\end{quote} | |
Write a Python program that tests all the six-digit numbers and prints | |
any numbers that satisfy these requirements. | |
Solution: \url{http://thinkpython.com/code/cartalk2.py}. | |
\end{exercise} | |
\begin{exercise} | |
Here's another {\em Car Talk} Puzzler you can solve with a | |
search (\url{http://www.cartalk.com/content/puzzlers}): | |
\index{Car Talk} | |
\index{Puzzler} | |
\index{palindrome} | |
\begin{quote} | |
``Recently I had a visit with my mom and we realized that | |
the two digits that make up my age when reversed resulted in her | |
age. For example, if she's 73, I'm 37. We wondered how often this has | |
happened over the years but we got sidetracked with other topics and | |
we never came up with an answer. | |
``When I got home I figured out that the digits of our ages have been | |
reversible six times so far. I also figured out that if we're lucky it | |
would happen again in a few years, and if we're really lucky it would | |
happen one more time after that. In other words, it would have | |
happened 8 times over all. So the question is, how old am I now?'' | |
\end{quote} | |
Write a Python program that searches for solutions to this Puzzler. | |
Hint: you might find the string method {\tt zfill} useful. | |
Solution: \url{http://thinkpython.com/code/cartalk3.py}. | |
\end{exercise} | |
\chapter{Lists} | |
\section{A list is a sequence} | |
\label{sequence} | |
Like a string, a {\bf list} is a sequence of values. In a string, the | |
values are characters; in a list, they can be any type. The values in | |
a list are called {\bf elements} or sometimes {\bf items}. | |
\index{list} | |
\index{type!list} | |
\index{element} | |
\index{sequence} | |
\index{item} | |
There are several ways to create a new list; the simplest is to | |
enclose the elements in square brackets (\verb"[" and \verb"]"): | |
\begin{verbatim} | |
[10, 20, 30, 40] | |
['crunchy frog', 'ram bladder', 'lark vomit'] | |
\end{verbatim} | |
% | |
The first example is a list of four integers. The second is a list of | |
three strings. The elements of a list don't have to be the same type. | |
The following list contains a string, a float, an integer, and | |
(lo!) another list: | |
\begin{verbatim} | |
['spam', 2.0, 5, [10, 20]] | |
\end{verbatim} | |
% | |
A list within another list is {\bf nested}. | |
\index{nested list} | |
\index{list!nested} | |
A list that contains no elements is | |
called an empty list; you can create one with empty | |
brackets, \verb"[]". | |
\index{empty list} | |
\index{list!empty} | |
As you might expect, you can assign list values to variables: | |
\begin{verbatim} | |
>>> cheeses = ['Cheddar', 'Edam', 'Gouda'] | |
>>> numbers = [17, 123] | |
>>> empty = [] | |
>>> print cheeses, numbers, empty | |
['Cheddar', 'Edam', 'Gouda'] [17, 123] [] | |
\end{verbatim} | |
% | |
\index{assignment} | |
\section{Lists are mutable} | |
\label{mutable} | |
\index{list!element} | |
\index{access} | |
\index{index} | |
\index{bracket operator} | |
\index{operator!bracket} | |
The syntax for accessing the elements of a list is the same as for | |
accessing the characters of a string---the bracket operator. The | |
expression inside the brackets specifies the index. Remember that the | |
indices start at 0: | |
\begin{verbatim} | |
>>> print cheeses[0] | |
Cheddar | |
\end{verbatim} | |
% | |
Unlike strings, lists are mutable. When the bracket operator appears | |
on the left side of an assignment, it identifies the element of the | |
list that will be assigned. | |
\index{mutability} | |
\begin{verbatim} | |
>>> numbers = [17, 123] | |
>>> numbers[1] = 5 | |
>>> print numbers | |
[17, 5] | |
\end{verbatim} | |
% | |
The one-eth element of {\tt numbers}, which | |
used to be 123, is now 5. | |
\index{index!starting at zero} | |
\index{zero, index starting at} | |
You can think of a list as a relationship between indices and | |
elements. This relationship is called a {\bf mapping}; each index | |
``maps to'' one of the elements. Figure~\ref{fig.liststate} shows | |
the state diagram for {\tt | |
cheeses}, {\tt numbers} and {\tt empty}: | |
\index{state diagram} | |
\index{diagram!state} | |
\index{mapping} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/liststate.pdf}} | |
\caption{State diagram.} | |
\label{fig.liststate} | |
\end{figure} | |
Lists are represented by boxes with the word ``list'' outside | |
and the elements of the list inside. {\tt cheeses} refers to | |
a list with three elements indexed 0, 1 and 2. | |
{\tt numbers} contains two elements; the diagram shows that the | |
value of the second element has been reassigned from 123 to 5. | |
{\tt empty} refers to a list with no elements. | |
\index{item assignment} | |
\index{assignment!item} | |
List indices work the same way as string indices: | |
\begin{itemize} | |
\item Any integer expression can be used as an index. | |
\item If you try to read or write an element that does not exist, you | |
get an {\tt IndexError}. | |
\index{exception!IndexError} | |
\index{IndexError} | |
\item If an index has a negative value, it counts backward from the | |
end of the list. | |
\end{itemize} | |
\index{list!index} | |
\index{list!membership} | |
\index{membership!list} | |
\index{in operator} | |
\index{operator!in} | |
The {\tt in} operator also works on lists. | |
\begin{verbatim} | |
>>> cheeses = ['Cheddar', 'Edam', 'Gouda'] | |
>>> 'Edam' in cheeses | |
True | |
>>> 'Brie' in cheeses | |
False | |
\end{verbatim} | |
\section{Traversing a list} | |
\index{list!traversal} | |
\index{traversal!list} | |
\index{for loop} | |
\index{loop!for} | |
\index{statement!for} | |
The most common way to traverse the elements of a list is | |
with a {\tt for} loop. The syntax is the same as for strings: | |
\begin{verbatim} | |
for cheese in cheeses: | |
print cheese | |
\end{verbatim} | |
% | |
This works well if you only need to read the elements of the | |
list. But if you want to write or update the elements, you | |
need the indices. A common way to do that is to combine | |
the functions {\tt range} and {\tt len}: | |
\index{looping!with indices} | |
\index{index!looping with} | |
\begin{verbatim} | |
for i in range(len(numbers)): | |
numbers[i] = numbers[i] * 2 | |
\end{verbatim} | |
% | |
This loop traverses the list and updates each element. {\tt len} | |
returns the number of elements in the list. {\tt range} returns | |
a list of indices from 0 to $n-1$, where $n$ is the length of | |
the list. Each time through the loop {\tt i} gets the index | |
of the next element. The assignment statement in the body uses | |
{\tt i} to read the old value of the element and to assign the | |
new value. | |
\index{item update} | |
\index{update!item} | |
A {\tt for} loop over an empty list never executes the body: | |
\begin{verbatim} | |
for x in []: | |
print 'This never happens.' | |
\end{verbatim} | |
% | |
Although a list can contain another list, the nested | |
list still counts as a single element. The length of this list is | |
four: | |
\index{nested list} | |
\index{list!nested} | |
\begin{verbatim} | |
['spam', 1, ['Brie', 'Roquefort', 'Pol le Veq'], [1, 2, 3]] | |
\end{verbatim} | |
\section{List operations} | |
\index{list!operation} | |
The {\tt +} operator concatenates lists: | |
\index{concatenation!list} | |
\index{list!concatenation} | |
\begin{verbatim} | |
>>> a = [1, 2, 3] | |
>>> b = [4, 5, 6] | |
>>> c = a + b | |
>>> print c | |
[1, 2, 3, 4, 5, 6] | |
\end{verbatim} | |
% | |
Similarly, the {\tt *} operator repeats a list a given number of times: | |
\index{repetition!list} | |
\index{list!repetition} | |
\begin{verbatim} | |
>>> [0] * 4 | |
[0, 0, 0, 0] | |
>>> [1, 2, 3] * 3 | |
[1, 2, 3, 1, 2, 3, 1, 2, 3] | |
\end{verbatim} | |
% | |
The first example repeats {\tt [0]} four times. The second example | |
repeats the list {\tt [1, 2, 3]} three times. | |
\section{List slices} | |
\index{slice operator} | |
\index{operator!slice} | |
\index{index!slice} | |
\index{list!slice} | |
\index{slice!list} | |
The slice operator also works on lists: | |
\begin{verbatim} | |
>>> t = ['a', 'b', 'c', 'd', 'e', 'f'] | |
>>> t[1:3] | |
['b', 'c'] | |
>>> t[:4] | |
['a', 'b', 'c', 'd'] | |
>>> t[3:] | |
['d', 'e', 'f'] | |
\end{verbatim} | |
% | |
If you omit the first index, the slice starts at the beginning. | |
If you omit the second, the slice goes to the end. So if you | |
omit both, the slice is a copy of the whole list. | |
\index{list!copy} | |
\index{slice!copy} | |
\index{copy!slice} | |
\begin{verbatim} | |
>>> t[:] | |
['a', 'b', 'c', 'd', 'e', 'f'] | |
\end{verbatim} | |
% | |
Since lists are mutable, it is often useful to make a copy | |
before performing operations that fold, spindle or mutilate | |
lists. | |
\index{mutability} | |
A slice operator on the left side of an assignment | |
can update multiple elements: | |
\index{slice!update} | |
\index{update!slice} | |
\begin{verbatim} | |
>>> t = ['a', 'b', 'c', 'd', 'e', 'f'] | |
>>> t[1:3] = ['x', 'y'] | |
>>> print t | |
['a', 'x', 'y', 'd', 'e', 'f'] | |
\end{verbatim} | |
% | |
% You can add elements to a list by squeezing them into an empty | |
% slice: | |
% % \begin{verbatim} | |
% >>> t = ['a', 'd', 'e', 'f'] | |
% >>> t[1:1] = ['b', 'c'] | |
% >>> print t | |
% ['a', 'b', 'c', 'd', 'e', 'f'] | |
% \end{verbatim} | |
% \afterverb | |
% | |
% And you can remove elements from a list by assigning the empty list to | |
% them: | |
% % \begin{verbatim} | |
% >>> t = ['a', 'b', 'c', 'd', 'e', 'f'] | |
% >>> t[1:3] = [] | |
% >>> print t | |
% ['a', 'd', 'e', 'f'] | |
% \end{verbatim} | |
% \afterverb | |
% | |
% But both of those operations can be expressed more clearly | |
% with list methods. | |
\section{List methods} | |
\index{list!method} | |
\index{method, list} | |
Python provides methods that operate on lists. For example, | |
{\tt append} adds a new element to the end of a list: | |
\index{append method} | |
\index{method!append} | |
\begin{verbatim} | |
>>> t = ['a', 'b', 'c'] | |
>>> t.append('d') | |
>>> print t | |
['a', 'b', 'c', 'd'] | |
\end{verbatim} | |
% | |
{\tt extend} takes a list as an argument and appends all of | |
the elements: | |
\index{extend method} | |
\index{method!extend} | |
\begin{verbatim} | |
>>> t1 = ['a', 'b', 'c'] | |
>>> t2 = ['d', 'e'] | |
>>> t1.extend(t2) | |
>>> print t1 | |
['a', 'b', 'c', 'd', 'e'] | |
\end{verbatim} | |
% | |
This example leaves {\tt t2} unmodified. | |
{\tt sort} arranges the elements of the list from low to high: | |
\index{sort method} | |
\index{method!sort} | |
\begin{verbatim} | |
>>> t = ['d', 'c', 'e', 'b', 'a'] | |
>>> t.sort() | |
>>> print t | |
['a', 'b', 'c', 'd', 'e'] | |
\end{verbatim} | |
% | |
List methods are all void; they modify the list and return {\tt None}. | |
If you accidentally write {\tt t = t.sort()}, you will be disappointed | |
with the result. | |
\index{void method} | |
\index{method!void} | |
\index{None special value} | |
\index{special value!None} | |
\section{Map, filter and reduce} | |
To add up all the numbers in a list, you can use a loop like this: | |
% see add.py | |
\begin{verbatim} | |
def add_all(t): | |
total = 0 | |
for x in t: | |
total += x | |
return total | |
\end{verbatim} | |
% | |
{\tt total} is initialized to 0. Each time through the loop, | |
{\tt x} gets one element from the list. The {\tt +=} operator | |
provides a short way to update a variable. This | |
{\bf augmented assignment statement}: | |
\index{update operator} | |
\index{operator!update} | |
\index{assignment!augmented} | |
\index{augmented assignment} | |
\begin{verbatim} | |
total += x | |
\end{verbatim} | |
% | |
is equivalent to: | |
\begin{verbatim} | |
total = total + x | |
\end{verbatim} | |
% | |
As the loop executes, {\tt total} accumulates the sum of the | |
elements; a variable used this way is sometimes called an | |
{\bf accumulator}. | |
\index{accumulator!sum} | |
Adding up the elements of a list is such a common operation | |
that Python provides it as a built-in function, {\tt sum}: | |
\begin{verbatim} | |
>>> t = [1, 2, 3] | |
>>> sum(t) | |
6 | |
\end{verbatim} | |
% | |
An operation like this that combines a sequence of elements into | |
a single value is sometimes called {\bf reduce}. | |
\index{reduce pattern} | |
\index{pattern!reduce} | |
\index{traversal} | |
\begin{exercise} | |
Write a function called \verb"nested_sum" that takes a nested list | |
of integers and add up the elements from all of the nested lists. | |
\end{exercise} | |
Sometimes you want to traverse one list while building | |
another. For example, the following function takes a list of strings | |
and returns a new list that contains capitalized strings: | |
\begin{verbatim} | |
def capitalize_all(t): | |
res = [] | |
for s in t: | |
res.append(s.capitalize()) | |
return res | |
\end{verbatim} | |
% | |
{\tt res} is initialized with an empty list; each time through | |
the loop, we append the next element. So {\tt res} is another | |
kind of accumulator. | |
\index{accumulator!list} | |
An operation like \verb"capitalize_all" is sometimes called a {\bf | |
map} because it ``maps'' a function (in this case the method {\tt | |
capitalize}) onto each of the elements in a sequence. | |
\index{map pattern} | |
\index{pattern!map} | |
\index{filter pattern} | |
\index{pattern!filter} | |
\begin{exercise} | |
Use \verb"capitalize_all" to write a function named \verb"capitalize_nested" | |
that takes a nested list of strings and returns a new nested list | |
with all strings capitalized. | |
\end{exercise} | |
Another common operation is to select some of the elements from | |
a list and return a sublist. For example, the following | |
function takes a list of strings and returns a list that contains | |
only the uppercase strings: | |
\begin{verbatim} | |
def only_upper(t): | |
res = [] | |
for s in t: | |
if s.isupper(): | |
res.append(s) | |
return res | |
\end{verbatim} | |
% | |
{\tt isupper} is a string method that returns {\tt True} if | |
the string contains only upper case letters. | |
An operation like \verb"only_upper" is called a {\bf filter} because | |
it selects some of the elements and filters out the others. | |
Most common list operations can be expressed as a combination | |
of map, filter and reduce. Because these operations are | |
so common, Python provides language features to support them, | |
including the built-in function {\tt map} and an operator | |
called a ``list comprehension.'' | |
\index{list!comprehension} | |
\begin{exercise} | |
\label{cumulative} | |
\index{cumulative sum} | |
Write a function that takes a list of numbers and returns the | |
cumulative sum; that is, a new list where the $i$th element | |
is the sum of the first $i+1$ elements from the original list. | |
For example, the cumulative sum of {\tt [1, 2, 3]} is | |
{\tt [1, 3, 6]}. | |
\end{exercise} | |
\section{Deleting elements} | |
\index{element deletion} | |
\index{deletion, element of list} | |
There are several ways to delete elements from a list. If you | |
know the index of the element you want, you can use | |
{\tt pop}: | |
\index{pop method} | |
\index{method!pop} | |
\begin{verbatim} | |
>>> t = ['a', 'b', 'c'] | |
>>> x = t.pop(1) | |
>>> print t | |
['a', 'c'] | |
>>> print x | |
b | |
\end{verbatim} | |
% | |
{\tt pop} modifies the list and returns the element that was removed. | |
If you don't provide an index, it deletes and returns the | |
last element. | |
If you don't need the removed value, you can use the {\tt del} | |
operator: | |
\index{del operator} | |
\index{operator!del} | |
\begin{verbatim} | |
>>> t = ['a', 'b', 'c'] | |
>>> del t[1] | |
>>> print t | |
['a', 'c'] | |
\end{verbatim} | |
% | |
If you know the element you want to remove (but not the index), you | |
can use {\tt remove}: | |
\index{remove method} | |
\index{method!remove} | |
\begin{verbatim} | |
>>> t = ['a', 'b', 'c'] | |
>>> t.remove('b') | |
>>> print t | |
['a', 'c'] | |
\end{verbatim} | |
% | |
The return value from {\tt remove} is {\tt None}. | |
\index{None special value} | |
\index{special value!None} | |
To remove more than one element, you can use {\tt del} with | |
a slice index: | |
\begin{verbatim} | |
>>> t = ['a', 'b', 'c', 'd', 'e', 'f'] | |
>>> del t[1:5] | |
>>> print t | |
['a', 'f'] | |
\end{verbatim} | |
% | |
As usual, the slice selects all the elements up to, but not | |
including, the second index. | |
\begin{exercise} | |
Write a function called \verb"middle" that takes a list and | |
returns a new list that contains all but the first and last | |
elements. So \verb"middle([1,2,3,4])" should return \verb"[2,3]". | |
\end{exercise} | |
\begin{exercise} | |
Write a function called \verb"chop" that takes a list, modifies it | |
by removing the first and last elements, and returns {\tt None}. | |
\end{exercise} | |
\section{Lists and strings} | |
\index{list} | |
\index{string} | |
\index{sequence} | |
A string is a sequence of characters and a list is a sequence | |
of values, but a list of characters is not the same as a | |
string. To convert from a string to a list of characters, | |
you can use {\tt list}: | |
\index{list!function} | |
\index{function!list} | |
\begin{verbatim} | |
>>> s = 'spam' | |
>>> t = list(s) | |
>>> print t | |
['s', 'p', 'a', 'm'] | |
\end{verbatim} | |
% | |
Because {\tt list} is the name of a built-in function, you should | |
avoid using it as a variable name. I also avoid {\tt l} because | |
it looks too much like {\tt 1}. So that's why I use {\tt t}. | |
The {\tt list} function breaks a string into individual letters. If | |
you want to break a string into words, you can use the {\tt split} | |
method: | |
\index{split method} | |
\index{method!split} | |
\begin{verbatim} | |
>>> s = 'pining for the fjords' | |
>>> t = s.split() | |
>>> print t | |
['pining', 'for', 'the', 'fjords'] | |
\end{verbatim} | |
% | |
An optional argument called a {\bf delimiter} specifies which | |
characters to use as word boundaries. | |
The following example | |
uses a hyphen as a delimiter: | |
\index{optional argument} | |
\index{argument!optional} | |
\index{delimiter} | |
\begin{verbatim} | |
>>> s = 'spam-spam-spam' | |
>>> delimiter = '-' | |
>>> s.split(delimiter) | |
['spam', 'spam', 'spam'] | |
\end{verbatim} | |
% | |
{\tt join} is the inverse of {\tt split}. It | |
takes a list of strings and | |
concatenates the elements. {\tt join} is a string method, | |
so you have to invoke it on the delimiter and pass the | |
list as a parameter: | |
\index{join method} | |
\index{method!join} | |
\index{concatenation} | |
\begin{verbatim} | |
>>> t = ['pining', 'for', 'the', 'fjords'] | |
>>> delimiter = ' ' | |
>>> delimiter.join(t) | |
'pining for the fjords' | |
\end{verbatim} | |
% | |
In this case the delimiter is a space character, so | |
{\tt join} puts a space between words. To concatenate | |
strings without spaces, you can use the empty string, | |
\verb"''", as a delimiter. | |
\index{empty string} | |
\index{string!empty} | |
\section{Objects and values} | |
\index{object} | |
\index{value} | |
If we execute these assignment statements: | |
\begin{verbatim} | |
a = 'banana' | |
b = 'banana' | |
\end{verbatim} | |
% | |
We know that {\tt a} and {\tt b} both refer to a | |
string, but we don't | |
know whether they refer to the {\em same} string. | |
There are two possible states, shown in Figure~\ref{fig.list1}. | |
\index{aliasing} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/list1.pdf}} | |
\caption{State diagram.} | |
\label{fig.list1} | |
\end{figure} | |
In one case, {\tt a} and {\tt b} refer to two different objects that | |
have the same value. In the second case, they refer to the same | |
object. | |
\index{is operator} | |
\index{operator!is} | |
To check whether two variables refer to the same object, you can | |
use the {\tt is} operator. | |
\begin{verbatim} | |
>>> a = 'banana' | |
>>> b = 'banana' | |
>>> a is b | |
True | |
\end{verbatim} | |
% | |
In this example, Python only created one string object, | |
and both {\tt a} and {\tt b} refer to it. | |
But when you create two lists, you get two objects: | |
\begin{verbatim} | |
>>> a = [1, 2, 3] | |
>>> b = [1, 2, 3] | |
>>> a is b | |
False | |
\end{verbatim} | |
% | |
So the state diagram looks like Figure~\ref{fig.list2}. | |
\index{state diagram} | |
\index{diagram!state} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/list2.pdf}} | |
\caption{State diagram.} | |
\label{fig.list2} | |
\end{figure} | |
In this case we would say that the two lists are {\bf equivalent}, | |
because they have the same elements, but not {\bf identical}, because | |
they are not the same object. If two objects are identical, they are | |
also equivalent, but if they are equivalent, they are not necessarily | |
identical. | |
\index{equivalence} | |
\index{identity} | |
Until now, we have been using ``object'' and ``value'' | |
interchangeably, but it is more precise to say that an object has a | |
value. If you execute {\tt [1,2,3]}, you get a list | |
object whose value is a sequence of integers. If another | |
list has the same elements, we say it has the same value, but | |
it is not the same object. | |
\index{object} | |
\index{value} | |
\section{Aliasing} | |
\index{aliasing} | |
\index{reference!aliasing} | |
If {\tt a} refers to an object and you assign {\tt b = a}, | |
then both variables refer to the same object: | |
\begin{verbatim} | |
>>> a = [1, 2, 3] | |
>>> b = a | |
>>> b is a | |
True | |
\end{verbatim} | |
% | |
The state diagram looks like Figure~\ref{fig.list3}. | |
\index{state diagram} | |
\index{diagram!state} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/list3.pdf}} | |
\caption{State diagram.} | |
\label{fig.list3} | |
\end{figure} | |
The association of a variable with an object is called a {\bf | |
reference}. In this example, there are two references to the same | |
object. | |
\index{reference} | |
An object with more than one reference has more | |
than one name, so we say that the object is {\bf aliased}. | |
\index{mutability} | |
If the aliased object is mutable, changes made with one alias affect | |
the other: | |
\begin{verbatim} | |
>>> b[0] = 17 | |
>>> print a | |
[17, 2, 3] | |
\end{verbatim} | |
% | |
Although this behavior can be useful, it is error-prone. In general, | |
it is safer to avoid aliasing when you are working with mutable | |
objects. | |
\index{immutability} | |
For immutable objects like strings, aliasing is not as much of a | |
problem. In this example: | |
\begin{verbatim} | |
a = 'banana' | |
b = 'banana' | |
\end{verbatim} | |
% | |
It almost never makes a difference whether {\tt a} and {\tt b} refer | |
to the same string or not. | |
\section{List arguments} | |
\label{list.arguments} | |
\index{list!as argument} | |
\index{argument} | |
\index{argument!list} | |
\index{reference} | |
\index{parameter} | |
When you pass a list to a function, the function gets a reference | |
to the list. | |
If the function modifies a list parameter, the caller sees the change. | |
For example, \verb"delete_head" removes the first element from a list: | |
\begin{verbatim} | |
def delete_head(t): | |
del t[0] | |
\end{verbatim} | |
% | |
Here's how it is used: | |
\begin{verbatim} | |
>>> letters = ['a', 'b', 'c'] | |
>>> delete_head(letters) | |
>>> print letters | |
['b', 'c'] | |
\end{verbatim} | |
% | |
The parameter {\tt t} and the variable {\tt letters} are | |
aliases for the same object. The stack diagram looks like | |
Figure~\ref{fig.stack5}. | |
\index{stack diagram} | |
\index{diagram!stack} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/stack5.pdf}} | |
\caption{Stack diagram.} | |
\label{fig.stack5} | |
\end{figure} | |
Since the list is shared by two frames, I drew | |
it between them. | |
It is important to distinguish between operations that | |
modify lists and operations that create new lists. For | |
example, the {\tt append} method modifies a list, but the | |
{\tt +} operator creates a new list: | |
\index{append method} | |
\index{method!append} | |
\index{list!concatenation} | |
\index{concatenation!list} | |
\begin{verbatim} | |
>>> t1 = [1, 2] | |
>>> t2 = t1.append(3) | |
>>> print t1 | |
[1, 2, 3] | |
>>> print t2 | |
None | |
>>> t3 = t1 + [4] | |
>>> print t3 | |
[1, 2, 3, 4] | |
\end{verbatim} | |
This difference is important when you write functions that | |
are supposed to modify lists. For example, this function | |
{\em does not} delete the head of a list: | |
\begin{verbatim} | |
def bad_delete_head(t): | |
t = t[1:] # WRONG! | |
\end{verbatim} | |
The slice operator creates a new list and the assignment | |
makes {\tt t} refer to it, but none of that has any effect | |
on the list that was passed as an argument. | |
\index{slice operator} | |
\index{operator!slice} | |
An alternative is to write a function that creates and | |
returns a new list. For | |
example, {\tt tail} returns all but the first | |
element of a list: | |
\begin{verbatim} | |
def tail(t): | |
return t[1:] | |
\end{verbatim} | |
% | |
This function leaves the original list unmodified. | |
Here's how it is used: | |
\begin{verbatim} | |
>>> letters = ['a', 'b', 'c'] | |
>>> rest = tail(letters) | |
>>> print rest | |
['b', 'c'] | |
\end{verbatim} | |
\section{Debugging} | |
\index{debugging} | |
Careless use of lists (and other mutable objects) | |
can lead to long hours of debugging. Here are some common | |
pitfalls and ways to avoid them: | |
\begin{enumerate} | |
\item Don't forget that most list methods modify the argument and | |
return {\tt None}. This is the opposite of the string methods, | |
which return a new string and leave the original alone. | |
If you are used to writing string code like this: | |
\begin{verbatim} | |
word = word.strip() | |
\end{verbatim} | |
It is tempting to write list code like this: | |
\begin{verbatim} | |
t = t.sort() # WRONG! | |
\end{verbatim} | |
\index{sort method} | |
\index{method!sort} | |
Because {\tt sort} returns {\tt None}, the | |
next operation you perform with {\tt t} is likely to fail. | |
Before using list methods and operators, you should read the | |
documentation carefully and then test them in interactive mode. The | |
methods and operators that lists share with other sequences (like | |
strings) are documented at | |
\url{http://docs.python.org/2/library/stdtypes.html#typesseq}. The | |
methods and operators that only apply to mutable sequences | |
are documented at \url{http://docs.python.org/2/library/stdtypes.html#typesseq-mutable}. | |
\item Pick an idiom and stick with it. | |
Part of the problem with lists is that there are too many | |
ways to do things. For example, to remove an element from | |
a list, you can use {\tt pop}, {\tt remove}, {\tt del}, | |
or even a slice assignment. | |
To add an element, you can use the {\tt append} method or | |
the {\tt +} operator. Assuming that {\tt t} is a list and | |
{\tt x} is a list element, these are right: | |
\begin{verbatim} | |
t.append(x) | |
t = t + [x] | |
\end{verbatim} | |
And these are wrong: | |
\begin{verbatim} | |
t.append([x]) # WRONG! | |
t = t.append(x) # WRONG! | |
t + [x] # WRONG! | |
t = t + x # WRONG! | |
\end{verbatim} | |
Try out each of these examples in interactive mode to make sure | |
you understand what they do. Notice that only the last | |
one causes a runtime error; the other three are legal, but they | |
do the wrong thing. | |
\item Make copies to avoid aliasing. | |
\index{aliasing!copying to avoid} | |
\index{copy!to avoid aliasing} | |
If you want to use a method like {\tt sort} that modifies | |
the argument, but you need to keep the original list as | |
well, you can make a copy. | |
\begin{verbatim} | |
orig = t[:] | |
t.sort() | |
\end{verbatim} | |
In this example you could also use the built-in function {\tt sorted}, | |
which returns a new, sorted list and leaves the original alone. | |
But in that case you should avoid using {\tt sorted} as a variable | |
name! | |
\end{enumerate} | |
\section{Glossary} | |
\begin{description} | |
\item[list:] A sequence of values. | |
\index{list} | |
\item[element:] One of the values in a list (or other sequence), | |
also called items. | |
\index{element} | |
\item[index:] An integer value that indicates an element in a list. | |
\index{index} | |
\item[nested list:] A list that is an element of another list. | |
\index{nested list} | |
\item[list traversal:] The sequential accessing of each element in a list. | |
\index{list!traversal} | |
\item[mapping:] A relationship in which each element of one set | |
corresponds to an element of another set. For example, a list is | |
a mapping from indices to elements. | |
\index{mapping} | |
\item[accumulator:] A variable used in a loop to add up or | |
accumulate a result. | |
\index{accumulator} | |
\item[augmented assignment:] A statement that updates the value | |
of a variable using an operator like \verb"+=". | |
\index{assignment!augmented} | |
\index{augmented assignment} | |
\index{traversal} | |
\item[reduce:] A processing pattern that traverses a sequence | |
and accumulates the elements into a single result. | |
\index{reduce pattern} | |
\index{pattern!reduce} | |
\item[map:] A processing pattern that traverses a sequence and | |
performs an operation on each element. | |
\index{map pattern} | |
\index{pattern!map} | |
\item[filter:] A processing pattern that traverses a list and | |
selects the elements that satisfy some criterion. | |
\index{filter pattern} | |
\index{pattern!filter} | |
\item[object:] Something a variable can refer to. An object | |
has a type and a value. | |
\index{object} | |
\item[equivalent:] Having the same value. | |
\index{equivalent} | |
\item[identical:] Being the same object (which implies equivalence). | |
\index{identical} | |
\item[reference:] The association between a variable and its value. | |
\index{reference} | |
\item[aliasing:] A circumstance where two or more variables refer to the same | |
object. | |
\index{aliasing} | |
\item[delimiter:] A character or string used to indicate where a | |
string should be split. | |
\index{delimiter} | |
\end{description} | |
\section{Exercises} | |
\begin{exercise} | |
Write a function called \verb"is_sorted" that takes a list as a | |
parameter and returns {\tt True} if the list is sorted in ascending | |
order and {\tt False} otherwise. You can assume (as a precondition) | |
that the elements of the list can be compared with the relational | |
operators {\tt <}, {\tt >}, etc. | |
\index{precondition} | |
For example, \verb"is_sorted([1,2,2])" should return {\tt True} | |
and \verb"is_sorted(['b','a'])" should return {\tt False}. | |
\end{exercise} | |
\begin{exercise} | |
\label{anagram} | |
\index{anagram} | |
Two words are anagrams if you can rearrange the letters from one | |
to spell the other. Write a function called \verb"is_anagram" | |
that takes two strings and returns {\tt True} if they are anagrams. | |
\end{exercise} | |
\begin{exercise} | |
\label{duplicate} | |
The (so-called) Birthday Paradox: | |
\begin{enumerate} | |
\item Write a function called \verb"has_duplicates" that takes | |
a list and returns {\tt True} if there is any element that | |
appears more than once. It should not modify the original | |
list. | |
\index{birthday paradox} | |
\index{duplicate} | |
\item If there are 23 students in your class, what are the chances | |
that two of you have the same birthday? You can estimate this | |
probability by generating random samples of 23 birthdays | |
and checking for matches. Hint: you can generate random birthdays | |
with the {\tt randint} function in the {\tt random} module. | |
\index{random module} | |
\index{module!random} | |
\index{randint function} | |
\index{function!randint} | |
\end{enumerate} | |
You can read about this problem at | |
\url{http://en.wikipedia.org/wiki/Birthday_paradox}, and you can download my | |
solution from \url{http://thinkpython.com/code/birthday.py}. | |
\end{exercise} | |
\begin{exercise} | |
\index{duplicate} | |
\index{uniqueness} | |
Write a function called \verb"remove_duplicates" that takes | |
a list and returns a new list with only the unique elements from | |
the original. Hint: they don't have to be in the same order. | |
\end{exercise} | |
\begin{exercise} | |
\index{append method} | |
\index{method append} | |
\index{list!concatenation} | |
\index{concatenation!list} | |
Write a function that reads the file {\tt words.txt} and builds | |
a list with one element per word. Write two versions of | |
this function, one using the {\tt append} method and the | |
other using the idiom {\tt t = t + [x]}. Which one takes | |
longer to run? Why? | |
Hint: use the {\tt time} module to measure elapsed time. | |
Solution: \url{http://thinkpython.com/code/wordlist.py}. | |
\index{time module} | |
\index{module!time} | |
\end{exercise} | |
\begin{exercise} | |
\label{wordlist1} | |
\label{bisection} | |
\index{membership!bisection search} | |
\index{bisection search} | |
\index{search, bisection} | |
\index{membership!binary search} | |
\index{binary search} | |
\index{search, binary} | |
To check whether a word is in the word list, you could use | |
the {\tt in} operator, but it would be slow because it searches | |
through the words in order. | |
Because the words are in alphabetical order, we can speed things up | |
with a bisection search (also known as binary search), which is | |
similar to what you do when you look a word up in the dictionary. You | |
start in the middle and check to see whether the word you are looking | |
for comes before the word in the middle of the list. If so, then you | |
search the first half of the list the same way. Otherwise you search | |
the second half. | |
Either way, you cut the remaining search space in half. If the | |
word list has 113,809 words, it will take about 17 steps to | |
find the word or conclude that it's not there. | |
Write a function called {\tt bisect} that takes a sorted list | |
and a target value and returns the index of the value | |
in the list, if it's there, or {\tt None} if it's not. | |
\index{bisect module} | |
\index{module!bisect} | |
Or you could read the documentation of the {\tt bisect} module | |
and use that! Solution: \url{http://thinkpython.com/code/inlist.py}. | |
\end{exercise} | |
\begin{exercise} | |
\index{reverse word pair} | |
Two words are a ``reverse pair'' if each is the reverse of the | |
other. Write a program that finds all the reverse pairs in the | |
word list. Solution: \url{http://thinkpython.com/code/reverse_pair.py}. | |
\end{exercise} | |
\begin{exercise} | |
\index{interlocking words} | |
Two words ``interlock'' if taking alternating letters from each forms | |
a new word. For example, ``shoe'' and ``cold'' | |
interlock to form ``schooled.'' | |
Solution: \url{http://thinkpython.com/code/interlock.py}. | |
Credit: This exercise is inspired by an example at \url{http://puzzlers.org}. | |
\begin{enumerate} | |
\item Write a program that finds all pairs of words that interlock. | |
Hint: don't enumerate all pairs! | |
\item Can you find any words that are three-way interlocked; that is, | |
every third letter forms a word, starting from the first, second or | |
third? | |
\end{enumerate} | |
\end{exercise} | |
\chapter{Dictionaries} | |
\index{dictionary} | |
\index{dictionary} | |
\index{type!dict} | |
\index{key} | |
\index{key-value pair} | |
\index{index} | |
A {\bf dictionary} is like a list, but more general. In a list, | |
the indices have to be integers; in a dictionary they can | |
be (almost) any type. | |
You can think of a dictionary as a mapping between a set of indices | |
(which are called {\bf keys}) and a set of values. Each key maps to a | |
value. The association of a key and a value is called a {\bf | |
key-value pair} or sometimes an {\bf item}. | |
As an example, we'll build a dictionary that maps from English | |
to Spanish words, so the keys and the values are all strings. | |
The function {\tt dict} creates a new dictionary with no items. | |
Because {\tt dict} is the name of a built-in function, you | |
should avoid using it as a variable name. | |
\index{dict function} | |
\index{function!dict} | |
\begin{verbatim} | |
>>> eng2sp = dict() | |
>>> print eng2sp | |
{} | |
\end{verbatim} | |
The squiggly-brackets, \verb"{}", represent an empty dictionary. | |
To add items to the dictionary, you can use square brackets: | |
\index{squiggly bracket} | |
\index{bracket!squiggly} | |
\begin{verbatim} | |
>>> eng2sp['one'] = 'uno' | |
\end{verbatim} | |
% | |
This line creates an item that maps from the key | |
{\tt 'one'} to the value \verb"'uno'". If we print the | |
dictionary again, we see a key-value pair with a colon | |
between the key and value: | |
\begin{verbatim} | |
>>> print eng2sp | |
{'one': 'uno'} | |
\end{verbatim} | |
% | |
This output format is also an input format. For example, | |
you can create a new dictionary with three items: | |
\begin{verbatim} | |
>>> eng2sp = {'one': 'uno', 'two': 'dos', 'three': 'tres'} | |
\end{verbatim} | |
% | |
But if you print {\tt eng2sp}, you might be surprised: | |
\begin{verbatim} | |
>>> print eng2sp | |
{'one': 'uno', 'three': 'tres', 'two': 'dos'} | |
\end{verbatim} | |
% | |
The order of the key-value pairs is not the same. In fact, if | |
you type the same example on your computer, you might get a | |
different result. In general, the order of items in | |
a dictionary is unpredictable. | |
But that's not a problem because | |
the elements of a dictionary are never indexed with integer indices. | |
Instead, you use the keys to look up the corresponding values: | |
\begin{verbatim} | |
>>> print eng2sp['two'] | |
'dos' | |
\end{verbatim} | |
% | |
The key {\tt 'two'} always maps to the value \verb"'dos'" so the order | |
of the items doesn't matter. | |
If the key isn't in the dictionary, you get an exception: | |
\index{exception!KeyError} | |
\index{KeyError} | |
\begin{verbatim} | |
>>> print eng2sp['four'] | |
KeyError: 'four' | |
\end{verbatim} | |
% | |
The {\tt len} function works on dictionaries; it returns the | |
number of key-value pairs: | |
\index{len function} | |
\index{function!len} | |
\begin{verbatim} | |
>>> len(eng2sp) | |
3 | |
\end{verbatim} | |
% | |
The {\tt in} operator works on dictionaries; it tells you whether | |
something appears as a {\em key} in the dictionary (appearing | |
as a value is not good enough). | |
\index{membership!dictionary} | |
\index{in operator} | |
\index{operator!in} | |
\begin{verbatim} | |
>>> 'one' in eng2sp | |
True | |
>>> 'uno' in eng2sp | |
False | |
\end{verbatim} | |
% | |
To see whether something appears as a value in a dictionary, you | |
can use the method {\tt values}, which returns the values as | |
a list, and then use the {\tt in} operator: | |
\index{values method} | |
\index{method!values} | |
\begin{verbatim} | |
>>> vals = eng2sp.values() | |
>>> 'uno' in vals | |
True | |
\end{verbatim} | |
% | |
The {\tt in} operator uses different algorithms for lists and | |
dictionaries. For lists, it uses a search algorithm, as in | |
Section~\ref{find}. As the list gets longer, the search time gets | |
longer in direct proportion. For dictionaries, Python uses an | |
algorithm called a {\bf hashtable} that has a remarkable property: the | |
{\tt in} operator takes about the same amount of time no matter how | |
many items there are in a dictionary. I won't explain how that's | |
possible, but you can read more about it at | |
\url{http://en.wikipedia.org/wiki/Hash_table}. | |
\index{hashtable} | |
\begin{exercise} | |
\label{wordlist2} | |
\index{set membership} | |
\index{membership!set} | |
Write a function that reads the words in {\tt words.txt} and | |
stores them as keys in a dictionary. It doesn't matter what the | |
values are. Then you can use the {\tt in} operator | |
as a fast way to check whether a string is in | |
the dictionary. | |
If you did Exercise~\ref{wordlist1}, you can compare the speed | |
of this implementation with the list {\tt in} operator and the | |
bisection search. | |
\end{exercise} | |
\section{Dictionary as a set of counters} | |
\label{histogram} | |
\index{counter} | |
Suppose you are given a string and you want to count how many | |
times each letter appears. There are several ways you could do it: | |
\begin{enumerate} | |
\item You could create 26 variables, one for each letter of the | |
alphabet. Then you could traverse the string and, for each | |
character, increment the corresponding counter, probably using | |
a chained conditional. | |
\item You could create a list with 26 elements. Then you could | |
convert each character to a number (using the built-in function | |
{\tt ord}), use the number as an index into the list, and increment | |
the appropriate counter. | |
\item You could create a dictionary with characters as keys | |
and counters as the corresponding values. The first time you | |
see a character, you would add an item to the dictionary. After | |
that you would increment the value of an existing item. | |
\end{enumerate} | |
Each of these options performs the same computation, but each | |
of them implements that computation in a different way. | |
\index{implementation} | |
An {\bf implementation} is a way of performing a computation; | |
some implementations are better than others. For example, | |
an advantage of the dictionary implementation is that we don't | |
have to know ahead of time which letters appear in the string | |
and we only have to make room for the letters that do appear. | |
Here is what the code might look like: | |
\begin{verbatim} | |
def histogram(s): | |
d = dict() | |
for c in s: | |
if c not in d: | |
d[c] = 1 | |
else: | |
d[c] += 1 | |
return d | |
\end{verbatim} | |
% | |
The name of the function is {\bf histogram}, which is a statistical | |
term for a set of counters (or frequencies). | |
\index{histogram} | |
\index{frequency} | |
\index{traversal} | |
The first line of the | |
function creates an empty dictionary. The {\tt for} loop traverses | |
the string. Each time through the loop, if the character {\tt c} is | |
not in the dictionary, we create a new item with key {\tt c} and the | |
initial value 1 (since we have seen this letter once). If {\tt c} is | |
already in the dictionary we increment {\tt d[c]}. | |
\index{histogram} | |
Here's how it works: | |
\begin{verbatim} | |
>>> h = histogram('brontosaurus') | |
>>> print h | |
{'a': 1, 'b': 1, 'o': 2, 'n': 1, 's': 2, 'r': 2, 'u': 2, 't': 1} | |
\end{verbatim} | |
% | |
The histogram indicates that the letters {\tt 'a'} and \verb"'b'" | |
appear once; \verb"'o'" appears twice, and so on. | |
\begin{exercise} | |
\index{get method} | |
\index{method!get} | |
Dictionaries have a method called {\tt get} that takes a key | |
and a default value. If the key appears in the dictionary, | |
{\tt get} returns the corresponding value; otherwise it returns | |
the default value. For example: | |
\begin{verbatim} | |
>>> h = histogram('a') | |
>>> print h | |
{'a': 1} | |
>>> h.get('a', 0) | |
1 | |
>>> h.get('b', 0) | |
0 | |
\end{verbatim} | |
% | |
Use {\tt get} to write {\tt histogram} more concisely. You | |
should be able to eliminate the {\tt if} statement. | |
\end{exercise} | |
\section{Looping and dictionaries} | |
\index{dictionary!looping with} | |
\index{looping!with dictionaries} | |
\index{traversal} | |
If you use a dictionary in a {\tt for} statement, it traverses | |
the keys of the dictionary. For example, \verb"print_hist" | |
prints each key and the corresponding value: | |
\begin{verbatim} | |
def print_hist(h): | |
for c in h: | |
print c, h[c] | |
\end{verbatim} | |
% | |
Here's what the output looks like: | |
\begin{verbatim} | |
>>> h = histogram('parrot') | |
>>> print_hist(h) | |
a 1 | |
p 1 | |
r 2 | |
t 1 | |
o 1 | |
\end{verbatim} | |
% | |
Again, the keys are in no particular order. | |
\begin{exercise} | |
\index{keys method} | |
\index{method!keys} | |
Dictionaries have a method called {\tt keys} that returns | |
the keys of the dictionary, in no particular order, as a list. | |
Modify \verb"print_hist" to print the keys and their values | |
in alphabetical order. | |
\end{exercise} | |
\section{Reverse lookup} | |
\label{raise} | |
\index{dictionary!lookup} | |
\index{dictionary!reverse lookup} | |
\index{lookup, dictionary} | |
\index{reverse lookup, dictionary} | |
Given a dictionary {\tt d} and a key {\tt k}, it is easy to | |
find the corresponding value {\tt v = d[k]}. This operation | |
is called a {\bf lookup}. | |
But what if you have {\tt v} and you want to find {\tt k}? | |
You have two problems: first, there might be more than one | |
key that maps to the value {\tt v}. Depending on the application, | |
you might be able to pick one, or you might have to make | |
a list that contains all of them. Second, there is no | |
simple syntax to do a {\bf reverse lookup}; you have to search. | |
Here is a function that takes a value and returns the first | |
key that maps to that value: | |
\begin{verbatim} | |
def reverse_lookup(d, v): | |
for k in d: | |
if d[k] == v: | |
return k | |
raise ValueError | |
\end{verbatim} | |
% | |
This function is yet another example of the search pattern, but it | |
uses a feature we haven't seen before, {\tt raise}. The {\tt raise} | |
statement causes an exception; in this case it causes a {\tt | |
ValueError}, which generally indicates that there is something wrong | |
with the value of a parameter. | |
\index{search} | |
\index{pattern!search} | |
\index{raise statement} | |
\index{statement!raise} | |
\index{exception!ValueError} | |
\index{ValueError} | |
If we get to the end of the loop, that means {\tt v} | |
doesn't appear in the dictionary as a value, so we raise an | |
exception. | |
Here is an example of a successful reverse lookup: | |
\begin{verbatim} | |
>>> h = histogram('parrot') | |
>>> k = reverse_lookup(h, 2) | |
>>> print k | |
r | |
\end{verbatim} | |
% | |
And an unsuccessful one: | |
\begin{verbatim} | |
>>> k = reverse_lookup(h, 3) | |
Traceback (most recent call last): | |
File "<stdin>", line 1, in ? | |
File "<stdin>", line 5, in reverse_lookup | |
ValueError | |
\end{verbatim} | |
% | |
The result when you raise an exception is the same as when | |
Python raises one: it prints a traceback and an error message. | |
\index{traceback} | |
\index{optional argument} | |
\index{argument!optional} | |
The {\tt raise} statement takes a detailed error message as an | |
optional argument. For example: | |
\begin{verbatim} | |
>>> raise ValueError('value does not appear in the dictionary') | |
Traceback (most recent call last): | |
File "<stdin>", line 1, in ? | |
ValueError: value does not appear in the dictionary | |
\end{verbatim} | |
% | |
A reverse lookup is much slower than a forward lookup; if you | |
have to do it often, or if the dictionary gets big, the performance | |
of your program will suffer. | |
\begin{exercise} | |
Modify \verb"reverse_lookup" so that it builds and returns a list | |
of {\em all} keys that map to {\tt v}, or an empty list if there | |
are none. | |
\end{exercise} | |
\section{Dictionaries and lists} | |
\label{invert} | |
Lists can appear as values in a dictionary. For example, if you | |
were given a dictionary that maps from letters to frequencies, you | |
might want to invert it; that is, create a dictionary that maps | |
from frequencies to letters. Since there might be several letters | |
with the same frequency, each value in the inverted dictionary | |
should be a list of letters. | |
\index{invert dictionary} | |
\index{dictionary!invert} | |
Here is a function that inverts a dictionary: | |
\begin{verbatim} | |
def invert_dict(d): | |
inverse = dict() | |
for key in d: | |
val = d[key] | |
if val not in inverse: | |
inverse[val] = [key] | |
else: | |
inverse[val].append(key) | |
return inverse | |
\end{verbatim} | |
% | |
Each time through the loop, {\tt key} gets a key from {\tt d} and | |
{\tt val} gets the corresponding value. If {\tt val} is not in {\tt inverse}, | |
that means we haven't seen it before, so we create a new item and | |
initialize it with a {\bf singleton} (a list that contains a | |
single element). Otherwise we have seen this value before, so we | |
append the corresponding key to the list. | |
\index{singleton} | |
Here is an example: | |
\begin{verbatim} | |
>>> hist = histogram('parrot') | |
>>> print hist | |
{'a': 1, 'p': 1, 'r': 2, 't': 1, 'o': 1} | |
>>> inverse = invert_dict(hist) | |
>>> print inverse | |
{1: ['a', 'p', 't', 'o'], 2: ['r']} | |
\end{verbatim} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/dict1.pdf}} | |
\caption{State diagram.} | |
\label{fig.dict1} | |
\end{figure} | |
Figure~\ref{fig.dict1} is a state diagram showing {\tt hist} and {\tt inverse}. | |
A dictionary is represented as a box with the type {\tt dict} above it | |
and the key-value pairs inside. If the values are integers, floats or | |
strings, I usually draw them inside the box, but I usually draw lists | |
outside the box, just to keep the diagram simple. | |
\index{state diagram} | |
\index{diagram!state} | |
Lists can be values in a dictionary, as this example shows, but they | |
cannot be keys. Here's what happens if you try: | |
\index{TypeError} | |
\index{exception!TypeError} | |
\begin{verbatim} | |
>>> t = [1, 2, 3] | |
>>> d = dict() | |
>>> d[t] = 'oops' | |
Traceback (most recent call last): | |
File "<stdin>", line 1, in ? | |
TypeError: list objects are unhashable | |
\end{verbatim} | |
% | |
I mentioned earlier that a dictionary is implemented using | |
a hashtable and that means that the keys have to be {\bf hashable}. | |
\index{hash function} | |
\index{hashable} | |
A {\bf hash} is a function that takes a value (of any kind) | |
and returns an integer. Dictionaries use these integers, | |
called hash values, to store and look up key-value pairs. | |
\index{immutability} | |
This system works fine if the keys are immutable. But if the | |
keys are mutable, like lists, bad things happen. For example, | |
when you create a key-value pair, Python hashes the key and | |
stores it in the corresponding location. If you modify the | |
key and then hash it again, it would go to a different location. | |
In that case you might have two entries for the same key, | |
or you might not be able to find a key. Either way, the | |
dictionary wouldn't work correctly. | |
That's why the keys have to be hashable, and why mutable types like | |
lists aren't. The simplest way to get around this limitation is to | |
use tuples, which we will see in the next chapter. | |
Since lists and dictionaries are mutable, they can't be used as keys, | |
but they {\em can} be used as values. | |
\begin{exercise} | |
Read the documentation of the dictionary method {\tt setdefault} | |
and use it to write a more concise version of \verb"invert_dict". | |
Solution: \url{http://thinkpython.com/code/invert_dict.py}. | |
\index{setdefault method} | |
\index{method!setdefault} | |
\end{exercise} | |
\section{Memos} | |
If you played with the {\tt fibonacci} function from | |
Section~\ref{one.more.example}, you might have noticed that the bigger | |
the argument you provide, the longer the function takes to run. | |
Furthermore, the run time increases very quickly. | |
\index{fibonacci function} | |
\index{function!fibonacci} | |
To understand why, consider Figure~\ref{fig.fibonacci}, which shows | |
the {\bf call graph} for {\tt fibonacci} with {\tt n=4}: | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.7]{figs/fibonacci.pdf}} | |
\caption{Call graph.} | |
\label{fig.fibonacci} | |
\end{figure} | |
A call graph shows a set of function frames, with lines connecting each | |
frame to the frames of the functions it calls. At the top of the | |
graph, {\tt fibonacci} with {\tt n=4} calls {\tt fibonacci} with {\tt | |
n=3} and {\tt n=2}. In turn, {\tt fibonacci} with {\tt n=3} calls | |
{\tt fibonacci} with {\tt n=2} and {\tt n=1}. And so on. | |
\index{function frame} | |
\index{frame} | |
\index{call graph} | |
Count how many times {\tt fibonacci(0)} and {\tt fibonacci(1)} are | |
called. This is an inefficient solution to the problem, and it gets | |
worse as the argument gets bigger. | |
\index{memo} | |
One solution is to keep track of values that have already been | |
computed by storing them in a dictionary. A previously computed value | |
that is stored for later use is called a {\bf memo}. Here is a | |
``memoized'' version of {\tt fibonacci}: | |
\begin{verbatim} | |
known = {0:0, 1:1} | |
def fibonacci(n): | |
if n in known: | |
return known[n] | |
res = fibonacci(n-1) + fibonacci(n-2) | |
known[n] = res | |
return res | |
\end{verbatim} | |
% | |
{\tt known} is a dictionary that keeps track of the Fibonacci | |
numbers we already know. It starts with | |
two items: 0 maps to 0 and 1 maps to 1. | |
Whenever {\tt fibonacci} is called, it checks {\tt known}. | |
If the result is already there, it can return | |
immediately. Otherwise it has to | |
compute the new value, add it to the dictionary, and return it. | |
\begin{exercise} | |
Run this version of {\tt fibonacci} and the original with | |
a range of parameters and compare their run times. | |
\end{exercise} | |
\begin{exercise} | |
Memoize the Ackermann function from Exercise~\ref{ackermann} and see if | |
memoization makes it possible to evaluate the function with bigger | |
arguments. Hint: no. | |
Solution: \url{http://thinkpython.com/code/ackermann_memo.py}. | |
\index{Ackermann function} | |
\index{function!ack} | |
\end{exercise} | |
\section{Global variables} | |
\index{global variable} | |
\index{variable!global} | |
In the previous example, {\tt known} is created outside the function, | |
so it belongs to the special frame called \verb"__main__". | |
Variables in \verb"__main__" are sometimes called {\bf global} | |
because they can be accessed from any function. Unlike local | |
variables, which disappear when their function ends, global variables | |
persist from one function call to the next. | |
\index{flag} | |
It is common to use global variables for {\bf flags}; that is, | |
boolean variables that indicate (``flag'') whether a condition | |
is true. For example, some programs use | |
a flag named {\tt verbose} to control the level of detail in the | |
output: | |
\begin{verbatim} | |
verbose = True | |
def example1(): | |
if verbose: | |
print 'Running example1' | |
\end{verbatim} | |
% | |
If you try to reassign a global variable, you might be surprised. | |
The following example is supposed to keep track of whether the | |
function has been called: | |
\index{multiple assignment} | |
\index{assignment!multiple} | |
\begin{verbatim} | |
been_called = False | |
def example2(): | |
been_called = True # WRONG | |
\end{verbatim} | |
% | |
But if you run it you will see that the value of \verb"been_called" | |
doesn't change. The problem is that {\tt example2} creates a new local | |
variable named \verb"been_called". The local variable goes away when | |
the function ends, and has no effect on the global variable. | |
\index{global statement} | |
\index{statement!global} | |
\index{declaration} | |
To reassign a global variable inside a function you have to | |
{\bf declare} the global variable before you use it: | |
\begin{verbatim} | |
been_called = False | |
def example2(): | |
global been_called | |
been_called = True | |
\end{verbatim} | |
% | |
The {\tt global} statement tells the interpreter | |
something like, ``In this function, when I say \verb"been_called", I | |
mean the global variable; don't create a local one.'' | |
\index{update!global variable} | |
\index{global variable!update} | |
Here's an example that tries to update a global variable: | |
\begin{verbatim} | |
count = 0 | |
def example3(): | |
count = count + 1 # WRONG | |
\end{verbatim} | |
% | |
If you run it you get: | |
\index{UnboundLocalError} | |
\index{exception!UnboundLocalError} | |
\begin{verbatim} | |
UnboundLocalError: local variable 'count' referenced before assignment | |
\end{verbatim} | |
% | |
Python assumes that {\tt count} is local, which means | |
that you are reading it before writing it. The solution, again, | |
is to declare {\tt count} global. | |
\index{counter} | |
\begin{verbatim} | |
def example3(): | |
global count | |
count += 1 | |
\end{verbatim} | |
% | |
If the global value is mutable, you can modify it without | |
declaring it: | |
\index{mutability} | |
\begin{verbatim} | |
known = {0:0, 1:1} | |
def example4(): | |
known[2] = 1 | |
\end{verbatim} | |
% | |
So you can add, remove and replace elements of a global list or | |
dictionary, but if you want to reassign the variable, you | |
have to declare it: | |
\begin{verbatim} | |
def example5(): | |
global known | |
known = dict() | |
\end{verbatim} | |
% | |
\section{Long integers} | |
\index{long integer} | |
\index{integer!long} | |
\index{type!long} | |
If you compute {\tt fibonacci(50)}, you get: | |
\begin{verbatim} | |
>>> fibonacci(50) | |
12586269025L | |
\end{verbatim} | |
% | |
The {\tt L} at the end indicates that the result is a long | |
integer, or type {\tt long}. In Python 3, {\tt long} is gone; all integers, | |
even really big ones, are type {\tt int}. | |
\index{Python 3} | |
Values with type {\tt int} have a limited range; | |
long integers can be arbitrarily big, but as they get bigger | |
they consume more space and time. | |
The mathematical operators work on long integers, and the functions | |
in the {\tt math} module, too, so in general any code that | |
works with {\tt int} will also work with {\tt long}. | |
Any time the result of a computation is too big to be represented with | |
an integer, Python converts the result as a long integer: | |
\begin{verbatim} | |
>>> 1000 * 1000 | |
1000000 | |
>>> 100000 * 100000 | |
10000000000L | |
\end{verbatim} | |
% | |
In the first case the result has type {\tt int}; in the | |
second case it is {\tt long}. | |
\begin{exercise} | |
\index{encryption} | |
\index{RSA algorithm} | |
\index{algorithm!RSA} | |
Exponentiation of large integers is the basis of common | |
algorithms for public-key encryption. Read the Wikipedia | |
page on the RSA algorithm (\url{http://en.wikipedia.org/wiki/RSA_(algorithm)}) | |
and write functions to encode and decode messages. | |
% TODO: solution for this one! | |
\end{exercise} | |
\section{Debugging} | |
\index{debugging} | |
As you work with bigger datasets it can become unwieldy to | |
debug by printing and checking data by hand. Here are some | |
suggestions for debugging large datasets: | |
\begin{description} | |
\item[Scale down the input:] If possible, reduce the size of the | |
dataset. For example if the program reads a text file, start with | |
just the first 10 lines, or with the smallest example you can find. | |
You can either edit the files themselves, or (better) modify the | |
program so it reads only the first {\tt n} lines. | |
If there is an error, you can reduce {\tt n} to the smallest | |
value that manifests the error, and then increase it gradually | |
as you find and correct errors. | |
\item[Check summaries and types:] Instead of printing and checking the | |
entire dataset, consider printing summaries of the data: for example, | |
the number of items in a dictionary or the total of a list of numbers. | |
A common cause of runtime errors is a value that is not the right | |
type. For debugging this kind of error, it is often enough to print | |
the type of a value. | |
\item[Write self-checks:] Sometimes you can write code to check | |
for errors automatically. For example, if you are computing the | |
average of a list of numbers, you could check that the result is | |
not greater than the largest element in the list or less than | |
the smallest. This is called a ``sanity check'' because it detects | |
results that are ``insane.'' | |
\index{sanity check} | |
\index{consistency check} | |
Another kind of check compares the results of two different | |
computations to see if they are consistent. This is called a | |
``consistency check.'' | |
\item[Pretty print the output:] Formatting debugging output | |
can make it easier to spot an error. We saw an example in | |
Section~\ref{factdebug}. The {\tt pprint} module provides | |
a {\tt pprint} function that displays built-in types in | |
a more human-readable format. | |
\index{pretty print} | |
\index{pprint module} | |
\index{module!pprint} | |
\end{description} | |
Again, time you spend building scaffolding can reduce | |
the time you spend debugging. | |
\index{scaffolding} | |
\section{Glossary} | |
\begin{description} | |
\item[dictionary:] A mapping from a set of keys to their | |
corresponding values. | |
\index{dictionary} | |
\item[key-value pair:] The representation of the mapping from | |
a key to a value. | |
\index{key-value pair} | |
\item[item:] Another name for a key-value pair. | |
\index{item!dictionary} | |
\item[key:] An object that appears in a dictionary as the | |
first part of a key-value pair. | |
\index{key} | |
\item[value:] An object that appears in a dictionary as the | |
second part of a key-value pair. This is more specific than | |
our previous use of the word ``value.'' | |
\index{value} | |
\item[implementation:] A way of performing a computation. | |
\index{implementation} | |
\item[hashtable:] The algorithm used to implement Python | |
dictionaries. | |
\index{hashtable} | |
\item[hash function:] A function used by a hashtable to compute the | |
location for a key. | |
\index{hash function} | |
\item[hashable:] A type that has a hash function. Immutable | |
types like integers, | |
floats and strings are hashable; mutable types like lists and | |
dictionaries are not. | |
\index{hashable} | |
\item[lookup:] A dictionary operation that takes a key and finds | |
the corresponding value. | |
\index{lookup} | |
\item[reverse lookup:] A dictionary operation that takes a value and finds | |
one or more keys that map to it. | |
\index{reverse lookup, dictionary} | |
\item[singleton:] A list (or other sequence) with a single element. | |
\index{singleton} | |
\item[call graph:] A diagram that shows every frame created during | |
the execution of a program, with an arrow from each caller to | |
each callee. | |
\index{call graph} | |
\index{diagram!call graph} | |
\item[histogram:] A set of counters. | |
\index{histogram} | |
\item[memo:] A computed value stored to avoid unnecessary future | |
computation. | |
\index{memo} | |
\item[global variable:] A variable defined outside a function. Global | |
variables can be accessed from any function. | |
\index{global variable} | |
\item[flag:] A boolean variable used to indicate whether a condition | |
is true. | |
\index{flag} | |
\item[declaration:] A statement like {\tt global} that tells the | |
interpreter something about a variable. | |
\index{declaration} | |
\end{description} | |
\section{Exercises} | |
\begin{exercise} | |
\index{duplicate} | |
If you did Exercise~\ref{duplicate}, you already have | |
a function named \verb"has_duplicates" that takes a list | |
as a parameter and returns {\tt True} if there is any object | |
that appears more than once in the list. | |
Use a dictionary to write a faster, simpler version of | |
\verb"has_duplicates". | |
Solution: \url{http://thinkpython.com/code/has_duplicates.py}. | |
\end{exercise} | |
\begin{exercise} | |
\label{exrotatepairs} | |
\index{letter rotation} | |
\index{rotation!letters} | |
Two words are ``rotate pairs'' if you can rotate one of them | |
and get the other (see \verb"rotate_word" in Exercise~\ref{exrotate}). | |
Write a program that reads a wordlist and finds all the rotate | |
pairs. Solution: \url{http://thinkpython.com/code/rotate_pairs.py}. | |
\end{exercise} | |
\begin{exercise} | |
\index{Car Talk} | |
\index{Puzzler} | |
Here's another Puzzler from {\em Car | |
Talk} (\url{http://www.cartalk.com/content/puzzlers}): | |
\begin{quote} | |
This was sent in by a fellow named Dan O'Leary. He came upon a common | |
one-syllable, five-letter word recently that has the following unique | |
property. When you remove the first letter, the remaining letters form | |
a homophone of the original word, that is a word that sounds exactly | |
the same. Replace the first letter, that is, put it back and remove | |
the second letter and the result is yet another homophone of the | |
original word. And the question is, what's the word? | |
Now I'm going to give you an example that doesn't work. Let's look at | |
the five-letter word, `wrack.' W-R-A-C-K, you know like to `wrack with | |
pain.' If I remove the first letter, I am left with a four-letter | |
word, 'R-A-C-K.' As in, `Holy cow, did you see the rack on that buck! | |
It must have been a nine-pointer!' It's a perfect homophone. If you | |
put the `w' back, and remove the `r,' instead, you're left with the | |
word, `wack,' which is a real word, it's just not a homophone of the | |
other two words. | |
But there is, however, at least one word that Dan and we know of, | |
which will yield two homophones if you remove either of the first two | |
letters to make two, new four-letter words. The question is, what's | |
the word? | |
\end{quote} | |
\index{homophone} | |
\index{reducible word} | |
\index{word, reducible} | |
You can use the dictionary from Exercise~\ref{wordlist2} to check | |
whether a string is in the word list. | |
To check whether two words are homophones, you can use the CMU | |
Pronouncing Dictionary. You can download it from | |
\url{http://www.speech.cs.cmu.edu/cgi-bin/cmudict} or from | |
\url{http://thinkpython.com/code/c06d} and you can also download | |
\url{http://thinkpython.com/code/pronounce.py}, which provides a function | |
named \verb"read_dictionary" that reads the pronouncing dictionary and | |
returns a Python dictionary that maps from each word to a string that | |
describes its primary pronunciation. | |
Write a program that lists all the words that solve the Puzzler. | |
Solution: \url{http://thinkpython.com/code/homophone.py}. | |
\end{exercise} | |
\chapter{Tuples} | |
\label{tuplechap} | |
\section{Tuples are immutable} | |
\index{tuple} | |
\index{type!tuple} | |
\index{sequence} | |
A tuple is a sequence of values. The values can be any type, and | |
they are indexed by integers, so in that respect tuples are a lot | |
like lists. The important difference is that tuples are immutable. | |
\index{mutability} | |
\index{immutability} | |
Syntactically, a tuple is a comma-separated list of values: | |
\begin{verbatim} | |
>>> t = 'a', 'b', 'c', 'd', 'e' | |
\end{verbatim} | |
% | |
Although it is not necessary, it is common to enclose tuples in | |
parentheses: | |
\index{parentheses!tuples in} | |
\begin{verbatim} | |
>>> t = ('a', 'b', 'c', 'd', 'e') | |
\end{verbatim} | |
% | |
To create a tuple with a single element, you have to include a final | |
comma: | |
\index{singleton} | |
\index{tuple!singleton} | |
\begin{verbatim} | |
>>> t1 = 'a', | |
>>> type(t1) | |
<type 'tuple'> | |
\end{verbatim} | |
% | |
A value in parentheses is not a tuple: | |
\begin{verbatim} | |
>>> t2 = ('a') | |
>>> type(t2) | |
<type 'str'> | |
\end{verbatim} | |
% | |
Another way to create a tuple is the built-in function {\tt tuple}. | |
With no argument, it creates an empty tuple: | |
\index{tuple function} | |
\index{function!tuple} | |
\begin{verbatim} | |
>>> t = tuple() | |
>>> print t | |
() | |
\end{verbatim} | |
% | |
If the argument is a sequence (string, list or tuple), the result | |
is a tuple with the elements of the sequence: | |
\begin{verbatim} | |
>>> t = tuple('lupins') | |
>>> print t | |
('l', 'u', 'p', 'i', 'n', 's') | |
\end{verbatim} | |
% | |
Because {\tt tuple} is the name of a built-in function, you should | |
avoid using it as a variable name. | |
Most list operators also work on tuples. The bracket operator | |
indexes an element: | |
\index{bracket operator} | |
\index{operator!bracket} | |
\begin{verbatim} | |
>>> t = ('a', 'b', 'c', 'd', 'e') | |
>>> print t[0] | |
'a' | |
\end{verbatim} | |
% | |
And the slice operator selects a range of elements. | |
\index{slice operator} | |
\index{operator!slice} | |
\index{tuple!slice} | |
\index{slice!tuple} | |
\begin{verbatim} | |
>>> print t[1:3] | |
('b', 'c') | |
\end{verbatim} | |
% | |
But if you try to modify one of the elements of the tuple, you get | |
an error: | |
\index{exception!TypeError} | |
\index{TypeError} | |
\index{item assignment} | |
\index{assignment!item} | |
\begin{verbatim} | |
>>> t[0] = 'A' | |
TypeError: object doesn't support item assignment | |
\end{verbatim} | |
% | |
You can't modify the elements of a tuple, but you can replace | |
one tuple with another: | |
\begin{verbatim} | |
>>> t = ('A',) + t[1:] | |
>>> print t | |
('A', 'b', 'c', 'd', 'e') | |
\end{verbatim} | |
% | |
\section{Tuple assignment} | |
\label{tuple.assignment} | |
\index{tuple!assignment} | |
\index{assignment!tuple} | |
\index{swap pattern} | |
\index{pattern!swap} | |
It is often useful to swap the values of two variables. | |
With conventional assignments, you have to use a temporary | |
variable. For example, to swap {\tt a} and {\tt b}: | |
\begin{verbatim} | |
>>> temp = a | |
>>> a = b | |
>>> b = temp | |
\end{verbatim} | |
% | |
This solution is cumbersome; {\bf tuple assignment} is more elegant: | |
\begin{verbatim} | |
>>> a, b = b, a | |
\end{verbatim} | |
% | |
The left side is a tuple of variables; the right side is a tuple of | |
expressions. Each value is assigned to its respective variable. | |
All the expressions on the right side are evaluated before any | |
of the assignments. | |
The number of variables on the left and the number of | |
values on the right have to be the same: | |
\index{exception!ValueError} | |
\index{ValueError} | |
\begin{verbatim} | |
>>> a, b = 1, 2, 3 | |
ValueError: too many values to unpack | |
\end{verbatim} | |
% | |
More generally, the right side can be any kind of sequence | |
(string, list or tuple). For example, to split an email address | |
into a user name and a domain, you could write: | |
\index{split method} | |
\index{method!split} | |
\index{email address} | |
\begin{verbatim} | |
>>> addr = '[email protected]' | |
>>> uname, domain = addr.split('@') | |
\end{verbatim} | |
% | |
The return value from {\tt split} is a list with two elements; | |
the first element is assigned to {\tt uname}, the second to | |
{\tt domain}. | |
\begin{verbatim} | |
>>> print uname | |
monty | |
>>> print domain | |
python.org | |
\end{verbatim} | |
% | |
\section{Tuples as return values} | |
\index{tuple} | |
\index{value!tuple} | |
\index{return value!tuple} | |
\index{function, tuple as return value} | |
Strictly speaking, a function can only return one value, but | |
if the value is a tuple, the effect is the same as returning | |
multiple values. For example, if you want to divide two integers | |
and compute the quotient and remainder, it is inefficient to | |
compute {\tt x/y} and then {\tt x\%y}. It is better to compute | |
them both at the same time. | |
\index{divmod} | |
The built-in function {\tt divmod} takes two arguments and | |
returns a tuple of two values, the quotient and remainder. | |
You can store the result as a tuple: | |
\begin{verbatim} | |
>>> t = divmod(7, 3) | |
>>> print t | |
(2, 1) | |
\end{verbatim} | |
% | |
Or use tuple assignment to store the elements separately: | |
\index{tuple assignment} | |
\index{assignment!tuple} | |
\begin{verbatim} | |
>>> quot, rem = divmod(7, 3) | |
>>> print quot | |
2 | |
>>> print rem | |
1 | |
\end{verbatim} | |
% | |
Here is an example of a function that returns a tuple: | |
\begin{verbatim} | |
def min_max(t): | |
return min(t), max(t) | |
\end{verbatim} | |
% | |
{\tt max} and {\tt min} are built-in functions that find | |
the largest and smallest elements of a sequence. \verb"min_max" | |
computes both and returns a tuple of two values. | |
\index{max function} | |
\index{function!max} | |
\index{min function} | |
\index{function!min} | |
\section{Variable-length argument tuples} | |
\index{variable-length argument tuple} | |
\index{argument!variable-length tuple} | |
\index{gather} | |
\index{parameter!gather} | |
\index{argument!gather} | |
Functions can take a variable number of arguments. A parameter | |
name that begins with {\tt *} {\bf gathers} arguments into | |
a tuple. For example, {\tt printall} | |
takes any number of arguments and prints them: | |
\begin{verbatim} | |
def printall(*args): | |
print args | |
\end{verbatim} | |
% | |
The gather parameter can have any name you like, but {\tt args} is | |
conventional. Here's how the function works: | |
\begin{verbatim} | |
>>> printall(1, 2.0, '3') | |
(1, 2.0, '3') | |
\end{verbatim} | |
% | |
The complement of gather is {\bf scatter}. If you have a | |
sequence of values and you want to pass it to a function | |
as multiple arguments, you can use the {\tt *} operator. | |
For example, {\tt divmod} takes exactly two arguments; it | |
doesn't work with a tuple: | |
% removing this because we haven't seen optional parameters yet | |
%You can combine the gather operator with required and positional | |
%arguments: | |
%%\begin{verbatim} | |
%def pointless(required, optional=0, *args): | |
% print required, optional, args | |
%\end{verbatim} | |
%\afterverb | |
% | |
%Run this function with 1, 2, 3 and 4 or more arguments and | |
%make sure you understand what it does. | |
\index{scatter} | |
\index{argument scatter} | |
\index{TypeError} | |
\index{exception!TypeError} | |
\begin{verbatim} | |
>>> t = (7, 3) | |
>>> divmod(t) | |
TypeError: divmod expected 2 arguments, got 1 | |
\end{verbatim} | |
% | |
But if you scatter the tuple, it works: | |
\begin{verbatim} | |
>>> divmod(*t) | |
(2, 1) | |
\end{verbatim} | |
% | |
\begin{exercise} | |
Many of the built-in functions use | |
variable-length argument tuples. For example, {\tt max} | |
and {\tt min} can take any number of arguments: | |
\index{max function} | |
\index{function!max} | |
\index{min function} | |
\index{function!min} | |
\begin{verbatim} | |
>>> max(1,2,3) | |
3 | |
\end{verbatim} | |
% | |
But {\tt sum} does not. | |
\index{sum function} | |
\index{function!sum} | |
\begin{verbatim} | |
>>> sum(1,2,3) | |
TypeError: sum expected at most 2 arguments, got 3 | |
\end{verbatim} | |
% | |
Write a function called {\tt sumall} that takes any number | |
of arguments and returns their sum. | |
\end{exercise} | |
\section{Lists and tuples} | |
\index{zip function} | |
\index{function!zip} | |
{\tt zip} is a built-in function that takes two or more sequences and | |
``zips'' them into a list of tuples where each tuple contains one | |
element from each sequence. In Python 3, {\tt zip} returns an iterator | |
of tuples, but for most purposes, an iterator behaves like a list. | |
\index{Python 3} | |
This example zips a string and a list: | |
\begin{verbatim} | |
>>> s = 'abc' | |
>>> t = [0, 1, 2] | |
>>> zip(s, t) | |
[('a', 0), ('b', 1), ('c', 2)] | |
\end{verbatim} | |
% | |
The result is a list of tuples where each tuple contains | |
a character from the string and the corresponding element from | |
the list. | |
\index{list!of tuples} | |
If the sequences are not the same length, the result has the | |
length of the shorter one. | |
\begin{verbatim} | |
>>> zip('Anne', 'Elk') | |
[('A', 'E'), ('n', 'l'), ('n', 'k')] | |
\end{verbatim} | |
% | |
You can use tuple assignment in a {\tt for} loop to traverse a list of | |
tuples: | |
\index{traversal} | |
\index{tuple assignment} | |
\index{assignment!tuple} | |
\begin{verbatim} | |
t = [('a', 0), ('b', 1), ('c', 2)] | |
for letter, number in t: | |
print number, letter | |
\end{verbatim} | |
% | |
Each time through the loop, Python selects the next tuple in | |
the list and assigns the elements to {\tt letter} and | |
{\tt number}. The output of this loop is: | |
\index{loop} | |
\begin{verbatim} | |
0 a | |
1 b | |
2 c | |
\end{verbatim} | |
% | |
If you combine {\tt zip}, {\tt for} and tuple assignment, you get a | |
useful idiom for traversing two (or more) sequences at the same | |
time. For example, \verb"has_match" takes two sequences, {\tt t1} and | |
{\tt t2}, and returns {\tt True} if there is an index {\tt i} | |
such that {\tt t1[i] == t2[i]}: | |
\index{for loop} | |
\begin{verbatim} | |
def has_match(t1, t2): | |
for x, y in zip(t1, t2): | |
if x == y: | |
return True | |
return False | |
\end{verbatim} | |
% | |
If you need to traverse the elements of a sequence and their | |
indices, you can use the built-in function {\tt enumerate}: | |
\index{traversal} | |
\index{enumerate function} | |
\index{function!enumerate} | |
\begin{verbatim} | |
for index, element in enumerate('abc'): | |
print index, element | |
\end{verbatim} | |
% | |
The output of this loop is: | |
\begin{verbatim} | |
0 a | |
1 b | |
2 c | |
\end{verbatim} | |
% | |
Again. | |
\section{Dictionaries and tuples} | |
\label{dictuple} | |
\index{dictionary} | |
\index{items method} | |
\index{method!items} | |
\index{key-value pair} | |
Dictionaries have a method called {\tt items} that returns a list of | |
tuples, where each tuple is a key-value pair. | |
\begin{verbatim} | |
>>> d = {'a':0, 'b':1, 'c':2} | |
>>> t = d.items() | |
>>> print t | |
[('a', 0), ('c', 2), ('b', 1)] | |
\end{verbatim} | |
% | |
As you should expect from a dictionary, the items are in no | |
particular order. In Python 3, {\tt items} returns an iterator, | |
but for many purposes, iterators behave like lists. | |
Going in the other direction, you can use a list of tuples to | |
initialize a new dictionary: \index{dictionary!initialize} | |
\begin{verbatim} | |
>>> t = [('a', 0), ('c', 2), ('b', 1)] | |
>>> d = dict(t) | |
>>> print d | |
{'a': 0, 'c': 2, 'b': 1} | |
\end{verbatim} | |
Combining {\tt dict} with {\tt zip} yields a concise way | |
to create a dictionary: | |
\index{zip function!use with dict} | |
\begin{verbatim} | |
>>> d = dict(zip('abc', range(3))) | |
>>> print d | |
{'a': 0, 'c': 2, 'b': 1} | |
\end{verbatim} | |
% | |
The dictionary method {\tt update} also takes a list of tuples | |
and adds them, as key-value pairs, to an existing dictionary. | |
\index{update method} | |
\index{method!update} | |
\index{traverse!dictionary} | |
\index{dictionary!traversal} | |
Combining {\tt items}, tuple assignment and {\tt for}, you | |
get the idiom for traversing the keys and values of a dictionary: | |
\begin{verbatim} | |
for key, val in d.items(): | |
print val, key | |
\end{verbatim} | |
% | |
The output of this loop is: | |
\begin{verbatim} | |
0 a | |
2 c | |
1 b | |
\end{verbatim} | |
% | |
Again. | |
It is common to use tuples as keys in dictionaries (primarily because | |
you can't use lists). For example, a telephone directory might map | |
from last-name, first-name pairs to telephone numbers. Assuming | |
that we have defined {\tt last}, {\tt first} and {\tt number}, we | |
could write: | |
\index{tuple!as key in dictionary} | |
\index{hashable} | |
\begin{verbatim} | |
directory[last,first] = number | |
\end{verbatim} | |
% | |
The expression in brackets is a tuple. We could use tuple | |
assignment to traverse this dictionary. | |
\index{tuple!in brackets} | |
\begin{verbatim} | |
for last, first in directory: | |
print first, last, directory[last,first] | |
\end{verbatim} | |
% | |
This loop traverses the keys in {\tt directory}, which are tuples. It | |
assigns the elements of each tuple to {\tt last} and {\tt first}, then | |
prints the name and corresponding telephone number. | |
There are two ways to represent tuples in a state diagram. The more | |
detailed version shows the indices and elements just as they appear in | |
a list. For example, the tuple \verb"('Cleese', 'John')" would appear | |
as in Figure~\ref{fig.tuple1}. | |
\index{state diagram} | |
\index{diagram!state} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/tuple1.pdf}} | |
\caption{State diagram.} | |
\label{fig.tuple1} | |
\end{figure} | |
But in a larger diagram you might want to leave out the | |
details. For example, a diagram of the telephone directory might | |
appear as in Figure~\ref{fig.dict2}. | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/dict2.pdf}} | |
\caption{State diagram.} | |
\label{fig.dict2} | |
\end{figure} | |
Here the tuples are shown using Python syntax as a graphical | |
shorthand. | |
The telephone number in the diagram is the complaints line for the | |
BBC, so please don't call it. | |
\section{Comparing tuples} | |
\index{comparison!tuple} | |
\index{tuple!comparison} | |
\index{sort method} | |
\index{method!sort} | |
The relational operators work with tuples and other sequences; | |
Python starts by comparing the first element from each | |
sequence. If they are equal, it goes on to the next elements, | |
and so on, until it finds elements that differ. Subsequent | |
elements are not considered (even if they are really big). | |
\begin{verbatim} | |
>>> (0, 1, 2) < (0, 3, 4) | |
True | |
>>> (0, 1, 2000000) < (0, 3, 4) | |
True | |
\end{verbatim} | |
% | |
The {\tt sort} function works the same way. It sorts | |
primarily by first element, but in the case of a tie, it sorts | |
by second element, and so on. | |
This feature lends itself to a pattern called {\bf DSU} for | |
\begin{description} | |
\item[Decorate] a sequence by building a list of tuples | |
with one or more sort keys preceding the elements from the sequence, | |
\item[Sort] the list of tuples, and | |
\item[Undecorate] by extracting the sorted elements of the sequence. | |
\end{description} | |
\label{DSU} | |
\index{DSU pattern} | |
\index{pattern!DSU} | |
\index{decorate-sort-undecorate pattern} | |
\index{pattern!decorate-sort-undecorate} | |
For example, suppose you have a list of words and you want to | |
sort them from longest to shortest: | |
\begin{verbatim} | |
def sort_by_length(words): | |
t = [] | |
for word in words: | |
t.append((len(word), word)) | |
t.sort(reverse=True) | |
res = [] | |
for length, word in t: | |
res.append(word) | |
return res | |
\end{verbatim} | |
% | |
The first loop builds a list of tuples, where each | |
tuple is a word preceded by its length. | |
{\tt sort} compares the first element, length, first, and | |
only considers the second element to break ties. The keyword argument | |
{\tt reverse=True} tells {\tt sort} to go in decreasing order. | |
\index{keyword argument} | |
\index{argument!keyword} | |
\index{traversal} | |
The second loop traverses the list of tuples and builds a list of | |
words in descending order of length. | |
\begin{exercise} | |
In this example, ties are broken by comparing words, so words | |
with the same length appear in reverse alphabetical order. For other | |
applications you might want to break ties at random. Modify | |
this example so that words with the same length appear in | |
random order. Hint: see the {\tt random} function in the | |
{\tt random} module. | |
Solution: \url{http://thinkpython.com/code/unstable_sort.py}. | |
\index{random module} | |
\index{module!random} | |
\index{random function} | |
\index{function!random} | |
\end{exercise} | |
\section{Sequences of sequences} | |
\index{sequence} | |
I have focused on lists of tuples, but almost all of the examples in | |
this chapter also work with lists of lists, tuples of tuples, and | |
tuples of lists. To avoid enumerating the possible combinations, it | |
is sometimes easier to talk about sequences of sequences. | |
In many contexts, the different kinds of sequences (strings, lists and | |
tuples) can be used interchangeably. So how and why do you choose one | |
over the others? | |
\index{string} | |
\index{list} | |
\index{tuple} | |
\index{mutability} | |
\index{immutability} | |
To start with the obvious, strings are more limited than other | |
sequences because the elements have to be characters. They are | |
also immutable. If you need the ability to change the characters | |
in a string (as opposed to creating a new string), you might | |
want to use a list of characters instead. | |
Lists are more common than tuples, mostly because they are mutable. | |
But there are a few cases where you might prefer tuples: | |
\begin{enumerate} | |
\item In some contexts, like a {\tt return} statement, it is | |
syntactically simpler to create a tuple than a list. In other | |
contexts, you might prefer a list. | |
\item If you want to use a sequence as a dictionary key, you | |
have to use an immutable type like a tuple or string. | |
\item If you are passing a sequence as an argument to a function, | |
using tuples reduces the potential for unexpected behavior | |
due to aliasing. | |
\end{enumerate} | |
Because tuples are immutable, they don't provide methods | |
like {\tt sort} and {\tt reverse}, which modify existing lists. | |
But Python provides the built-in functions {\tt sorted} | |
and {\tt reversed}, which take any sequence as a parameter | |
and return a new list with the same elements in a different | |
order. | |
\index{sorted function} | |
\index{function!sorted} | |
\index{reversed function} | |
\index{function!reversed} | |
\section{Debugging} | |
\index{debugging} | |
\index{data structure} | |
\index{shape error} | |
\index{error!shape} | |
Lists, dictionaries and tuples are known generically as {\bf data | |
structures}; in this chapter we are starting to see compound data | |
structures, like lists of tuples, and dictionaries that contain tuples | |
as keys and lists as values. Compound data structures are useful, but | |
they are prone to what I call {\bf shape errors}; that is, errors | |
caused when a data structure has the wrong type, size or composition. | |
For example, if you are expecting a list with one integer and I | |
give you a plain old integer (not in a list), it won't work. | |
\index{structshape module} | |
\index{module!structshape} | |
% TODO: structshape is now part of Swampy | |
To help debug these kinds of errors, I have written a module | |
called {\tt structshape} that provides a function, also called | |
{\tt structshape}, that takes any kind of data structure as | |
an argument and returns a string that summarizes its shape. | |
You can download it from \url{http://thinkpython.com/code/structshape.py} | |
Here's the result for a simple list: | |
\begin{verbatim} | |
>>> from structshape import structshape | |
>>> t = [1,2,3] | |
>>> print structshape(t) | |
list of 3 int | |
\end{verbatim} | |
% | |
A fancier program might write ``list of 3 int{\em s},'' but it | |
was easier not to deal with plurals. Here's a list of lists: | |
\begin{verbatim} | |
>>> t2 = [[1,2], [3,4], [5,6]] | |
>>> print structshape(t2) | |
list of 3 list of 2 int | |
\end{verbatim} | |
% | |
If the elements of the list are not the same type, | |
{\tt structshape} groups them, in order, by type: | |
\begin{verbatim} | |
>>> t3 = [1, 2, 3, 4.0, '5', '6', [7], [8], 9] | |
>>> print structshape(t3) | |
list of (3 int, float, 2 str, 2 list of int, int) | |
\end{verbatim} | |
% | |
Here's a list of tuples: | |
\begin{verbatim} | |
>>> s = 'abc' | |
>>> lt = zip(t, s) | |
>>> print structshape(lt) | |
list of 3 tuple of (int, str) | |
\end{verbatim} | |
% | |
And here's a dictionary with 3 items that map integers to strings. | |
\begin{verbatim} | |
>>> d = dict(lt) | |
>>> print structshape(d) | |
dict of 3 int->str | |
\end{verbatim} | |
% | |
If you are having trouble keeping track of your data structures, | |
{\tt structshape} can help. | |
\section{Glossary} | |
\begin{description} | |
\item[tuple:] An immutable sequence of elements. | |
\index{tuple} | |
\item[tuple assignment:] An assignment with a sequence on the | |
right side and a tuple of variables on the left. The right | |
side is evaluated and then its elements are assigned to the | |
variables on the left. | |
\index{tuple assignment} | |
\index{assignment!tuple} | |
\item[gather:] The operation of assembling a variable-length | |
argument tuple. | |
\index{gather} | |
\item[scatter:] The operation of treating a sequence as a list of | |
arguments. | |
\index{scatter} | |
\item[DSU:] Abbreviation of ``decorate-sort-undecorate,'' a | |
pattern that involves building a list of tuples, sorting, and | |
extracting part of the result. | |
\index{DSU pattern} | |
\item[data structure:] A collection of related values, often | |
organized in lists, dictionaries, tuples, etc. | |
\index{data structure} | |
\item[shape (of a data structure):] A summary of the type, | |
size and composition of a data structure. | |
\index{shape} | |
\end{description} | |
\section{Exercises} | |
\begin{exercise} | |
Write a function called \verb"most_frequent" that takes a string and | |
prints the letters in decreasing order of frequency. Find text | |
samples from several different languages and see how letter frequency | |
varies between languages. Compare your results with the tables at | |
\url{http://en.wikipedia.org/wiki/Letter_frequencies}. Solution: | |
\url{http://thinkpython.com/code/most_frequent.py}. \index{letter | |
frequency} \index{frequency!letter} | |
\end{exercise} | |
\begin{exercise} | |
\label{anagrams} | |
\index{anagram set} | |
\index{set!anagram} | |
More anagrams! | |
\begin{enumerate} | |
\item Write a program | |
that reads a word list from a file (see Section~\ref{wordlist}) and | |
prints all the sets of words that are anagrams. | |
Here is an example of what the output might look like: | |
\begin{verbatim} | |
['deltas', 'desalt', 'lasted', 'salted', 'slated', 'staled'] | |
['retainers', 'ternaries'] | |
['generating', 'greatening'] | |
['resmelts', 'smelters', 'termless'] | |
\end{verbatim} | |
% | |
Hint: you might want to build a dictionary that maps from a | |
set of letters to a list of words that can be spelled with those | |
letters. The question is, how can you represent the set of | |
letters in a way that can be used as a key? | |
\item Modify the previous program so that it prints the largest set | |
of anagrams first, followed by the second largest set, and so on. | |
\index{Scrabble} | |
\index{bingo} | |
\item In Scrabble a ``bingo'' is when you play all seven tiles in | |
your rack, along with a letter on the board, to form an eight-letter | |
word. What set of 8 letters forms the most possible bingos? | |
Hint: there are seven. | |
% (7, ['angriest', 'astringe', 'ganister', 'gantries', 'granites', | |
% 'ingrates', 'rangiest']) | |
Solution: \url{http://thinkpython.com/code/anagram_sets.py}. | |
\end{enumerate} | |
\end{exercise} | |
\begin{exercise} | |
\index{metathesis} | |
Two words form a ``metathesis pair'' if you can transform one into the | |
other by swapping two letters; for example, ``converse'' and | |
``conserve.'' Write a program that finds all of the metathesis pairs | |
in the dictionary. Hint: don't test all pairs of words, and don't | |
test all possible swaps. Solution: \url{http://thinkpython.com/code/metathesis.py}. | |
Credit: This exercise is inspired by an example at \url{http://puzzlers.org}. | |
\end{exercise} | |
\begin{exercise} | |
\index{Car Talk} | |
\index{Puzzler} | |
Here's another Car Talk Puzzler | |
(\url{http://www.cartalk.com/content/puzzlers}): | |
\begin{quote} | |
What is the longest English word, that remains a valid English word, | |
as you remove its letters one at a time? | |
Now, letters can be removed from either end, or the middle, but you | |
can't rearrange any of the letters. Every time you drop a letter, you | |
wind up with another English word. If you do that, you're eventually | |
going to wind up with one letter and that too is going to be an | |
English word---one that's found in the dictionary. I want to know | |
what's the longest word and how many letters does it | |
have? | |
I'm going to give you a little modest example: Sprite. Ok? You start | |
off with sprite, you take a letter off, one from the interior of the | |
word, take the r away, and we're left with the word spite, then we | |
take the e off the end, we're left with spit, we take the s off, we're | |
left with pit, it, and I. | |
\end{quote} | |
\index{reducible word} | |
\index{word, reducible} | |
Write a program to find all words that can be reduced in this way, | |
and then find the longest one. | |
This exercise is a little more challenging than most, so here are | |
some suggestions: | |
\begin{enumerate} | |
\item You might want to write a function that takes a word and | |
computes a list of all the words that can be formed by removing one | |
letter. These are the ``children'' of the word. | |
\index{recursive definition} | |
\index{definition!recursive} | |
\item Recursively, a word is reducible if any of its children | |
are reducible. As a base case, you can consider the empty | |
string reducible. | |
\item The wordlist I provided, {\tt words.txt}, doesn't | |
contain single letter words. So you might want to add | |
``I'', ``a'', and the empty string. | |
\item To improve the performance of your program, you might want | |
to memoize the words that are known to be reducible. | |
\end{enumerate} | |
Solution: \url{http://thinkpython.com/code/reducible.py}. | |
\end{exercise} | |
%\begin{exercise} | |
%\url{http://en.wikipedia.org/wiki/Word_Ladder} | |
%\end{exercise} | |
\chapter{Case study: data structure selection} | |
\section{Word frequency analysis} | |
\label{analysis} | |
As usual, you should at least attempt the following exercises | |
before you read my solutions. | |
\begin{exercise} | |
Write a program that reads a file, breaks each line into | |
words, strips whitespace and punctuation from the words, and | |
converts them to lowercase. | |
\index{string module} | |
\index{module!string} | |
Hint: The {\tt string} module provides strings named {\tt whitespace}, | |
which contains space, tab, newline, etc., and {\tt | |
punctuation} which contains the punctuation characters. Let's see | |
if we can make Python swear: | |
\begin{verbatim} | |
>>> import string | |
>>> print string.punctuation | |
!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~ | |
\end{verbatim} | |
% | |
Also, you might consider using the string methods {\tt strip}, | |
{\tt replace} and {\tt translate}. | |
\index{strip method} | |
\index{method!strip} | |
\index{replace method} | |
\index{method!replace} | |
\index{translate method} | |
\index{method!translate} | |
\end{exercise} | |
\begin{exercise} | |
\index{Project Gutenberg} | |
Go to Project Gutenberg (\url{http://gutenberg.org}) and download | |
your favorite out-of-copyright book in plain text format. | |
\index{plain text} | |
\index{text!plain} | |
Modify your program from the previous exercise to read the book | |
you downloaded, skip over the header information at the beginning | |
of the file, and process the rest of the words as before. | |
Then modify the program to count the total number of words in | |
the book, and the number of times each word is used. | |
\index{word frequency} | |
\index{frequency!word} | |
Print the number of different words used in the book. Compare | |
different books by different authors, written in different eras. | |
Which author uses the most extensive vocabulary? | |
\end{exercise} | |
\begin{exercise} | |
Modify the program from the previous exercise to print the | |
20 most frequently-used words in the book. | |
\end{exercise} | |
\begin{exercise} | |
Modify the previous program to read a word list (see | |
Section~\ref{wordlist}) and then print all the words in the book that | |
are not in the word list. How many of them are typos? How many of | |
them are common words that {\em should} be in the word list, and how | |
many of them are really obscure? | |
\end{exercise} | |
\section{Random numbers} | |
\index{random number} | |
\index{number, random} | |
\index{deterministic} | |
\index{pseudorandom} | |
Given the same inputs, most computer programs generate the same | |
outputs every time, so they are said to be {\bf deterministic}. | |
Determinism is usually a good thing, since we expect the same | |
calculation to yield the same result. For some applications, though, | |
we want the computer to be unpredictable. Games are an obvious | |
example, but there are more. | |
Making a program truly nondeterministic turns out to be not so easy, | |
but there are ways to make it at least seem nondeterministic. One of | |
them is to use algorithms that generate {\bf pseudorandom} numbers. | |
Pseudorandom numbers are not truly random because they are generated | |
by a deterministic computation, but just by looking at the numbers it | |
is all but impossible to distinguish them from random. | |
\index{random module} | |
\index{module!random} | |
The {\tt random} module provides functions that generate | |
pseudorandom numbers (which I will simply call ``random'' from | |
here on). | |
\index{random function} | |
\index{function!random} | |
The function {\tt random} returns a random float | |
between 0.0 and 1.0 (including 0.0 but not 1.0). Each time you | |
call {\tt random}, you get the next number in a long series. To see a | |
sample, run this loop: | |
\begin{verbatim} | |
import random | |
for i in range(10): | |
x = random.random() | |
print x | |
\end{verbatim} | |
% | |
The function {\tt randint} takes parameters {\tt low} and | |
{\tt high} and returns an integer between {\tt low} and | |
{\tt high} (including both). | |
\index{randint function} | |
\index{function!randint} | |
\begin{verbatim} | |
>>> random.randint(5, 10) | |
5 | |
>>> random.randint(5, 10) | |
9 | |
\end{verbatim} | |
% | |
To choose an element from a sequence at random, you can use | |
{\tt choice}: | |
\index{choice function} | |
\index{function!choice} | |
\begin{verbatim} | |
>>> t = [1, 2, 3] | |
>>> random.choice(t) | |
2 | |
>>> random.choice(t) | |
3 | |
\end{verbatim} | |
% | |
The {\tt random} module also provides functions to generate | |
random values from continuous distributions including | |
Gaussian, exponential, gamma, and a few more. | |
\begin{exercise} | |
\index{histogram!random choice} | |
Write a function named \verb"choose_from_hist" that takes | |
a histogram as defined in Section~\ref{histogram} and returns a | |
random value from the histogram, chosen with probability | |
in proportion to frequency. For example, for this histogram: | |
\begin{verbatim} | |
>>> t = ['a', 'a', 'b'] | |
>>> hist = histogram(t) | |
>>> print hist | |
{'a': 2, 'b': 1} | |
\end{verbatim} | |
% | |
your function should return {\tt 'a'} with probability $2/3$ and {\tt 'b'} | |
with probability $1/3$. | |
\end{exercise} | |
\section{Word histogram} | |
You should attempt the previous exercises before you go on. | |
You can download my solution from | |
\url{http://thinkpython.com/code/analyze_book.py}. You will | |
also need \url{http://thinkpython.com/code/emma.txt}. | |
Here is a program that reads a file and builds a histogram of the | |
words in the file: | |
\index{histogram!word frequencies} | |
\begin{verbatim} | |
import string | |
def process_file(filename): | |
hist = dict() | |
fp = open(filename) | |
for line in fp: | |
process_line(line, hist) | |
return hist | |
def process_line(line, hist): | |
line = line.replace('-', ' ') | |
for word in line.split(): | |
word = word.strip(string.punctuation + string.whitespace) | |
word = word.lower() | |
hist[word] = hist.get(word, 0) + 1 | |
hist = process_file('emma.txt') | |
\end{verbatim} | |
% | |
This program reads {\tt emma.txt}, which contains the text of {\em | |
Emma} by Jane Austen. | |
\index{Austin, Jane} | |
\verb"process_file" loops through the lines of the file, | |
passing them one at a time to \verb"process_line". The histogram | |
{\tt hist} is being used as an accumulator. | |
\index{accumulator!histogram} | |
\index{traversal} | |
\verb"process_line" uses the string method {\tt replace} to replace | |
hyphens with spaces before using {\tt split} to break the line into a | |
list of strings. It traverses the list of words and uses {\tt strip} | |
and {\tt lower} to remove punctuation and convert to lower case. (It | |
is a shorthand to say that strings are ``converted;'' remember that | |
string are immutable, so methods like {\tt strip} and {\tt lower} | |
return new strings.) | |
Finally, \verb"process_line" updates the histogram by creating a new | |
item or incrementing an existing one. | |
\index{update!histogram} | |
To count the total number of words in the file, we can add up | |
the frequencies in the histogram: | |
\begin{verbatim} | |
def total_words(hist): | |
return sum(hist.values()) | |
\end{verbatim} | |
% | |
The number of different words is just the number of items in | |
the dictionary: | |
\begin{verbatim} | |
def different_words(hist): | |
return len(hist) | |
\end{verbatim} | |
% | |
Here is some code to print the results: | |
\begin{verbatim} | |
print 'Total number of words:', total_words(hist) | |
print 'Number of different words:', different_words(hist) | |
\end{verbatim} | |
% | |
And the results: | |
\begin{verbatim} | |
Total number of words: 161080 | |
Number of different words: 7214 | |
\end{verbatim} | |
% | |
\section{Most common words} | |
\index{DSU pattern} | |
\index{pattern!DSU} | |
To find the most common words, we can apply the DSU pattern; | |
\verb"most_common" takes a histogram and returns a list of | |
word-frequency tuples, sorted in reverse order by frequency: | |
\begin{verbatim} | |
def most_common(hist): | |
t = [] | |
for key, value in hist.items(): | |
t.append((value, key)) | |
t.sort(reverse=True) | |
return t | |
\end{verbatim} | |
% | |
Here is a loop that prints the ten most common words: | |
\begin{verbatim} | |
t = most_common(hist) | |
print 'The most common words are:' | |
for freq, word in t[0:10]: | |
print word, '\t', freq | |
\end{verbatim} | |
% | |
And here are the results from {\em Emma}: | |
\begin{verbatim} | |
The most common words are: | |
to 5242 | |
the 5205 | |
and 4897 | |
of 4295 | |
i 3191 | |
a 3130 | |
it 2529 | |
her 2483 | |
was 2400 | |
she 2364 | |
\end{verbatim} | |
% | |
\section{Optional parameters} | |
\index{optional parameter} | |
\index{parameter!optional} | |
We have seen built-in functions and methods that take a variable | |
number of arguments. It is possible to write user-defined functions | |
with optional arguments, too. For example, here is a function that | |
prints the most common words in a histogram | |
\begin{verbatim} | |
def print_most_common(hist, num=10): | |
t = most_common(hist) | |
print 'The most common words are:' | |
for freq, word in t[:num]: | |
print word, '\t', freq | |
\end{verbatim} | |
The first parameter is required; the second is optional. | |
The {\bf default value} of {\tt num} is 10. | |
\index{default value} | |
\index{value!default} | |
If you only provide one argument: | |
\begin{verbatim} | |
print_most_common(hist) | |
\end{verbatim} | |
{\tt num} gets the default value. If you provide two arguments: | |
\begin{verbatim} | |
print_most_common(hist, 20) | |
\end{verbatim} | |
{\tt num} gets the value of the argument instead. In other | |
words, the optional argument {\bf overrides} the default value. | |
\index{override} | |
If a function has both required and optional parameters, all | |
the required parameters have to come first, followed by the | |
optional ones. | |
\section{Dictionary subtraction} | |
\index{dictionary!subtraction} | |
\index{subtraction!dictionary} | |
Finding the words from the book that are not in the word list | |
from {\tt words.txt} is a problem you might recognize as set | |
subtraction; that is, we want to find all the words from one | |
set (the words in the book) that are not in another set (the | |
words in the list). | |
{\tt subtract} takes dictionaries {\tt d1} and {\tt d2} and returns a | |
new dictionary that contains all the keys from {\tt d1} that are not | |
in {\tt d2}. Since we don't really care about the values, we | |
set them all to None. | |
\begin{verbatim} | |
def subtract(d1, d2): | |
res = dict() | |
for key in d1: | |
if key not in d2: | |
res[key] = None | |
return res | |
\end{verbatim} | |
% | |
To find the words in the book that are not in {\tt words.txt}, | |
we can use \verb"process_file" to build a histogram for | |
{\tt words.txt}, and then subtract: | |
\begin{verbatim} | |
words = process_file('words.txt') | |
diff = subtract(hist, words) | |
print "The words in the book that aren't in the word list are:" | |
for word in diff.keys(): | |
print word, | |
\end{verbatim} | |
% | |
Here are some of the results from {\em Emma}: | |
\begin{verbatim} | |
The words in the book that aren't in the word list are: | |
rencontre jane's blanche woodhouses disingenuousness | |
friend's venice apartment ... | |
\end{verbatim} | |
% | |
Some of these words are names and possessives. Others, like | |
``rencontre,'' are no longer in common use. But a few are common | |
words that should really be in the list! | |
\begin{exercise} | |
\index{set} | |
\index{type!set} | |
Python provides a data structure called {\tt set} that provides many | |
common set operations. Read the documentation at | |
\url{http://docs.python.org/2/library/stdtypes.html#types-set} and | |
write a program that uses set subtraction to find words in the book | |
that are not in the word list. Solution: | |
\url{http://thinkpython.com/code/analyze_book2.py}. | |
\end{exercise} | |
\section{Random words} | |
\label{randomwords} | |
\index{histogram!random choice} | |
To choose a random word from the histogram, the simplest algorithm | |
is to build a list with multiple copies of each word, according | |
to the observed frequency, and then choose from the list: | |
\begin{verbatim} | |
def random_word(h): | |
t = [] | |
for word, freq in h.items(): | |
t.extend([word] * freq) | |
return random.choice(t) | |
\end{verbatim} | |
% | |
The expression {\tt [word] * freq} creates a list with {\tt freq} | |
copies of the string {\tt word}. The {\tt extend} | |
method is similar to {\tt append} except that the argument is | |
a sequence. | |
\begin{exercise} | |
\label{randhist} | |
\index{algorithm} | |
This algorithm works, but it is not very efficient; each time you | |
choose a random word, it rebuilds the list, which is as big as | |
the original book. An obvious improvement is to build the list | |
once and then make multiple selections, but the list is still big. | |
An alternative is: | |
\begin{enumerate} | |
\item Use {\tt keys} to get a list of the words in the book. | |
\item Build a list that contains the cumulative sum of the word | |
frequencies (see Exercise~\ref{cumulative}). The last item | |
in this list is the total number of words in the book, $n$. | |
\item Choose a random number from 1 to $n$. Use a bisection search | |
(See Exercise~\ref{bisection}) to find the index where the random | |
number would be inserted in the cumulative sum. | |
\item Use the index to find the corresponding word in the word list. | |
\end{enumerate} | |
Write a program that uses this algorithm to choose a random | |
word from the book. Solution: \url{http://thinkpython.com/code/analyze_book3.py}. | |
\end{exercise} | |
\section{Markov analysis} | |
\label{markov} | |
\index{Markov analysis} | |
If you choose words from the book at random, you can get a | |
sense of the vocabulary, you probably won't get a sentence: | |
\begin{verbatim} | |
this the small regard harriet which knightley's it most things | |
\end{verbatim} | |
% | |
A series of random words seldom makes sense because there | |
is no relationship between successive words. For example, in | |
a real sentence you would expect an article like ``the'' to | |
be followed by an adjective or a noun, and probably not a verb | |
or adverb. | |
One way to measure these kinds of relationships is Markov | |
analysis, which | |
characterizes, for a given sequence of words, the probability of the | |
word that comes next. For example, the song {\em Eric, the Half a | |
Bee} begins: | |
\begin{quote} | |
Half a bee, philosophically, \\ | |
Must, ipso facto, half not be. \\ | |
But half the bee has got to be \\ | |
Vis a vis, its entity. D'you see? \\ | |
\\ | |
But can a bee be said to be \\ | |
Or not to be an entire bee \\ | |
When half the bee is not a bee \\ | |
Due to some ancient injury? \\ | |
\end{quote} | |
% | |
In this text, | |
the phrase ``half the'' is always followed by the word ``bee,'' | |
but the phrase ``the bee'' might be followed by either | |
``has'' or ``is''. | |
\index{prefix} | |
\index{suffix} | |
\index{mapping} | |
The result of Markov analysis is a mapping from each prefix | |
(like ``half the'' and ``the bee'') to all possible suffixes | |
(like ``has'' and ``is''). | |
\index{random text} | |
\index{text!random} | |
Given this mapping, you can generate a random text by | |
starting with any prefix and choosing at random from the | |
possible suffixes. Next, you can combine the end of the | |
prefix and the new suffix to form the next prefix, and repeat. | |
For example, if you start with the prefix ``Half a,'' then the | |
next word has to be ``bee,'' because the prefix only appears | |
once in the text. The next prefix is ``a bee,'' so the | |
next suffix might be ``philosophically,'' ``be'' or ``due.'' | |
In this example the length of the prefix is always two, but | |
you can do Markov analysis with any prefix length. The length | |
of the prefix is called the ``order'' of the analysis. | |
\begin{exercise} | |
Markov analysis: | |
\begin{enumerate} | |
\item Write a program to read a text from a file and perform Markov | |
analysis. The result should be a dictionary that maps from | |
prefixes to a collection of possible suffixes. The collection | |
might be a list, tuple, or dictionary; it is up to you to make | |
an appropriate choice. You can test your program with prefix | |
length two, but you should write the program in a way that makes | |
it easy to try other lengths. | |
\item Add a function to the previous program to generate random text | |
based on the Markov analysis. Here is an example from {\em Emma} | |
with prefix length 2: | |
\begin{quote} | |
He was very clever, be it sweetness or be angry, ashamed or only | |
amused, at such a stroke. She had never thought of Hannah till you | |
were never meant for me?" "I cannot make speeches, Emma:" he soon cut | |
it all himself. | |
\end{quote} | |
For this example, I left the punctuation attached to the words. | |
The result is almost syntactically correct, but not quite. | |
Semantically, it almost makes sense, but not quite. | |
What happens if you increase the prefix length? Does the random | |
text make more sense? | |
\index{mash-up} | |
\item Once your program is working, you might want to try a mash-up: | |
if you analyze text from two or more books, the random | |
text you generate will blend the vocabulary and phrases from | |
the sources in interesting ways. | |
\end{enumerate} | |
Credit: This case study is based on an example from Kernighan and | |
Pike, {\em The Practice of Programming}, Addison-Wesley, 1999. | |
\end{exercise} | |
You should attempt this exercise before you go on; then you can can | |
download my solution from \url{http://thinkpython.com/code/markov.py}. You | |
will also need \url{http://thinkpython.com/code/emma.txt}. | |
\section{Data structures} | |
\index{data structure} | |
Using Markov analysis to generate random text is fun, but there is | |
also a point to this exercise: data structure selection. In your | |
solution to the previous exercises, you had to choose: | |
\begin{itemize} | |
\item How to represent the prefixes. | |
\item How to represent the collection of possible suffixes. | |
\item How to represent the mapping from each prefix to | |
the collection of possible suffixes. | |
\end{itemize} | |
Ok, the last one is easy; the only mapping type we have | |
seen is a dictionary, so it is the natural choice. | |
For the prefixes, the most obvious options are string, | |
list of strings, or tuple of strings. For the suffixes, | |
one option is a list; another is a histogram (dictionary). | |
\index{implementation} | |
How should you choose? The first step is to think about | |
the operations you will need to implement for each data structure. | |
For the prefixes, we need to be able to remove words from | |
the beginning and add to the end. For example, if the current | |
prefix is ``Half a,'' and the next word is ``bee,'' you need | |
to be able to form the next prefix, ``a bee.'' | |
\index{tuple!as key in dictionary} | |
Your first choice might be a list, since it is easy to add | |
and remove elements, but we also need to be able to use the | |
prefixes as keys in a dictionary, so that rules out lists. | |
With tuples, you can't append or remove, but you can use | |
the addition operator to form a new tuple: | |
\begin{verbatim} | |
def shift(prefix, word): | |
return prefix[1:] + (word,) | |
\end{verbatim} | |
% | |
{\tt shift} takes a tuple of words, {\tt prefix}, and a string, | |
{\tt word}, and forms a new tuple that has all the words | |
in {\tt prefix} except the first, and {\tt word} added to | |
the end. | |
For the collection of suffixes, the operations we need to | |
perform include adding a new suffix (or increasing the frequency | |
of an existing one), and choosing a random suffix. | |
Adding a new suffix is equally easy for the list implementation | |
or the histogram. Choosing a random element from a list | |
is easy; choosing from a histogram is harder to do | |
efficiently (see Exercise~\ref{randhist}). | |
So far we have been talking mostly about ease of implementation, | |
but there are other factors to consider in choosing data structures. | |
One is run time. Sometimes there is a theoretical reason to expect | |
one data structure to be faster than other; for example, I mentioned | |
that the {\tt in} operator is faster for dictionaries than for lists, | |
at least when the number of elements is large. | |
But often you don't know ahead of time which implementation will | |
be faster. One option is to implement both of them and see which | |
is better. This approach is called {\bf benchmarking}. A practical | |
alternative is to choose the data structure that is | |
easiest to implement, and then see if it is fast enough for the | |
intended application. If so, there is no need to go on. If not, | |
there are tools, like the {\tt profile} module, that can identify | |
the places in a program that take the most time. | |
\index{benchmarking} | |
\index{profile module} | |
\index{module!profile} | |
The other factor to consider is storage space. For example, using a | |
histogram for the collection of suffixes might take less space because | |
you only have to store each word once, no matter how many times it | |
appears in the text. In some cases, saving space can also make your | |
program run faster, and in the extreme, your program might not run at | |
all if you run out of memory. But for many applications, space is a | |
secondary consideration after run time. | |
One final thought: in this discussion, I have implied that | |
we should use one data structure for both analysis and generation. But | |
since these are separate phases, it would also be possible to use one | |
structure for analysis and then convert to another structure for | |
generation. This would be a net win if the time saved during | |
generation exceeded the time spent in conversion. | |
\section{Debugging} | |
\index{debugging} | |
When you are debugging a program, and especially if you are | |
working on a hard bug, there are four things to try: | |
\begin{description} | |
\item[reading:] Examine your code, read it back to yourself, and | |
check that it says what you meant to say. | |
\item[running:] Experiment by making changes and running different | |
versions. Often if you display the right thing at the right place | |
in the program, the problem becomes obvious, but sometimes you have to | |
spend some time to build scaffolding. | |
\item[ruminating:] Take some time to think! What kind of error | |
is it: syntax, runtime, semantic? What information can you get from | |
the error messages, or from the output of the program? What kind of | |
error could cause the problem you're seeing? What did you change | |
last, before the problem appeared? | |
\item[retreating:] At some point, the best thing to do is back | |
off, undoing recent changes, until you get back to a program that | |
works and that you understand. Then you can start rebuilding. | |
\end{description} | |
Beginning programmers sometimes get stuck on one of these activities | |
and forget the others. Each activity comes with its own failure | |
mode. | |
\index{typographical error} | |
For example, reading your code might help if the problem is a | |
typographical error, but not if the problem is a conceptual | |
misunderstanding. If you don't understand what your program does, you | |
can read it 100 times and never see the error, because the error is in | |
your head. | |
\index{experimental debugging} | |
Running experiments can help, especially if you run small, simple | |
tests. But if you run experiments without thinking or reading your | |
code, you might fall into a pattern I call ``random walk programming,'' | |
which is the process of making random changes until the program | |
does the right thing. Needless to say, random walk programming | |
can take a long time. | |
\index{random walk programming} | |
\index{development plan!random walk programming} | |
You have to take time to think. Debugging is like an | |
experimental science. You should have at least one hypothesis about | |
what the problem is. If there are two or more possibilities, try to | |
think of a test that would eliminate one of them. | |
Taking a break helps with the thinking. So does talking. | |
If you explain the problem to someone else (or even yourself), you | |
will sometimes find the answer before you finish asking the question. | |
But even the best debugging techniques will fail if there are too many | |
errors, or if the code you are trying to fix is too big and | |
complicated. Sometimes the best option is to retreat, simplifying the | |
program until you get to something that works and that you | |
understand. | |
Beginning programmers are often reluctant to retreat because | |
they can't stand to delete a line of code (even if it's wrong). | |
If it makes you feel better, copy your program into another file | |
before you start stripping it down. Then you can paste the pieces | |
back in a little bit at a time. | |
Finding a hard bug requires reading, running, ruminating, and | |
sometimes retreating. If you get stuck on one of these activities, | |
try the others. | |
\section{Glossary} | |
\begin{description} | |
\item[deterministic:] Pertaining to a program that does the same | |
thing each time it runs, given the same inputs. | |
\index{deterministic} | |
\item[pseudorandom:] Pertaining to a sequence of numbers that appear | |
to be random, but are generated by a deterministic program. | |
\index{pseudorandom} | |
\item[default value:] The value given to an optional parameter if no | |
argument is provided. | |
\index{default value} | |
\item[override:] To replace a default value with an argument. | |
\index{override} | |
\item[benchmarking:] The process of choosing between data structures | |
by implementing alternatives and testing them on a sample of the | |
possible inputs. | |
\index{benchmarking} | |
\end{description} | |
\section{Exercises} | |
\begin{exercise} | |
\index{word frequency} | |
\index{frequency!word} | |
\index{Zipf's law} | |
The ``rank'' of a word is its position in a list of words | |
sorted by frequency: the most common word has rank 1, the | |
second most common has rank 2, etc. | |
Zipf's law describes a relationship between the ranks and frequencies | |
of words in natural languages | |
(\url{http://en.wikipedia.org/wiki/Zipf's_law}). Specifically, it | |
predicts that the frequency, $f$, of the word with rank $r$ is: | |
\[ f = c r^{-s} \] | |
% | |
where $s$ and $c$ are parameters that depend on the language and the | |
text. If you take the logarithm of both sides of this equation, you | |
get: | |
\index{logarithm} | |
\[ \log f = \log c - s \log r \] | |
% | |
So if you plot log $f$ versus log $r$, you should get | |
a straight line with slope $-s$ and intercept log $c$. | |
Write a program that reads a text from a file, counts | |
word frequencies, and prints one line | |
for each word, in descending order of frequency, with | |
log $f$ and log $r$. Use the graphing program of your | |
choice to plot the results and check whether they form | |
a straight line. Can you estimate the value of $s$? | |
Solution: \url{http://thinkpython.com/code/zipf.py}. To make the plots, you | |
might have to install matplotlib (see | |
\url{http://matplotlib.sourceforge.net/}). | |
\index{Matplotlib} | |
\end{exercise} | |
\chapter{Files} | |
\section{Persistence} | |
\index{file} | |
\index{type!file} | |
\index{persistence} | |
Most of the programs we have seen so far are transient in the | |
sense that they run for a short time and produce some output, | |
but when they end, their data disappears. If you run the program | |
again, it starts with a clean slate. | |
Other programs are {\bf persistent}: they run for a long time | |
(or all the time); they keep at least some of their data | |
in permanent storage (a hard drive, for example); and | |
if they shut down and restart, they pick up where they left off. | |
Examples of persistent programs are operating systems, which | |
run pretty much whenever a computer is on, and web servers, | |
which run all the time, waiting for requests to come in on | |
the network. | |
One of the simplest ways for programs to maintain their data | |
is by reading and writing text files. We have already seen | |
programs that read text files; in this chapter we will see programs | |
that write them. | |
An alternative is to store the state of the program in a database. | |
In this chapter I will present a simple database and a module, | |
{\tt pickle}, that makes it easy to store program data. | |
\index{pickle module} | |
\index{module!pickle} | |
\section{Reading and writing} | |
\index{file!reading and writing} | |
A text file is a sequence of characters stored on a permanent | |
medium like a hard drive, flash memory, or CD-ROM. We saw how | |
to open and read a file in Section~\ref{wordlist}. | |
\index{open function} | |
\index{function!open} | |
To write a file, you have to open it with mode \verb"'w'" as a second | |
parameter: | |
\begin{verbatim} | |
>>> fout = open('output.txt', 'w') | |
>>> print fout | |
<open file 'output.txt', mode 'w' at 0xb7eb2410> | |
\end{verbatim} | |
% | |
If the file already exists, opening it in write mode clears out | |
the old data and starts fresh, so be careful! | |
If the file doesn't exist, a new one is created. | |
The {\tt write} method puts data into the file. | |
\begin{verbatim} | |
>>> line1 = "This here's the wattle,\n" | |
>>> fout.write(line1) | |
\end{verbatim} | |
% | |
Again, the file object keeps track of where it is, so if | |
you call {\tt write} again, it adds the new data to the end. | |
\begin{verbatim} | |
>>> line2 = "the emblem of our land.\n" | |
>>> fout.write(line2) | |
\end{verbatim} | |
% | |
When you are done writing, you have to close the file. | |
\begin{verbatim} | |
>>> fout.close() | |
\end{verbatim} | |
% | |
\index{close method} | |
\index{method!close} | |
\section{Format operator} | |
\index{format operator} | |
\index{operator!format} | |
The argument of {\tt write} has to be a string, so if we want | |
to put other values in a file, we have to convert them to | |
strings. The easiest way to do that is with {\tt str}: | |
\begin{verbatim} | |
>>> x = 52 | |
>>> fout.write(str(x)) | |
\end{verbatim} | |
% | |
An alternative is to use the {\bf format operator}, {\tt \%}. When | |
applied to integers, {\tt \%} is the modulus operator. But | |
when the first operand is a string, {\tt \%} is the format operator. | |
\index{format string} | |
The first operand is the {\bf format string}, which contains | |
one or more {\bf format sequences}, which | |
specify how | |
the second operand is formatted. The result is a string. | |
\index{format sequence} | |
For example, the format sequence \verb"'%d'" means that | |
the second operand should be formatted as an | |
integer ({\tt d} stands for ``decimal''): | |
\begin{verbatim} | |
>>> camels = 42 | |
>>> '%d' % camels | |
'42' | |
\end{verbatim} | |
% | |
The result is the string \verb"'42'", which is not to be confused | |
with the integer value {\tt 42}. | |
A format sequence can appear anywhere in the string, | |
so you can embed a value in a sentence: | |
\begin{verbatim} | |
>>> camels = 42 | |
>>> 'I have spotted %d camels.' % camels | |
'I have spotted 42 camels.' | |
\end{verbatim} | |
% | |
If there is more than one format sequence in the string, | |
the second argument has to be a tuple. Each format sequence is | |
matched with an element of the tuple, in order. | |
The following example uses \verb"'%d'" to format an integer, | |
\verb"'%g'" to format | |
a floating-point number (don't ask why), and \verb"'%s'" to format | |
a string: | |
\begin{verbatim} | |
>>> 'In %d years I have spotted %g %s.' % (3, 0.1, 'camels') | |
'In 3 years I have spotted 0.1 camels.' | |
\end{verbatim} | |
% | |
The number of elements in the tuple has to match the number | |
of format sequences in the string. Also, the types of the | |
elements have to match the format sequences: | |
\index{exception!TypeError} | |
\index{TypeError} | |
\begin{verbatim} | |
>>> '%d %d %d' % (1, 2) | |
TypeError: not enough arguments for format string | |
>>> '%d' % 'dollars' | |
TypeError: illegal argument type for built-in operation | |
\end{verbatim} | |
% | |
In the first example, there aren't enough elements; in the | |
second, the element is the wrong type. | |
The format operator is powerful, but it can be difficult to use. You | |
can read more about it at | |
\url{http://docs.python.org/2/library/stdtypes.html#string-formatting}. | |
% You can specify the number of digits as part of the format sequence. | |
% For example, the sequence \verb"'%8.2f'" | |
% formats a floating-point number to be 8 characters long, with | |
% 2 digits after the decimal point: | |
% % \begin{verbatim} | |
% >>> '%8.2f' % 3.14159 | |
% ' 3.14' | |
% \end{verbatim} | |
% \afterverb | |
% % | |
% The result takes up eight spaces with two | |
% digits after the decimal point. | |
\section{Filenames and paths} | |
\label{paths} | |
\index{filename} | |
\index{path} | |
\index{directory} | |
\index{folder} | |
Files are organized into {\bf directories} (also called ``folders''). | |
Every running program has a ``current directory,'' which is the | |
default directory for most operations. | |
For example, when you open a file for reading, Python looks for it in the | |
current directory. | |
\index{os module} | |
\index{module!os} | |
The {\tt os} module provides functions for working with files and | |
directories (``os'' stands for ``operating system''). {\tt os.getcwd} | |
returns the name of the current directory: | |
\index{getcwd function} | |
\index{function!getcwd} | |
\begin{verbatim} | |
>>> import os | |
>>> cwd = os.getcwd() | |
>>> print cwd | |
/home/dinsdale | |
\end{verbatim} | |
% | |
{\tt cwd} stands for ``current working directory.'' The result in | |
this example is {\tt /home/dinsdale}, which is the home directory of a | |
user named {\tt dinsdale}. | |
\index{working directory} | |
\index{directory!working} | |
A string like {\tt cwd} that identifies a file is called a {\bf path}. | |
A {\bf relative path} starts from the current directory; | |
an {\bf absolute path} starts from the topmost directory in the | |
file system. | |
\index{relative path} | |
\index{path!relative} | |
\index{absolute path} | |
\index{path!absolute} | |
The paths we have seen so far are simple filenames, so they are | |
relative to the current directory. To find the absolute path to | |
a file, you can use {\tt os.path.abspath}: | |
\begin{verbatim} | |
>>> os.path.abspath('memo.txt') | |
'/home/dinsdale/memo.txt' | |
\end{verbatim} | |
% | |
{\tt os.path.exists} checks | |
whether a file or directory exists: | |
\index{exists function} | |
\index{function!exists} | |
\begin{verbatim} | |
>>> os.path.exists('memo.txt') | |
True | |
\end{verbatim} | |
% | |
If it exists, {\tt os.path.isdir} checks whether it's a directory: | |
\begin{verbatim} | |
>>> os.path.isdir('memo.txt') | |
False | |
>>> os.path.isdir('music') | |
True | |
\end{verbatim} | |
% | |
Similarly, {\tt os.path.isfile} checks whether it's a file. | |
{\tt os.listdir} returns a list of the files (and other directories) | |
in the given directory: | |
\begin{verbatim} | |
>>> os.listdir(cwd) | |
['music', 'photos', 'memo.txt'] | |
\end{verbatim} | |
% | |
To demonstrate these functions, the following example | |
``walks'' through a directory, prints | |
the names of all the files, and calls itself recursively on | |
all the directories. | |
\index{walk, directory} | |
\index{directory!walk} | |
\begin{verbatim} | |
def walk(dirname): | |
for name in os.listdir(dirname): | |
path = os.path.join(dirname, name) | |
if os.path.isfile(path): | |
print path | |
else: | |
walk(path) | |
\end{verbatim} | |
% | |
{\tt os.path.join} takes a directory and a file name and joins | |
them into a complete path. | |
\begin{exercise} | |
The {\tt os} module provides a function called {\tt walk} | |
that is similar to this one but more versatile. Read | |
the documentation and use it to print the names of the | |
files in a given directory and its subdirectories. | |
Solution: \url{http://thinkpython.com/code/walk.py}. | |
\end{exercise} | |
\section{Catching exceptions} | |
\label{catch} | |
A lot of things can go wrong when you try to read and write | |
files. If you try to open a file that doesn't exist, you get an | |
{\tt IOError}: | |
\index{open function} | |
\index{function!open} | |
\index{exception!IOError} | |
\index{IOError} | |
\begin{verbatim} | |
>>> fin = open('bad_file') | |
IOError: [Errno 2] No such file or directory: 'bad_file' | |
\end{verbatim} | |
% | |
If you don't have permission to access a file: | |
\index{file!permission} | |
\index{permission, file} | |
\begin{verbatim} | |
>>> fout = open('/etc/passwd', 'w') | |
IOError: [Errno 13] Permission denied: '/etc/passwd' | |
\end{verbatim} | |
% | |
And if you try to open a directory for reading, you get | |
\begin{verbatim} | |
>>> fin = open('/home') | |
IOError: [Errno 21] Is a directory | |
\end{verbatim} | |
% | |
To avoid these errors, you could use functions like {\tt os.path.exists} | |
and {\tt os.path.isfile}, but it would take a lot of time and code | |
to check all the possibilities (if ``{\tt Errno 21}'' is any | |
indication, there are at least 21 things that can go wrong). | |
\index{exception, catching} | |
\index{try statement} | |
\index{statement!try} | |
It is better to go ahead and try---and deal with problems if they | |
happen---which is exactly what the {\tt try} statement does. The | |
syntax is similar to an {\tt if} statement: | |
\begin{verbatim} | |
try: | |
fin = open('bad_file') | |
for line in fin: | |
print line | |
fin.close() | |
except: | |
print 'Something went wrong.' | |
\end{verbatim} | |
% | |
Python starts by executing the {\tt try} clause. If all goes | |
well, it skips the {\tt except} clause and proceeds. If an | |
exception occurs, it jumps out of the {\tt try} clause and | |
executes the {\tt except} clause. | |
Handling an exception with a {\tt try} statement is called {\bf | |
catching} an exception. In this example, the {\tt except} clause | |
prints an error message that is not very helpful. In general, | |
catching an exception gives you a chance to fix the problem, or try | |
again, or at least end the program gracefully. | |
\begin{exercise} | |
Write a function called {\tt sed} that takes as arguments a pattern string, | |
a replacement string, and two filenames; it should read the first file | |
and write the contents into the second file (creating it if | |
necessary). If the pattern string appears anywhere in the file, it | |
should be replaced with the replacement string. | |
If an error occurs while opening, reading, writing or closing files, | |
your program should catch the exception, print an error message, and | |
exit. Solution: \url{http://thinkpython.com/code/sed.py}. | |
\end{exercise} | |
\section{Databases} | |
\index{database} | |
A {\bf database} is a file that is organized for storing data. | |
Most databases are organized like a dictionary in the sense | |
that they map from keys to values. The biggest difference | |
is that the database is on disk (or other permanent storage), | |
so it persists after the program ends. | |
\index{anydbm module} | |
\index{module!anydbm} | |
The module {\tt anydbm} provides an interface for creating | |
and updating database files. As an example, I'll create a database | |
that contains captions for image files. | |
\index{open function} | |
\index{function!open} | |
Opening a database is similar to opening other files: | |
\begin{verbatim} | |
>>> import anydbm | |
>>> db = anydbm.open('captions.db', 'c') | |
\end{verbatim} | |
% | |
The mode \verb"'c'" means that the database should be created if | |
it doesn't already exist. The result is a database object | |
that can be used (for most operations) like a dictionary. | |
If you create a new item, {\tt anydbm} updates the database file. | |
\index{update!database} | |
\begin{verbatim} | |
>>> db['cleese.png'] = 'Photo of John Cleese.' | |
\end{verbatim} | |
% | |
When you access one of the items, {\tt anydbm} reads the file: | |
\begin{verbatim} | |
>>> print db['cleese.png'] | |
Photo of John Cleese. | |
\end{verbatim} | |
% | |
If you make another assignment to an existing key, {\tt anydbm} replaces | |
the old value: | |
\begin{verbatim} | |
>>> db['cleese.png'] = 'Photo of John Cleese doing a silly walk.' | |
>>> print db['cleese.png'] | |
Photo of John Cleese doing a silly walk. | |
\end{verbatim} | |
% | |
Some dictionary methods, like {\tt keys}, also | |
work with database objects, so you can iterate through the database | |
like this: | |
\index{dictionary methods!anydbm module} | |
\begin{verbatim} | |
for key in db.keys(): | |
print key | |
\end{verbatim} | |
% | |
As with other files, you should close the database when you are | |
done: | |
\begin{verbatim} | |
>>> db.close() | |
\end{verbatim} | |
% | |
\index{close method} | |
\index{method!close} | |
\section{Pickling} | |
\index{pickling} | |
A limitation of {\tt anydbm} is that the keys and values have | |
to be strings. If you try to use any other type, you get an | |
error. | |
\index{pickle module} | |
\index{module!pickle} | |
The {\tt pickle} module can help. It translates | |
almost any type of object into a string suitable for storage in a | |
database, and then translates strings back into objects. | |
{\tt pickle.dumps} takes an object as a parameter and returns | |
a string representation ({\tt dumps} is short for ``dump string''): | |
\begin{verbatim} | |
>>> import pickle | |
>>> t = [1, 2, 3] | |
>>> pickle.dumps(t) | |
'(lp0\nI1\naI2\naI3\na.' | |
\end{verbatim} | |
% | |
The format isn't obvious to human readers; it is meant to be | |
easy for {\tt pickle} to interpret. {\tt pickle.loads} | |
(``load string'') reconstitutes the object: | |
\begin{verbatim} | |
>>> t1 = [1, 2, 3] | |
>>> s = pickle.dumps(t1) | |
>>> t2 = pickle.loads(s) | |
>>> print t2 | |
[1, 2, 3] | |
\end{verbatim} | |
% | |
Although the new object has the same value as the old, it is | |
not (in general) the same object: | |
\begin{verbatim} | |
>>> t1 == t2 | |
True | |
>>> t1 is t2 | |
False | |
\end{verbatim} | |
% | |
In other words, pickling and then unpickling has the same effect | |
as copying the object. | |
You can use {\tt pickle} to store non-strings in a database. | |
In fact, this combination is so common that it has been | |
encapsulated in a module called {\tt shelve}. | |
\index{shelve module} | |
\index{module!shelve} | |
\begin{exercise} | |
\index{anagram set} | |
\index{set!anagram} | |
If you download my solution to Exercise~\ref{anagrams} from | |
\url{http://thinkpython.com/code/anagram_sets.py}, you'll see that it creates | |
a dictionary that maps from a sorted string of letters to the list of | |
words that can be spelled with those letters. For example, {\tt | |
'opst'} maps to the list {\tt ['opts', 'post', 'pots', 'spot', | |
'stop', 'tops']}. | |
Write a module that imports \verb"anagram_sets" and provides | |
two new functions: \verb"store_anagrams" should store the | |
anagram dictionary in a ``shelf;'' \verb"read_anagrams" should | |
look up a word and return a list of its anagrams. | |
Solution: \url{http://thinkpython.com/code/anagram_db.py} | |
\end{exercise} | |
\section{Pipes} | |
\index{shell} | |
\index{pipe} | |
Most operating systems provide a command-line interface, | |
also known as a {\bf shell}. Shells usually provide commands | |
to navigate the file system and launch applications. For | |
example, in Unix you can change directories with {\tt cd}, | |
display the contents of a directory with {\tt ls}, and launch | |
a web browser by typing (for example) {\tt firefox}. | |
\index{ls (Unix command)} | |
\index{Unix command!ls} | |
Any program that you can launch from the shell can also be | |
launched from Python using a {\bf pipe}. A pipe is an object | |
that represents a running program. | |
For example, the Unix command {\tt ls -l} normally displays the | |
contents of the current directory (in long format). You can | |
launch {\tt ls} with {\tt os.popen}\footnote{{\tt popen} is deprecated | |
now, which means we are supposed to stop using it and start using | |
the {\tt subprocess} module. But for simple cases, I find | |
{\tt subprocess} more complicated than necessary. So I am going | |
to keep using {\tt popen} until they take it away.}: | |
\index{popen function} | |
\index{function!popen} | |
\begin{verbatim} | |
>>> cmd = 'ls -l' | |
>>> fp = os.popen(cmd) | |
\end{verbatim} | |
% | |
The argument is a string that contains a shell command. The | |
return value is an object that behaves just like an open | |
file. You can read the output from the {\tt ls} process one | |
line at a time with {\tt readline} or get the whole thing at | |
once with {\tt read}: | |
\index{readline method} | |
\index{method!readline} | |
\index{read method} | |
\index{method!read} | |
\begin{verbatim} | |
>>> res = fp.read() | |
\end{verbatim} | |
% | |
When you are done, you close the pipe like a file: | |
\index{close method} | |
\index{method!close} | |
\begin{verbatim} | |
>>> stat = fp.close() | |
>>> print stat | |
None | |
\end{verbatim} | |
% | |
The return value is the final status of the {\tt ls} process; | |
{\tt None} means that it ended normally (with no errors). | |
For example, most Unix systems provide a command called {\tt md5sum} | |
that reads the contents of a file and computes a ``checksum.'' | |
You can read about MD5 at \url{http://en.wikipedia.org/wiki/Md5}. This | |
command provides an efficient way to check whether two files | |
have the same contents. The probability that different contents | |
yield the same checksum is very small (that is, unlikely to happen | |
before the universe collapses). | |
\index{md5} | |
\index{checksum} | |
You can use a pipe to run {\tt md5sum} from Python and get the result: | |
\begin{verbatim} | |
>>> filename = 'book.tex' | |
>>> cmd = 'md5sum ' + filename | |
>>> fp = os.popen(cmd) | |
>>> res = fp.read() | |
>>> stat = fp.close() | |
>>> print res | |
1e0033f0ed0656636de0d75144ba32e0 book.tex | |
>>> print stat | |
None | |
\end{verbatim} | |
\begin{exercise} | |
\label{checksum} | |
\index{MP3} | |
In a large collection of MP3 files, there may be more than one | |
copy of the same song, stored in different directories or with | |
different file names. The goal of this exercise is to search for | |
duplicates. | |
\begin{enumerate} | |
\item Write a program that searches a directory and all of its | |
subdirectories, recursively, and returns a list of complete paths | |
for all files with a given suffix (like {\tt .mp3}). | |
Hint: {\tt os.path} provides several useful functions for | |
manipulating file and path names. | |
\index{duplicate} | |
\index{MD5 algorithm} | |
\index{algorithm!MD5} | |
\index{checksum} | |
\item To recognize duplicates, you can use {\tt md5sum} | |
to compute a ``checksum'' for each files. If two files have | |
the same checksum, they probably have the same contents. | |
\index{md5sum} | |
\item To double-check, you can use the Unix command {\tt diff}. | |
\index{diff} | |
\end{enumerate} | |
Solution: \url{http://thinkpython.com/code/find_duplicates.py}. | |
\end{exercise} | |
\section{Writing modules} | |
\label{modules} | |
\index{module, writing} | |
\index{word count} | |
Any file that contains Python code can be imported as a module. | |
For example, suppose you have a file named {\tt wc.py} with the following | |
code: | |
\begin{verbatim} | |
def linecount(filename): | |
count = 0 | |
for line in open(filename): | |
count += 1 | |
return count | |
print linecount('wc.py') | |
\end{verbatim} | |
% | |
If you run this program, it reads itself and prints the number | |
of lines in the file, which is 7. | |
You can also import it like this: | |
\begin{verbatim} | |
>>> import wc | |
7 | |
\end{verbatim} | |
% | |
Now you have a module object {\tt wc}: | |
\index{module object} | |
\index{object!module} | |
\begin{verbatim} | |
>>> print wc | |
<module 'wc' from 'wc.py'> | |
\end{verbatim} | |
% | |
That provides a function called \verb"linecount": | |
\begin{verbatim} | |
>>> wc.linecount('wc.py') | |
7 | |
\end{verbatim} | |
% | |
So that's how you write modules in Python. | |
The only problem with this example is that when you import | |
the module it executes the test code at the bottom. Normally | |
when you import a module, it defines new functions but it | |
doesn't execute them. | |
\index{import statement} | |
\index{statement!import} | |
Programs that will be imported as modules often | |
use the following idiom: | |
\begin{verbatim} | |
if __name__ == '__main__': | |
print linecount('wc.py') | |
\end{verbatim} | |
% | |
\verb"__name__" is a built-in variable that is set when the | |
program starts. If the program is running as a script, | |
\verb"__name__" has the value \verb"__main__"; in that | |
case, the test code is executed. Otherwise, | |
if the module is being imported, the test code is skipped. | |
\begin{exercise} | |
Type this example into a file named {\tt wc.py} and run | |
it as a script. Then run the Python interpreter and | |
{\tt import wc}. What is the value of \verb"__name__" | |
when the module is being imported? | |
Warning: If you import a module that has already been imported, | |
Python does nothing. It does not re-read the file, even if it has | |
changed. | |
\index{module!reload} | |
\index{reload function} | |
\index{function!reload} | |
If you want to reload a module, you can use the built-in function | |
{\tt reload}, but it can be tricky, so the safest thing to do is | |
restart the interpreter and then import the module again. | |
\end{exercise} | |
\section{Debugging} | |
\index{debugging} | |
\index{whitespace} | |
When you are reading and writing files, you might run into problems | |
with whitespace. These errors can be hard to debug because spaces, | |
tabs and newlines are normally invisible: | |
\begin{verbatim} | |
>>> s = '1 2\t 3\n 4' | |
>>> print s | |
1 2 3 | |
4 | |
\end{verbatim} | |
\index{repr function} | |
\index{function!repr} | |
\index{string representation} | |
The built-in function {\tt repr} can help. It takes any object as an | |
argument and returns a string representation of the object. For | |
strings, it represents whitespace | |
characters with backslash sequences: | |
\begin{verbatim} | |
>>> print repr(s) | |
'1 2\t 3\n 4' | |
\end{verbatim} | |
This can be helpful for debugging. | |
One other problem you might run into is that different systems | |
use different characters to indicate the end of a line. Some | |
systems use a newline, represented \verb"\n". Others use | |
a return character, represented \verb"\r". Some use both. | |
If you move files between different systems, these inconsistencies | |
might cause problems. | |
\index{end of line character} | |
For most systems, there are applications to convert from one | |
format to another. You can find them (and read more about this | |
issue) at \url{http://en.wikipedia.org/wiki/Newline}. Or, of course, you | |
could write one yourself. | |
\section{Glossary} | |
\begin{description} | |
\item[persistent:] Pertaining to a program that runs indefinitely | |
and keeps at least some of its data in permanent storage. | |
\index{persistence} | |
\item[format operator:] An operator, {\tt \%}, that takes a format | |
string and a tuple and generates a string that includes | |
the elements of the tuple formatted as specified by the format string. | |
\index{format operator} | |
\index{operator!format} | |
\item[format string:] A string, used with the format operator, that | |
contains format sequences. | |
\index{format string} | |
\item[format sequence:] A sequence of characters in a format string, | |
like {\tt \%d}, that specifies how a value should be formatted. | |
\index{format sequence} | |
\item[text file:] A sequence of characters stored in permanent | |
storage like a hard drive. | |
\index{text file} | |
\item[directory:] A named collection of files, also called a folder. | |
\index{directory} | |
\item[path:] A string that identifies a file. | |
\index{path} | |
\item[relative path:] A path that starts from the current directory. | |
\index{relative path} | |
\item[absolute path:] A path that starts from the topmost directory | |
in the file system. | |
\index{absolute path} | |
\item[catch:] To prevent an exception from terminating | |
a program using the {\tt try} | |
and {\tt except} statements. | |
\index{catch} | |
\item[database:] A file whose contents are organized like a dictionary | |
with keys that correspond to values. | |
\index{database} | |
\end{description} | |
\section{Exercises} | |
\begin{exercise} | |
\label{urllib} | |
\index{urllib module} | |
\index{module!urllib} | |
\index{URL} | |
The {\tt urllib} module provides methods for manipulating URLs | |
and downloading information from the web. The following example | |
downloads and prints a secret message from {\tt thinkpython.com}: | |
\begin{verbatim} | |
import urllib | |
conn = urllib.urlopen('http://thinkpython.com/secret.html') | |
for line in conn: | |
print line.strip() | |
\end{verbatim} | |
Run this code and follow the instructions you see there. | |
Solution: \url{http://thinkpython.com/code/zip_code.py}. | |
\index{secret exercise} | |
\index{exercise, secret} | |
\end{exercise} | |
%\begin{exercise} | |
%\index{Internet Movie Database (IMDb)} | |
%\index{IMDb (Internet Movie Database)} | |
%\index{database} | |
%The Internet Movie Database (IMDb) is an online collection of | |
%information about movies. Their database is available | |
%in plain text format, so it is reasonably easy to read from | |
%Python. For this exercise, the files you need | |
%are {\tt actors.list.gz} and {\tt actresses.list.gz}; you | |
%can download them from \url{http://www.imdb.com/interfaces#plain}. | |
%\index{plain text} | |
%\index{text!plain} | |
%\index{parse} | |
%I have written a program that parses these files and | |
%splits them into actor names, movie titles, etc. You can | |
%download it from \url{http://thinkpython.com/code/imdb.py}. | |
%If you run {\tt imdb.py} as a script, it reads {\tt actors.list.gz} | |
%and prints one actor-movie pair per line. Or, if you {\tt import | |
%imdb} you can use the function \verb"process_file" to, well, | |
%process the file. The arguments are a filename, a function | |
%object and an optional number of lines to process. Here is | |
%an example: | |
% | |
%\begin{verbatim} | |
%import imdb | |
%def print_info(actor, date, title, role): | |
% print actor, date, title, role | |
%imdb.process_file('actors.list.gz', print_info) | |
%\end{verbatim} | |
%When you call \verb"process_file", it opens {\tt filename}, reads the | |
%contents, and calls \verb"print_info" once for each line in the file. | |
%\verb"print_info" takes an actor, date, movie title and role as | |
%arguments and prints them. | |
%\begin{enumerate} | |
%\item Write a program that reads {\tt actors.list.gz} and {\tt | |
% actresses.list.gz} and uses {\tt shelve} to build a database | |
%that maps from each actor to a list of his or her films. | |
%\index{shelve module} | |
%\index{module!shelve} | |
%\item Two actors are ``costars'' if they have been in at least one | |
% movie together. Process the database you built in the previous step | |
% and build a second database that maps from each actor to a list of | |
% his or her costars. | |
%\index{Bacon, Kevin} | |
%\index{Kevin Bacon Game} | |
%\item Write a program that can play the ``Six Degrees of Kevin | |
% Bacon,'' which you can read about at | |
% \url{http://en.wikipedia.org/wiki/Six_Degrees_of_Kevin_Bacon}. This | |
%problem is challenging because it requires you to find the shortest | |
%path in a graph. You can read about shortest path algorithms | |
%at \url{http://en.wikipedia.org/wiki/Shortest_path_problem}. | |
%\end{enumerate} | |
%\end{exercise} | |
\chapter{Classes and objects} | |
Code examples from this chapter are available from | |
\url{http://thinkpython.com/code/Point1.py}; solutions | |
to the exercises are available from | |
\url{http://thinkpython.com/code/Point1_soln.py}. | |
\section{User-defined types} | |
\label{point} | |
\index{user-defined type} | |
\index{type!user-defined} | |
We have used many of Python's built-in types; now we are going | |
to define a new type. As an example, we will create a type | |
called {\tt Point} that represents a point in two-dimensional | |
space. | |
\index{point, mathematical} | |
In mathematical notation, points are often written in | |
parentheses with a comma separating the coordinates. For example, | |
$(0,0)$ represents the origin, and $(x,y)$ represents the | |
point $x$ units to the right and $y$ units up from the origin. | |
There are several ways we might represent points in Python: | |
\begin{itemize} | |
\item We could store the coordinates separately in two | |
variables, {\tt x} and {\tt y}. | |
\item We could store the coordinates as elements in a list | |
or tuple. | |
\item We could create a new type to represent points as | |
objects. | |
\end{itemize} | |
\index{representation} | |
Creating a new type | |
is (a little) more complicated than the other options, but | |
it has advantages that will be apparent soon. | |
A user-defined type is also called a {\bf class}. | |
A class definition looks like this: | |
\index{class} | |
\index{object} | |
\index{class definition} | |
\index{definition!class} | |
\begin{verbatim} | |
class Point(object): | |
"""Represents a point in 2-D space.""" | |
\end{verbatim} | |
% | |
This header indicates that the new class is a {\tt Point}, | |
which is a kind of {\tt object}, which is a built-in | |
type. | |
\index{Point class} | |
\index{class!Point} | |
The body is a docstring that explains what the class is for. | |
You can define variables and functions inside a class definition, | |
but we will get back to that later. | |
\index{docstring} | |
Defining a class named {\tt Point} creates a class object. | |
\begin{verbatim} | |
>>> print Point | |
<class '__main__.Point'> | |
\end{verbatim} | |
% | |
Because {\tt Point} is defined at the top level, its ``full | |
name'' is \verb"__main__.Point". | |
\index{object!class} | |
\index{class object} | |
The class object is like a factory for creating objects. To create a | |
Point, you call {\tt Point} as if it were a function. | |
\begin{verbatim} | |
>>> blank = Point() | |
>>> print blank | |
<__main__.Point instance at 0xb7e9d3ac> | |
\end{verbatim} | |
% | |
The return value is a reference to a Point object, which we | |
assign to {\tt blank}. | |
Creating a new object is called | |
{\bf instantiation}, and the object is an {\bf instance} of | |
the class. | |
\index{instance} | |
\index{instantiation} | |
When you print an instance, Python tells you what class it | |
belongs to and where it is stored in memory (the prefix | |
{\tt 0x} means that the following number is in hexadecimal). | |
\index{hexadecimal} | |
\section{Attributes} | |
\label{attributes} | |
\index{instance attribute} | |
\index{attribute!instance} | |
\index{dot notation} | |
You can assign values to an instance using dot notation: | |
\begin{verbatim} | |
>>> blank.x = 3.0 | |
>>> blank.y = 4.0 | |
\end{verbatim} | |
% | |
This syntax is similar to the syntax for selecting a variable from a | |
module, such as {\tt math.pi} or {\tt string.whitespace}. In this case, | |
though, we are assigning values to named elements of an object. | |
These elements are called {\bf attributes}. | |
As a noun, ``AT-trib-ute'' is pronounced with emphasis on the first | |
syllable, as opposed to ``a-TRIB-ute,'' which is a verb. | |
The following diagram shows the result of these assignments. | |
A state diagram that shows an object and its attributes is | |
called an {\bf object diagram}; see Figure~\ref{fig.point}. | |
\index{state diagram} | |
\index{diagram!state} | |
\index{object diagram} | |
\index{diagram!object} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/point.pdf}} | |
\caption{Object diagram.} | |
\label{fig.point} | |
\end{figure} | |
The variable {\tt blank} refers to a Point object, which | |
contains two attributes. Each attribute refers to a | |
floating-point number. | |
You can read the value of an attribute using the same syntax: | |
\begin{verbatim} | |
>>> print blank.y | |
4.0 | |
>>> x = blank.x | |
>>> print x | |
3.0 | |
\end{verbatim} | |
% | |
The expression {\tt blank.x} means, ``Go to the object {\tt blank} | |
refers to and get the value of {\tt x}.'' In this case, we assign that | |
value to a variable named {\tt x}. There is no conflict between | |
the variable {\tt x} and the attribute {\tt x}. | |
You can use dot notation as part of any expression. For example: | |
\begin{verbatim} | |
>>> print '(%g, %g)' % (blank.x, blank.y) | |
(3.0, 4.0) | |
>>> distance = math.sqrt(blank.x**2 + blank.y**2) | |
>>> print distance | |
5.0 | |
\end{verbatim} | |
% | |
You can pass an instance as an argument in the usual way. | |
For example: | |
\index{instance!as argument} | |
\begin{verbatim} | |
def print_point(p): | |
print '(%g, %g)' % (p.x, p.y) | |
\end{verbatim} | |
% | |
\verb"print_point" takes a point as an argument and displays it in | |
mathematical notation. To invoke it, you can pass {\tt blank} as | |
an argument: | |
\begin{verbatim} | |
>>> print_point(blank) | |
(3.0, 4.0) | |
\end{verbatim} | |
% | |
Inside the function, {\tt p} is an alias for {\tt blank}, so if | |
the function modifies {\tt p}, {\tt blank} changes. | |
\index{aliasing} | |
\begin{exercise} | |
Write a function called \verb"distance_between_points" that takes two | |
Points as arguments and returns the distance between them. | |
\end{exercise} | |
\section{Rectangles} | |
\label{rectangles} | |
Sometimes it is obvious what the attributes of an object should be, | |
but other times you have to make decisions. For example, imagine you | |
are designing a class to represent rectangles. What attributes would | |
you use to specify the location and size of a rectangle? You can | |
ignore angle; to keep things simple, assume that the rectangle is | |
either vertical or horizontal. | |
\index{representation} | |
There are at least two possibilities: | |
\begin{itemize} | |
\item You could specify one corner of the rectangle | |
(or the center), the width, and the height. | |
\item You could specify two opposing corners. | |
\end{itemize} | |
At this point it is hard to say whether either is better than | |
the other, so we'll implement the first one, just as an example. | |
\index{Rectangle class} | |
\index{class!Rectangle} | |
Here is the class definition: | |
\begin{verbatim} | |
class Rectangle(object): | |
"""Represents a rectangle. | |
attributes: width, height, corner. | |
""" | |
\end{verbatim} | |
% | |
The docstring lists the attributes: {\tt width} and | |
{\tt height} are numbers; {\tt corner} is a Point object that | |
specifies the lower-left corner. | |
To represent a rectangle, you have to instantiate a Rectangle | |
object and assign values to the attributes: | |
\begin{verbatim} | |
box = Rectangle() | |
box.width = 100.0 | |
box.height = 200.0 | |
box.corner = Point() | |
box.corner.x = 0.0 | |
box.corner.y = 0.0 | |
\end{verbatim} | |
% | |
The expression {\tt box.corner.x} means, | |
``Go to the object {\tt box} refers to and select the attribute named | |
{\tt corner}; then go to that object and select the attribute named | |
{\tt x}.'' | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/rectangle.pdf}} | |
\caption{Object diagram.} | |
\label{fig.rectangle} | |
\end{figure} | |
Figure~\ref{fig.rectangle} shows the state of this object. | |
\index{state diagram} | |
\index{diagram!state} | |
\index{object diagram} | |
\index{diagram!object} | |
An object that is an attribute of another object is {\bf embedded}. | |
\index{embedded object} | |
\index{object!embedded} | |
\section{Instances as return values} | |
\index{instance!as return value} | |
\index{return value} | |
Functions can return instances. For example, \verb"find_center" | |
takes a {\tt Rectangle} as an argument and returns a {\tt Point} | |
that contains the coordinates of the center of the {\tt Rectangle}: | |
\begin{verbatim} | |
def find_center(rect): | |
p = Point() | |
p.x = rect.corner.x + rect.width/2.0 | |
p.y = rect.corner.y + rect.height/2.0 | |
return p | |
\end{verbatim} | |
% | |
Here is an example that passes {\tt box} as an argument and assigns | |
the resulting Point to {\tt center}: | |
\begin{verbatim} | |
>>> center = find_center(box) | |
>>> print_point(center) | |
(50.0, 100.0) | |
\end{verbatim} | |
% | |
\section{Objects are mutable} | |
\index{object!mutable} | |
\index{mutability} | |
You can change the state of an object by making an assignment to one of | |
its attributes. For example, to change the size of a rectangle | |
without changing its position, you can modify the values of {\tt | |
width} and {\tt height}: | |
\begin{verbatim} | |
box.width = box.width + 50 | |
box.height = box.width + 100 | |
\end{verbatim} | |
% | |
You can also write functions that modify objects. For example, | |
\verb"grow_rectangle" takes a Rectangle object and two numbers, | |
{\tt dwidth} and {\tt dheight}, and adds the numbers to the | |
width and height of the rectangle: | |
\begin{verbatim} | |
def grow_rectangle(rect, dwidth, dheight): | |
rect.width += dwidth | |
rect.height += dheight | |
\end{verbatim} | |
% | |
Here is an example that demonstrates the effect: | |
\begin{verbatim} | |
>>> print box.width | |
100.0 | |
>>> print box.height | |
200.0 | |
>>> grow_rectangle(box, 50, 100) | |
>>> print box.width | |
150.0 | |
>>> print box.height | |
300.0 | |
\end{verbatim} | |
% | |
Inside the function, {\tt rect} is an | |
alias for {\tt box}, so if the function modifies {\tt rect}, | |
{\tt box} changes. | |
\begin{exercise} | |
Write a function named \verb"move_rectangle" that takes | |
a Rectangle and two numbers named {\tt dx} and {\tt dy}. It | |
should change the location of the rectangle by adding {\tt dx} | |
to the {\tt x} coordinate of {\tt corner} and adding {\tt dy} | |
to the {\tt y} coordinate of {\tt corner}. | |
\end{exercise} | |
\section{Copying} | |
\label{copying} | |
\index{aliasing} | |
Aliasing can make a program difficult to read because changes | |
in one place might have unexpected effects in another place. | |
It is hard to keep track of all the variables that might refer | |
to a given object. | |
\index{copying objects} | |
\index{object!copying} | |
\index{copy module} | |
\index{module!copy} | |
Copying an object is often an alternative to aliasing. | |
The {\tt copy} module contains a function called {\tt copy} that | |
can duplicate any object: | |
\begin{verbatim} | |
>>> p1 = Point() | |
>>> p1.x = 3.0 | |
>>> p1.y = 4.0 | |
>>> import copy | |
>>> p2 = copy.copy(p1) | |
\end{verbatim} | |
% | |
{\tt p1} and {\tt p2} contain the same data, but they are | |
not the same Point. | |
\begin{verbatim} | |
>>> print_point(p1) | |
(3.0, 4.0) | |
>>> print_point(p2) | |
(3.0, 4.0) | |
>>> p1 is p2 | |
False | |
>>> p1 == p2 | |
False | |
\end{verbatim} | |
% | |
The {\tt is} operator indicates that {\tt p1} and {\tt p2} are not the | |
same object, which is what we expected. But you might have expected | |
{\tt ==} to yield {\tt True} because these points contain the same | |
data. In that case, you will be disappointed to learn that for | |
instances, the default behavior of the {\tt ==} operator is the same | |
as the {\tt is} operator; it checks object identity, not object | |
equivalence. This behavior can be changed---we'll see how later. | |
\index{is operator} | |
\index{operator!is} | |
If you use {\tt copy.copy} to duplicate a Rectangle, you will find | |
that it copies the Rectangle object but not the embedded Point. | |
\index{embedded object!copying} | |
\begin{verbatim} | |
>>> box2 = copy.copy(box) | |
>>> box2 is box | |
False | |
>>> box2.corner is box.corner | |
True | |
\end{verbatim} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/rectangle2.pdf}} | |
\caption{Object diagram.} | |
\label{fig.rectangle2} | |
\end{figure} | |
Figure~\ref{fig.rectangle2} shows what the object diagram looks like. | |
\index{state diagram} | |
\index{diagram!state} | |
\index{object diagram} | |
\index{diagram!object} | |
This operation is called a {\bf shallow copy} because it copies the | |
object and any references it contains, but not the embedded objects. | |
\index{shallow copy} | |
\index{copy!shallow} | |
For most applications, this is not what you want. In this example, | |
invoking \verb"grow_rectangle" on one of the Rectangles would not | |
affect the other, but invoking \verb"move_rectangle" on either would | |
affect both! This behavior is confusing and error-prone. | |
\index{deep copy} | |
\index{copy!deep} | |
Fortunately, the {\tt copy} module contains a method named {\tt | |
deepcopy} that copies not only the object but also | |
the objects it refers to, and the objects {\em they} refer to, | |
and so on. | |
You will not be surprised to learn that this operation is | |
called a {\bf deep copy}. | |
\index{deepcopy function} | |
\index{function!deepcopy} | |
\begin{verbatim} | |
>>> box3 = copy.deepcopy(box) | |
>>> box3 is box | |
False | |
>>> box3.corner is box.corner | |
False | |
\end{verbatim} | |
% | |
{\tt box3} and {\tt box} are completely separate objects. | |
\begin{exercise} | |
Write a version of \verb"move_rectangle" that creates and | |
returns a new Rectangle instead of modifying the old one. | |
\end{exercise} | |
\section{Debugging} | |
\label{hasattr} | |
\index{debugging} | |
When you start working with objects, you are likely to encounter | |
some new exceptions. If you try to access an attribute | |
that doesn't exist, you get an {\tt AttributeError}: | |
\index{exception!AttributeError} | |
\index{AttributeError} | |
\begin{verbatim} | |
>>> p = Point() | |
>>> print p.z | |
AttributeError: Point instance has no attribute 'z' | |
\end{verbatim} | |
% | |
If you are not sure what type an object is, you can ask: | |
\index{type function} | |
\index{function!type} | |
\begin{verbatim} | |
>>> type(p) | |
<type '__main__.Point'> | |
\end{verbatim} | |
% | |
If you are not sure whether an object has a particular attribute, | |
you can use the built-in function {\tt hasattr}: | |
\index{hasattr function} | |
\index{function!hasattr} | |
\begin{verbatim} | |
>>> hasattr(p, 'x') | |
True | |
>>> hasattr(p, 'z') | |
False | |
\end{verbatim} | |
% | |
The first argument can be any object; the second argument is a {\em | |
string} that contains the name of the attribute. | |
\section{Glossary} | |
\begin{description} | |
\item[class:] A user-defined type. A class definition creates a new | |
class object. | |
\index{class} | |
\item[class object:] An object that contains information about a | |
user-defined type. The class object can be used to create instances | |
of the type. | |
\index{class object} | |
\index{object!class} | |
\item[instance:] An object that belongs to a class. | |
\index{instance} | |
\item[attribute:] One of the named values associated with an object. | |
\index{attribute!instance} | |
\index{instance attribute} | |
\item[embedded (object):] An object that is stored as an attribute | |
of another object. | |
\index{embedded object} | |
\index{object!embedded} | |
\item[shallow copy:] To copy the contents of an object, including | |
any references to embedded objects; | |
implemented by the {\tt copy} function in the {\tt copy} module. | |
\index{shallow copy} | |
\item[deep copy:] To copy the contents of an object as well as any | |
embedded objects, and any objects embedded in them, and so on; | |
implemented by the {\tt deepcopy} function in the {\tt copy} module. | |
\index{deep copy} | |
\item[object diagram:] A diagram that shows objects, their | |
attributes, and the values of the attributes. | |
\index{object diagram} | |
\index{diagram!object} | |
\end{description} | |
\section{Exercises} | |
\begin{exercise} | |
\label{canvas} | |
\index{Swampy} | |
\index{World module} | |
\index{module!World} | |
Swampy (see Chapter~\ref{turtlechap}) provides a module named {\tt | |
World}, which defines a user-defined type also called {\tt World}. | |
You can import it like this: | |
\begin{verbatim} | |
from swampy.World import World | |
\end{verbatim} | |
Or, depending on how you installed Swampy, like this: | |
\begin{verbatim} | |
from World import World | |
\end{verbatim} | |
The following code creates a World object and calls | |
the {\tt mainloop} method, which | |
waits for the user. | |
\begin{verbatim} | |
world = World() | |
world.mainloop() | |
\end{verbatim} | |
A window should appear with a title bar and an empty square. | |
We will use this window to draw Points, | |
Rectangles and other shapes. | |
Add the following lines before calling | |
\verb"mainloop" and run the program again. | |
\index{Canvas object} | |
\index{object!Canvas} | |
\begin{verbatim} | |
canvas = world.ca(width=500, height=500, background='white') | |
bbox = [[-150,-100], [150, 100]] | |
canvas.rectangle(bbox, outline='black', width=2, fill='green4') | |
\end{verbatim} | |
You should see a green rectangle with a black outline. | |
The first line creates a Canvas, which appears in the window | |
as a white square. The Canvas object provides methods like | |
{\tt rectangle} for drawing various shapes. | |
\index{bounding box} | |
{\tt bbox} is a list of lists that represents the ``bounding box'' | |
of the rectangle. The first pair of coordinates is the lower-left | |
corner of the rectangle; the second pair is the upper-right corner. | |
You can draw a circle like this: | |
\begin{verbatim} | |
canvas.circle([-25,0], 70, outline=None, fill='red') | |
\end{verbatim} | |
The first parameter is the coordinate pair for the center of the | |
circle; the second parameter is the radius. | |
If you add this line to the program, | |
the result should resemble the national flag of Bangladesh | |
(see \url{http://en.wikipedia.org/wiki/Gallery_of_sovereign-state_flags}). | |
\index{Bangladesh, national flag} | |
\begin{enumerate} | |
\item Write a function called \verb"draw_rectangle" that takes a | |
Canvas and a Rectangle as arguments and draws a | |
representation of the Rectangle on the Canvas. | |
\item Add an attribute named {\tt color} to your Rectangle objects and | |
modify \verb"draw_rectangle" so that it uses the color attribute as | |
the fill color. | |
\item Write a function called \verb"draw_point" that takes a | |
Canvas and a Point as arguments and draws a | |
representation of the Point on the Canvas. | |
\item Define a new class called Circle with appropriate attributes and | |
instantiate a few Circle objects. Write a function called | |
\verb"draw_circle" that draws circles on the canvas. | |
\index{Czech Republic, national flag} | |
\item Write a program that draws the national flag of the Czech Republic. | |
Hint: you can draw a polygon like this: | |
\begin{verbatim} | |
points = [[-150,-100], [150, 100], [150, -100]] | |
canvas.polygon(points, fill='blue') | |
\end{verbatim} | |
\end{enumerate} | |
\index{color list} | |
\index{available colors} | |
I have written a small program that lists the available colors; | |
you can download it from \url{http://thinkpython.com/code/color_list.py}. | |
\end{exercise} | |
\chapter{Classes and functions} | |
\label{time} | |
Code examples from this chapter are available from | |
\url{http://thinkpython.com/code/Time1.py}. | |
\section{Time} | |
\label{time.object} | |
As another example of a user-defined type, we'll define a class called | |
{\tt Time} that records the time of day. The class definition looks | |
like this: | |
\index{user-defined type} | |
\index{type!user-defined} | |
\index{Time class} | |
\index{class!Time} | |
\begin{verbatim} | |
class Time(object): | |
"""Represents the time of day. | |
attributes: hour, minute, second | |
""" | |
\end{verbatim} | |
% | |
We can create a new {\tt Time} object and assign | |
attributes for hours, minutes, and seconds: | |
\begin{verbatim} | |
time = Time() | |
time.hour = 11 | |
time.minute = 59 | |
time.second = 30 | |
\end{verbatim} | |
% | |
The state diagram for the {\tt Time} object looks like Figure~\ref{fig.time}. | |
\index{state diagram} | |
\index{diagram!state} | |
\index{object diagram} | |
\index{diagram!object} | |
\begin{exercise} | |
\label{ex.printtime} | |
Write a function called \verb"print_time" that takes a | |
Time object and prints it in the form {\tt hour:minute:second}. | |
Hint: the format sequence \verb"'%.2d'" prints an integer using | |
at least two digits, including a leading zero if necessary. | |
\end{exercise} | |
\begin{exercise} | |
\label{isafter} | |
\index{boolean function} | |
Write a boolean function called \verb"is_after" that | |
takes two Time objects, {\tt t1} and {\tt t2}, and | |
returns {\tt True} if {\tt t1} follows {\tt t2} chronologically and | |
{\tt False} otherwise. Challenge: don't use an {\tt if} statement. | |
\end{exercise} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/time.pdf}} | |
\caption{Object diagram.} | |
\label{fig.time} | |
\end{figure} | |
\section{Pure functions} | |
\index{prototype and patch} | |
\index{development plan!prototype and patch} | |
In the next few sections, we'll write two functions that add time | |
values. They demonstrate two kinds of functions: pure functions and | |
modifiers. They also demonstrate a development plan I'll call {\bf | |
prototype and patch}, which is a way of tackling a complex problem | |
by starting with a simple prototype and incrementally dealing with the | |
complications. | |
Here is a simple prototype of \verb"add_time": | |
\begin{verbatim} | |
def add_time(t1, t2): | |
sum = Time() | |
sum.hour = t1.hour + t2.hour | |
sum.minute = t1.minute + t2.minute | |
sum.second = t1.second + t2.second | |
return sum | |
\end{verbatim} | |
% | |
The function creates a new {\tt Time} object, initializes its | |
attributes, and returns a reference to the new object. This is called | |
a {\bf pure function} because it does not modify any of the objects | |
passed to it as arguments and it has no effect, | |
like displaying a value or getting user input, | |
other than returning a value. | |
\index{pure function} | |
\index{function type!pure} | |
To test this function, I'll create two Time objects: {\tt start} | |
contains the start time of a movie, like {\em Monty Python and the | |
Holy Grail}, and {\tt duration} contains the run time of the movie, | |
which is one hour 35 minutes. | |
\index{Monty Python and the Holy Grail} | |
\verb"add_time" figures out when the movie will be done. | |
\begin{verbatim} | |
>>> start = Time() | |
>>> start.hour = 9 | |
>>> start.minute = 45 | |
>>> start.second = 0 | |
>>> duration = Time() | |
>>> duration.hour = 1 | |
>>> duration.minute = 35 | |
>>> duration.second = 0 | |
>>> done = add_time(start, duration) | |
>>> print_time(done) | |
10:80:00 | |
\end{verbatim} | |
% | |
The result, {\tt 10:80:00} might not be what you were hoping | |
for. The problem is that this function does not deal with cases where the | |
number of seconds or minutes adds up to more than sixty. When that | |
happens, we have to ``carry'' the extra seconds into the minute column | |
or the extra minutes into the hour column. | |
\index{carrying, addition with} | |
Here's an improved version: | |
\begin{verbatim} | |
def add_time(t1, t2): | |
sum = Time() | |
sum.hour = t1.hour + t2.hour | |
sum.minute = t1.minute + t2.minute | |
sum.second = t1.second + t2.second | |
if sum.second >= 60: | |
sum.second -= 60 | |
sum.minute += 1 | |
if sum.minute >= 60: | |
sum.minute -= 60 | |
sum.hour += 1 | |
return sum | |
\end{verbatim} | |
% | |
Although this function is correct, it is starting to get big. | |
We will see a shorter alternative later. | |
\section{Modifiers} | |
\label{increment} | |
\index{modifier} | |
\index{function type!modifier} | |
Sometimes it is useful for a function to modify the objects it gets as | |
parameters. In that case, the changes are visible to the caller. | |
Functions that work this way are called {\bf modifiers}. | |
\index{increment} | |
{\tt increment}, which adds a given number of seconds to a {\tt Time} | |
object, can be written naturally as a | |
modifier. Here is a rough draft: | |
\begin{verbatim} | |
def increment(time, seconds): | |
time.second += seconds | |
if time.second >= 60: | |
time.second -= 60 | |
time.minute += 1 | |
if time.minute >= 60: | |
time.minute -= 60 | |
time.hour += 1 | |
\end{verbatim} | |
% | |
The first line performs the basic operation; the remainder deals | |
with the special cases we saw before. | |
\index{special case} | |
Is this function correct? What happens if the parameter {\tt seconds} | |
is much greater than sixty? | |
In that case, it is not enough to carry | |
once; we have to keep doing it until {\tt time.second} is less than sixty. | |
One solution is to replace the {\tt if} statements with {\tt while} | |
statements. That would make the function correct, but not | |
very efficient. | |
\begin{exercise} | |
Write a correct version of {\tt increment} that | |
doesn't contain any loops. | |
\end{exercise} | |
Anything that can be done with modifiers can also be done with pure | |
functions. In fact, some programming languages only allow pure | |
functions. There is some evidence that programs that use pure | |
functions are faster to develop and less error-prone than programs | |
that use modifiers. But modifiers are convenient at times, | |
and functional programs tend to be less efficient. | |
In general, I recommend that you write pure functions whenever it is | |
reasonable and resort to modifiers only if there is a compelling | |
advantage. This approach might be called a {\bf functional | |
programming style}. | |
\index{functional programming style} | |
\begin{exercise} | |
Write a ``pure'' version of {\tt increment} that creates and returns | |
a new Time object rather than modifying the parameter. | |
\end{exercise} | |
\section{Prototyping versus planning} | |
\label{prototype} | |
\index{prototype and patch} | |
\index{development plan!prototype and patch} | |
\index{planned development} | |
\index{development plan!planned} | |
The development plan I am demonstrating is called ``prototype and | |
patch.'' For each function, I wrote a prototype that performed the | |
basic calculation and then tested it, patching errors along the | |
way. | |
This approach can be effective, especially if you don't yet have a | |
deep understanding of the problem. But incremental corrections can | |
generate code that is unnecessarily complicated---since it deals with | |
many special cases---and unreliable---since it is hard to know if you | |
have found all the errors. | |
An alternative is {\bf planned development}, in which high-level | |
insight into the problem can make the programming much easier. In | |
this case, the insight is that a Time object is really a three-digit | |
number in base 60 (see \url{http://en.wikipedia.org/wiki/Sexagesimal}.)! The | |
{\tt second} attribute is the ``ones column,'' the {\tt minute} | |
attribute is the ``sixties column,'' and the {\tt hour} attribute is | |
the ``thirty-six hundreds column.'' | |
\index{sexagesimal} | |
When we wrote \verb"add_time" and {\tt increment}, we were effectively | |
doing addition in base 60, which is why we had to carry from one | |
column to the next. | |
\index{carrying, addition with} | |
This observation suggests another approach to the whole problem---we | |
can convert Time objects to integers and take advantage of the fact | |
that the computer knows how to do integer arithmetic. | |
Here is a function that converts Times to integers: | |
\begin{verbatim} | |
def time_to_int(time): | |
minutes = time.hour * 60 + time.minute | |
seconds = minutes * 60 + time.second | |
return seconds | |
\end{verbatim} | |
% | |
And here is the function that converts integers to Times | |
(recall that {\tt divmod} divides the first argument by the second | |
and returns the quotient and remainder as a tuple). | |
\index{divmod} | |
\begin{verbatim} | |
def int_to_time(seconds): | |
time = Time() | |
minutes, time.second = divmod(seconds, 60) | |
time.hour, time.minute = divmod(minutes, 60) | |
return time | |
\end{verbatim} | |
% | |
You might have to think a bit, and run some tests, to convince | |
yourself that these functions are correct. One way to test them is to | |
check that \verb"time_to_int(int_to_time(x)) == x" for many values of | |
{\tt x}. This is an example of a consistency check. | |
\index{consistency check} | |
Once you are convinced they are correct, you can use them to | |
rewrite \verb"add_time": | |
\begin{verbatim} | |
def add_time(t1, t2): | |
seconds = time_to_int(t1) + time_to_int(t2) | |
return int_to_time(seconds) | |
\end{verbatim} | |
% | |
This version is shorter than the original, and easier to verify. | |
\begin{exercise} | |
Rewrite {\tt increment} using \verb"time_to_int" and \verb"int_to_time". | |
\end{exercise} | |
In some ways, converting from base 60 to base 10 and back is harder | |
than just dealing with times. Base conversion is more abstract; our | |
intuition for dealing with time values is better. | |
But if we have the insight to treat times as base 60 numbers and make | |
the investment of writing the conversion functions (\verb"time_to_int" | |
and \verb"int_to_time"), we get a program that is shorter, easier to | |
read and debug, and more reliable. | |
It is also easier to add features later. For example, imagine | |
subtracting two Times to find the duration between them. The | |
naive approach would be to implement subtraction with borrowing. | |
Using the conversion functions would be easier and more likely to be | |
correct. | |
\index{subtraction with borrowing} | |
\index{borrowing, subtraction with} | |
\index{generalization} | |
Ironically, sometimes making a problem harder (or more general) makes it | |
easier (because there are fewer special cases and fewer opportunities | |
for error). | |
\section{Debugging} | |
\index{debugging} | |
A Time object is well-formed if the values of {\tt minute} and {\tt | |
second} are between 0 and 60 (including 0 but not 60) and if | |
{\tt hour} is positive. {\tt hour} and {\tt minute} should be | |
integral values, but we might allow {\tt second} to have a | |
fraction part. | |
\index{invariant} | |
Requirements like these are called {\bf invariants} because | |
they should always be true. To put it a different way, if they | |
are not true, then something has gone wrong. | |
Writing code to check your invariants can help you detect errors | |
and find their causes. For example, you might have a function | |
like \verb"valid_time" that takes a Time object and returns | |
{\tt False} if it violates an invariant: | |
\begin{verbatim} | |
def valid_time(time): | |
if time.hour < 0 or time.minute < 0 or time.second < 0: | |
return False | |
if time.minute >= 60 or time.second >= 60: | |
return False | |
return True | |
\end{verbatim} | |
% | |
Then at the beginning of each function you could check the | |
arguments to make sure they are valid: | |
\index{raise statement} | |
\index{statement!raise} | |
\begin{verbatim} | |
def add_time(t1, t2): | |
if not valid_time(t1) or not valid_time(t2): | |
raise ValueError('invalid Time object in add_time') | |
seconds = time_to_int(t1) + time_to_int(t2) | |
return int_to_time(seconds) | |
\end{verbatim} | |
% | |
Or you could use an {\tt assert} statement, which checks a given invariant | |
and raises an exception if it fails: | |
\index{assert statement} | |
\index{statement!assert} | |
\begin{verbatim} | |
def add_time(t1, t2): | |
assert valid_time(t1) and valid_time(t2) | |
seconds = time_to_int(t1) + time_to_int(t2) | |
return int_to_time(seconds) | |
\end{verbatim} | |
% | |
{\tt assert} statements are useful because they distinguish | |
code that deals with normal conditions from code | |
that checks for errors. | |
\section{Glossary} | |
\begin{description} | |
\item[prototype and patch:] A development plan that involves | |
writing a rough draft of a program, testing, and correcting errors as | |
they are found. | |
\index{prototype and patch} | |
\item[planned development:] A development plan that involves | |
high-level insight into the problem and more planning than incremental | |
development or prototype development. | |
\index{planned development} | |
\item[pure function:] A function that does not modify any of the objects it | |
receives as arguments. Most pure functions are fruitful. | |
\index{pure function} | |
\item[modifier:] A function that changes one or more of the objects it | |
receives as arguments. Most modifiers are fruitless. | |
\index{modifier} | |
\item[functional programming style:] A style of program design in which the | |
majority of functions are pure. | |
\index{functional programming style} | |
\item[invariant:] A condition that should always be true during the | |
execution of a program. | |
\index{invariant} | |
\end{description} | |
\section{Exercises} | |
Code examples from this chapter are available from | |
\url{http://thinkpython.com/code/Time1.py}; solutions to these | |
exercises are available from \url{http://thinkpython.com/code/Time1_soln.py}. | |
\begin{exercise} | |
Write a function called \verb"mul_time" that takes a Time object | |
and a number and returns a new Time object that contains | |
the product of the original Time and the number. | |
Then use \verb"mul_time" to write a function that takes a Time | |
object that represents the finishing time in a race, and a number | |
that represents the distance, and returns a Time object that represents | |
the average pace (time per mile). | |
\index{running pace} | |
\end{exercise} | |
%\begin{exercise} | |
%\index{Date class} | |
%\index{class!Date} | |
%Write a class definition for a Date object that has attributes {\tt | |
% day}, {\tt month} and {\tt year}. Write a function called | |
%\verb"increment_date" that takes a Date object, {\tt date} and an | |
%integer, {\tt n}, and returns a new Date object that | |
%represents the day {\tt n} days after {\tt date}. Hint: | |
%``Thirty days hath September...'' Challenge: does your function | |
%deal with leap years correctly? See \url{http://en.wikipedia.org/wiki/Leap_year}. | |
%\end{exercise} | |
\begin{exercise} | |
\index{datetime module} | |
\index{module!datetime} | |
The {\tt datetime} module provides {\tt date} and {\tt time} objects | |
that are similar to the Date and Time objects in this chapter, but | |
they provide a rich set of methods and operators. Read the | |
documentation at \url{http://docs.python.org/2/library/datetime.html}. | |
\begin{enumerate} | |
\item Use the {\tt datetime} module to write a program that gets the | |
current date and prints the day of the week. | |
\index{birthday} | |
\item Write a program that takes a birthday as input and prints the | |
user's age and the number of days, hours, minutes and seconds until | |
their next birthday. | |
\item For two people born on different days, there is a day when one | |
is twice as old as the other. That's their Double Day. Write a | |
program that takes two birthdays and computes their Double Day. | |
\item For a little more challenge, write the more general version that | |
computes the day when one person is $n$ times older than the other. | |
\index{Double Day} | |
\end{enumerate} | |
\end{exercise} | |
\chapter{Classes and methods} | |
Code examples from this chapter are available from | |
\url{http://thinkpython.com/code/Time2.py}. | |
\section{Object-oriented features} | |
\index{object-oriented programming} | |
Python is an {\bf object-oriented programming language}, which means | |
that it provides features that support object-oriented | |
programming. | |
It is not easy to define object-oriented programming, but we have | |
already seen some of its characteristics: | |
\begin{itemize} | |
\item Programs are made up of object definitions and function | |
definitions, and most of the computation is expressed in terms | |
of operations on objects. | |
\item Each object definition corresponds to some object or concept | |
in the real world, and the functions that operate on that object | |
correspond to the ways real-world objects interact. | |
\end{itemize} | |
For example, the {\tt Time} class defined in Chapter~\ref{time} | |
corresponds to the way people record the time of day, and the | |
functions we defined correspond to the kinds of things people do with | |
times. Similarly, the {\tt Point} and {\tt Rectangle} classes | |
correspond to the mathematical concepts of a point and a rectangle. | |
So far, we have not taken advantage of the features Python provides to | |
support object-oriented programming. These | |
features are not strictly necessary; most of them provide | |
alternative syntax for things we have already done. But in many cases, | |
the alternative is more concise and more accurately conveys the | |
structure of the program. | |
For example, in the {\tt Time} program, there is no obvious | |
connection between the class definition and the function definitions | |
that follow. With some examination, it is apparent that every function | |
takes at least one {\tt Time} object as an argument. | |
\index{method} | |
\index{function} | |
This observation is the motivation for {\bf methods}; a method is | |
a function that is associated with a particular class. | |
We have seen methods for strings, lists, dictionaries and tuples. | |
In this chapter, we will define methods for user-defined types. | |
\index{syntax} | |
\index{semantics} | |
Methods are semantically the same as functions, but there are | |
two syntactic differences: | |
\begin{itemize} | |
\item Methods are defined inside a class definition in order | |
to make the relationship between the class and the method explicit. | |
\item The syntax for invoking a method is different from the | |
syntax for calling a function. | |
\end{itemize} | |
In the next few sections, we will take the functions from the previous | |
two chapters and transform them into methods. This transformation is | |
purely mechanical; you can do it simply by following a sequence of | |
steps. If you are comfortable converting from one form to another, | |
you will be able to choose the best form for whatever you are doing. | |
\section{Printing objects} | |
\index{object!printing} | |
In Chapter~\ref{time}, we defined a class named | |
{\tt Time} and in Exercise~\ref{ex.printtime}, you | |
wrote a function named \verb"print_time": | |
\begin{verbatim} | |
class Time(object): | |
"""Represents the time of day.""" | |
def print_time(time): | |
print '%.2d:%.2d:%.2d' % (time.hour, time.minute, time.second) | |
\end{verbatim} | |
% | |
To call this function, you have to pass a {\tt Time} object as an | |
argument: | |
\begin{verbatim} | |
>>> start = Time() | |
>>> start.hour = 9 | |
>>> start.minute = 45 | |
>>> start.second = 00 | |
>>> print_time(start) | |
09:45:00 | |
\end{verbatim} | |
% | |
To make \verb"print_time" a method, all we have to do is | |
move the function definition inside the class definition. Notice | |
the change in indentation. | |
\index{indentation} | |
\begin{verbatim} | |
class Time(object): | |
def print_time(time): | |
print '%.2d:%.2d:%.2d' % (time.hour, time.minute, time.second) | |
\end{verbatim} | |
% | |
Now there are two ways to call \verb"print_time". The first | |
(and less common) way is to use function syntax: | |
\index{function syntax} | |
\index{dot notation} | |
\begin{verbatim} | |
>>> Time.print_time(start) | |
09:45:00 | |
\end{verbatim} | |
% | |
In this use of dot notation, {\tt Time} is the name of the class, | |
and \verb"print_time" is the name of the method. {\tt start} is | |
passed as a parameter. | |
The second (and more concise) way is to use method syntax: | |
\index{method syntax} | |
\begin{verbatim} | |
>>> start.print_time() | |
09:45:00 | |
\end{verbatim} | |
% | |
In this use of dot notation, \verb"print_time" is the name of the | |
method (again), and {\tt start} is the object the method is | |
invoked on, which is called the {\bf subject}. Just as the | |
subject of a sentence is what the sentence is about, the subject | |
of a method invocation is what the method is about. | |
\index{subject} | |
Inside the method, the subject is assigned to the first | |
parameter, so in this case {\tt start} is assigned | |
to {\tt time}. | |
\index{self (parameter name)} | |
\index{parameter!self} | |
By convention, the first parameter of a method is | |
called {\tt self}, so it would be more common to write | |
\verb"print_time" like this: | |
\begin{verbatim} | |
class Time(object): | |
def print_time(self): | |
print '%.2d:%.2d:%.2d' % (self.hour, self.minute, self.second) | |
\end{verbatim} | |
% | |
The reason for this convention is an implicit metaphor: | |
\index{metaphor, method invocation} | |
\begin{itemize} | |
\item The syntax for a function call, \verb"print_time(start)", | |
suggests that the function is the active agent. It says something | |
like, ``Hey \verb"print_time"! Here's an object for you to print.'' | |
\item In object-oriented programming, the objects are the active | |
agents. A method invocation like \verb"start.print_time()" says | |
``Hey {\tt start}! Please print yourself.'' | |
\end{itemize} | |
This change in perspective might be more polite, but it is not obvious | |
that it is useful. In the examples we have seen so far, it may not | |
be. But sometimes shifting responsibility from the functions onto the | |
objects makes it possible to write more versatile functions, and makes | |
it easier to maintain and reuse code. | |
\begin{exercise} | |
\label{convert} | |
Rewrite \verb"time_to_int" (from Section~\ref{prototype}) as a method. | |
It is probably not appropriate to rewrite \verb"int_to_time" as a | |
method; what object you would invoke it on? | |
\end{exercise} | |
\section{Another example} | |
\index{increment} | |
Here's a version of {\tt increment} (from Section~\ref{increment}) | |
rewritten as a method: | |
\begin{verbatim} | |
# inside class Time: | |
def increment(self, seconds): | |
seconds += self.time_to_int() | |
return int_to_time(seconds) | |
\end{verbatim} | |
% | |
This version assumes that \verb"time_to_int" is written | |
as a method, as in Exercise~\ref{convert}. Also, note that | |
it is a pure function, not a modifier. | |
Here's how you would invoke {\tt increment}: | |
\begin{verbatim} | |
>>> start.print_time() | |
09:45:00 | |
>>> end = start.increment(1337) | |
>>> end.print_time() | |
10:07:17 | |
\end{verbatim} | |
% | |
The subject, {\tt start}, gets assigned to the first parameter, | |
{\tt self}. The argument, {\tt 1337}, gets assigned to the | |
second parameter, {\tt seconds}. | |
This mechanism can be confusing, especially if you make an error. | |
For example, if you invoke {\tt increment} with two arguments, you | |
get: | |
\index{exception!TypeError} | |
\index{TypeError} | |
\begin{verbatim} | |
>>> end = start.increment(1337, 460) | |
TypeError: increment() takes exactly 2 arguments (3 given) | |
\end{verbatim} | |
% | |
The error message is initially confusing, because there are | |
only two arguments in parentheses. But the subject is also | |
considered an argument, so all together that's three. | |
\section{A more complicated example} | |
\verb"is_after" (from Exercise~\ref{isafter}) is slightly more complicated | |
because it takes two Time objects as parameters. In this case it is | |
conventional to name the first parameter {\tt self} and the second | |
parameter {\tt other}: | |
\index{other (parameter name)} | |
\index{parameter!other} | |
\begin{verbatim} | |
# inside class Time: | |
def is_after(self, other): | |
return self.time_to_int() > other.time_to_int() | |
\end{verbatim} | |
% | |
To use this method, you have to invoke it on one object and pass | |
the other as an argument: | |
\begin{verbatim} | |
>>> end.is_after(start) | |
True | |
\end{verbatim} | |
% | |
One nice thing about this syntax is that it almost reads | |
like English: ``end is after start?'' | |
\section{The init method} | |
\index{init method} | |
\index{method!init} | |
The init method (short for ``initialization'') is | |
a special method that gets invoked when an object is instantiated. | |
Its full name is \verb"__init__" (two underscore characters, | |
followed by {\tt init}, and then two more underscores). An | |
init method for the {\tt Time} class might look like this: | |
\begin{verbatim} | |
# inside class Time: | |
def __init__(self, hour=0, minute=0, second=0): | |
self.hour = hour | |
self.minute = minute | |
self.second = second | |
\end{verbatim} | |
% | |
It is common for the parameters of \verb"__init__" | |
to have the same names as the attributes. The statement | |
\begin{verbatim} | |
self.hour = hour | |
\end{verbatim} | |
% | |
stores the value of the parameter {\tt hour} as an attribute | |
of {\tt self}. | |
\index{optional parameter} | |
\index{parameter!optional} | |
\index{default value} | |
\index{override} | |
The parameters are optional, so if you call {\tt Time} with | |
no arguments, you get the default values. | |
\begin{verbatim} | |
>>> time = Time() | |
>>> time.print_time() | |
00:00:00 | |
\end{verbatim} | |
% | |
If you provide one argument, it overrides {\tt hour}: | |
\begin{verbatim} | |
>>> time = Time (9) | |
>>> time.print_time() | |
09:00:00 | |
\end{verbatim} | |
% | |
If you provide two arguments, they override {\tt hour} and | |
{\tt minute}. | |
\begin{verbatim} | |
>>> time = Time(9, 45) | |
>>> time.print_time() | |
09:45:00 | |
\end{verbatim} | |
% | |
And if you provide three arguments, they override all three | |
default values. | |
\begin{exercise} | |
\index{Point class} | |
\index{class!Point} | |
Write an init method for the {\tt Point} class that takes | |
{\tt x} and {\tt y} as optional parameters and assigns | |
them to the corresponding attributes. | |
\end{exercise} | |
\section{The {\tt \_\_str\_\_} method} | |
\index{str method@\_\_str\_\_ method} | |
\index{method!\_\_str\_\_} | |
\verb"__str__" is a special method, like \verb"__init__", | |
that is supposed to return a string representation of an object. | |
\index{string representation} | |
For example, here is a {\tt str} method for Time objects: | |
\begin{verbatim} | |
# inside class Time: | |
def __str__(self): | |
return '%.2d:%.2d:%.2d' % (self.hour, self.minute, self.second) | |
\end{verbatim} | |
% | |
When you {\tt print} an object, Python invokes the {\tt str} method: | |
\index{print statement} | |
\index{statement!print} | |
\begin{verbatim} | |
>>> time = Time(9, 45) | |
>>> print time | |
09:45:00 | |
\end{verbatim} | |
% | |
When I write a new class, I almost always start by writing | |
\verb"__init__", which makes it easier to instantiate objects, and | |
\verb"__str__", which is useful for debugging. | |
\begin{exercise} | |
Write a {\tt str} method for the {\tt Point} class. Create | |
a Point object and print it. | |
\end{exercise} | |
\section{Operator overloading} | |
\label{operator.overloading} | |
By defining other special methods, you can specify the behavior | |
of operators on user-defined types. For example, if you define | |
a method named \verb"__add__" for the {\tt Time} class, you can use the | |
{\tt +} operator on Time objects. | |
Here is what the definition might look like: | |
\index{add method} | |
\index{method!add} | |
\begin{verbatim} | |
# inside class Time: | |
def __add__(self, other): | |
seconds = self.time_to_int() + other.time_to_int() | |
return int_to_time(seconds) | |
\end{verbatim} | |
% | |
And here is how you could use it: | |
\begin{verbatim} | |
>>> start = Time(9, 45) | |
>>> duration = Time(1, 35) | |
>>> print start + duration | |
11:20:00 | |
\end{verbatim} | |
% | |
When you apply the {\tt +} operator to Time objects, Python invokes | |
\verb"__add__". When you print the result, Python invokes | |
\verb"__str__". So there is quite a lot happening behind the scenes! | |
\index{operator overloading} | |
Changing the behavior of an operator so that it works with | |
user-defined types is called {\bf operator overloading}. For every | |
operator in Python there is a corresponding special method, like | |
\verb"__add__". For more details, see | |
\url{http://docs.python.org/2/reference/datamodel.html#specialnames}. | |
\begin{exercise} | |
Write an {\tt add} method for the Point class. | |
\end{exercise} | |
\section{Type-based dispatch} | |
In the previous section we added two Time objects, but you | |
also might want to add an integer to a Time object. The | |
following is a version of \verb"__add__" | |
that checks the type of {\tt other} and invokes either | |
\verb"add_time" or {\tt increment}: | |
\begin{verbatim} | |
# inside class Time: | |
def __add__(self, other): | |
if isinstance(other, Time): | |
return self.add_time(other) | |
else: | |
return self.increment(other) | |
def add_time(self, other): | |
seconds = self.time_to_int() + other.time_to_int() | |
return int_to_time(seconds) | |
def increment(self, seconds): | |
seconds += self.time_to_int() | |
return int_to_time(seconds) | |
\end{verbatim} | |
% | |
The built-in function {\tt isinstance} takes a value and a | |
class object, and returns {\tt True} if the value is an instance | |
of the class. | |
\index{isinstance function} | |
\index{function!isinstance} | |
If {\tt other} is a Time object, \verb"__add__" invokes | |
\verb"add_time". Otherwise it assumes that the parameter | |
is a number and invokes {\tt increment}. This operation is | |
called a {\bf type-based dispatch} because it dispatches the | |
computation to different methods based on the type of the | |
arguments. | |
\index{type-based dispatch} | |
\index{dispatch, type-based} | |
Here are examples that use the {\tt +} operator with different | |
types: | |
\begin{verbatim} | |
>>> start = Time(9, 45) | |
>>> duration = Time(1, 35) | |
>>> print start + duration | |
11:20:00 | |
>>> print start + 1337 | |
10:07:17 | |
\end{verbatim} | |
% | |
Unfortunately, this implementation of addition is not commutative. | |
If the integer is the first operand, you get | |
\index{commutativity} | |
\begin{verbatim} | |
>>> print 1337 + start | |
TypeError: unsupported operand type(s) for +: 'int' and 'instance' | |
\end{verbatim} | |
% | |
The problem is, instead of asking the Time object to add an integer, | |
Python is asking an integer to add a Time object, and it doesn't know | |
how to do that. But there is a clever solution for this problem: the | |
special method \verb"__radd__", which stands for ``right-side add.'' | |
This method is invoked when a Time object appears on the right side of | |
the {\tt +} operator. Here's the definition: | |
\index{radd method} | |
\index{method!radd} | |
\begin{verbatim} | |
# inside class Time: | |
def __radd__(self, other): | |
return self.__add__(other) | |
\end{verbatim} | |
% | |
And here's how it's used: | |
\begin{verbatim} | |
>>> print 1337 + start | |
10:07:17 | |
\end{verbatim} | |
% | |
\begin{exercise} | |
Write an {\tt add} method for Points that works with either a | |
Point object or a tuple: | |
\begin{itemize} | |
\item If the second operand is a Point, the method should return a new | |
Point whose $x$ coordinate is the sum of the $x$ coordinates of the | |
operands, and likewise for the $y$ coordinates. | |
\item If the second operand is a tuple, the method should add the | |
first element of the tuple to the $x$ coordinate and the second | |
element to the $y$ coordinate, and return a new Point with the result. | |
\end{itemize} | |
\end{exercise} | |
\section{Polymorphism} | |
Type-based dispatch is useful when it is necessary, but (fortunately) | |
it is not always necessary. Often you can avoid it by writing functions | |
that work correctly for arguments with different types. | |
\index{type-based dispatch} | |
\index{dispatch!type-based} | |
Many of the functions we wrote for strings will actually | |
work for any kind of sequence. | |
For example, in Section~\ref{histogram} | |
we used {\tt histogram} to count the number of times each letter | |
appears in a word. | |
\begin{verbatim} | |
def histogram(s): | |
d = dict() | |
for c in s: | |
if c not in d: | |
d[c] = 1 | |
else: | |
d[c] = d[c]+1 | |
return d | |
\end{verbatim} | |
% | |
This function also works for lists, tuples, and even dictionaries, | |
as long as the elements of {\tt s} are hashable, so they can be used | |
as keys in {\tt d}. | |
\begin{verbatim} | |
>>> t = ['spam', 'egg', 'spam', 'spam', 'bacon', 'spam'] | |
>>> histogram(t) | |
{'bacon': 1, 'egg': 1, 'spam': 4} | |
\end{verbatim} | |
% | |
Functions that can work with several types are called {\bf polymorphic}. | |
Polymorphism can facilitate code reuse. For example, the built-in | |
function {\tt sum}, which adds the elements of a sequence, works | |
as long as the elements of the sequence support addition. | |
\index{polymorphism} | |
Since Time objects provide an {\tt add} method, they work | |
with {\tt sum}: | |
\begin{verbatim} | |
>>> t1 = Time(7, 43) | |
>>> t2 = Time(7, 41) | |
>>> t3 = Time(7, 37) | |
>>> total = sum([t1, t2, t3]) | |
>>> print total | |
23:01:00 | |
\end{verbatim} | |
% | |
In general, if all of the operations inside a function | |
work with a given type, then the function works with that type. | |
The best kind of polymorphism is the unintentional kind, where | |
you discover that a function you already wrote can be | |
applied to a type you never planned for. | |
\section{Debugging} | |
\index{debugging} | |
It is legal to add attributes to objects at any point in the execution | |
of a program, but if you are a stickler for type theory, it is a | |
dubious practice to have objects of the same type with different | |
attribute sets. It is usually a good idea to | |
initialize all of an object's attributes in the init method. | |
\index{init method} | |
\index{attribute!initializing} | |
If you are not sure whether an object has a particular attribute, you | |
can use the built-in function {\tt hasattr} (see Section~\ref{hasattr}). | |
\index{hasattr function} | |
\index{function!hasattr} | |
\index{dict attribute@\_\_dict\_\_ attribute} | |
\index{attribute!\_\_dict\_\_} | |
Another way to access the attributes of an object is through the | |
special attribute \verb"__dict__", which is a dictionary that maps | |
attribute names (as strings) and values: | |
\begin{verbatim} | |
>>> p = Point(3, 4) | |
>>> print p.__dict__ | |
{'y': 4, 'x': 3} | |
\end{verbatim} | |
% | |
For purposes of debugging, you might find it useful to keep this | |
function handy: | |
\begin{verbatim} | |
def print_attributes(obj): | |
for attr in obj.__dict__: | |
print attr, getattr(obj, attr) | |
\end{verbatim} | |
% | |
\verb"print_attributes" traverses the items in the object's dictionary | |
and prints each attribute name and its corresponding value. | |
\index{traversal!dictionary} | |
\index{dictionary!traversal} | |
The built-in function {\tt getattr} takes an object and an attribute | |
name (as a string) and returns the attribute's value. | |
\index{getattr function} | |
\index{function!getattr} | |
\section{Interface and implementation} | |
One of the goals of object-oriented design is to make software more | |
maintainable, which means that you can keep the program working when | |
other parts of the system change, and modify the program to meet new | |
requirements. | |
\index{interface} | |
\index{implementation} | |
\index{maintainable} | |
\index{object-oriented design} | |
A design principle that helps achieve that goal is to keep | |
interfaces separate from implementations. For objects, that means | |
that the methods a class provides should not depend on how the | |
attributes are represented. | |
\index{attribute} | |
For example, in this chapter we developed a class that represents | |
a time of day. Methods provided by this class include | |
\verb"time_to_int", \verb"is_after", and \verb"add_time". | |
We could implement those methods in several ways. The details of the | |
implementation depend on how we represent time. In this chapter, the | |
attributes of a {\tt Time} object are {\tt hour}, {\tt minute}, and | |
{\tt second}. | |
As an alternative, we could replace these attributes with | |
a single integer representing the number of seconds | |
since midnight. This implementation would make some methods, | |
like \verb"is_after", easier to write, but it makes some methods | |
harder. | |
After you deploy a new class, you might discover a better | |
implementation. If other parts of the program are using your | |
class, it might be time-consuming and error-prone to change the | |
interface. | |
But if you designed the interface carefully, you can | |
change the implementation without changing the interface, which | |
means that other parts of the program don't have to change. | |
Keeping the interface separate from the implementation means that | |
you have to hide the attributes. Code in other parts of the program | |
(outside the class definition) should use methods to read | |
and modify the state of the object. They should not access the | |
attributes directly. This principle is called {\bf information hiding}; | |
see \url{http://en.wikipedia.org/wiki/Information_hiding}. | |
\index{information hiding} | |
\begin{exercise} | |
Download the code from this chapter | |
(\url{http://thinkpython.com/code/Time2.py}). Change the attributes | |
of {\tt Time} to be a single integer representing seconds since | |
midnight. Then modify the methods (and the function | |
\verb"int_to_time") to work with the new implementation. You should | |
not have to modify the test code in {\tt main}. When you are done, | |
the output should be the same as before. Solution: | |
\url{http://thinkpython.com/code/Time2_soln.py} | |
\end{exercise} | |
\section{Glossary} | |
\begin{description} | |
\item[object-oriented language:] A language that provides features, | |
such as user-defined classes and method syntax, that facilitate | |
object-oriented programming. | |
\index{object-oriented language} | |
\item[object-oriented programming:] A style of programming in which | |
data and the operations that manipulate it are organized into classes | |
and methods. | |
\index{object-oriented programming} | |
\item[method:] A function that is defined inside a class definition and | |
is invoked on instances of that class. | |
\index{method} | |
\item[subject:] The object a method is invoked on. | |
\index{subject} | |
\item[operator overloading:] Changing the behavior of an operator like | |
{\tt +} so it works with a user-defined type. | |
\index{overloading} | |
\index{operator!overloading} | |
\item[type-based dispatch:] A programming pattern that checks the type | |
of an operand and invokes different functions for different types. | |
\index{type-based dispatch} | |
\item[polymorphic:] Pertaining to a function that can work with more | |
than one type. | |
\index{polymorphism} | |
\item[information hiding:] The principle that the interface provided | |
by an object should not depend on its implementation, in particular | |
the representation of its attributes. | |
\index{information hiding} | |
\end{description} | |
\section{Exercises} | |
\begin{exercise} | |
\index{default value!avoiding mutable} | |
\index{mutable object, as default value} | |
\index{worst bug} | |
\index{bug!worst} | |
\index{Kangaroo class} | |
\index{class!Kangaroo} | |
This exercise is a cautionary tale about one of the most | |
common, and difficult to find, errors in Python. | |
Write a definition for a class named {\tt Kangaroo} with the following | |
methods: | |
\begin{enumerate} | |
\item An \verb"__init__" method that initializes an attribute named | |
\verb"pouch_contents" to an empty list. | |
\item A method named \verb"put_in_pouch" that takes an object | |
of any type and adds it to \verb"pouch_contents". | |
\item A \verb"__str__" method that returns a string representation | |
of the Kangaroo object and the contents of the pouch. | |
\end{enumerate} | |
% | |
Test your code | |
by creating two {\tt Kangaroo} objects, assigning them to variables | |
named {\tt kanga} and {\tt roo}, and then adding {\tt roo} to the | |
contents of {\tt kanga}'s pouch. | |
Download \url{http://thinkpython.com/code/BadKangaroo.py}. It contains | |
a solution to the previous problem with one big, nasty bug. | |
Find and fix the bug. | |
If you get stuck, you can download | |
\url{http://thinkpython.com/code/GoodKangaroo.py}, which explains the | |
problem and demonstrates a solution. | |
\index{aliasing} | |
\index{embedded object} | |
\index{object!embedded} | |
\end{exercise} | |
\begin{exercise} | |
\index{Visual module} | |
\index{module!Visual} | |
\index{vpython module} | |
\index{module!vpython} | |
Visual is a Python module that provides 3-D graphics. It is | |
not always included in a Python installation, so you might have | |
to install it from your software repository or, if it's not there, | |
from \url{http://vpython.org}. | |
The following example creates a 3-D space that is 256 units | |
wide, long and high, and sets the ``center'' to be the | |
point $(128,128,128)$. Then it draws a blue sphere. | |
\begin{verbatim} | |
from visual import * | |
scene.range = (256, 256, 256) | |
scene.center = (128, 128, 128) | |
color = (0.1, 0.1, 0.9) # mostly blue | |
sphere(pos=scene.center, radius=128, color=color) | |
\end{verbatim} | |
{\tt color} is an RGB tuple; that is, the elements are Red-Green-Blue | |
levels between 0.0 and 1.0 (see | |
\url{http://en.wikipedia.org/wiki/RGB_color_model}). | |
If you run this code, you should see a window with a black | |
background and a blue sphere. If you drag the middle button | |
up and down, you can zoom in and out. You can also rotate | |
the scene by dragging the right button, but with only one | |
sphere in the world, it is hard to tell the difference. | |
The following loop creates a cube of spheres: | |
\begin{verbatim} | |
t = range(0, 256, 51) | |
for x in t: | |
for y in t: | |
for z in t: | |
pos = x, y, z | |
sphere(pos=pos, radius=10, color=color) | |
\end{verbatim} | |
\begin{enumerate} | |
\item Put this code in a script and make sure it works for | |
you. | |
\item Modify the program so that each sphere in the cube | |
has the color that corresponds to its position in RGB space. | |
Notice that the coordinates are in the range 0--255, but | |
the RGB tuples are in the range 0.0--1.0. | |
\index{color list} | |
\index{available colors} | |
\item Download \url{http://thinkpython.com/code/color_list.py} | |
and use the function \verb"read_colors" to generate a list | |
of the available colors on your system, their names and | |
RGB values. For each named color draw a sphere in the | |
position that corresponds to its RGB values. | |
\end{enumerate} | |
You can see my solution at \url{http://thinkpython.com/code/color_space.py}. | |
\end{exercise} | |
\chapter{Inheritance} | |
In this chapter I present classes to represent playing cards, | |
decks of cards, and poker hands. If you don't play poker, you can | |
read about it at \url{http://en.wikipedia.org/wiki/Poker}, but you don't have | |
to; I'll tell you what you need to know for the exercises. | |
Code examples from this chapter are available from | |
\url{http://thinkpython.com/code/Card.py}. | |
\index{playing card, Anglo-American} | |
\index{card, playing} | |
\index{poker} | |
If you are not familiar with Anglo-American playing cards, | |
you can read about them at \url{http://en.wikipedia.org/wiki/Playing_cards}. | |
\section{Card objects} | |
There are fifty-two cards in a deck, each of which belongs to one of | |
four suits and one of thirteen ranks. The suits are Spades, Hearts, | |
Diamonds, and Clubs (in descending order in bridge). The ranks are | |
Ace, 2, 3, 4, 5, 6, 7, 8, 9, 10, Jack, Queen, and King. Depending on | |
the game that you are playing, an Ace may be higher than King | |
or lower than 2. | |
\index{rank} | |
\index{suit} | |
If we want to define a new object to represent a playing card, it is | |
obvious what the attributes should be: {\tt rank} and | |
{\tt suit}. It is not as obvious what type the attributes | |
should be. One possibility is to use strings containing words like | |
\verb"'Spade'" for suits and \verb"'Queen'" for ranks. One problem with | |
this implementation is that it would not be easy to compare cards to | |
see which had a higher rank or suit. | |
\index{encode} | |
\index{encrypt} | |
\index{map to} | |
\index{representation} | |
An alternative is to use integers to {\bf encode} the ranks and suits. | |
In this context, ``encode'' means that we are going to define a mapping | |
between numbers and suits, or between numbers and ranks. This | |
kind of encoding is not meant to be a secret (that | |
would be ``encryption''). | |
\newcommand{\mymapsto}{$\mapsto$} | |
For example, this table shows the suits and the corresponding integer | |
codes: | |
\begin{tabular}{l c l} | |
Spades & \mymapsto & 3 \\ | |
Hearts & \mymapsto & 2 \\ | |
Diamonds & \mymapsto & 1 \\ | |
Clubs & \mymapsto & 0 | |
\end{tabular} | |
This code makes it easy to compare cards; because higher suits map to | |
higher numbers, we can compare suits by comparing their codes. | |
The mapping for ranks is fairly obvious; each of the numerical ranks | |
maps to the corresponding integer, and for face cards: | |
\begin{tabular}{l c l} | |
Jack & \mymapsto & 11 \\ | |
Queen & \mymapsto & 12 \\ | |
King & \mymapsto & 13 \\ | |
\end{tabular} | |
I am using the \mymapsto~symbol to make it clear that these mappings | |
are not part of the Python program. They are part of the program | |
design, but they don't appear explicitly in the code. | |
\index{Card class} | |
\index{class!Card} | |
The class definition for {\tt Card} looks like this: | |
\begin{verbatim} | |
class Card(object): | |
"""Represents a standard playing card.""" | |
def __init__(self, suit=0, rank=2): | |
self.suit = suit | |
self.rank = rank | |
\end{verbatim} | |
% | |
As usual, the init method takes an optional | |
parameter for each attribute. The default card is | |
the 2 of Clubs. | |
\index{init method} | |
\index{method!init} | |
To create a Card, you call {\tt Card} with the | |
suit and rank of the card you want. | |
\begin{verbatim} | |
queen_of_diamonds = Card(1, 12) | |
\end{verbatim} | |
% | |
\section{Class attributes} | |
\label{class.attribute} | |
\index{class attribute} | |
\index{attribute!class} | |
In order to print Card objects in a way that people can easily | |
read, we need a mapping from the integer codes to the corresponding | |
ranks and suits. A natural way to | |
do that is with lists of strings. We assign these lists to {\bf class | |
attributes}: | |
\begin{verbatim} | |
# inside class Card: | |
suit_names = ['Clubs', 'Diamonds', 'Hearts', 'Spades'] | |
rank_names = [None, 'Ace', '2', '3', '4', '5', '6', '7', | |
'8', '9', '10', 'Jack', 'Queen', 'King'] | |
def __str__(self): | |
return '%s of %s' % (Card.rank_names[self.rank], | |
Card.suit_names[self.suit]) | |
\end{verbatim} | |
% | |
Variables like \verb"suit_names" and \verb"rank_names", which are | |
defined inside a class but outside of any method, are called | |
class attributes because they are associated with the class object | |
{\tt Card}. | |
\index{instance attribute} | |
\index{attribute!instance} | |
This term distinguishes them from variables like {\tt suit} and {\tt | |
rank}, which are called {\bf instance attributes} because they are | |
associated with a particular instance. | |
\index{dot notation} | |
Both kinds of attribute are accessed using dot notation. For | |
example, in \verb"__str__", {\tt self} is a Card object, | |
and {\tt self.rank} is its rank. Similarly, {\tt Card} | |
is a class object, and \verb"Card.rank_names" is a | |
list of strings associated with the class. | |
Every card has its own {\tt suit} and {\tt rank}, but there | |
is only one copy of \verb"suit_names" and \verb"rank_names". | |
Putting it all together, the expression | |
\verb"Card.rank_names[self.rank]" means ``use the attribute {\tt rank} | |
from the object {\tt self} as an index into the list \verb"rank_names" | |
from the class {\tt Card}, and select the appropriate string.'' | |
The first element of \verb"rank_names" is {\tt None} because there | |
is no card with rank zero. By including {\tt None} as a place-keeper, | |
we get a mapping with the nice property that the index 2 maps to the | |
string \verb"'2'", and so on. To avoid this tweak, we could have | |
used a dictionary instead of a list. | |
With the methods we have so far, we can create and print cards: | |
\begin{verbatim} | |
>>> card1 = Card(2, 11) | |
>>> print card1 | |
Jack of Hearts | |
\end{verbatim} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/card1.pdf}} | |
\caption{Object diagram.} | |
\label{fig.card1} | |
\end{figure} | |
Figure~\ref{fig.card1} is a diagram of the {\tt Card} class object | |
and one Card instance. | |
\index{state diagram} | |
\index{diagram!state} | |
\index{object diagram} | |
\index{diagram!object} | |
{\tt Card} is a class object, so it has type {\tt type}. {\tt | |
card1} has type {\tt Card}. (To save space, I didn't draw the | |
contents of \verb"suit_names" and \verb"rank_names"). | |
\section{Comparing cards} | |
\label{comparecard} | |
\index{operator!relational} | |
\index{relational operator} | |
For built-in types, there are relational operators | |
({\tt <}, {\tt >}, {\tt ==}, etc.) | |
that compare | |
values and determine when one is greater than, less than, or equal to | |
another. For user-defined types, we can override the behavior of | |
the built-in operators by providing a method named | |
\verb"__cmp__". | |
\verb"__cmp__" takes two parameters, {\tt self} and {\tt other}, | |
and returns a positive number if the first object is greater, a | |
negative number if the second object is greater, and 0 if they are | |
equal to each other. | |
\index{override} | |
\index{operator overloading} | |
The correct ordering for cards is not obvious. | |
For example, which | |
is better, the 3 of Clubs or the 2 of Diamonds? One has a higher | |
rank, but the other has a higher suit. In order to compare | |
cards, you have to decide whether rank or suit is more important. | |
The answer might depend on what game you are playing, but to keep | |
things simple, we'll make the arbitrary choice that suit is more | |
important, so all of the Spades outrank all of the Diamonds, | |
and so on. | |
\index{cmp method@\_\_cmp\_\_ method} | |
\index{method!\_\_cmp\_\_} | |
With that decided, we can write \verb"__cmp__": | |
\begin{verbatim} | |
# inside class Card: | |
def __cmp__(self, other): | |
# check the suits | |
if self.suit > other.suit: return 1 | |
if self.suit < other.suit: return -1 | |
# suits are the same... check ranks | |
if self.rank > other.rank: return 1 | |
if self.rank < other.rank: return -1 | |
# ranks are the same... it's a tie | |
return 0 | |
\end{verbatim} | |
% | |
You can write this more concisely using tuple comparison: | |
\index{tuple!comparison} | |
\index{comparison!tuple} | |
\begin{verbatim} | |
# inside class Card: | |
def __cmp__(self, other): | |
t1 = self.suit, self.rank | |
t2 = other.suit, other.rank | |
return cmp(t1, t2) | |
\end{verbatim} | |
% | |
The built-in function {\tt cmp} has the same interface as | |
the method \verb"__cmp__": it takes two values and returns | |
a positive number if the first is larger, a negative number | |
if the second is larger, and 0 if they are equal. | |
\index{cmp function} | |
\index{function!cmp} | |
In Python 3, {\tt cmp} no longer exists, and the \verb"__cmp__" | |
method is not supported. Instead you should provide \verb"__lt__", | |
which returns {\tt True} if {\tt self} is less than {\tt other}. | |
You can implement \verb"__lt__" using tuples and the \verb"<" | |
operator. | |
\begin{exercise} | |
Write a \verb"__cmp__" method for Time objects. Hint: you | |
can use tuple comparison, but you also might consider using | |
integer subtraction. | |
% def __cmp__(self, other): | |
% return time_to_int(self) - time_to_int(other) | |
%If {\tt self} is later than {\tt other}, the result is | |
%a positive number. If {\tt other} is later, the result | |
%is negative. And if {\tt self} and {\tt other} are equal | |
%(but not necessarily identical) | |
%the result is zero. | |
\end{exercise} | |
\section{Decks} | |
\index{list!of objects} | |
\index{deck, playing cards} | |
Now that we have Cards, the next step is to define Decks. Since a | |
deck is made up of cards, it is natural for each Deck to contain a | |
list of cards as an attribute. | |
\index{init method} | |
\index{method!init} | |
The following is a class definition for {\tt Deck}. The | |
init method creates the attribute {\tt cards} and generates | |
the standard set of fifty-two cards: | |
\index{composition} | |
\index{loop!nested} | |
\index{Deck class} | |
\index{class!Deck} | |
\begin{verbatim} | |
class Deck(object): | |
def __init__(self): | |
self.cards = [] | |
for suit in range(4): | |
for rank in range(1, 14): | |
card = Card(suit, rank) | |
self.cards.append(card) | |
\end{verbatim} | |
% | |
The easiest way to populate the deck is with a nested loop. The outer | |
loop enumerates the suits from 0 to 3. The inner loop enumerates the | |
ranks from 1 to 13. Each iteration | |
creates a new Card with the current suit and rank, | |
and appends it to {\tt self.cards}. | |
\index{append method} | |
\index{method!append} | |
\section{Printing the deck} | |
\label{printdeck} | |
\index{str method@\_\_str\_\_ method} | |
\index{method!\_\_str\_\_} | |
Here is a \verb"__str__" method for {\tt Deck}: | |
\begin{verbatim} | |
#inside class Deck: | |
def __str__(self): | |
res = [] | |
for card in self.cards: | |
res.append(str(card)) | |
return '\n'.join(res) | |
\end{verbatim} | |
% | |
This method demonstrates an efficient way to accumulate a large | |
string: building a list of strings and then using {\tt join}. | |
The built-in function {\tt str} invokes the \verb"__str__" | |
method on each card and returns the string representation. | |
\index{accumulator!string} | |
\index{string!accumulator} | |
\index{join method} | |
\index{method!join} | |
\index{newline} | |
Since we invoke {\tt join} on a newline character, the cards | |
are separated by newlines. Here's what the result looks like: | |
\begin{verbatim} | |
>>> deck = Deck() | |
>>> print deck | |
Ace of Clubs | |
2 of Clubs | |
3 of Clubs | |
... | |
10 of Spades | |
Jack of Spades | |
Queen of Spades | |
King of Spades | |
\end{verbatim} | |
% | |
Even though the result appears on 52 lines, it is | |
one long string that contains newlines. | |
\section{Add, remove, shuffle and sort} | |
To deal cards, we would like a method that | |
removes a card from the deck and returns it. | |
The list method {\tt pop} provides a convenient way to do that: | |
\index{pop method} | |
\index{method!pop} | |
\begin{verbatim} | |
#inside class Deck: | |
def pop_card(self): | |
return self.cards.pop() | |
\end{verbatim} | |
% | |
Since {\tt pop} removes the {\em last} card in the list, we are | |
dealing from the bottom of the deck. In real life ``bottom dealing'' is | |
frowned upon, | |
but in this context it's ok. | |
\index{append method} | |
\index{method!append} | |
To add a card, we can use the list method {\tt append}: | |
\begin{verbatim} | |
#inside class Deck: | |
def add_card(self, card): | |
self.cards.append(card) | |
\end{verbatim} | |
% | |
A method like this that uses another function without doing | |
much real work is sometimes called a {\bf veneer}. The metaphor | |
comes from woodworking, where it is common to glue a thin | |
layer of good quality wood to the surface of a cheaper piece of | |
wood. | |
\index{veneer} | |
In this case we are defining a ``thin'' method that expresses | |
a list operation in terms that are appropriate for decks. | |
As another example, we can write a Deck method named {\tt shuffle} | |
using the function {\tt shuffle} from the {\tt random} module: | |
\index{random module} | |
\index{module!random} | |
\index{shuffle function} | |
\index{function!shuffle} | |
\begin{verbatim} | |
# inside class Deck: | |
def shuffle(self): | |
random.shuffle(self.cards) | |
\end{verbatim} | |
% | |
Don't forget to import {\tt random}. | |
\begin{exercise} | |
\index{sort method} | |
\index{method!sort} | |
Write a Deck method named {\tt sort} that uses the list method | |
{\tt sort} to sort the cards in a {\tt Deck}. {\tt sort} uses | |
the \verb"__cmp__" method we defined to determine sort order. | |
\end{exercise} | |
\section{Inheritance} | |
\index{inheritance} | |
\index{object-oriented programming} | |
The language feature most often associated with object-oriented | |
programming is {\bf inheritance}. Inheritance is the ability to | |
define a new class that is a modified version of an existing | |
class. | |
\index{parent class} | |
\index{child class} | |
\index{class!child} | |
\index{subclass} | |
\index{superclass} | |
It is called ``inheritance'' because the new class inherits the | |
methods of the existing class. Extending this metaphor, the existing | |
class is called the {\bf parent} and the new class is | |
called the {\bf child}. | |
As an example, let's say we want a class to represent a ``hand,'' | |
that is, the set of cards held by one player. A hand is similar to a | |
deck: both are made up of a set of cards, and both require operations | |
like adding and removing cards. | |
A hand is also different from a deck; there are operations we want for | |
hands that don't make sense for a deck. For example, in poker we | |
might compare two hands to see which one wins. In bridge, we might | |
compute a score for a hand in order to make a bid. | |
This relationship between classes---similar, but different---lends | |
itself to inheritance. | |
The definition of a child class is like other class definitions, | |
but the name of the parent class appears in parentheses: | |
\index{parentheses!parent class in} | |
\index{parent class} | |
\index{class!parent} | |
\index{Hand class} | |
\index{class!Hand} | |
\begin{verbatim} | |
class Hand(Deck): | |
"""Represents a hand of playing cards.""" | |
\end{verbatim} | |
% | |
This definition indicates that {\tt Hand} inherits from {\tt Deck}; | |
that means we can use methods like \verb"pop_card" and \verb"add_card" | |
for Hands as well as Decks. | |
{\tt Hand} also inherits \verb"__init__" from {\tt Deck}, but | |
it doesn't really do what we want: instead of populating the hand | |
with 52 new cards, the init method for Hands should initialize | |
{\tt cards} with an empty list. | |
\index{override} | |
\index{init method} | |
\index{method!init} | |
If we provide an init method in the {\tt Hand} class, it overrides the | |
one in the {\tt Deck} class: | |
\begin{verbatim} | |
# inside class Hand: | |
def __init__(self, label=''): | |
self.cards = [] | |
self.label = label | |
\end{verbatim} | |
% | |
So when you create a Hand, Python invokes this init method: | |
\begin{verbatim} | |
>>> hand = Hand('new hand') | |
>>> print hand.cards | |
[] | |
>>> print hand.label | |
new hand | |
\end{verbatim} | |
% | |
But the other methods are inherited from {\tt Deck}, so we can use | |
\verb"pop_card" and \verb"add_card" to deal a card: | |
\begin{verbatim} | |
>>> deck = Deck() | |
>>> card = deck.pop_card() | |
>>> hand.add_card(card) | |
>>> print hand | |
King of Spades | |
\end{verbatim} | |
% | |
A natural next step is to encapsulate this code in a method | |
called \verb"move_cards": | |
\index{encapsulation} | |
\begin{verbatim} | |
#inside class Deck: | |
def move_cards(self, hand, num): | |
for i in range(num): | |
hand.add_card(self.pop_card()) | |
\end{verbatim} | |
% | |
\verb"move_cards" takes two arguments, a Hand object and the number of | |
cards to deal. It modifies both {\tt self} and {\tt hand}, and | |
returns {\tt None}. | |
In some games, cards are moved from one hand to another, | |
or from a hand back to the deck. You can use \verb"move_cards" | |
for any of these operations: {\tt self} can be either a Deck | |
or a Hand, and {\tt hand}, despite the name, can also be a {\tt Deck}. | |
\begin{exercise} | |
Write a Deck method called \verb"deal_hands" that takes two | |
parameters, the number of hands and the number of cards per | |
hand, and that creates new Hand objects, deals the appropriate | |
number of cards per hand, and returns a list of Hand objects. | |
\end{exercise} | |
Inheritance is a useful feature. Some programs that would be | |
repetitive without inheritance can be written more elegantly | |
with it. Inheritance can facilitate code reuse, since you can | |
customize the behavior of parent classes without having to modify | |
them. In some cases, the inheritance structure reflects the natural | |
structure of the problem, which makes the program easier to | |
understand. | |
On the other hand, inheritance can make programs difficult to read. | |
When a method is invoked, it is sometimes not clear where to find its | |
definition. The relevant code may be scattered among several modules. | |
Also, many of the things that can be done using inheritance can be | |
done as well or better without it. | |
\section{Class diagrams} | |
\label{class.diagram} | |
So far we have seen stack diagrams, which show the state of | |
a program, and object diagrams, which show the attributes | |
of an object and their values. These diagrams represent a snapshot | |
in the execution of a program, so they change as the program | |
runs. | |
They are also highly detailed; for some purposes, too | |
detailed. A class diagram is a more abstract representation | |
of the structure of a program. Instead of showing individual | |
objects, it shows classes and the relationships between them. | |
There are several kinds of relationship between classes: | |
\begin{itemize} | |
\item Objects in one class might contain references to objects | |
in another class. For example, each Rectangle contains a reference | |
to a Point, and each Deck contains references to many Cards. | |
This kind of relationship is called {\bf HAS-A}, as in, ``a Rectangle | |
has a Point.'' | |
\item One class might inherit from another. This relationship | |
is called {\bf IS-A}, as in, ``a Hand is a kind of a Deck.'' | |
\item One class might depend on another in the sense that changes | |
in one class would require changes in the other. | |
\end{itemize} | |
\index{IS-A relationship} | |
\index{HAS-A relationship} | |
\index{class diagram} | |
\index{diagram!class} | |
A {\bf class diagram} is a graphical representation of these | |
relationships. For example, Figure~\ref{fig.class1} shows the | |
relationships between {\tt Card}, {\tt Deck} and {\tt Hand}. | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.8]{figs/class1.pdf}} | |
\caption{Class diagram.} | |
\label{fig.class1} | |
\end{figure} | |
The arrow with a hollow triangle head represents an IS-A | |
relationship; in this case it indicates that Hand inherits | |
from Deck. | |
The standard arrow head represents a HAS-A | |
relationship; in this case a Deck has references to Card | |
objects. | |
\index{multiplicity (in class diagram)} | |
The star ({\tt *}) near the arrow head is a | |
{\bf multiplicity}; it indicates how many Cards a Deck has. | |
A multiplicity can be a simple number, like {\tt 52}, a range, | |
like {\tt 5..7} or a star, which indicates that a Deck can | |
have any number of Cards. | |
A more detailed diagram might show that a Deck actually | |
contains a {\em list} of Cards, but built-in types | |
like list and dict are usually not included in class diagrams. | |
\begin{exercise} | |
Read {\tt TurtleWorld.py}, {\tt World.py} and {\tt Gui.py} | |
and draw a class diagram that shows the relationships among | |
the classes defined there. | |
\end{exercise} | |
\section{Debugging} | |
\index{debugging} | |
Inheritance can make debugging a challenge because when you | |
invoke a method on an object, you might not know which method | |
will be invoked. | |
\index{polymorphism} | |
Suppose you are writing a function that works with Hand objects. | |
You would like it to work with all kinds of Hands, like | |
PokerHands, BridgeHands, etc. If you invoke a method like | |
{\tt shuffle}, you might get the one defined in {\tt Deck}, | |
but if any of the subclasses override this method, you'll | |
get that version instead. | |
\index{flow of execution} | |
Any time you are unsure about the flow of execution through your | |
program, the simplest solution is to add print statements at the | |
beginning of the relevant methods. If {\tt Deck.shuffle} prints a | |
message that says something like {\tt Running Deck.shuffle}, then as | |
the program runs it traces the flow of execution. | |
As an alternative, you could use this function, which takes an | |
object and a method name (as a string) and returns the class that | |
provides the definition of the method: | |
\begin{verbatim} | |
def find_defining_class(obj, meth_name): | |
for ty in type(obj).mro(): | |
if meth_name in ty.__dict__: | |
return ty | |
\end{verbatim} | |
% | |
Here's an example: | |
\begin{verbatim} | |
>>> hand = Hand() | |
>>> print find_defining_class(hand, 'shuffle') | |
<class 'Card.Deck'> | |
\end{verbatim} | |
% | |
So the {\tt shuffle} method for this Hand is the one in {\tt Deck}. | |
\index{mro method} | |
\index{method!mro} | |
\index{method resolution order} | |
\verb"find_defining_class" uses the {\tt mro} method to get the list | |
of class objects (types) that will be searched for methods. ``MRO'' | |
stands for ``method resolution order.'' | |
\index{override} | |
\index{interface} | |
\index{precondition} | |
\index{postcondition} | |
Here's a program design suggestion: whenever you override a method, | |
the interface of the new method should be the same as the old. It | |
should take the same parameters, return the same type, and obey the | |
same preconditions and postconditions. If you obey this rule, you | |
will find that any function designed to work with an instance of a | |
superclass, like a Deck, will also work with instances of subclasses | |
like a Hand or PokerHand. | |
If you violate this rule, your code will collapse like (sorry) | |
a house of cards. | |
\section{Data encapsulation} | |
Chapter~\ref{time} demonstrates a development plan we might call | |
``object-oriented design.'' We identified objects we needed---{\tt | |
Time}, {\tt Point} and {\tt Rectangle}---and defined classes to | |
represent them. In each case there is an obvious correspondence | |
between the object and some entity in the real world (or at least a | |
mathematical world). | |
\index{development plan} | |
But sometimes it is less obvious what objects you need | |
and how they should interact. In that case you need a different | |
development plan. In the same way that we discovered function | |
interfaces by encapsulation and generalization, we can discover | |
class interfaces by {\bf data encapsulation}. | |
\index{data encapsulation} | |
\index{encapsulation!data} | |
Markov analysis, from Section~\ref{markov}, provides a good example. | |
If you download my code from \url{http://thinkpython.com/code/markov.py}, | |
you'll see that it uses two global variables---\verb"suffix_map" and | |
\verb"prefix"---that are read and written from several functions. | |
\begin{verbatim} | |
suffix_map = {} | |
prefix = () | |
\end{verbatim} | |
Because these variables are global | |
we can only run one analysis | |
at a time. If we read two texts, their prefixes and suffixes would | |
be added to the same data structures (which makes for some interesting | |
generated text). | |
To run multiple analyses, and keep them separate, we can encapsulate | |
the state of each analysis in an object. | |
Here's what that looks like: | |
\begin{verbatim} | |
class Markov(object): | |
def __init__(self): | |
self.suffix_map = {} | |
self.prefix = () | |
\end{verbatim} | |
Next, we transform the functions into methods. For example, | |
here's \verb"process_word": | |
\begin{verbatim} | |
def process_word(self, word, order=2): | |
if len(self.prefix) < order: | |
self.prefix += (word,) | |
return | |
try: | |
self.suffix_map[self.prefix].append(word) | |
except KeyError: | |
# if there is no entry for this prefix, make one | |
self.suffix_map[self.prefix] = [word] | |
self.prefix = shift(self.prefix, word) | |
\end{verbatim} | |
Transforming a program like this---changing the design without | |
changing the function---is another example of refactoring | |
(see Section~\ref{refactoring}). | |
\index{refactoring} | |
This example suggests a development plan for designing objects and | |
methods: | |
\begin{enumerate} | |
\item Start by writing functions that read and write global | |
variables (when necessary). | |
\item Once you get the program working, look for associations | |
between global variables and the functions that use them. | |
\item Encapsulate related variables as attributes of an object. | |
\item Transform the associated functions into methods of the new | |
class. | |
\end{enumerate} | |
\begin{exercise} | |
Download my code from Section~\ref{markov} | |
(\url{http://thinkpython.com/code/markov.py}), and follow the steps described | |
above to encapsulate the global variables as attributes of a new class | |
called {\tt Markov}. Solution: \url{http://thinkpython.com/code/Markov.py} | |
(note the capital M). | |
\end{exercise} | |
\section{Glossary} | |
\begin{description} | |
\item[encode:] To represent one set of values using another | |
set of values by constructing a mapping between them. | |
\index{encode} | |
\item[class attribute:] An attribute associated with a class | |
object. Class attributes are defined inside | |
a class definition but outside any method. | |
\index{class attribute} | |
\index{attribute!class} | |
\item[instance attribute:] An attribute associated with an | |
instance of a class. | |
\index{instance attribute} | |
\index{attribute!instance} | |
\item[veneer:] A method or function that provides a different | |
interface to another function without doing much computation. | |
\index{veneer} | |
\item[inheritance:] The ability to define a new class that is a | |
modified version of a previously defined class. | |
\index{inheritance} | |
\item[parent class:] The class from which a child class inherits. | |
\index{parent class} | |
\item[child class:] A new class created by inheriting from an | |
existing class; also called a ``subclass.'' | |
\index{child class} | |
\index{class!child} | |
\item[IS-A relationship:] The relationship between a child class | |
and its parent class. | |
\index{IS-A relationship} | |
\item[HAS-A relationship:] The relationship between two classes | |
where instances of one class contain references to instances of | |
the other. | |
\index{HAS-A relationship} | |
\item[class diagram:] A diagram that shows the classes in a program | |
and the relationships between them. | |
\index{class diagram} | |
\index{diagram!class} | |
\item[multiplicity:] A notation in a class diagram that shows, for | |
a HAS-A relationship, how many references there are to instances | |
of another class. | |
\index{multiplicity (in class diagram)} | |
\end{description} | |
\section{Exercises} | |
\begin{exercise} | |
\label{poker} | |
The following are the possible hands in poker, in increasing order | |
of value (and decreasing order of probability): | |
\index{poker} | |
\begin{description} | |
\item[pair:] two cards with the same rank | |
\vspace{-0.05in} | |
\item[two pair:] two pairs of cards with the same rank | |
\vspace{-0.05in} | |
\item[three of a kind:] three cards with the same rank | |
\vspace{-0.05in} | |
\item[straight:] five cards with ranks in sequence (aces can | |
be high or low, so {\tt Ace-2-3-4-5} is a straight and so is {\tt | |
10-Jack-Queen-King-Ace}, but {\tt Queen-King-Ace-2-3} is not.) | |
\vspace{-0.05in} | |
\item[flush:] five cards with the same suit | |
\vspace{-0.05in} | |
\item[full house:] three cards with one rank, two cards with another | |
\vspace{-0.05in} | |
\item[four of a kind:] four cards with the same rank | |
\vspace{-0.05in} | |
\item[straight flush:] five cards in sequence (as defined above) and | |
with the same suit | |
\vspace{-0.05in} | |
\end{description} | |
% | |
The goal of these exercises is to estimate | |
the probability of drawing these various hands. | |
\begin{enumerate} | |
\item Download the following files from \url{http://thinkpython.com/code}: | |
\begin{description} | |
\item[{\tt Card.py}]: A complete version of the {\tt Card}, | |
{\tt Deck} and {\tt Hand} classes in this chapter. | |
\item[{\tt PokerHand.py}]: An incomplete implementation of a class | |
that represents a poker hand, and some code that tests it. | |
\end{description} | |
% | |
\item If you run {\tt PokerHand.py}, it deals seven 7-card poker hands | |
and checks to see if any of them contains a flush. Read this | |
code carefully before you go on. | |
\item Add methods to {\tt PokerHand.py} named \verb"has_pair", | |
\verb"has_twopair", etc. that return True or False according to | |
whether or not the hand meets the relevant criteria. Your code should | |
work correctly for ``hands'' that contain any number of cards | |
(although 5 and 7 are the most common sizes). | |
\item Write a method named {\tt classify} that figures out | |
the highest-value classification for a hand and sets the | |
{\tt label} attribute accordingly. For example, a 7-card hand | |
might contain a flush and a pair; it should be labeled ``flush''. | |
\item When you are convinced that your classification methods are | |
working, the next step is to estimate the probabilities of the various | |
hands. Write a function in {\tt PokerHand.py} that shuffles a deck of | |
cards, divides it into hands, classifies the hands, and counts the | |
number of times various classifications appear. | |
\item Print a table of the classifications and their probabilities. | |
Run your program with larger and larger numbers of hands until the | |
output values converge to a reasonable degree of accuracy. Compare | |
your results to the values at \url{http://en.wikipedia.org/wiki/Hand_rankings}. | |
\end{enumerate} | |
Solution: \url{http://thinkpython.com/code/PokerHandSoln.py}. | |
\end{exercise} | |
\begin{exercise} | |
\index{Swampy} | |
\index{TurtleWorld} | |
This exercise uses TurtleWorld from Chapter~\ref{turtlechap}. | |
You will write code that makes Turtles play tag. If you | |
are not familiar with the rules of tag, see | |
\url{http://en.wikipedia.org/wiki/Tag_(game)}. | |
\begin{enumerate} | |
\item Download \url{http://thinkpython.com/code/Wobbler.py} and run it. You | |
should see a TurtleWorld with three Turtles. If you press the | |
{\sf Run} button, the Turtles wander at random. | |
\item Read the code and make sure you understand how it works. | |
The {\tt Wobbler} class inherits from {\tt Turtle}, which means | |
that the {\tt Turtle} methods {\tt lt}, {\tt rt}, {\tt fd} | |
and {\tt bk} work on Wobblers. | |
The {\tt step} method gets invoked by TurtleWorld. It invokes | |
{\tt steer}, which turns the Turtle in the desired direction, | |
{\tt wobble}, which makes a random turn in proportion to the Turtle's | |
clumsiness, and {\tt move}, which moves forward a few pixels, | |
depending on the Turtle's speed. | |
\index{Tagger} | |
\item Create a file named {\tt Tagger.py}. Import everything from | |
{\tt Wobbler}, then define a class named {\tt Tagger} that inherits | |
from {\tt Wobbler}. Call \verb"make_world" passing the {\tt | |
Tagger} class object as an argument. | |
\item Add a {\tt steer} method to {\tt Tagger} to override the one in | |
{\tt Wobbler}. As a starting place, write a version that always | |
points the Turtle toward the origin. Hint: use the math function | |
{\tt atan2} and the Turtle attributes {\tt x}, {\tt y} and | |
{\tt heading}. | |
\item Modify {\tt steer} so that the Turtles stay in bounds. | |
For debugging, you might want to use the {\sf Step} button, | |
which invokes {\tt step} once on each Turtle. | |
\item Modify {\tt steer} so that each Turtle points toward its nearest | |
neighbor. Hint: Turtles have an attribute, {\tt world}, that is a | |
reference to the TurtleWorld they live in, and the TurtleWorld has | |
an attribute, {\tt animals}, that is a list of all Turtles in the | |
world. | |
\item Modify {\tt steer} so the Turtles play tag. You can add methods | |
to {\tt Tagger} and you can override {\tt steer} and | |
\verb"__init__", but you may not modify or override {\tt step}, {\tt | |
wobble} or {\tt move}. Also, {\tt steer} is allowed to change the | |
heading of the Turtle but not the position. | |
Adjust the rules and your {\tt steer} method for good quality play; | |
for example, it should be possible for the slow Turtle to tag the | |
faster Turtles eventually. | |
\end{enumerate} | |
Solution: \url{http://thinkpython.com/code/Tagger.py}. | |
\end{exercise} | |
\chapter{Case study: Tkinter} | |
\label{tkinter} | |
\section{GUI} | |
Most of the programs we have seen so far are text-based, but | |
many programs use {\bf graphical user interfaces}, also | |
known as {\bf GUIs}. | |
\index{GUI} | |
\index{graphical user interface} | |
\index{Tkinter} | |
Python provides several choices for writing GUI-based programs, | |
including wxPython, Tkinter, and Qt. Each has pros and cons, which | |
is why Python has not converged on a standard. | |
The one I will present in this chapter is Tkinter because I think | |
it is the easiest to get started with. Most of the concepts | |
in this chapter apply to the other GUI modules, too. | |
There are several books and web pages about Tkinter. One of | |
the best online resources is {\em An Introduction to Tkinter} | |
by Fredrik Lundh. | |
\index{Gui module} | |
\index{module!Gui} | |
\index{Swampy} | |
I have written a module called {\tt Gui.py} that comes with | |
Swampy. It provides a simplified interface to the functions | |
and classes in Tkinter. The examples in this chapter are | |
based on this module. | |
Here is a simple example that creates and displays a Gui: | |
To create a GUI, you have to import {\tt Gui} from Swampy: | |
% | |
\begin{verbatim} | |
from swampy.Gui import * | |
\end{verbatim} | |
% | |
Or, depending on how you installed Swampy, like this: | |
% | |
\begin{verbatim} | |
from Gui import * | |
\end{verbatim} | |
% | |
Then instantiate a Gui object: | |
% | |
\begin{verbatim} | |
g = Gui() | |
g.title('Gui') | |
g.mainloop() | |
\end{verbatim} | |
% | |
When you run this code, a window should appear with an empty gray | |
square and the title {\sf Gui}. {\tt mainloop} runs the {\bf event | |
loop}, which waits for the user to do something and responds | |
accordingly. It is an infinite loop; it runs until the user closes | |
the window, or presses Control-C, or does something that causes the | |
program to quit. | |
\index{event loop} | |
\index{loop!event} | |
\index{infinite loop} | |
\index{loop!infinite} | |
This Gui doesn't do much because it doesn't have any | |
{\bf widgets}. Widgets are the elements that make up a | |
GUI; they include: | |
\index{widget} | |
\begin{description} | |
\item[Button:] A widget, containing text or an image, that | |
performs an action when pressed. | |
\item[Canvas:] A region that can display lines, rectangles, | |
circles and other shapes. | |
\item[Entry:] A region where users can type text. | |
\item[Scrollbar:] A widget that controls the visible part of another | |
widget. | |
\item[Frame:] A container, often invisible, that contains other | |
widgets. | |
\end{description} | |
The empty gray square you see when you create a Gui is | |
a Frame. When you create a new widget, it is added to this Frame. | |
\section{Buttons and callbacks} | |
\index{Button widget} | |
\index{widget!Button} | |
The method {\tt bu} creates a Button widget: | |
\begin{verbatim} | |
button = g.bu(text='Press me.') | |
\end{verbatim} | |
% | |
The return value from {\tt bu} is a Button object. The button | |
that appears in the Frame is a graphical representation of this | |
object; you can control the button by invoking methods on it. | |
\index{option} | |
{\tt bu} takes up to 32 parameters that control the appearance | |
and function of the button. These parameters are called | |
{\bf options}. Instead of providing values for all 32 options, | |
you can use keyword arguments, like \verb"text='Press me.'", | |
to specify only the options you need and use the default | |
values for the rest. | |
\index{keyword argument} | |
\index{argument!keyword} | |
When you add a widget to the Frame, it gets ``shrink-wrapped;'' | |
that is, the Frame shrinks to the size of the Button. If you | |
add more widgets, the Frame grows to accommodate them. | |
\index{Label widget} | |
\index{widget!Label} | |
The method {\tt la} creates a Label widget: | |
\begin{verbatim} | |
label = g.la(text='Press the button.') | |
\end{verbatim} | |
% | |
By default, Tkinter stacks the widgets top-to-bottom and centers | |
them. We'll see how to override that behavior soon. | |
If you press the button, you will see that it doesn't do much. | |
That's because you haven't ``wired it up;'' that is, you haven't | |
told it what to do! | |
The option that controls the behavior of a button is {\tt command}. | |
The value of {\tt command} is a function that gets executed when | |
the button is pressed. For example, here is a function that creates | |
a new Label: | |
\begin{verbatim} | |
def make_label(): | |
g.la(text='Thank you.') | |
\end{verbatim} | |
% | |
Now we can create a button with this function as its command: | |
\begin{verbatim} | |
button2 = g.bu(text='No, press me!', command=make_label) | |
\end{verbatim} | |
% | |
When you press this button, it should execute \verb"make_label" | |
and a new label should appear. | |
\index{callback} | |
The value of the {\tt command} option | |
is a function object, which is known as a {\bf callback} because | |
after you call {\tt bu} to create the button, the flow of execution | |
``calls back'' when the user presses the button. | |
\index{event-driven programming} | |
This kind of flow is characteristic of {\bf event-driven programming}. | |
User actions, like button presses and key strokes, are called {\bf | |
events}. In event-driven programming, the flow of execution is | |
determined by user actions rather than by the programmer. | |
The challenge of event-driven programming is to construct a set of | |
widgets and callbacks that work correctly (or at least generate | |
appropriate error messages) for any sequence of user actions. | |
\begin{exercise} | |
Write a program that creates a GUI with a single button. When the | |
button is pressed it should create a second button. When | |
{\em that} button is pressed, it should create a label that | |
says, ``Nice job!''. | |
What happens if you press the buttons more than once? | |
Solution: \url{http://thinkpython.com/code/button_demo.py} | |
\end{exercise} | |
\section{Canvas widgets} | |
\index{Canvas widget} | |
\index{widget!Canvas} | |
One of the most versatile widgets is the Canvas, which creates | |
a region for drawing lines, circles and other shapes. If you | |
did Exercise~\ref{canvas} you are already familiar with canvases. | |
The method {\tt ca} creates a new Canvas: | |
\begin{verbatim} | |
canvas = g.ca(width=500, height=500) | |
\end{verbatim} | |
% | |
{\tt width} and {\tt height} are the dimensions of the canvas | |
in pixels. | |
\index{config method} | |
\index{method!config} | |
After you create a widget, you can still change the values of | |
the options with the | |
{\tt config} method. For example, the {\tt bg} option changes | |
the background color: | |
\begin{verbatim} | |
canvas.config(bg='white') | |
\end{verbatim} | |
% | |
The value of {\tt bg} is a string | |
that names a color. The set of legal color names is different | |
for different implementations of Python, but all implementations | |
provide at least: | |
\begin{verbatim} | |
white black | |
red green blue | |
cyan yellow magenta | |
\end{verbatim} | |
% | |
Shapes on a Canvas are called {\bf items}. For example, | |
the Canvas method {\tt circle} draws (you guessed it) a circle: | |
\index{Canvas item} | |
\index{item!Canvas} | |
\begin{verbatim} | |
item = canvas.circle([0,0], 100, fill='red') | |
\end{verbatim} | |
% | |
The first argument is a coordinate pair that specifies the | |
center of the circle; the second is the radius. | |
\index{Canvas coordinate} | |
\index{coordinate!Canvas} | |
{\tt Gui.py} provides a standard Cartesian coordinate system with | |
the origin at the center of the Canvas and the positive $y$ axis | |
pointing up. This is different from some other graphics systems | |
where the origin is in the upper left corner, with the $y$ axis | |
pointing down. | |
The {\tt fill} option specifies that the circle should be filled | |
in with red. | |
The return value from {\tt circle} is an Item object that | |
provides methods for modifying the item on the canvas. For | |
example, you can use {\tt config} to change any of the circle's | |
options: | |
\begin{verbatim} | |
item.config(fill='yellow', outline='orange', width=10) | |
\end{verbatim} | |
% | |
{\tt width} is the thickness of the outline in pixels; | |
{\tt outline} is the color. | |
\begin{exercise} | |
\label{circle} | |
Write a program that creates a Canvas and a Button. When the | |
user presses the Button, it should draw a circle on the canvas. | |
\end{exercise} | |
\section{Coordinate sequences} | |
\index{coordinate sequence} | |
\index{sequence!coordinate} | |
The {\tt rectangle} method takes a sequence of coordinates that | |
specify opposite corners of the rectangle. This example | |
draws a blue rectangle with the lower left corner at the origin | |
and the upper right corner at $(200,100)$: | |
\begin{verbatim} | |
canvas.rectangle([[0, 0], [200, 100]], | |
fill='blue', outline='orange', width=10) | |
\end{verbatim} | |
% | |
This way of specifying corners is called | |
a {\bf bounding box} because the two points | |
bound the rectangle. | |
\index{bounding box} | |
{\tt oval} takes a bounding box and draws an oval | |
within the specified rectangle: | |
\begin{verbatim} | |
canvas.oval([[0, 0], [200, 100]], outline='orange', width=10) | |
\end{verbatim} | |
% | |
{\tt line} takes a sequence of coordinates and draws | |
a line that connects the points. This example draws two legs | |
of a triangle: | |
\begin{verbatim} | |
canvas.line([[0, 100], [100, 200], [200, 100]], width=10) | |
\end{verbatim} | |
% | |
{\tt polygon} takes the same arguments, but it draws the last | |
leg of the polygon (if necessary) and fills it in: | |
\begin{verbatim} | |
canvas.polygon([[0, 100], [100, 200], [200, 100]], | |
fill='red', outline='orange', width=10) | |
\end{verbatim} | |
% | |
\section{More widgets} | |
\index{Text widget} | |
\index{widget!Text} | |
Tkinter provides two widgets that let users type text: an | |
Entry, which is a single line, and a Text widget, which has | |
multiple lines. | |
\index{Entry widget} | |
\index{widget!Entry} | |
{\tt en} creates a new Entry: | |
\begin{verbatim} | |
entry = g.en(text='Default text.') | |
\end{verbatim} | |
% | |
The {\tt text} option allows you to put text into the entry | |
when it is created. The {\tt get} method returns the contents | |
of the Entry (which may have been changed by the user): | |
\begin{verbatim} | |
>>> entry.get() | |
'Default text.' | |
\end{verbatim} | |
% | |
{\tt te} creates a Text widget: | |
\begin{verbatim} | |
text = g.te(width=100, height=5) | |
\end{verbatim} | |
% | |
{\tt width} and {\tt height} are the dimensions of the | |
widget in characters and lines. | |
{\tt insert} puts text into the Text widget: | |
\begin{verbatim} | |
text.insert(END, 'A line of text.') | |
\end{verbatim} | |
% | |
{\tt END} is a special index that indicates the last character in the | |
Text widget. | |
You can also specify a character using a dotted index, like {\tt 1.1}, | |
which has the line number before the dot and the column number after. | |
The following example adds the letters \verb"'nother'" after the first | |
character of the first line. | |
\begin{verbatim} | |
>>> text.insert(1.1, 'nother') | |
\end{verbatim} | |
% | |
The {\tt get} method reads the text in the widget; it takes a start | |
and end index as arguments. The following example returns all the | |
text in the widget, including the newline character: | |
\begin{verbatim} | |
>>> text.get(0.0, END) | |
'Another line of text.\n' | |
\end{verbatim} | |
% | |
The {\tt delete} method removes text from the widget; | |
the following example deletes all but the first two characters: | |
\begin{verbatim} | |
>>> text.delete(1.2, END) | |
>>> text.get(0.0, END) | |
'An\n' | |
\end{verbatim} | |
% | |
\begin{exercise} | |
\label{circle2} | |
Modify your solution to Exercise~\ref{circle} by adding an | |
Entry widget and a second button. When the user presses the | |
second button, it should read a color name from the Entry and | |
use it to change the fill color of the circle. Use {\tt config} | |
to modify the existing circle; don't create a new one. | |
Your program should handle the case where the user tries to | |
change the color of a circle that hasn't been created, and | |
the case where the color name is invalid. | |
You can see my solution at \url{http://thinkpython.com/code/circle_demo.py}. | |
\end{exercise} | |
\section{Packing widgets} | |
So far we have been stacking widgets in a single column, but in most | |
GUIs the layout is more complicated. For example, | |
Figure~\ref{fig.turtleworld} shows a simplified version of | |
TurtleWorld (see Chapter~\ref{turtlechap}). | |
\begin{figure} | |
\centerline{\includegraphics[scale=0.5]{figs/TurtleWorld.pdf}} | |
\caption{TurtleWorld after running the snowflake code.} | |
\label{fig.turtleworld} | |
\end{figure} | |
This section presents the code that creates this GUI, broken into a | |
series of steps. You can download the complete example | |
from \url{http://thinkpython.com/code/SimpleTurtleWorld.py}. | |
At the top level, this GUI contains two widgets---a Canvas and a | |
Frame---arranged in a row. So the first step is to create the row. | |
\index{SimpleTurtleWorld class} | |
\index{class!SimpleTurtleWorld} | |
\begin{verbatim} | |
class SimpleTurtleWorld(TurtleWorld): | |
"""This class is identical to TurtleWorld, but the code that | |
lays out the GUI is simplified for explanatory purposes.""" | |
def setup(self): | |
self.row() | |
... | |
\end{verbatim} | |
% | |
{\tt setup} is the function that creates and arranges the widgets. | |
Arranging widgets in a GUI is called {\bf packing}. | |
\index{packing widgets} | |
\index{widget, packing} | |
\index{Frame widget} | |
\index{widget!Frame} | |
{\tt row} creates a row Frame and makes it the ``current Frame.'' | |
Until this Frame is closed or another Frame is created, all | |
subsequent widgets are packed in a row. | |
Here is the code that creates the Canvas and the column Frame | |
that hold the other widgets: | |
\begin{verbatim} | |
self.canvas = self.ca(width=400, height=400, bg='white') | |
self.col() | |
\end{verbatim} | |
% | |
The first widget in the column is a grid Frame, which contains | |
four buttons arranged two-by-two: | |
\begin{verbatim} | |
self.gr(cols=2) | |
self.bu(text='Print canvas', command=self.canvas.dump) | |
self.bu(text='Quit', command=self.quit) | |
self.bu(text='Make Turtle', command=self.make_turtle) | |
self.bu(text='Clear', command=self.clear) | |
self.endgr() | |
\end{verbatim} | |
% | |
{\tt gr} creates the grid; the argument is the number of | |
columns. Widgets in the grid are | |
laid out left-to-right, top-to-bottom. | |
\index{callback} | |
\index{bound method} | |
\index{method, bound} | |
\index{subject} | |
The first button uses {\tt self.canvas.dump} as a callback; the second | |
uses {\tt self.quit}. These are {\bf bound methods}, which means they | |
are associated with a particular object. When they are invoked, they | |
are invoked on the object. | |
The next widget in the column is a row Frame that contains | |
a Button and an Entry: | |
\begin{verbatim} | |
self.row([0,1], pady=30) | |
self.bu(text='Run file', command=self.run_file) | |
self.en_file = self.en(text='snowflake.py', width=5) | |
self.endrow() | |
\end{verbatim} | |
% | |
The first argument to {\tt row} is a list of weights that | |
determines how extra space is allocated between widgets. | |
The list {\tt [0,1]} means that all extra space is allocated | |
to the second widget, which is the Entry. If you run this code | |
and resize the window, you will see that the Entry grows and | |
the Button doesn't. | |
The option {\tt pady} ``pads'' this row in the $y$ direction, | |
adding 30 pixels of space above and below. | |
{\tt endrow} ends this row of widgets, so subsequent widgets are | |
packed in the column Frame. {\tt Gui.py} keeps a stack of Frames: | |
\begin{itemize} | |
\item When you use {\tt row}, {\tt col} or {\tt gr} to create a Frame, | |
it goes on top of the stack and becomes the current Frame. | |
\item When you use {\tt endrow}, {\tt endcol} or {\tt endgr} to close | |
a Frame, it gets popped off the stack and the previous Frame on the | |
stack becomes the current Frame. | |
\end{itemize} | |
The method \verb"run_file" reads the contents of the Entry, | |
uses it as a filename, reads the contents | |
and passes it to \verb"run_code". {\tt self.inter} is an | |
Interpreter object that knows how to take a string and | |
execute it as Python code. | |
\begin{verbatim} | |
def run_file(self): | |
filename = self.en_file.get() | |
fp = open(filename) | |
source = fp.read() | |
self.inter.run_code(source, filename) | |
\end{verbatim} | |
% | |
The last two widgets are a Text widget and a Button: | |
\begin{verbatim} | |
self.te_code = self.te(width=25, height=10) | |
self.te_code.insert(END, 'world.clear()\n') | |
self.te_code.insert(END, 'bob = Turtle(world)\n') | |
self.bu(text='Run code', command=self.run_text) | |
\end{verbatim} | |
% | |
\verb"run_text" is similar to \verb"run_file" except that it takes | |
the code from the Text widget instead of from a file: | |
\begin{verbatim} | |
def run_text(self): | |
source = self.te_code.get(1.0, END) | |
self.inter.run_code(source, '<user-provided code>') | |
\end{verbatim} | |
% | |
Unfortunately, the details of widget layout are different in | |
other languages, and in different Python modules. | |
Tkinter alone provides three different mechanisms for arranging | |
widgets. These mechanisms are called {\bf geometry managers}. | |
The one I demonstrated in this section is the ``grid'' geometry | |
manager; the others are called ``pack'' and ``place''. | |
\index{geometry manager} | |
Fortunately, most of the concepts in this section apply to | |
other GUI modules and other languages. | |
\section{Menus and Callables} | |
\index{Menubutton widget} | |
\index{widget!Menubutton} | |
A Menubutton is a widget that looks like a button, but when pressed | |
it pops up a menu. After the user selects an item, the menu | |
disappears. | |
Here is code that creates a color selection Menubutton | |
(you can download it from \url{http://thinkpython.com/code/menubutton_demo.py}): | |
\begin{verbatim} | |
g = Gui() | |
g.la('Select a color:') | |
colors = ['red', 'green', 'blue'] | |
mb = g.mb(text=colors[0]) | |
\end{verbatim} | |
% | |
{\tt mb} creates the Menubutton. Initially, the text on the button is | |
the name of the default color. The following loop creates one menu | |
item for each color: | |
\begin{verbatim} | |
for color in colors: | |
g.mi(mb, text=color, command=Callable(set_color, color)) | |
\end{verbatim} | |
% | |
The first argument of {\tt mi} is the Menubutton these items are | |
associated with. | |
\index{callback} | |
\index{Callable object} | |
\index{object!Callable} | |
The {\tt command} option is a Callable object, which is something new. | |
So far we have seen functions and bound methods used as callbacks, | |
which works fine if you don't have to pass any arguments to | |
the function. Otherwise you have to construct a Callable object | |
that contains a function, like \verb"set_color", and its arguments, | |
like {\tt color}. | |
The Callable object stores a reference to the function and the | |
arguments as attributes. Later, when the user clicks on a menu | |
item, the callback calls the function and passes the stored | |
arguments. | |
Here is what \verb"set_color" might look like: | |
\begin{verbatim} | |
def set_color(color): | |
mb.config(text=color) | |
print color | |
\end{verbatim} | |
% | |
When the user selects a menu item and \verb"set_color" is called, | |
it configures the Menubutton to display the newly-selected color. | |
It also print the color; if you try this example, you can confirm that | |
\verb"set_color" is called when you select an item (and {\em not} | |
called when you create the Callable object). | |
\section{Binding} | |
\index{binding} | |
\index{callback} | |
A {\bf binding} is an association between a widget, an event and a | |
callback: when an event (like a button press) happens on a widget, the | |
callback is invoked. | |
Many widgets have default bindings. For example, when you press | |
a button, the default binding changes the relief of the button | |
to make it look depressed. When you release the button, the | |
binding restores the appearance of the button and invokes the | |
callback specified with the {\tt command} option. | |
You can use the {\tt bind} method to override these default | |
bindings or to add new ones. For example, this code creates a | |
binding for a canvas (you can download the code in this | |
section from \url{http://thinkpython.com/code/draggable_demo.py}): | |
\begin{verbatim} | |
ca.bind('<ButtonPress-1>', make_circle) | |
\end{verbatim} | |
% | |
The first argument is an event string; this event is triggered | |
when the user presses the left mouse button. Other mouse | |
events include {\tt ButtonMotion}, {\tt ButtonRelease} and | |
{\tt Double-Button}. | |
\index{event string} | |
\index{event handler} | |
The second argument is an event handler. An event handler | |
is a function or bound method, like a callback, but an important | |
difference is that an event handler takes an Event object as a | |
parameter. Here is an example: | |
\begin{verbatim} | |
def make_circle(event): | |
pos = ca.canvas_coords([event.x, event.y]) | |
item = ca.circle(pos, 5, fill='red') | |
\end{verbatim} | |
% | |
The Event object contains information about the type of event and | |
details like the coordinates of the mouse pointer. In this example | |
the information we need is | |
the location of the mouse click. These | |
values are in ``pixel coordinates,'' which are defined by the | |
underlying graphical system. The method \verb"canvas_coords" | |
translates them to ``Canvas coordinates,'' which are compatible with | |
Canvas methods like {\tt circle}. | |
\index{Event object} | |
\index{object!Event} | |
For Entry widgets, it is common to bind the \verb"<Return>" event, | |
which is triggered when the user presses the {\sf Return} or | |
{\sf Enter} key. For example, the following code creates a Button | |
and an Entry. | |
\begin{verbatim} | |
bu = g.bu('Make text item:', make_text) | |
en = g.en() | |
en.bind('<Return>', make_text) | |
\end{verbatim} | |
% | |
\verb"make_text" is called when the Button is pressed or when | |
the user hits {\sf Return} while typing in the Entry. To make | |
this work, we need a function that can be called as a command | |
(with no arguments) or as an event handler (with an Event | |
as an argument): | |
\begin{verbatim} | |
def make_text(event=None): | |
text = en.get() | |
item = ca.text([0,0], text) | |
\end{verbatim} | |
% | |
\verb"make_text" gets the contents of the Entry and displays | |
it as a Text item in the Canvas. | |
It is also possible to create bindings for Canvas items. | |
The following is a class definition for {\tt Draggable}, | |
which is a child class of {\tt Item} that provides bindings | |
that implement drag-and-drop capability. | |
\index{drag-and-drop} | |
\begin{verbatim} | |
class Draggable(Item): | |
def __init__(self, item): | |
self.canvas = item.canvas | |
self.tag = item.tag | |
self.bind('<Button-3>', self.select) | |
self.bind('<B3-Motion>', self.drag) | |
self.bind('<Release-3>', self.drop) | |
\end{verbatim} | |
% | |
The init method takes an Item as a parameter. It copies | |
the attributes of the Item and then creates bindings for | |
three events: a button press, button motion, and button release. | |
The event handler {\tt select} stores the coordinates | |
of the current event and the original color of the item, then | |
changes the color to yellow: | |
\begin{verbatim} | |
def select(self, event): | |
self.dragx = event.x | |
self.dragy = event.y | |
self.fill = self.cget('fill') | |
self.config(fill='yellow') | |
\end{verbatim} | |
% | |
{\tt cget} stands for ``get configuration;'' it takes the name of an | |
option as a string and returns the current value of that option. | |
{\tt drag} computes how far the object has moved relative to the | |
starting place, updates the stored coordinates, and then moves the | |
item. | |
\index{update!coordinate} | |
\begin{verbatim} | |
def drag(self, event): | |
dx = event.x - self.dragx | |
dy = event.y - self.dragy | |
self.dragx = event.x | |
self.dragy = event.y | |
self.move(dx, dy) | |
\end{verbatim} | |
% | |
This computation is done in pixel coordinates; there is no need to | |
convert to Canvas coordinates. | |
\index{Canvas coordinate} | |
\index{coordinate!Canvas} | |
\index{pixel coordinate} | |
\index{coordinate!pixel} | |
Finally, {\tt drop} restores the original color of the item: | |
\begin{verbatim} | |
def drop(self, event): | |
self.config(fill=self.fill) | |
\end{verbatim} | |
% | |
You can use the {\tt Draggable} class to add drag-and-drop | |
capability to an existing item. For example, here is a modified | |
version of \verb"make_circle" that uses {\tt circle} to create | |
an Item and {\tt Draggable} to make it draggable: | |
\begin{verbatim} | |
def make_circle(event): | |
pos = ca.canvas_coords([event.x, event.y]) | |
item = ca.circle(pos, 5, fill='red') | |
item = Draggable(item) | |
\end{verbatim} | |
% | |
This example demonstrates one of the benefits of inheritance: you can | |
modify the capabilities of a parent class without modifying its | |
definition. This is particularly useful if you want to change | |
behavior defined in a module you did not write. | |
\section{Debugging} | |
\index{debugging} | |
One of the challenges of GUI programming is keeping track of | |
which things happen while the GUI is being built and which | |
things happen later in response to user events. | |
\index{callback} | |
For example, when you are setting up a callback, it is a common error | |
to call the function rather than passing a reference to it: | |
\begin{verbatim} | |
def the_callback(): | |
print 'Called.' | |
g.bu(text='This is wrong!', command=the_callback()) | |
\end{verbatim} | |
% | |
If you run this code, you will see that it calls \verb"the_callback" | |
immediately, and {\em then} creates the button. When you press the | |
button, it does nothing because the return value from | |
\verb"the_callback" is {\tt None}. | |
Usually you do not want to invoke a callback while you are | |
setting up the GUI; it should only be invoked later in response to | |
a user event. | |
\index{flow of execution} | |
\index{event-driven programming} | |
Another challenge of GUI programming is that you don't have control | |
of the flow of execution. Which parts of the program execute | |
and their order are determined by user actions. | |
That means that you have to design your program to work correctly | |
for any possible sequence of events. | |
For example, the GUI in Exercise~\ref{circle2} has two widgets: | |
one creates a Circle item and the other changes the color of the | |
Circle. If the user creates the circle and then changes its color, | |
there's no problem. But what if the user changes the color of | |
a circle that doesn't exist yet? Or creates more than one circle? | |
As the number of widgets grows, it is increasingly difficult to | |
imagine all possible sequences of events. One way to manage this | |
complexity is to encapsulate the state of the system in an object | |
and then consider: | |
\begin{itemize} | |
\item What are the possible states? In the Circle example, we | |
might consider two states: before and after the user creates the | |
first circle. | |
\item In each state, what events can occur? In the example, | |
the user can press either of the buttons, or quit. | |
\item For each state-event pair, what is the desired outcome? | |
Since there are two states and two buttons, there are four | |
state-event pairs to consider. | |
\item What can cause a transition from one state to another? | |
In this case, there is a transition when the user creates | |
the first circle. | |
\end{itemize} | |
You might also find it useful to define, and check, invariants that | |
should hold regardless of the sequence of events. | |
\index{invariant} | |
This approach to GUI programming can help you write correct | |
code without taking the time to test every possible sequence | |
of user events! | |
\section{Glossary} | |
\begin{description} | |
\item[GUI:] A graphical user interface. | |
\index{GUI} | |
\item[widget:] One of the elements that makes up a GUI, including | |
buttons, menus, text entry fields, etc. | |
\index{widget} | |
\item[option:] A value that controls the appearance or function of | |
a widget. | |
\index{option} | |
\item[keyword argument:] An argument that indicates the parameter | |
name as part of the function call. | |
\index{keyword argument} | |
\item[callback:] A function associated with a widget that is | |
called when the user performs an action. | |
\index{callback} | |
\item[bound method:] A method associated with a particular instance. | |
\index{bound method} | |
\item[event-driven programming:] A style of programming in which | |
the flow of execution is determined by user actions. | |
\index{event-driven programming} | |
\item[event:] A user action, like a mouse click or key press, that | |
causes a GUI to respond. | |
\index{event} | |
\item[event loop:] An infinite loop that waits for user actions | |
and responds. | |
\index{event loop} | |
\item[item:] A graphical element on a Canvas widget. | |
\index{item!Canvas} | |
\item[bounding box:] A rectangle that encloses a set of items, | |
usually specified by two opposing corners. | |
\index{bounding box} | |
\item[pack:] To arrange and display the elements of a GUI. | |
\index{packing widgets} | |
\item[geometry manager:] A system for packing widgets. | |
\index{geometry manager} | |
\item[binding:] An association between a widget, an event, and | |
an event handler. The event handler is called when the event | |
occurs in the widget. | |
\index{binding} | |
\end{description} | |
\section{Exercises} | |
\begin{exercise} | |
\index{image viewer} | |
For this exercise, you will write an image viewer. Here is | |
a simple example: | |
\begin{verbatim} | |
g = Gui() | |
canvas = g.ca(width=300) | |
photo = PhotoImage(file='danger.gif') | |
canvas.image([0,0], image=photo) | |
g.mainloop() | |
\end{verbatim} | |
% | |
{\tt PhotoImage} reads a file and returns a {\tt PhotoImage} object | |
that Tkinter can display. {\tt Canvas.image} puts the image on the | |
canvas, centered on the given coordinates. You can also put images on | |
labels, buttons, and some other widgets: | |
\begin{verbatim} | |
g.la(image=photo) | |
g.bu(image=photo) | |
\end{verbatim} | |
% | |
PhotoImage can only handle a few image formats, like GIF and PPM, | |
but we can use the Python Imaging Library (PIL) to read other | |
files. | |
\index{Python Imaging Library (PIL)} | |
\index{PIL (Python Imaging Library)} | |
\index{Image module} | |
\index{module!Image} | |
The name of the PIL module is {\tt Image}, but Tkinter defines an | |
object with the same name. To avoid the conflict, you can use {\tt | |
import...as} like this: | |
\begin{verbatim} | |
import Image as PIL | |
import ImageTk | |
\end{verbatim} | |
% | |
The first line imports {\tt Image} and | |
gives it the local name {\tt PIL}. The second | |
line imports {\tt ImageTk}, which can translate a PIL | |
image into a Tkinter PhotoImage. Here's an example: | |
\begin{verbatim} | |
image = PIL.open('allen.png') | |
photo2 = ImageTk.PhotoImage(image) | |
g.la(image=photo2) | |
\end{verbatim} | |
% | |
\begin{enumerate} | |
\item Download \verb"image_demo.py", \verb"danger.gif" and \verb"allen.png" | |
from \url{http://thinkpython.com/code}. Run \verb"image_demo.py". You | |
might have to install {\tt PIL} and {\tt ImageTk}. | |
They are probably in your software repository, but if not | |
you can get them from \url{http://pythonware.com/products/pil}. | |
\item In \verb"image_demo.py" change the name of the second | |
PhotoImage from {\tt photo2} to {\tt photo} and run the program | |
again. You should see the second PhotoImage but not the first. | |
The problem is that when you reassign {\tt photo} it overwrites | |
the reference to the first PhotoImage, which then disappears. The | |
same thing happens if you assign a PhotoImage to a local | |
variable; it disappears when the function ends. | |
To avoid this problem, you have to store a reference to each | |
PhotoImage you want to keep. You can use a global variable, or | |
store PhotoImages in a data structure or as an attribute of | |
an object. | |
This behavior can be frustrating, which is why I am warning | |
you (and why the example image says ``Danger!''). | |
\index{bug!worst ever} | |
\index{worst bug!ever} | |
\item Starting with this example, write a program that takes | |
the name of a directory and loops through all the files, displaying | |
any files that PIL recognizes as images. You can use a {\tt try} | |
statement to catch the files PIL doesn't recognize. | |
When the user clicks on the image, the program should display the next one. | |
\item PIL provides a variety of methods for manipulating images. | |
You can read about them at \url{http://pythonware.com/library/pil/handbook}. | |
As a challenge, choose a few of these methods and provide a | |
GUI for applying them to images. | |
\end{enumerate} | |
Solution: \url{http://thinkpython.com/code/ImageBrowser.py}. | |
\end{exercise} | |
\begin{exercise} | |
\index{vector graphics} | |
\index{SVG} | |
A vector graphics editor is a program that allows users to draw and | |
edit shapes on the screen and generate output files in vector graphics | |
formats like Postscript and SVG. | |
Write a simple vector graphics editor using Tkinter. At a | |
minimum, it should allow users to draw lines, circles and | |
rectangles, and it should use {\tt Canvas.dump} to | |
generate a Postscript description of the contents of the | |
Canvas. | |
As a challenge, you could allow users to select and resize | |
items on the Canvas. | |
% TODO: write a solution! | |
\end{exercise} | |
\begin{exercise} | |
Use Tkinter to write a basic web browser. It | |
should have a Text widget where the user can enter a URL | |
and a Canvas to display the contents of the page. | |
\index{urllib module} | |
\index{module!urllib} | |
\index{URL} | |
\index{HTMLParser module} | |
\index{module!HTMLParser} | |
You can use the {\tt urllib} module to download files | |
(see Exercise~\ref{urllib}) and | |
the {\tt HTMLParser} module to parse the HTML | |
tags (see \url{http://docs.python.org/2/library/htmlparser.html}). | |
\index{plain text} | |
\index{text!plain} | |
\index{hyperlink} | |
At a minimum your browser should handle plain text and hyperlinks. As | |
a challenge you could handle background colors, text | |
formatting tags and images. | |
% TODO: write a solution! | |
\end{exercise} | |
\appendix | |
\chapter{Debugging} | |
\index{debugging} | |
Different kinds of errors can occur | |
in a program, and it is useful to distinguish among them | |
in order to track them down more quickly: | |
\begin{itemize} | |
\item Syntax errors are produced by Python when it is translating the | |
source code into byte code. They usually indicate that there is | |
something wrong with the syntax of the program. Example: Omitting | |
the colon at the end of a {\tt def} statement yields the somewhat | |
redundant message {\tt SyntaxError: invalid syntax}. | |
\item Runtime errors are produced by the interpreter if something goes | |
wrong while the program is running. Most runtime error messages | |
include information about where the error occurred and what | |
functions were executing. Example: An infinite recursion eventually | |
causes the runtime error ``maximum recursion depth exceeded.'' | |
\item Semantic errors are problems with a program that runs without | |
producing error messages but doesn't do the right thing. Example: | |
An expression may not be evaluated in the order you expect, yielding | |
an incorrect result. | |
\end{itemize} | |
\index{syntax error} | |
\index{runtime error} | |
\index{semantic error} | |
\index{error!compile-time} | |
\index{error!syntax} | |
\index{error!runtime} | |
\index{error!semantic} | |
\index{exception} | |
The first step in debugging is to figure out which kind of | |
error you are dealing with. Although the following sections are | |
organized by error type, some techniques are | |
applicable in more than one situation. | |
\section{Syntax errors} | |
\index{error message} | |
Syntax errors are usually easy to fix once you figure out what they | |
are. Unfortunately, the error messages are often not helpful. | |
The most common messages are {\tt SyntaxError: invalid syntax} and | |
{\tt SyntaxError: invalid token}, neither of which is very informative. | |
On the other hand, the message does tell you where in the program the | |
problem occurred. Actually, it tells you where Python | |
noticed a problem, which is not necessarily where the error | |
is. Sometimes the error is prior to the location of the error | |
message, often on the preceding line. | |
\index{incremental development} | |
\index{development plan!incremental} | |
If you are building the program incrementally, you should have | |
a good idea about where the error is. It will be in the last | |
line you added. | |
If you are copying code from a book, start by comparing | |
your code to the book's code very carefully. Check every character. | |
At the same time, remember that the book might be wrong, so | |
if you see something that looks like a syntax error, it might be. | |
Here are some ways to avoid the most common syntax errors: | |
\index{syntax} | |
\begin{enumerate} | |
\item Make sure you are not using a Python keyword for a variable name. | |
\index{keyword} | |
\item Check that you have a colon at the end of the header of every | |
compound statement, including {\tt for}, {\tt while}, | |
{\tt if}, and {\tt def} statements. | |
\index{header} | |
\index{colon} | |
\item Make sure that any strings in the code have matching | |
quotation marks. | |
\index{quotation mark} | |
\item If you have multiline strings with triple quotes (single or double), make | |
sure you have terminated the string properly. An unterminated string | |
may cause an {\tt invalid token} error at the end of your program, | |
or it may treat the following part of the program as a string until it | |
comes to the next string. In the second case, it might not produce an error | |
message at all! | |
\index{multiline string} | |
\index{string!multiline} | |
\item An unclosed opening operator---\verb+(+, \verb+{+, or | |
\verb+[+---makes Python continue with the next line as part of the | |
current statement. Generally, an error occurs almost immediately in | |
the next line. | |
\item Check for the classic {\tt =} instead of {\tt ==} inside | |
a conditional. | |
\index{conditional} | |
\item Check the indentation to make sure it lines up the way it | |
is supposed to. Python can handle space and tabs, but if you mix | |
them it can cause problems. The best way to avoid this problem | |
is to use a text editor that knows about Python and generates | |
consistent indentation. | |
\index{indentation} | |
\index{whitespace} | |
\end{enumerate} | |
If nothing works, move on to the next section... | |
\subsection{I keep making changes and it makes no difference.} | |
If the interpreter says there is an error and you don't see it, that | |
might be because you and the interpreter are not looking at the same | |
code. Check your programming environment to make sure that the | |
program you are editing is the one Python is trying to run. | |
If you are not sure, try putting an obvious and deliberate syntax | |
error at the beginning of the program. Now run it again. If the | |
interpreter doesn't find the new error, you are not running the | |
new code. | |
There are a few likely culprits: | |
\begin{itemize} | |
\item You edited the file and forgot to save the changes before | |
running it again. Some programming environments do this | |
for you, but some don't. | |
\item You changed the name of the file, but you are still running | |
the old name. | |
\item Something in your development environment is configured | |
incorrectly. | |
\item If you are writing a module and using {\tt import}, | |
make sure you don't give your module the same name as one | |
of the standard Python modules. | |
\index{module!reload} | |
\index{reload function} | |
\index{function!reload} | |
\item If you are using {\tt import} to read a module, remember | |
that you have to restart the interpreter or use {\tt reload} | |
to read a modified file. If you import the module again, it | |
doesn't do anything. | |
\end{itemize} | |
If you get stuck and you can't figure out what is going on, one | |
approach is to start again with a new program like ``Hello, World!,'' | |
and make sure you can get a known program to run. Then gradually add | |
the pieces of the original program to the new one. | |
\section{Runtime errors} | |
Once your program is syntactically correct, | |
Python can compile it and at least start running it. What could | |
possibly go wrong? | |
\subsection{My program does absolutely nothing.} | |
This problem is most common when your file consists of functions and | |
classes but does not actually invoke anything to start execution. | |
This may be intentional if you only plan to import this module to | |
supply classes and functions. | |
If it is not intentional, make sure that you | |
are invoking a function to start execution, or execute one from | |
the interactive prompt. Also see the ``Flow of Execution'' section | |
below. | |
\subsection{My program hangs.} | |
\index{infinite loop} | |
\index{infinite recursion} | |
\index{hanging} | |
If a program stops and seems to be doing nothing, it is ``hanging.'' | |
Often that means that it is caught in an infinite loop or infinite | |
recursion. | |
\begin{itemize} | |
\item If there is a particular loop that you suspect is the | |
problem, add a {\tt print} statement immediately before the loop that says | |
``entering the loop'' and another immediately after that says | |
``exiting the loop.'' | |
Run the program. If you get the first message and not the second, | |
you've got an infinite loop. Go to the ``Infinite Loop'' section | |
below. | |
\item Most of the time, an infinite recursion will cause the program | |
to run for a while and then produce a ``RuntimeError: Maximum | |
recursion depth exceeded'' error. If that happens, go to the | |
``Infinite Recursion'' section below. | |
If you are not getting this error but you suspect there is a problem | |
with a recursive method or function, you can still use the techniques | |
in the ``Infinite Recursion'' section. | |
\item If neither of those steps works, start testing other | |
loops and other recursive functions and methods. | |
\item If that doesn't work, then it is possible that | |
you don't understand the flow of execution in your program. | |
Go to the ``Flow of Execution'' section below. | |
\end{itemize} | |
\subsubsection{Infinite Loop} | |
\index{infinite loop} | |
\index{loop!infinite} | |
\index{condition} | |
\index{loop!condition} | |
If you think you have an infinite loop and you think you know | |
what loop is causing the problem, add a {\tt print} statement at | |
the end of the loop that prints the values of the variables in | |
the condition and the value of the condition. | |
For example: | |
\begin{verbatim} | |
while x > 0 and y < 0 : | |
# do something to x | |
# do something to y | |
print "x: ", x | |
print "y: ", y | |
print "condition: ", (x > 0 and y < 0) | |
\end{verbatim} | |
% | |
Now when you run the program, you will see three lines of output | |
for each time through the loop. The last time through the | |
loop, the condition should be {\tt false}. If the loop keeps | |
going, you will be able to see the values of {\tt x} and {\tt y}, | |
and you might figure out why they are not being updated correctly. | |
\subsubsection{Infinite Recursion} | |
\index{infinite recursion} | |
\index{recursion!infinite} | |
Most of the time, an infinite recursion will cause the program to run | |
for a while and then produce a {\tt Maximum recursion depth exceeded} | |
error. | |
If you suspect that a function or method is causing an infinite | |
recursion, start by checking to make sure that there is a base case. | |
In other words, there should be some condition that will cause the | |
function or method to return without making a recursive invocation. | |
If not, then you need to rethink the algorithm and identify a base | |
case. | |
If there is a base case but the program doesn't seem to be reaching | |
it, add a {\tt print} statement at the beginning of the function or method | |
that prints the parameters. Now when you run the program, you will see | |
a few lines of output every time the function or method is invoked, | |
and you will see the parameters. If the parameters are not moving | |
toward the base case, you will get some ideas about why not. | |
\subsubsection{Flow of Execution} | |
\index{flow of execution} | |
If you are not sure how the flow of execution is moving through | |
your program, add {\tt print} statements to the beginning of each | |
function with a message like ``entering function {\tt foo},'' where | |
{\tt foo} is the name of the function. | |
Now when you run the program, it will print a trace of each | |
function as it is invoked. | |
\subsection{When I run the program I get an exception.} | |
\index{exception} | |
\index{runtime error} | |
If something goes wrong during runtime, Python | |
prints a message that includes the name of the | |
exception, the line of the program where the problem occurred, | |
and a traceback. | |
\index{traceback} | |
The traceback identifies the function that is currently running, | |
and then the function that invoked it, and then the function that | |
invoked {\em that}, and so on. In other words, it traces the | |
sequence of function invocations that got you to where you are. It | |
also includes the line number in your file where each of these | |
calls occurs. | |
The first step is to examine the place in the program where | |
the error occurred and see if you can figure out what happened. | |
These are some of the most common runtime errors: | |
\begin{description} | |
\item[NameError:] You are trying to use a variable that doesn't | |
exist in the current environment. | |
Remember that local variables are local. You | |
cannot refer to them from outside the function where they are defined. | |
\index{NameError} | |
\index{TypeError} | |
\index{exception!NameError} | |
\index{exception!TypeError} | |
\item[TypeError:] There are several possible causes: | |
\begin{itemize} | |
\item You are trying to use a value improperly. Example: indexing | |
a string, list, or tuple with something other than an integer. | |
\index{index} | |
\item There is a mismatch between the items in a format string and | |
the items passed for conversion. This can happen if either the number | |
of items does not match or an invalid conversion is called for. | |
\index{format operator} | |
\index{operator!format} | |
\item You are passing the wrong number of arguments to a function or method. | |
For methods, look at the method definition and | |
check that the first parameter is {\tt self}. Then look at the | |
method invocation; make sure you are invoking the method on an | |
object with the right type and providing the other arguments | |
correctly. | |
\end{itemize} | |
\item[KeyError:] You are trying to access an element of a dictionary | |
using a key that the dictionary does not contain. | |
\index{KeyError} | |
\index{exception!KeyError} | |
\index{dictionary} | |
\item[AttributeError:] You are trying to access an attribute or method | |
that does not exist. Check the spelling! You can use | |
{\tt dir} to list the attributes that do exist. | |
If an AttributeError indicates that an object has {\tt NoneType}, | |
that means that it is {\tt None}. One common cause is forgetting | |
to return a value from a function; if you get to the end of | |
a function without hitting a {\tt return} statement, it returns | |
{\tt None}. Another common cause is using the result from | |
a list method, like {\tt sort}, that returns {\tt None}. | |
\index{AttributeError} | |
\index{exception!AttributeError} | |
\item[IndexError:] The index you are using | |
to access a list, string, or tuple is greater than | |
its length minus one. Immediately before the site of the error, | |
add a {\tt print} statement to display | |
the value of the index and the length of the array. | |
Is the array the right size? Is the index the right value? | |
\index{IndexError} | |
\index{exception!IndexError} | |
\end{description} | |
\index{debugger (pdb)} | |
\index{Python debugger (pdb)} | |
\index{pdb (Python debugger)} | |
The Python debugger ({\tt pdb}) is useful for tracking down | |
Exceptions because it allows you to examine the state of the | |
program immediately before the error. You can read | |
about {\tt pdb} at \url{http://docs.python.org/2/library/pdb.html}. | |
\subsection{I added so many {\tt print} statements I get inundated with | |
output.} | |
\index{print statement} | |
\index{statement!print} | |
One of the problems with using {\tt print} statements for debugging | |
is that you can end up buried in output. There are two ways | |
to proceed: simplify the output or simplify the program. | |
To simplify the output, you can remove or comment out {\tt print} | |
statements that aren't helping, or combine them, or format | |
the output so it is easier to understand. | |
To simplify the program, there are several things you can do. First, | |
scale down the problem the program is working on. For example, if you | |
are searching a list, search a {\em small} list. If the program takes | |
input from the user, give it the simplest input that causes the | |
problem. | |
\index{dead code} | |
Second, clean up the program. Remove dead code and reorganize the | |
program to make it as easy to read as possible. For example, if you | |
suspect that the problem is in a deeply nested part of the program, | |
try rewriting that part with simpler structure. If you suspect a | |
large function, try splitting it into smaller functions and testing them | |
separately. | |
\index{testing!minimal test case} | |
\index{test case, minimal} | |
Often the process of finding the minimal test case leads you to the | |
bug. If you find that a program works in one situation but not in | |
another, that gives you a clue about what is going on. | |
Similarly, rewriting a piece of code can help you find subtle | |
bugs. If you make a change that you think shouldn't affect the | |
program, and it does, that can tip you off. | |
\section{Semantic errors} | |
\index{semantic error} | |
\index{error!semantic} | |
In some ways, semantic errors are the hardest to debug, | |
because the interpreter provides no information | |
about what is wrong. Only you know what the program is supposed to | |
do. | |
The first step is to make a connection between the program | |
text and the behavior you are seeing. You need a hypothesis | |
about what the program is actually doing. One of the things | |
that makes that hard is that computers run so fast. | |
You will often wish that you could slow the program down to human | |
speed, and with some debuggers you can. But the time it takes to | |
insert a few well-placed {\tt print} statements is often short compared to | |
setting up the debugger, inserting and removing breakpoints, and | |
``stepping'' the program to where the error is occurring. | |
\subsection{My program doesn't work.} | |
You should ask yourself these questions: | |
\begin{itemize} | |
\item Is there something the program was supposed to do but | |
which doesn't seem to be happening? Find the section of the code | |
that performs that function and make sure it is executing when | |
you think it should. | |
\item Is something happening that shouldn't? Find code in | |
your program that performs that function and see if it is | |
executing when it shouldn't. | |
\item Is a section of code producing an effect that is not | |
what you expected? Make sure that you understand the code in | |
question, especially if it involves invocations to functions or methods in | |
other Python modules. Read the documentation for the functions you invoke. | |
Try them out by writing simple test cases and checking the results. | |
\end{itemize} | |
In order to program, you need to have a mental model of how | |
programs work. If you write a program that doesn't do what you expect, | |
very often the problem is not in the program; it's in your mental | |
model. | |
\index{model, mental} | |
\index{mental model} | |
The best way to correct your mental model is to break the program | |
into its components (usually the functions and methods) and test | |
each component independently. Once you find the discrepancy | |
between your model and reality, you can solve the problem. | |
Of course, you should be building and testing components as you | |
develop the program. If you encounter a problem, | |
there should be only a small amount of new code | |
that is not known to be correct. | |
\subsection{I've got a big hairy expression and it doesn't | |
do what I expect.} | |
\index{expression!big and hairy} | |
\index{big, hairy expression} | |
Writing complex expressions is fine as long as they are readable, | |
but they can be hard to debug. It is often a good idea to | |
break a complex expression into a series of assignments to | |
temporary variables. | |
For example: | |
\begin{verbatim} | |
self.hands[i].addCard(self.hands[self.findNeighbor(i)].popCard()) | |
\end{verbatim} | |
% | |
This can be rewritten as: | |
\begin{verbatim} | |
neighbor = self.findNeighbor(i) | |
pickedCard = self.hands[neighbor].popCard() | |
self.hands[i].addCard(pickedCard) | |
\end{verbatim} | |
% | |
The explicit version is easier to read because the variable | |
names provide additional documentation, and it is easier to debug | |
because you can check the types of the intermediate variables | |
and display their values. | |
\index{temporary variable} | |
\index{variable!temporary} | |
\index{order of operations} | |
\index{precedence} | |
Another problem that can occur with big expressions is | |
that the order of evaluation may not be what you expect. | |
For example, if you are translating the expression | |
$\frac{x}{2 \pi}$ into Python, you might write: | |
\begin{verbatim} | |
y = x / 2 * math.pi | |
\end{verbatim} | |
% | |
That is not correct because multiplication and division have | |
the same precedence and are evaluated from left to right. | |
So this expression computes $x \pi / 2$. | |
A good way to debug expressions is to add parentheses to make | |
the order of evaluation explicit: | |
\begin{verbatim} | |
y = x / (2 * math.pi) | |
\end{verbatim} | |
% | |
Whenever you are not sure of the order of evaluation, use | |
parentheses. Not only will the program be correct (in the sense | |
of doing what you intended), it will also be more readable for | |
other people who haven't memorized the rules of precedence. | |
\subsection{I've got a function or method that doesn't return what I | |
expect.} | |
\index{return statement} | |
\index{statement!return} | |
If you have a {\tt return} statement with a complex expression, | |
you don't have a chance to print the {\tt return} value before | |
returning. Again, you can use a temporary variable. For | |
example, instead of: | |
\begin{verbatim} | |
return self.hands[i].removeMatches() | |
\end{verbatim} | |
% | |
you could write: | |
\begin{verbatim} | |
count = self.hands[i].removeMatches() | |
return count | |
\end{verbatim} | |
% | |
Now you have the opportunity to display the value of | |
{\tt count} before returning. | |
\subsection{I'm really, really stuck and I need help.} | |
First, try getting away from the computer for a few minutes. | |
Computers emit waves that affect the brain, causing these | |
symptoms: | |
\begin{itemize} | |
\item Frustration and rage. | |
\index{frustration} | |
\index{rage} | |
\index{debugging!emotional response} | |
\index{emotional debugging} | |
\item Superstitious beliefs (``the computer hates me'') and | |
magical thinking (``the program only works when I wear my | |
hat backward''). | |
\index{debugging!superstition} | |
\index{superstitious debugging} | |
\item Random walk programming (the attempt to program by writing | |
every possible program and choosing the one that does the right | |
thing). | |
\index{random walk programming} | |
\index{development plan!random walk programming} | |
\end{itemize} | |
If you find yourself suffering from any of these symptoms, get | |
up and go for a walk. When you are calm, think about the program. | |
What is it doing? What are some possible causes of that | |
behavior? When was the last time you had a working program, | |
and what did you do next? | |
Sometimes it just takes time to find a bug. I often find bugs | |
when I am away from the computer and let my mind wander. Some | |
of the best places to find bugs are trains, showers, and in bed, | |
just before you fall asleep. | |
\subsection{No, I really need help.} | |
It happens. Even the best programmers occasionally get stuck. | |
Sometimes you work on a program so long that you can't see the | |
error. A fresh pair of eyes is just the thing. | |
Before you bring someone else in, make sure you are prepared. | |
Your program should be as simple | |
as possible, and you should be working on the smallest input | |
that causes the error. You should have {\tt print} statements in the | |
appropriate places (and the output they produce should be | |
comprehensible). You should understand the problem well enough | |
to describe it concisely. | |
When you bring someone in to help, be sure to give | |
them the information they need: | |
\begin{itemize} | |
\item If there is an error message, what is it | |
and what part of the program does it indicate? | |
\item What was the last thing you did before this error occurred? | |
What were the last lines of code that you wrote, or what is | |
the new test case that fails? | |
\item What have you tried so far, and what have you learned? | |
\end{itemize} | |
When you find the bug, take a second to think about what you | |
could have done to find it faster. Next time you see something | |
similar, you will be able to find the bug more quickly. | |
Remember, the goal is not just to make the program | |
work. The goal is to learn how to make the program work. | |
\chapter{Analysis of Algorithms} | |
\begin{quote} | |
This appendix is an edited excerpt from {\it Think Complexity}, by | |
Allen B. Downey, also published by O'Reilly Media (2011). When you | |
are done with this book, you might want to move on to that one. | |
\end{quote} | |
{\bf Analysis of algorithms} is a branch of computer science that | |
studies the performance of algorithms, especially their run time and | |
space requirements. See | |
\url{http://en.wikipedia.org/wiki/Analysis_of_algorithms}. | |
\index{algorithm} \index{analysis of algorithms} | |
The practical goal of algorithm analysis is to predict the performance | |
of different algorithms in order to guide design decisions. | |
During the 2008 United States Presidential Campaign, candidate | |
Barack Obama was asked to perform an impromptu analysis when | |
he visited Google. Chief executive Eric Schmidt jokingly asked him | |
for ``the most efficient way to sort a million 32-bit integers.'' | |
Obama had apparently been tipped off, because he quickly | |
replied, ``I think the bubble sort would be the wrong way to go.'' | |
See \url{http://www.youtube.com/watch?v=k4RRi_ntQc8}. | |
\index{Obama, Barack} | |
\index{Schmidt, Eric} | |
\index{bubble sort} | |
This is true: bubble sort is conceptually simple but slow for | |
large datasets. The answer Schmidt was probably looking for is | |
``radix sort'' (\url{http://en.wikipedia.org/wiki/Radix_sort})\footnote{ | |
But if you get a question like this in an interview, I think | |
a better answer is, ``The fastest way to sort a million integers | |
is to use whatever sort function is provided by the language | |
I'm using. Its performance is good enough for the vast majority | |
of applications, but if it turned out that my application was too | |
slow, I would use a profiler to see where the time was being | |
spent. If it looked like a faster sort algorithm would have | |
a significant effect on performance, then I would look | |
around for a good implementation of radix sort.''}. | |
\index{radix sort} | |
The goal of algorithm analysis is to make meaningful | |
comparisons between algorithms, but there are some problems: | |
\index{comparing algorithms} | |
\begin{itemize} | |
\item The relative performance of the algorithms might | |
depend on characteristics of the hardware, so one algorithm | |
might be faster on Machine A, another on Machine B. | |
The general solution to this problem is to specify a | |
{\bf machine model} and analyze the number of steps, or | |
operations, an algorithm requires under a given model. | |
\index{machine model} | |
\item Relative performance might depend on the details of | |
the dataset. For example, some sorting | |
algorithms run faster if the data are already partially sorted; | |
other algorithms run slower in this case. | |
A common way to avoid this problem is to analyze the | |
{\bf worst case} scenario. It is sometimes useful to | |
analyze average case performance, but that's usually harder, | |
and it might not be obvious what set of cases to average over. | |
\index{worst case} | |
\index{average case} | |
\item Relative performance also depends on the size of the | |
problem. A sorting algorithm that is fast for small lists | |
might be slow for long lists. | |
The usual solution to this problem is to express run time | |
(or number of operations) as a function of problem size, | |
and to compare the functions {\bf asymptotically} as the problem | |
size increases. | |
\index{asymptotic analysis} | |
\end{itemize} | |
The good thing about this kind of comparison that it lends | |
itself to simple classification of algorithms. For example, | |
if I know that the run time of Algorithm A tends to be | |
proportional to the size of the input, $n$, and Algorithm B | |
tends to be proportional to $n^2$, then I | |
expect A to be faster than B for large values of $n$. | |
This kind of analysis comes with some caveats, but we'll get | |
to that later. | |
\section{Order of growth} | |
Suppose you have analyzed two algorithms and expressed | |
their run times in terms of the size of the input: | |
Algorithm A takes $100n+1$ steps to solve a problem with | |
size $n$; Algorithm B takes $n^2 + n + 1$ steps. | |
\index{order of growth} | |
The following table shows the run time of these algorithms | |
for different problem sizes: | |
\begin{tabular}{|r|r|r|} | |
\hline | |
Input & Run time of & Run time of \\ | |
size & Algorithm A & Algorithm B \\ | |
\hline | |
10 & 1 001 & 111 \\ | |
100 & 10 001 & 10 101 \\ | |
1 000 & 100 001 & 1 001 001 \\ | |
10 000 & 1 000 001 & $> 10^{10}$ \\ | |
\hline | |
\end{tabular} | |
At $n=10$, Algorithm A looks pretty bad; it takes almost 10 times | |
longer than Algorithm B. But for $n=100$ they are about the same, and | |
for larger values A is much better. | |
The fundamental reason is that for large values of $n$, any function | |
that contains an $n^2$ term will grow faster than a function whose | |
leading term is $n$. The {\bf leading term} is the term with the | |
highest exponent. | |
\index{leading term} | |
\index{exponent} | |
For Algorithm A, the leading term has a large coefficient, 100, which | |
is why B does better than A for small $n$. But regardless of the | |
coefficients, there will always be some value of $n$ where | |
$a n^2 > b n$. | |
\index{leading coefficient} | |
The same argument applies to the non-leading terms. Even if the run | |
time of Algorithm A were $n+1000000$, it would still be better than | |
Algorithm B for sufficiently large $n$. | |
In general, we expect an algorithm with a smaller leading term to be a | |
better algorithm for large problems, but for smaller problems, there | |
may be a {\bf crossover point} where another algorithm is better. The | |
location of the crossover point depends on the details of the | |
algorithms, the inputs, and the hardware, so it is usually ignored for | |
purposes of algorithmic analysis. But that doesn't mean you can forget | |
about it. | |
\index{crossover point} | |
If two algorithms have the same leading order term, it is hard to say | |
which is better; again, the answer depends on the details. So for | |
algorithmic analysis, functions with the same leading term | |
are considered equivalent, even if they have different coefficients. | |
An {\bf order of growth} is a set of functions whose asymptotic growth | |
behavior is considered equivalent. For example, $2n$, $100n$ and $n+1$ | |
belong to the same order of growth, which is written $O(n)$ in | |
{\bf Big-Oh notation} and often called {\bf linear} because every function | |
in the set grows linearly with $n$. | |
\index{big-oh notation} | |
\index{linear growth} | |
All functions with the leading term $n^2$ belong to $O(n^2)$; they are | |
{\bf quadratic}, which is a fancy word for functions with the | |
leading term $n^2$. | |
\index{quadratic growth} | |
The following table shows some of the orders of growth that | |
appear most commonly in algorithmic analysis, | |
in increasing order of badness. | |
\index{badness} | |
\begin{tabular}{|r|r|r|} | |
\hline | |
Order of & Name \\ | |
growth & \\ | |
\hline | |
$O(1)$ & constant \\ | |
$O(\log_b n)$ & logarithmic (for any $b$) \\ | |
$O(n)$ & linear \\ | |
$O(n \log_b n)$ & ``en log en'' \\ | |
$O(n^2)$ & quadratic \\ | |
$O(n^3)$ & cubic \\ | |
$O(c^n)$ & exponential (for any $c$) \\ | |
\hline | |
\end{tabular} | |
For the logarithmic terms, the base of the logarithm doesn't matter; | |
changing bases is the equivalent of multiplying by a constant, which | |
doesn't change the order of growth. Similarly, all exponential | |
functions belong to the same order of growth regardless of the base of | |
the exponent. | |
Exponential functions grow very quickly, so exponential algorithms are | |
only useful for small problems. | |
\index{logarithmic growth} | |
\index{exponential growth} | |
\begin{exercise} | |
Read the Wikipedia page on Big-Oh notation at | |
\url{http://en.wikipedia.org/wiki/Big_O_notation} and | |
answer the following questions: | |
\begin{enumerate} | |
\item What is the order of growth of $n^3 + n^2$? | |
What about $1000000 n^3 + n^2$? | |
What about $n^3 + 1000000 n^2$? | |
\item What is the order of growth of $(n^2 + n) \cdot (n + 1)$? Before | |
you start multiplying, remember that you only need the leading term. | |
\item If $f$ is in $O(g)$, for some unspecified function $g$, what can | |
we say about $af+b$? | |
\item If $f_1$ and $f_2$ are in $O(g)$, what can we say about $f_1 + f_2$? | |
\item If $f_1$ is in $O(g)$ | |
and $f_2$ is in $O(h)$, | |
what can we say about $f_1 + f_2$? | |
\item If $f_1$ is in $O(g)$ and $f_2$ is $O(h)$, | |
what can we say about $f_1 \cdot f_2$? | |
\end{enumerate} | |
\end{exercise} | |
Programmers who care about performance often find this kind of | |
analysis hard to swallow. They have a point: sometimes the | |
coefficients and the non-leading terms make a real difference. | |
Sometimes the details of the hardware, the programming language, and | |
the characteristics of the input make a big difference. And for small | |
problems asymptotic behavior is irrelevant. | |
\index{practical analysis of algorithms} | |
But if you keep those caveats in mind, algorithmic analysis is a | |
useful tool. At least for large problems, the ``better'' algorithms | |
is usually better, and sometimes it is {\em much} better. The | |
difference between two algorithms with the same order of growth is | |
usually a constant factor, but the difference between a good algorithm | |
and a bad algorithm is unbounded! | |
\index{unbounded} | |
\section{Analysis of basic Python operations} | |
Most arithmetic operations are constant time; multiplication | |
usually takes longer than addition and subtraction, and division | |
takes even longer, but these run times don't | |
depend on the magnitude of the operands. Very large integers | |
are an exception; in that case the run time increases | |
with the number of digits. | |
\index{analysis of primitives} | |
Indexing operations---reading or writing elements in a sequence | |
or dictionary---are also constant time, regardless of the size | |
of the data structure. | |
\index{indexing} | |
A {\tt for} loop that traverses a sequence or dictionary is | |
usually linear, as long as all of the operations in the body | |
of the loop are constant time. For example, adding up the | |
elements of a list is linear: | |
\begin{verbatim} | |
total = 0 | |
for x in t: | |
total += x | |
\end{verbatim} | |
The built-in function {\tt sum} is also linear because it does | |
the same thing, but it tends to be faster because it is a more | |
efficient implementation; in the language of algorithmic analysis, | |
it has a smaller leading coefficient. | |
If you use the same loop to ``add'' a list of strings, the | |
run time is quadratic | |
because string concatenation is linear. | |
\index{string concatenation} | |
The string method {\tt join} is usually faster because it is | |
linear in the total length of the strings. | |
\index{join@{\tt join}} | |
As a rule of thumb, if the body of a loop is in $O(n^a)$ then | |
the whole loop is in $O(n^{a+1})$. The exception is if you can | |
show that the loop exits after a constant number of iterations. | |
If a loop runs $k$ times regardless of $n$, then | |
the loop is in $O(n^a)$, even for large $k$. | |
Multiplying by $k$ doesn't change the order of growth, but neither | |
does dividing. So if the body of a loop is in $O(n^a)$ and it runs | |
$n/k$ times, the loop is in $O(n^{a+1})$, even for large $k$. | |
Most string and tuple operations are linear, except indexing and {\tt | |
len}, which are constant time. The built-in functions {\tt min} and | |
{\tt max} are linear. The run-time of a slice operation is | |
proportional to the length of the output, but independent of the size | |
of the input. | |
\index{string methods} | |
\index{tuple methods} | |
All string methods are linear, but if the lengths of | |
the strings are bounded by a constant---for example, operations on single | |
characters---they are considered constant time. | |
Most list methods are linear, but there are some exceptions: | |
\index{list methods} | |
\begin{itemize} | |
\item Adding an element to the end of a list is constant time on | |
average; when it runs out of room it occasionally gets copied | |
to a bigger location, but the total time for $n$ operations | |
is $O(n)$, so we say that the ``amortized'' time for one | |
operation is $O(1)$. | |
\item Removing an element from the end of a list is constant time. | |
\item Sorting is $O(n \log n)$. | |
\index{sorting} | |
\end{itemize} | |
Most dictionary operations and methods are constant time, but | |
there are some exceptions: | |
\index{dictionary methods} | |
\begin{itemize} | |
\item The run time of {\tt copy} is proportional to the number of | |
elements, but not the size of the elements (it copies references, | |
not the elements themselves). | |
\item The run time of {\tt update} is | |
proportional to the size of the dictionary passed as a parameter, | |
not the dictionary being updated. | |
\item {\tt keys}, {\tt values} and {\tt items} are linear because they | |
return new lists; {\tt iterkeys}, {\tt itervalues} and {\tt | |
iteritems} are constant time because they return iterators. But | |
if you loop through the iterators, the loop will be linear. Using | |
the ``iter'' functions saves some overhead, but it doesn't change | |
the order of growth unless the number of items you access is | |
bounded. | |
\end{itemize} | |
The performance of dictionaries is one of the minor miracles of | |
computer science. We will see how they work in | |
Section~\ref{hashtable}. | |
\begin{exercise} | |
Read the Wikipedia page on sorting algorithms at | |
\url{http://en.wikipedia.org/wiki/Sorting_algorithm} and answer | |
the following questions: | |
\index{sorting} | |
\begin{enumerate} | |
\item What is a ``comparison sort?'' What is the best worst-case order | |
of growth for a comparison sort? What is the best worst-case order | |
of growth for any sort algorithm? | |
\index{comparison sort} | |
\item What is the order of growth of bubble sort, and why does Barack | |
Obama think it is ``the wrong way to go?'' | |
\item What is the order of growth of radix sort? What preconditions | |
do we need to use it? | |
\item What is a stable sort and why might it matter in practice? | |
\index{stable sort} | |
\item What is the worst sorting algorithm (that has a name)? | |
\item What sort algorithm does the C library use? What sort algorithm | |
does Python use? Are these algorithms stable? You might have to | |
Google around to find these answers. | |
\item Many of the non-comparison sorts are linear, so why does does | |
Python use an $O(n \log n)$ comparison sort? | |
\end{enumerate} | |
\end{exercise} | |
\section{Analysis of search algorithms} | |
A {\bf search} is an algorithm that takes a collection and a target | |
item and determines whether the target is in the collection, often | |
returning the index of the target. | |
\index{search} | |
The simplest search algorithm is a ``linear search,'' which traverses | |
the items of the collection in order, stopping if it finds the target. | |
In the worst case it has to traverse the entire collection, so the run | |
time is linear. | |
\index{linear search} | |
The {\tt in} operator for sequences uses a linear search; so do string | |
methods like {\tt find} and {\tt count}. | |
\index{in@{\tt in} operator} | |
If the elements of the sequence are in order, you can use a {\bf | |
bisection search}, which is $O(\log n)$. Bisection search is | |
similar to the algorithm you probably use to look a word up in a | |
dictionary (a real dictionary, not the data structure). Instead of starting at | |
the beginning and checking each item in order, you start with the item | |
in the middle and check whether the word you are looking for comes | |
before or after. If it comes before, then you search the first half | |
of the sequence. Otherwise you search the second half. Either way, | |
you cut the number of remaining items in half. \index{bisection | |
search} | |
If the sequence has 1,000,000 items, it will take about 20 steps to | |
find the word or conclude that it's not there. So that's about 50,000 | |
times faster than a linear search. | |
\begin{exercise} | |
Write a function called {\tt bisection} that takes a sorted list | |
and a target value and returns the index of the value | |
in the list, if it's there, or {\tt None} if it's not. | |
\index{bisect@{\tt bisect} module} | |
\index{bisect module} | |
\index{module!bisect} | |
Or you could read the documentation of the {\tt bisect} module | |
and use that! | |
\end{exercise} | |
Bisection search can be much faster than linear search, but | |
it requires the sequence to be in order, which might require | |
extra work. | |
There is another data structure, called a {\bf hashtable} that | |
is even faster---it can do a search in constant time---and it | |
doesn't require the items to be sorted. Python dictionaries | |
are implemented using hashtables, which is why most dictionary | |
operations, including the {\tt in} operator, are constant time. | |
\section{Hashtables} | |
\label{hashtable} | |
To explain how hashtables work and why their performance is so | |
good, I start with a simple implementation of a map and | |
gradually improve it until it's a hashtable. | |
\index{hashtable} | |
I use Python to demonstrate these implementations, but in real | |
life you wouldn't write code like this in Python; you would just use a | |
dictionary! So for the rest of this chapter, you have to imagine that | |
dictionaries don't exist and you want to implement a data structure | |
that maps from keys to values. The operations you have to | |
implement are: | |
\begin{description} | |
\item[{\tt add(k, v)}:] Add a new item that maps from key {\tt k} | |
to value {\tt v}. With a Python dictionary, {\tt d}, this operation | |
is written {\tt d[k] = v}. | |
\item[{\tt get(target)}:] Look up and return the value that corresponds | |
to key {\tt target}. With a Python dictionary, {\tt d}, this operation | |
is written {\tt d[target]} or {\tt d.get(target)}. | |
\end{description} | |
For now, I assume that each key only appears once. | |
The simplest implementation of this interface uses a list of | |
tuples, where each tuple is a key-value pair. | |
\index{LinearMap@{\tt LinearMap}} | |
\begin{verbatim} | |
class LinearMap(object): | |
def __init__(self): | |
self.items = [] | |
def add(self, k, v): | |
self.items.append((k, v)) | |
def get(self, k): | |
for key, val in self.items: | |
if key == k: | |
return val | |
raise KeyError | |
\end{verbatim} | |
{\tt add} appends a key-value tuple to the list of items, which | |
takes constant time. | |
{\tt get} uses a {\tt for} loop to search the list: | |
if it finds the target key it returns the corresponding value; | |
otherwise it raises a {\tt KeyError}. | |
So {\tt get} is linear. | |
\index{KeyError@{\tt KeyError}} | |
An alternative is to keep the list sorted by key. Then {\tt get} | |
could use a bisection search, which is $O(\log n)$. But inserting a | |
new item in the middle of a list is linear, so this might not be the | |
best option. There are other data structures (see | |
\url{http://en.wikipedia.org/wiki/Red-black_tree}) that can implement {\tt | |
add} and {\tt get} in log time, but that's still not as good as | |
constant time, so let's move on. | |
\index{red-black tree} | |
One way to improve {\tt LinearMap} is to break the list of key-value | |
pairs into smaller lists. Here's an implementation called | |
{\tt BetterMap}, which is a list of 100 LinearMaps. As we'll see | |
in a second, the order of growth for {\tt get} is still linear, | |
but {\tt BetterMap} is a step on the path toward hashtables: | |
\index{BetterMap@{\tt BetterMap}} | |
\begin{verbatim} | |
class BetterMap(object): | |
def __init__(self, n=100): | |
self.maps = [] | |
for i in range(n): | |
self.maps.append(LinearMap()) | |
def find_map(self, k): | |
index = hash(k) % len(self.maps) | |
return self.maps[index] | |
def add(self, k, v): | |
m = self.find_map(k) | |
m.add(k, v) | |
def get(self, k): | |
m = self.find_map(k) | |
return m.get(k) | |
\end{verbatim} | |
\verb"__init__" makes a list of {\tt n} {\tt LinearMap}s. | |
\verb"find_map" is used by | |
{\tt add} and {\tt get} | |
to figure out which map to put the | |
new item in, or which map to search. | |
\verb"find_map" uses the built-in function {\tt hash}, which takes | |
almost any Python object and returns an integer. A limitation of this | |
implementation is that it only works with hashable keys. Mutable | |
types like lists and dictionaries are unhashable. | |
\index{hash function} | |
Hashable objects that are considered equal return the same hash value, | |
but the converse is not necessarily true: two different objects | |
can return the same hash value. | |
\verb"find_map" uses the modulus operator to wrap the hash values | |
into the range from 0 to {\tt len(self.maps)}, so the result is a legal | |
index into the list. Of course, this means that many different | |
hash values will wrap onto the same index. But if the hash function | |
spreads things out pretty evenly (which is what hash functions | |
are designed to do), then we expect $n/100$ items per LinearMap. | |
Since the run time of {\tt LinearMap.get} is proportional to the | |
number of items, we expect BetterMap to be about 100 times faster | |
than LinearMap. The order of growth is still linear, but the | |
leading coefficient is smaller. That's nice, but still not | |
as good as a hashtable. | |
Here (finally) is the crucial idea that makes hashtables fast: if you | |
can keep the maximum length of the LinearMaps bounded, {\tt | |
LinearMap.get} is constant time. All you have to do is keep track | |
of the number of items and when the number of | |
items per LinearMap exceeds a threshold, resize the hashtable by | |
adding more LinearMaps. | |
\index{bounded} | |
Here is an implementation of a hashtable: | |
\index{HashMap} | |
\begin{verbatim} | |
class HashMap(object): | |
def __init__(self): | |
self.maps = BetterMap(2) | |
self.num = 0 | |
def get(self, k): | |
return self.maps.get(k) | |
def add(self, k, v): | |
if self.num == len(self.maps.maps): | |
self.resize() | |
self.maps.add(k, v) | |
self.num += 1 | |
def resize(self): | |
new_maps = BetterMap(self.num * 2) | |
for m in self.maps.maps: | |
for k, v in m.items: | |
new_maps.add(k, v) | |
self.maps = new_maps | |
\end{verbatim} | |
Each {\tt HashMap} contains a {\tt BetterMap}; \verb"__init__" starts | |
with just 2 LinearMaps and initializes {\tt num}, which keeps track of | |
the number of items. | |
{\tt get} just dispatches to {\tt BetterMap}. The real work happens | |
in {\tt add}, which checks the number of items and the size of the | |
{\tt BetterMap}: if they are equal, the average number of items per | |
LinearMap is 1, so it calls {\tt resize}. | |
{\tt resize} make a new {\tt BetterMap}, twice as big as the previous | |
one, and then ``rehashes'' the items from the old map to the new. | |
Rehashing is necessary because changing the number of LinearMaps | |
changes the denominator of the modulus operator in | |
\verb"find_map". That means that some objects that used | |
to wrap into the same LinearMap will get split up (which is | |
what we wanted, right?). | |
\index{rehashing} | |
Rehashing is linear, so | |
{\tt resize} is linear, which might seem bad, since I promised | |
that {\tt add} would be constant time. But remember that | |
we don't have to resize every time, so {\tt add} is usually | |
constant time and only occasionally linear. The total amount | |
of work to run {\tt add} $n$ times is proportional to $n$, | |
so the average time of each {\tt add} is constant time! | |
\index{constant time} | |
To see how this works, think about starting with an empty | |
HashTable and adding a sequence of items. We start with 2 LinearMaps, | |
so the first 2 adds are fast (no resizing required). Let's | |
say that they take one unit of work each. The next add | |
requires a resize, so we have to rehash the first two | |
items (let's call that 2 more units of work) and then | |
add the third item (one more unit). Adding the next item | |
costs 1 unit, so the total so far is | |
6 units of work for 4 items. | |
The next {\tt add} costs 5 units, but the next three | |
are only one unit each, so the total is 14 units for the | |
first 8 adds. | |
The next {\tt add} costs 9 units, but then we can add 7 more | |
before the next resize, so the total is 30 units for the | |
first 16 adds. | |
After 32 adds, the total cost is 62 units, and I hope you are starting | |
to see a pattern. After $n$ adds, where $n$ is a power of two, the | |
total cost is $2n-2$ units, so the average work per add is | |
a little less than 2 units. When $n$ is a power of two, that's | |
the best case; for other values of $n$ the average work is a little | |
higher, but that's not important. The important thing is that it | |
is $O(1)$. | |
\index{average cost} | |
Figure~\ref{fig.hash} shows how this works graphically. Each | |
block represents a unit of work. The columns show the total | |
work for each add in order from left to right: the first two | |
{\tt adds} cost 1 units, the third costs 3 units, etc. | |
\begin{figure} | |
\centerline{\includegraphics[scale=1.0]{figs/towers.pdf}} | |
\caption{The cost of a hashtable add.\label{fig.hash}} | |
\end{figure} | |
The extra work of rehashing appears as a sequence of increasingly | |
tall towers with increasing space between them. Now if you knock | |
over the towers, amortizing the cost of resizing over all | |
adds, you can see graphically that the total cost after $n$ | |
adds is $2n - 2$. | |
An important feature of this algorithm is that when we resize the | |
HashTable it grows geometrically; that is, we multiply the size by a | |
constant. If you increase the size | |
arithmetically---adding a fixed number each time---the average time | |
per {\tt add} is linear. | |
\index{geometric resizing} | |
You can download my implementation of HashMap from | |
\url{http://thinkpython/code/Map.py}, but remember that there | |
is no reason to use it; if you want a map, just use a Python dictionary. | |
\chapter{Lumpy} | |
\label{lumpy} | |
Throughout the book, I have used diagrams to represent the state of | |
running programs. | |
\index{Lumpy} | |
In Section~\ref{variables}, we used a state diagram to show the names | |
and values of variables. In Section~\ref{stackdiagram} I introduced a | |
stack diagram, which shows one frame for each function call. Each | |
frame shows the parameters and local variables for the function or | |
method. Stack diagrams for recursive functions appear in | |
Section~\ref{recursive.stack} and Section~\ref{more.recursion}. | |
\index{stack diagram} \index{diagram!stack} | |
\index{state diagram} \index{diagram!state} | |
Section~\ref{mutable} shows what a list looks like in a state diagram, | |
Section~\ref{invert} shows what a dictionary looks like, and | |
Section~\ref{dictuple} shows two ways to represent tuples. | |
Section~\ref{attributes} introduces object diagrams, which show the | |
state of an object's attributes, and their attributes, and so on. | |
Section~\ref{rectangles} has object diagrams for Rectangles and | |
their embedded Points. Section~\ref{time.object} shows the state | |
of a Time object. | |
Section~\ref{class.attribute} has a diagram that includes a class | |
object and an instance, each with their own attributes. | |
\index{object diagram} | |
\index{diagram!object} | |
Finally, Section~\ref{class.diagram} introduces class diagrams, | |
which show the classes that make up a program and the relationships | |
between them. | |
\index{class diagram} | |
\index{diagram!class} | |
These diagrams are based on the Unified Modeling Language (UML), which | |
is a standardized graphical language used by software engineers | |
to communicate about program design, especially for object-oriented | |
programs. | |
\index{Unified Modeling Language} | |
\index{UML} | |
UML is a rich language with many kinds of diagrams that represent | |
many kinds of relationship between objects and classes. What I presented | |
in this book is a small subset of the language, but it is the subset | |
most commonly used in practice. | |
The purpose of this appendix is to review the diagrams presented in | |
the previous chapters, and to introduce Lumpy. Lumpy, which stands | |
for ``UML in Python,'' with some of the letters rearranged, is part of | |
Swampy, which you already installed if you worked on the case study in | |
Chapter~\ref{turtlechap} or Chapter~\ref{tkinter}, or if you did | |
Exercise~\ref{canvas}, | |
\index{Lumpy} | |
\index{Swampy} | |
Lumpy uses Python's {\tt inspect} module to examine the state of a running | |
program and generate object diagrams (including stack diagrams) and | |
class diagrams. | |
\section{State diagram} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.7]{figs/lumpydemo1.pdf}} | |
\caption{State diagram generated by Lumpy.} | |
\label{fig.lumpy1} | |
\end{figure} | |
Here's an example that uses Lumpy to generate a state diagram. | |
\index{state diagram} \index{diagram!state} | |
\begin{verbatim} | |
from swampy.Lumpy import Lumpy | |
lumpy = Lumpy() | |
lumpy.make_reference() | |
message = 'And now for something completely different' | |
n = 17 | |
pi = 3.1415926535897932 | |
lumpy.object_diagram() | |
\end{verbatim} | |
The first line imports the Lumpy class from {\tt swampy.Lumpy}. | |
If you don't have Swampy installed as a package, make sure | |
the Swampy files are in Python's search path and use this | |
{\tt import} statement instead: | |
\begin{verbatim} | |
from Lumpy import Lumpy | |
\end{verbatim} | |
The next lines create a {\tt Lumpy} object and make a ``reference'' | |
point, which means that Lumpy records the objects that have been | |
defined so far. | |
Next we define new variables and invoke \verb"object_diagram", | |
which draws the objects that have been defined since the reference | |
point, in this case {\tt message}, {\tt n} and {\tt pi}. | |
Figure~\ref{fig.lumpy1} shows the result. The graphical style is | |
different from what I showed earlier; for example, each | |
reference is represented by a circle next to the variable name and a | |
line to the value. And long strings are truncated. But the | |
information conveyed by the diagram is the same. | |
The variable names are in a frame labeled \verb"<module>", which | |
indicates that these are module-level variables, also known as | |
global. | |
\index{global variable} | |
\index{variable!global} | |
\index{module-level variable} | |
\index{variable!module-level} | |
You can download this example from | |
\url{http://thinkpython.com/code/lumpy_demo1.py}. Try adding some | |
additional assignments and see what the diagram looks like. | |
\section{Stack diagram} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.7]{figs/lumpydemo2.pdf}} | |
\caption{Stack diagram.} | |
\label{fig.lumpy2} | |
\end{figure} | |
Here's an example that uses Lumpy to generate a stack diagram. | |
You can download it from \url{http://thinkpython.com/code/lumpy_demo2.py}. | |
\index{stack diagram} \index{diagram!stack} | |
\begin{verbatim} | |
from swampy.Lumpy import Lumpy | |
def countdown(n): | |
if n <= 0: | |
print 'Blastoff!' | |
lumpy.object_diagram() | |
else: | |
print n | |
countdown(n-1) | |
lumpy = Lumpy() | |
lumpy.make_reference() | |
countdown(3) | |
\end{verbatim} | |
Figure~\ref{fig.lumpy2} shows the result. Each frame is represented | |
with a box that has the function's name outside and variables inside. | |
Since this function is recursive, there is one frame for each | |
level of recursion. | |
\index{recursion} | |
\index{function frame} | |
\index{frame} | |
Remember that a stack diagram shows the state of the program at | |
a particular point in its execution. To get the diagram you want, | |
sometimes you have to think about where to invoke \verb"object_diagram". | |
In this case I invoke \verb"object_diagram" after executing the base | |
case of the recursion; that way the stack diagram shows each level of | |
the recursion. You can call \verb"object_diagram" more than once to | |
get a series of snapshots of the program's execution. | |
\index{base case} | |
\section{Object diagrams} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.7]{figs/lumpydemo3.pdf}} | |
\caption{Object diagram.} | |
\label{fig.lumpy3} | |
\end{figure} | |
This example generates an object diagram showing the lists from | |
Section~\ref{sequence}. You can download it from | |
\url{http://thinkpython.com/code/lumpy_demo3.py}. | |
\index{object diagram} \index{diagram!object} | |
\begin{verbatim} | |
from swampy.Lumpy import Lumpy | |
lumpy = Lumpy() | |
lumpy.make_reference() | |
cheeses = ['Cheddar', 'Edam', 'Gouda'] | |
numbers = [17, 123] | |
empty = [] | |
lumpy.object_diagram() | |
\end{verbatim} | |
Figure~\ref{fig.lumpy3} shows the result. Lists are represented by | |
a box that shows the indices mapping to the elements. This representation | |
is slightly misleading, since indices are not actually | |
part of the list, but I think they make the diagram easier to | |
read. The empty list is represented by an empty box. | |
\index{list index} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.7]{figs/lumpydemo4.pdf}} | |
\caption{Object diagram.} | |
\label{fig.lumpy4} | |
\end{figure} | |
And here's an example | |
showing the dictionaries from Section~\ref{invert}. You can download | |
it from \url{http://thinkpython.com/code/lumpy_demo4.py}. | |
\index{dictionary} | |
\begin{verbatim} | |
from swampy.Lumpy import Lumpy | |
lumpy = Lumpy() | |
lumpy.make_reference() | |
hist = histogram('parrot') | |
inverse = invert_dict(hist) | |
lumpy.object_diagram() | |
\end{verbatim} | |
Figure~\ref{fig.lumpy4} shows the result. {\tt hist} is a dictionary | |
that maps from characters (single-letter strings) to integers; | |
{\tt inverse} maps from integers to lists of strings. | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.7]{figs/lumpydemo5.pdf}} | |
\caption{Object diagram.} | |
\label{fig.lumpy5} | |
\end{figure} | |
This example generates an object diagram for Point and Rectangle | |
objects, as in Section~\ref{copying}. You can download it from | |
\url{http://thinkpython.com/code/lumpy_demo5.py}. | |
\index{Point class} | |
\index{class!Point} | |
\index{Rectangle class} | |
\index{class!Rectangle} | |
\begin{verbatim} | |
import copy | |
from swampy.Lumpy import Lumpy | |
lumpy = Lumpy() | |
lumpy.make_reference() | |
box = Rectangle() | |
box.width = 100.0 | |
box.height = 200.0 | |
box.corner = Point() | |
box.corner.x = 0.0 | |
box.corner.y = 0.0 | |
box2 = copy.copy(box) | |
lumpy.object_diagram() | |
\end{verbatim} | |
Figure~\ref{fig.lumpy5} shows the result. {\tt copy.copy} make a | |
shallow copy, so {\tt box} and {\tt box2} have their own {\tt width} | |
and {\tt height}, but they share the same embedded Point object. This | |
kind of sharing is usually fine with immutable objects, but with | |
mutable types, it is highly error-prone. | |
\index{copy} | |
\index{shallow copy} | |
\section{Function and class objects} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.7]{figs/lumpydemo6.pdf}} | |
\caption{Object diagram.} | |
\label{fig.lumpy6} | |
\end{figure} | |
When I use Lumpy to make object diagrams, I usually define the functions | |
and classes before I make the reference point. That way, function | |
and class objects don't appear in the diagram. | |
\index{function object} | |
\index{object!function} | |
\index{class object} | |
\index{object!class} | |
But if you are passing functions and classes as parameters, you might | |
want them to appear. This example shows what that looks like; | |
you can download it from | |
\url{http://thinkpython.com/code/lumpy_demo6.py}. | |
\begin{verbatim} | |
import copy | |
from swampy.Lumpy import Lumpy | |
lumpy = Lumpy() | |
lumpy.make_reference() | |
class Point(object): | |
"""Represents a point in 2-D space.""" | |
class Rectangle(object): | |
"""Represents a rectangle.""" | |
def instantiate(constructor): | |
"""Instantiates a new object.""" | |
obj = constructor() | |
lumpy.object_diagram() | |
return obj | |
point = instantiate(Point) | |
\end{verbatim} | |
Figure~\ref{fig.lumpy6} shows the result. Since we invoke | |
\verb"object_diagram" inside a function, we get a stack diagram | |
with a frame for the module-level variables and for the invocation | |
of {\tt instantiate}. | |
At the module level, {\tt Point} and {\tt Rectangle} refer to | |
class objects (which have type {\tt type}); {\tt instantiate} | |
refers to a function object. | |
\index{instantiate} | |
\index{constructor} | |
This diagram might clarify two points of common confusion: (1) the | |
difference between the class object, {\tt Point}, and the instance of | |
Point, {\tt obj}, and (2) the difference between the function object | |
created when {\tt instantiate} is defined, and the frame created with | |
it is called. | |
\section{Class Diagrams} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.7]{figs/lumpydemo7.pdf}} | |
\caption{Class diagram.} | |
\label{fig.lumpy7} | |
\end{figure} | |
\begin{figure} | |
\centerline | |
{\includegraphics[scale=0.7]{figs/lumpydemo8.pdf}} | |
\caption{Class diagram.} | |
\label{fig.lumpy8} | |
\end{figure} | |
Although I distinguish between state diagrams, stack diagrams and | |
object diagrams, they are mostly the same thing: they show the | |
state of a running program at a point in time. | |
\index{class diagram} | |
\index{diagram!class} | |
Class diagrams are different. They show the classes that make up a | |
program and the relationships between them. They are timeless in the | |
sense that they describe the program as a whole, not any particular | |
point in time. For example, if an instance of Class A generally | |
contains a reference to an instance of Class B, we say there is a | |
``HAS-A relationship'' between those classes. | |
\index{HAS-A relationship} | |
\index{class diagram} | |
\index{diagram!class} | |
\index{UML} | |
Here's an example that shows a HAS-A relationship. You can download | |
it from \url{http://thinkpython.com/code/lumpy_demo7.py}. | |
\begin{verbatim} | |
from swampy.Lumpy import Lumpy | |
lumpy = Lumpy() | |
lumpy.make_reference() | |
box = Rectangle() | |
box.width = 100.0 | |
box.height = 200.0 | |
box.corner = Point() | |
box.corner.x = 0.0 | |
box.corner.y = 0.0 | |
lumpy.class_diagram() | |
\end{verbatim} | |
Figure~\ref{fig.lumpy7} shows the result. | |
Each class is represented with a box that contains the name of the | |
class, any methods the class provides, any class variables, and | |
any instance variables. In this example, {\tt Rectangle} and {\tt Point} | |
have instance variables, but no methods or class variables. | |
The arrow from {\tt Rectangle} to {\tt Point} shows that Rectangles | |
contain an embedded Point. In addition, {\tt Rectangle} and {\tt | |
Point} both inherit from {\tt object}, which is represented in | |
the diagram with a triangle-headed arrow. | |
\index{IS-A relationship} | |
Here's a more complex example using my solution to Exercise~\ref{poker}. | |
You can download | |
the code from \url{http://thinkpython.com/code/lumpy_demo8.py}; | |
you will also need \url{http://thinkpython.com/code/PokerHand.py}. | |
\begin{verbatim} | |
from swampy.Lumpy import Lumpy | |
from PokerHand import * | |
lumpy = Lumpy() | |
lumpy.make_reference() | |
deck = Deck() | |
hand = PokerHand() | |
deck.move_cards(hand, 7) | |
lumpy.class_diagram() | |
\end{verbatim} | |
Figure~\ref{fig.lumpy8} shows the result. | |
{\tt PokerHand} inherits from {\tt Hand}, which inherits from {\tt Deck}. | |
Both {\tt Deck} and {\tt PokerHand} have Cards. | |
\index{Card class} | |
\index{Deck class} | |
\index{Hand class} | |
This diagram does not show that {\tt Hand} also has cards, because | |
in the program there are no instances of Hand. This example | |
demonstrates a limitation of Lumpy; it only knows about the | |
attributes and HAS-A relationships of objects that are instantiated. | |
\printindex | |
\clearemptydoublepage | |
%\blankpage | |
%\blankpage | |
%\blankpage | |
\end{document} |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment