git-basics-tutorial/thinkpython2019.html at master · etyme/git-basics-tutorial

History

690 lines (641 loc) · 47 KB

Raw

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

316

317

318

319

320

321

322

323

324

325

326

327

328

329

330

331

332

333

334

335

336

337

338

339

340

341

342

343

344

345

346

347

348

349

350

351

352

353

354

355

356

357

358

359

360

361

362

363

364

365

366

367

368

369

370

371

372

373

374

375

376

377

378

379

380

381

382

383

384

385

386

387

388

389

390

391

392

393

394

395

396

397

398

399

400

401

402

403

404

405

406

407

408

409

410

411

412

413

414

415

416

417

418

419

420

421

422

423

424

425

426

427

428

429

430

431

432

433

434

435

436

437

438

439

440

441

442

443

444

445

446

447

448

449

450

451

452

453

454

455

456

457

458

459

460

461

462

463

464

465

466

467

468

469

470

471

472

473

474

475

476

477

478

479

480

481

482

483

484

485

486

487

488

489

490

491

492

493

494

495

496

497

498

499

500

501

502

503

504

505

506

507

508

509

510

511

512

513

514

515

516

517

518

519

520

521

522

523

524

525

526

527

528

529

530

531

532

533

534

535

536

537

538

539

540

541

542

543

544

545

546

547

548

549

550

551

552

553

554

555

556

557

558

559

560

561

562

563

564

565

566

567

568

569

570

571

572

573

574

575

576

577

578

579

580

581

582

583

584

585

586

587

588

589

590

591

592

593

594

595

596

597

598

599

600

601

602

603

604

605

606

607

608

609

610

611

612

613

614

615

616

617

618

619

620

621

622

623

624

625

626

627

628

629

630

631

632

633

634

635

636

637

638

639

640

641

642

643

644

645

646

647

648

649

650

651

652

653

654

655

656

657

658

659

660

661

662

663

664

665

666

667

668

669

670

671

672

673

674

675

676

677

678

679

680

681

682

683

684

685

686

687

688

689

690

<!DOCTYPE html>

<html>

<head>

<title>Inheritance</title>

</head>

<body>

Toggle navigation

</button>

<a class="navbar-brand" href="#">Think Python - How to Think like a Computer Scientist (2e) by Allen B. Downey</a>

</div>

<div>

</ul>

<div>

</div>

</nav>

<table>

<tr>

</td>

<h1 class="chapter" id="sec209">Chapter&#XA0;18&#XA0;&#XA0;Inheritance</h1>

The language feature most often associated with object-oriented

programming is inheritance. Inheritance is the ability to

define a new class that is a modified version of an existing class.

In this chapter I demonstrate inheritance using classes that represent

playing cards, decks of cards, and poker hands.

<a id="hevea_default1546"></a>If you don&#X2019;t play

poker, you can read about it at

<a href="http://en.wikipedia.org/wiki/Poker">http://en.wikipedia.org/wiki/Poker</a>, but you don&#X2019;t have to; I&#X2019;ll

tell you what you need to know for the exercises.Code examples from

this chapter are available from

<a href="http://thinkpython2.com/code/Card.py">http://thinkpython2.com/code/Card.py</a>.

<h2 class="section" id="sec210">18.1&#XA0;&#XA0;Card objects</h2>

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.

<a id="hevea_default1548"></a>If we want to define a new object to represent a playing card, it is

obvious what the attributes should be: rank and

suit. It is not as obvious what type the attributes

should be. One possibility is to use strings containing words like

<code>'Spade'</code> for suits and <code>'Queen'</code> 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.

<a id="hevea_default1552"></a>An alternative is to use integers to encode the ranks and suits.

In this context, &#X201C;encode&#X201D; 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 &#X201C;encryption&#X201D;).For example, this table shows the suits and the corresponding integer

codes:<table class="c001 cellpading0"><tr><td class="c013">Spades</td><td class="c012">&#X21A6;</td><td class="c013">3 </td></tr>

<tr><td class="c013">Hearts</td><td class="c012">&#X21A6;</td><td class="c013">2 </td></tr>

<tr><td class="c013">Diamonds</td><td class="c012">&#X21A6;</td><td class="c013">1 </td></tr>

<tr><td class="c013">Clubs</td><td class="c012">&#X21A6;</td><td class="c013">0

</td></tr>

</table>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:<table class="c001 cellpading0"><tr><td class="c013">Jack</td><td class="c012">&#X21A6;</td><td class="c013">11 </td></tr>

<tr><td class="c013">Queen</td><td class="c012">&#X21A6;</td><td class="c013">12 </td></tr>

</table>I am using the &#X21A6;&#XA0;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&#X2019;t appear explicitly in the code.

<a id="hevea_default1554"></a>The class definition for Card looks like this:<pre class="verbatim">class Card:

"""Represents a standard playing card."""

def __init__(self, suit=0, rank=2):

self.suit = suit

self.rank = rank

</pre>As usual, the init method takes an optional

parameter for each attribute. The default card is

the 2 of Clubs.

<a id="hevea_default1556"></a>To create a Card, you call Card with the

suit and rank of the card you want.<pre class="verbatim">queen_of_diamonds = Card(1, 12)

</pre>

<h2 class="section" id="sec211">18.2&#XA0;&#XA0;Class attributes</h2>

<a id="hevea_default1558"></a>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 class

attributes:<pre class="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])

</pre>Variables like <code>suit_names</code> and <code>rank_names</code>, which are

defined inside a class but outside of any method, are called

class attributes because they are associated with the class object

Card.

<a id="hevea_default1560"></a>This term distinguishes them from variables like suit and rank, which are called instance attributes because they are

associated with a particular instance.

<a id="hevea_default1561"></a>Both kinds of attribute are accessed using dot notation. For

example, in <code>__str__</code>, self is a Card object,

and self.rank is its rank. Similarly, Card

is a class object, and <code>Card.rank_names</code> is a

list of strings associated with the class.Every card has its own suit and rank, but there

is only one copy of <code>suit_names</code> and <code>rank_names</code>.Putting it all together, the expression

<code>Card.rank_names[self.rank]</code> means &#X201C;use the attribute rank

from the object self as an index into the list <code>rank_names</code>

from the class Card, and select the appropriate string.&#X201D;The first element of <code>rank_names</code> is None because there

is no card with rank zero. By including None as a place-keeper,

we get a mapping with the nice property that the index 2 maps to the

string <code>'2'</code>, 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:<pre class="verbatim">>>> card1 = Card(2, 11)

>>> print(card1)

Jack of Hearts

</pre><blockquote class="figure"><div class="center"><hr class="c019"></div>

<div class="caption"><table class="c001 cellpading0"><tr><td class="c018">Figure 18.1: Object diagram.</td></tr>

</table></div>

<div class="center"><hr class="c019"></div></blockquote>Figure&#XA0;<a href="thinkpython2019.html#fig.card1">18.1</a> is a diagram of the Card class object and

one Card instance. Card is a class object; its type is type. card1 is an instance of Card, so its type is

Card. To save space, I didn&#X2019;t draw the contents of

<code>suit_names</code> and <code>rank_names</code>. <a id="hevea_default1562"></a>

<h2 class="section" id="sec212">18.3&#XA0;&#XA0;Comparing cards</h2>

<a id="hevea_default1567"></a>For built-in types, there are relational operators

(<, >, ==, etc.)

that compare

values and determine when one is greater than, less than, or equal to

another. For programmer-defined types, we can override the behavior of

the built-in operators by providing a method named

<code>__lt__</code>, which stands for &#X201C;less than&#X201D;.

<a id="hevea_default1569"></a><code>__lt__</code> takes two parameters, self and other,

and True if self is strictly less than other.

<a id="hevea_default1571"></a>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&#X2019;ll make the arbitrary choice that suit is more

important, so all of the Spades outrank all of the Diamonds,

and so on.

<a id="hevea_default1573"></a>With that decided, we can write <code>__lt__</code>:<pre class="verbatim"># inside class Card:

def __lt__(self, other):

# check the suits

if self.suit < other.suit: return True

if self.suit > other.suit: return False

# suits are the same... check ranks

return self.rank < other.rank

</pre>You can write this more concisely using tuple comparison:

<a id="hevea_default1575"></a><pre class="verbatim"># inside class Card:

def __lt__(self, other):

t1 = self.suit, self.rank

t2 = other.suit, other.rank

return t1 < t2

</pre>As an exercise, write an <code>__lt__</code> method for Time objects. You

can use tuple comparison, but you also might consider

comparing integers.

<h2 class="section" id="sec213">18.4&#XA0;&#XA0;Decks</h2>

<a id="hevea_default1577"></a>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.

<a id="hevea_default1579"></a>The following is a class definition for Deck. The

init method creates the attribute cards and generates

the standard set of fifty-two cards:

<a id="hevea_default1583"></a><pre class="verbatim">class Deck:

def __init__(self):

self.cards = []

for suit in range(4):

for rank in range(1, 14):

card = Card(suit, rank)

self.cards.append(card)

</pre>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 self.cards.

<h2 class="section" id="sec214">18.5&#XA0;&#XA0;Printing the deck</h2>

<a id="hevea_default1587"></a>Here is a <code>__str__</code> method for Deck:<pre class="verbatim">#inside class Deck:

def __str__(self):

res = []

for card in self.cards:

res.append(str(card))

return '\n'.join(res)

</pre>This method demonstrates an efficient way to accumulate a large

string: building a list of strings and then using the string method

join. The built-in function str invokes the

<code>__str__</code> method on each card and returns the string

representation. <a id="hevea_default1588"></a> <a id="hevea_default1589"></a>

<a id="hevea_default1590"></a> <a id="hevea_default1591"></a> <a id="hevea_default1592"></a>Since we invoke join on a newline character, the cards

are separated by newlines. Here&#X2019;s what the result looks like:<pre class="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

</pre>Even though the result appears on 52 lines, it is

one long string that contains newlines.

<h2 class="section" id="sec215">18.6&#XA0;&#XA0;Add, remove, shuffle and sort</h2>

To deal cards, we would like a method that

removes a card from the deck and returns it.

The list method pop provides a convenient way to do that:

<a id="hevea_default1594"></a><pre class="verbatim">#inside class Deck:

def pop_card(self):

return self.cards.pop()

</pre>Since pop removes the last card in the list, we are

dealing from the bottom of the deck.

<a id="hevea_default1596"></a>To add a card, we can use the list method append:<pre class="verbatim">#inside class Deck:

def add_card(self, card):

self.cards.append(card)

</pre>A method like this that uses another method without doing

much work is sometimes called a veneer. The metaphor

comes from woodworking, where a veneer is a thin

layer of good quality wood glued to the surface of a cheaper piece of

wood to improve the appearance.

<a id="hevea_default1597"></a>In this case <code>add_card</code> is a &#X201C;thin&#X201D; method that expresses

a list operation in terms appropriate for decks. It

improves the appearance, or interface, of the

implementation.As another example, we can write a Deck method named shuffle

using the function shuffle from the random module:

<a id="hevea_default1601"></a><pre class="verbatim"># inside class Deck:

def shuffle(self):

random.shuffle(self.cards)

</pre>Don&#X2019;t forget to import random.As an exercise, write a Deck method named sort that uses the

list method sort to sort the cards in a Deck. sort

uses the <code>__lt__</code> method we defined to determine the order.

<h2 class="section" id="sec216">18.7&#XA0;&#XA0;Inheritance</h2>

<a id="hevea_default1605"></a>Inheritance is the ability to define a new class that is a modified

version of an existing class. As an example, let&#X2019;s say we want a

class to represent a &#X201C;hand&#X201D;, that is, the cards held by one player.

A hand is similar to a deck: both are made up of a collection 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&#X2019;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&#X2014;similar, but different&#X2014;lends

itself to inheritance.

To define a new class that inherits from an existing class,

you put the name of the existing class in parentheses:

<a id="hevea_default1610"></a><pre class="verbatim">class Hand(Deck):

"""Represents a hand of playing cards."""

</pre>This definition indicates that Hand inherits from Deck;

that means we can use methods like <code>pop_card</code> and <code>add_card</code>

for Hands as well as Decks.When a new class inherits from an existing one, the existing

one is called the parent and the new class is

called the child.

<a id="hevea_default1613"></a>In this example, Hand inherits <code>__init__</code> from Deck,

but it doesn&#X2019;t really do what we want: instead of populating the hand

with 52 new cards, the init method for Hands should initialize cards with an empty list. <a id="hevea_default1614"></a> <a id="hevea_default1615"></a>

<a id="hevea_default1616"></a>If we provide an init method in the Hand class, it overrides the

one in the Deck class:<pre class="verbatim"># inside class Hand:

def __init__(self, label=''):

self.cards = []

self.label = label

</pre>When you create a Hand, Python invokes this init method, not the

one in Deck.<pre class="verbatim">>>> hand = Hand('new hand')

>>> hand.cards

[]

>>> hand.label

'new hand'

</pre>The other methods are inherited from Deck, so we can use

<code>pop_card</code> and <code>add_card</code> to deal a card:<pre class="verbatim">>>> deck = Deck()

>>> card = deck.pop_card()

>>> hand.add_card(card)

>>> print(hand)

King of Spades

</pre>A natural next step is to encapsulate this code in a method

called <code>move_cards</code>:

<a id="hevea_default1617"></a><pre class="verbatim">#inside class Deck:

def move_cards(self, hand, num):

for i in range(num):

hand.add_card(self.pop_card())

</pre><code>move_cards</code> takes two arguments, a Hand object and the number of

cards to deal. It modifies both self and hand, and

returns None.In some games, cards are moved from one hand to another,

or from a hand back to the deck. You can use <code>move_cards</code>

for any of these operations: self can be either a Deck

or a Hand, and hand, despite the name, can also be a Deck.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 design 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 spread across several modules.

Also, many of the things that can be done using inheritance can be

done as well or better without it.

<h2 class="section" id="sec217">18.8&#XA0;&#XA0;Class diagrams</h2>

<a id="class.diagram"></a>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:<ul class="itemize"><li class="li-itemize">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 HAS-A, as in, &#X201C;a Rectangle

has a Point.&#X201D;</li><li class="li-itemize">One class might inherit from another. This relationship

is called IS-A, as in, &#X201C;a Hand is a kind of a Deck.&#X201D;</li><li class="li-itemize">One class might depend on another in the sense that objects

in one class take objects in the second class as parameters, or

use objects in the second class as part of a computation. This

kind of relationship is called a dependency.</li></ul>

<a id="hevea_default1621"></a>A class diagram is a graphical representation of these

relationships. For example, Figure&#XA0;<a href="thinkpython2019.html#fig.class1">18.2</a> shows the

relationships between Card, Deck and Hand.<blockquote class="figure"><div class="center"><hr class="c019"></div>

<div class="caption"><table class="c001 cellpading0"><tr><td class="c018">Figure 18.2: Class diagram.</td></tr>

</table></div>

<div class="center"><hr class="c019"></div></blockquote>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.

<a id="hevea_default1622"></a>The star (*) near the arrow head is a

multiplicity; it indicates how many Cards a Deck has.

A multiplicity can be a simple number, like 52, a range,

like 5..7 or a star, which indicates that a Deck can

have any number of Cards.There are no dependencies in this diagram. They would normally

be shown with a dashed arrow. Or if there are a lot of

dependencies, they are sometimes omitted.A more detailed diagram might show that a Deck actually

contains a list of Cards, but built-in types

like list and dict are usually not included in class diagrams.

<h2 class="section" id="sec218">18.9&#XA0;&#XA0;Debugging</h2>

<a id="hevea_default1623"></a>Inheritance can make debugging difficult because when you invoke a

method on an object, it might be hard to figure out which method will

be invoked.

<a id="hevea_default1624"></a>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

shuffle, you might get the one defined in Deck,

but if any of the subclasses override this method, you&#X2019;ll

get that version instead. This behavior is usually a good

thing, but it can be confusing.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 Deck.shuffle prints a

message that says something like Running Deck.shuffle, then as

the program runs it traces the flow of execution.

<a id="hevea_default1625"></a>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:<pre class="verbatim">def find_defining_class(obj, meth_name):

for ty in type(obj).mro():

if meth_name in ty.__dict__:

return ty

</pre>Here&#X2019;s an example:<pre class="verbatim">>>> hand = Hand()

>>> find_defining_class(hand, 'shuffle')

</pre>So the shuffle method for this Hand is the one in Deck.

<a id="hevea_default1628"></a><code>find_defining_class</code> uses the mro method to get the list

of class objects (types) that will be searched for methods. &#X201C;MRO&#X201D;

stands for &#X201C;method resolution order&#X201D;, which is the sequence of

classes Python searches to &#X201C;resolve&#X201D; a method name.Here&#X2019;s a design suggestion: when 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 follow this rule, you

will find that any function designed to work with an instance of a

parent class, like a Deck, will also work with instances of child

classes like a Hand and PokerHand.

<a id="hevea_default1632"></a>If you violate this rule, which is called the &#X201C;Liskov substitution

principle&#X201D;, your code will collapse like (sorry) a house of cards.

<h2 class="section" id="sec219">18.10&#XA0;&#XA0;Data encapsulation</h2>

The previous chapters demonstrate a development plan we might call

&#X201C;object-oriented design&#X201D;. We identified objects we needed&#X2014;like

Point, Rectangle and Time&#X2014;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).

<a id="hevea_default1634"></a>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 data encapsulation.

<a id="hevea_default1635"></a>Markov analysis, from Section&#XA0;<a href="thinkpython2014.html#markov">13.8</a>, provides a good example.

If you download my code from <a href="http://thinkpython2.com/code/markov.py">http://thinkpython2.com/code/markov.py</a>,

you&#X2019;ll see that it uses two global variables&#X2014;<code>suffix_map</code> and

<code>prefix</code>&#X2014;that are read and written from several functions.<pre class="verbatim">suffix_map = {}

prefix = ()

</pre>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&#X2019;s what that looks like:<pre class="verbatim">class Markov:

def __init__(self):

self.suffix_map = {}

self.prefix = ()

</pre>Next, we transform the functions into methods. For example,

here&#X2019;s <code>process_word</code>:<pre class="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)

</pre>Transforming a program like this&#X2014;changing the design without

changing the behavior&#X2014;is another example of refactoring

(see Section&#XA0;<a href="thinkpython2005.html#refactoring">4.7</a>).

<a id="hevea_default1636"></a>This example suggests a development plan for designing objects and

methods:<ol class="enumerate" type=1><li class="li-enumerate">Start by writing functions that read and write global

variables (when necessary).</li><li class="li-enumerate">Once you get the program working, look for associations

between global variables and the functions that use them.</li><li class="li-enumerate">Encapsulate related variables as attributes of an object.</li><li class="li-enumerate">Transform the associated functions into methods of the new

class.</li></ol>As an exercise, download my Markov code from

<a href="http://thinkpython2.com/code/markov.py">http://thinkpython2.com/code/markov.py</a>, and follow the steps

described above to encapsulate the global variables as attributes of a

new class called Markov. Solution:

<a href="http://thinkpython2.com/code/Markov.py">http://thinkpython2.com/code/Markov.py</a> (note the capital M).

<h2 class="section" id="sec220">18.11&#XA0;&#XA0;Glossary</h2>

<dl class="description"><dt class="dt-description">encode:</dt><dd class="dd-description"> To represent one set of values using another

set of values by constructing a mapping between them.

<a id="hevea_default1637"></a></dd><dt class="dt-description">class attribute:</dt><dd class="dd-description"> An attribute associated with a class

object. Class attributes are defined inside

a class definition but outside any method.

<a id="hevea_default1639"></a></dd><dt class="dt-description">instance attribute:</dt><dd class="dd-description"> An attribute associated with an

instance of a class.

<a id="hevea_default1641"></a></dd><dt class="dt-description">veneer:</dt><dd class="dd-description"> A method or function that provides a different

interface to another function without doing much computation.

<a id="hevea_default1642"></a></dd><dt class="dt-description">inheritance:</dt><dd class="dd-description"> The ability to define a new class that is a

modified version of a previously defined class.

<a id="hevea_default1643"></a></dd><dt class="dt-description">parent class:</dt><dd class="dd-description"> The class from which a child class inherits.

<a id="hevea_default1644"></a></dd><dt class="dt-description">child class:</dt><dd class="dd-description"> A new class created by inheriting from an

existing class; also called a &#X201C;subclass&#X201D;.

<a id="hevea_default1646"></a></dd><dt class="dt-description">IS-A relationship:</dt><dd class="dd-description"> A relationship between a child class

and its parent class.

<a id="hevea_default1647"></a></dd><dt class="dt-description">HAS-A relationship:</dt><dd class="dd-description"> A relationship between two classes

where instances of one class contain references to instances of

the other.

<a id="hevea_default1648"></a></dd><dt class="dt-description">dependency:</dt><dd class="dd-description"> A relationship between two classes

where instances of one class use instances of the other class,

but do not store them as attributes.

<a id="hevea_default1649"></a></dd><dt class="dt-description">class diagram:</dt><dd class="dd-description"> A diagram that shows the classes in a program

and the relationships between them.

<a id="hevea_default1651"></a></dd><dt class="dt-description">multiplicity:</dt><dd class="dd-description"> A notation in a class diagram that shows, for

a HAS-A relationship, how many references there are to instances

of another class.

<a id="hevea_default1652"></a></dd><dt class="dt-description">data encapsulation:</dt><dd class="dd-description"> A program development plan that

involves a prototype using global variables and a final version

that makes the global variables into instance attributes.

<h2 class="section" id="sec221">18.12&#XA0;&#XA0;Exercises</h2>

<div class="theorem">Exercise&#XA0;1&#XA0;&#XA0;

For the following program, draw a UML class diagram that shows

these classes and the relationships among them.<pre class="verbatim">class PingPongParent:

pass

class Ping(PingPongParent):

def __init__(self, pong):

self.pong = pong

class Pong(PingPongParent):

def __init__(self, pings=None):

if pings is None:

self.pings = []

else:

self.pings = pings

def add_ping(self, ping):

self.pings.append(ping)

pong = Pong()

ping = Ping(pong)

pong.add_ping(ping)

</pre></div><div class="theorem">Exercise&#XA0;2&#XA0;&#XA0;

Write a Deck method called <code>deal_hands</code> that

takes two parameters, the number of hands and the number of cards per

hand. It should create the appropriate number of Hand objects, deal

the appropriate number of cards per hand, and return a list of Hands.

</div><div class="theorem">Exercise&#XA0;3&#XA0;&#XA0;

<a id="poker"></a>The following are the possible hands in poker, in increasing order

of value and decreasing order of probability:

<a id="hevea_default1655"></a><dl class="description"><dt class="dt-description">pair:</dt><dd class="dd-description"> two cards with the same rank

</dd><dt class="dt-description">two pair:</dt><dd class="dd-description"> two pairs of cards with the same rank

</dd><dt class="dt-description">three of a kind:</dt><dd class="dd-description"> three cards with the same rank

</dd><dt class="dt-description">straight:</dt><dd class="dd-description"> five cards with ranks in sequence (aces can

be high or low, so Ace-2-3-4-5 is a straight and so is 10-Jack-Queen-King-Ace, but Queen-King-Ace-2-3 is not.)

</dd><dt class="dt-description">flush:</dt><dd class="dd-description"> five cards with the same suit

</dd><dt class="dt-description">full house:</dt><dd class="dd-description"> three cards with one rank, two cards with another

</dd><dt class="dt-description">four of a kind:</dt><dd class="dd-description"> four cards with the same rank

</dd><dt class="dt-description">straight flush:</dt><dd class="dd-description"> five cards in sequence (as defined above) and

with the same suit

</dd></dl>

The goal of these exercises is to estimate

the probability of drawing these various hands.<ol class="enumerate" type=1><li class="li-enumerate">Download the following files from <a href="http://thinkpython2.com/code">http://thinkpython2.com/code</a>:<dl class="description"><dt class="dt-description">Card.py</dt><dd class="dd-description">: A complete version of the Card,

Deck and Hand classes in this chapter.</dd><dt class="dt-description">PokerHand.py</dt><dd class="dd-description">: An incomplete implementation of a class

that represents a poker hand, and some code that tests it.</dd></dl></li><li class="li-enumerate">If you run 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.</li><li class="li-enumerate">Add methods to PokerHand.py named <code>has_pair</code>,

<code>has_twopair</code>, etc. that return True or False according to

whether or not the hand meets the relevant criteria. Your code should

work correctly for &#X201C;hands&#X201D; that contain any number of cards

(although 5 and 7 are the most common sizes).</li><li class="li-enumerate">Write a method named classify that figures out

the highest-value classification for a hand and sets the

label attribute accordingly. For example, a 7-card hand

might contain a flush and a pair; it should be labeled &#X201C;flush&#X201D;.</li><li class="li-enumerate">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 PokerHand.py that shuffles a deck of

cards, divides it into hands, classifies the hands, and counts the

number of times various classifications appear.</li><li class="li-enumerate">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 <a href="http://en.wikipedia.org/wiki/Hand_rankings">http://en.wikipedia.org/wiki/Hand_rankings</a>.</li></ol>Solution: <a href="http://thinkpython2.com/code/PokerHandSoln.py">http://thinkpython2.com/code/PokerHandSoln.py</a>.

</div>

</td>

<h4>Are you using one of our books in a class?</h4> We'd like to know

about it. Please consider filling out <a href="http://spreadsheets.google.com/viewform?formkey=dC0tNUZkMjBEdXVoRGljNm9FRmlTMHc6MA" onClick="javascript: pageTracker._trackPageview('/outbound/survey');">this short survey</a>.

<a rel="nofollow" href="http://www.amazon.com/gp/product/1491938455/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1491938455&linkCode=as2&tag=greenteapre01-20&linkId=2JJH4SWCAVVYSQHO">Think DSP</a><img class="c003" src="http://ir-na.amazon-adsystem.com/e/ir?t=greenteapre01-20&l=as2&o=1&a=1491938455" width="1" height="1" border="0" alt="">

<a rel="nofollow" href="http://www.amazon.com/gp/product/1491929561/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1491929561&linkCode=as2&tag=greenteapre01-20&linkId=ZY6MAYM33ZTNSCNZ">Think Java</a><img class="c003" src="http://ir-na.amazon-adsystem.com/e/ir?t=greenteapre01-20&l=as2&o=1&a=1491929561" width="1" height="1" border="0" alt="">

<a href="http://www.amazon.com/gp/product/1449370780/ref=as_li_qf_sp_asin_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1449370780&linkCode=as2&tag=greenteapre01-20">Think Bayes</a><img class="c003" src="http://ir-na.amazon-adsystem.com/e/ir?t=greenteapre01-20&l=as2&o=1&a=1449370780" width="1" height="1" border="0" alt="">

<a rel="nofollow" href="http://www.amazon.com/gp/product/1491939362/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1491939362&linkCode=as2&tag=greenteapre01-20&linkId=FJKSQ3IHEMY2F2VA">Think Python 2e</a><img class="c003" src="http://ir-na.amazon-adsystem.com/e/ir?t=greenteapre01-20&l=as2&o=1&a=1491939362" width="1" height="1" border="0" alt="">

<a href="http://www.amazon.com/gp/product/1491907339/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1491907339&linkCode=as2&tag=greenteapre01-20&linkId=O7WYM6H6YBYUFNWU">Think Stats 2e</a><img class="c003" src="http://ir-na.amazon-adsystem.com/e/ir?t=greenteapre01-20&l=as2&o=1&a=1491907339" width="1" height="1" border="0" alt="">

<a href="http://www.amazon.com/gp/product/1449314635/ref=as_li_tf_tl?ie=UTF8&tag=greenteapre01-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1449314635">Think Complexity</a><img class="c003" src="http://www.assoc-amazon.com/e/ir?t=greenteapre01-20&l=as2&o=1&a=1449314635" width="1" height="1" border="0" alt="">

</td>

</tr>

</table>

Toggle navigation

</button>

<a class="navbar-brand" href="#">Think Python - How to Think like a Computer Scientist (2e) by Allen B. Downey</a>

</div>

<div>

</ul>

<div>

</div>

</nav></body>

</html>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

FilesExpand file tree

thinkpython2019.html

Latest commit

History

thinkpython2019.html

File metadata and controls