Beginning Python - From Novice to Professional
Beginning Python - From Novice to Professional Beginning Python - From Novice to Professional
CHAPTER 19 ■ PLAYFUL PROGRAMMING 387 The log file in this example isn’t very detailed, but by configuring the logging module properly you can get log entries of different types (information, debug info, warnings, custom types . . .) or just relating to certain parts of your program, information about time and date and so forth. (You can even log to different locations, such as sockets.) You can also configure the logger to filter out some or most of the logging, so you get only what you need at any one time, without rewriting the program. Per default, only warnings are let through (which is why I had to explicitly set the level to logging.INFO). The logging module is quite sophisticated, and there is lots to be learned in the documentation (http://python.org/doc/lib/module-logging.html). If You Can’t Be Bothered “All this is well and good,” you may think, “but there’s no way I’m going to put that much effort into writing a simple little program. Configuration, testing, logging—it sounds really boring.” Well, that’s fine. You may not need it for simple programs. And even if you’re working on a larger project, you may not really need all of this at the beginning. I would say that the minimum is that you have some way of testing your program (as discussed in Chapter 16), even if it’s not based on automatic unit tests. For example, if you’re writing a program that automatically makes you coffee, you should have a coffee pot around, to see if it works. In the project chapters that follow, I don’t write full test suites, intricate logging facilities, and so forth. I present you with some simple test cases to demonstrate that the programs work, and that’s it. If you find the core idea of a project interesting, you should take it further—try to enhance and expand it. And in the process, you should consider the issues you read about in this chapter. Perhaps a configuration mechanism would be a good idea? Or a more extensive test suite? It’s up to you. I WANT TO LEARN MORE . . . Just in case you want more information on the art, craft, and philosophy of programming, here are some books that discuss these things more in depth; even if you don’t read every page of every book (I know I haven’t), just browsing in a few of these can give you quite a lot of insight: • The Pragmatic Programmer, by Andrew Hunt and David Thomas (Addison-Wesley, 2000) • Refactoring, by Kent Beck et al. (Addison-Wesley, 1999) • Design Patterns, by the “Gang of Four,” Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (Addison-Wesley, 1995) • Test-Driven Development: By Example, by Kent Beck (Addison-Wesley, 2002) • The Art of UNIX Programming, by Eric S. Raymond (Addison-Wesley, 2003) • Introduction to Algorithms, Second Edition, by Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, Clifford Stein (MIT Press, 2001) • The Art of Computer Programming, Volumes 1–3, by Donald Knuth (Addison-Wesley, 1998)
388 CHAPTER 19 ■ PLAYFUL PROGRAMMING Project Structure Now, about those projects . . . All the projects follow more or less the same structure, with the following sections: • What’s the problem? In this section the main goals of the project are outlined, including some background information. • Useful tools. Here, I describe modules, classes, functions, and so on that might be useful for the project. • Preparations. Here we perform any preparations necessary before starting to program. This may include setting up the necessary framework for testing the implementation. • First implementation. This is the first whack—a tentative implementation to learn more about the problem. • Second implementation. After the first implementation, you will probably have a better understanding of things, which will enable you to create a new and improved version. • Further exploration. Finally, I give pointers for further experimentation and exploration. A Quick Summary In this chapter, I described some general principles and techniques for programming in Python, conveniently lumped under the heading “Playful Programming.” Here are the highlights: Flexibility. When designing and programming, you should aim for flexibility. Instead of clinging to your initial ideas, you should be willing to, and even prepared to, revise and change every aspect of your program as you gain insight into the problem at hand. Prototyping. One important technique for learning about a problem and possible implementations is to write a simple version of your program to see how it works. In Python, this is so easy that you can write several prototypes in the time it takes to write a single version in many other languages. Configuration. Extracting constants from your program makes it easier to change them at some later point. Putting them in a configuration file makes it possible for your user to configure the program to behave like he or she wants it to. Logging. Logging can be quite useful for uncovering problems with your program—or just to monitor its ordinary behavior. You can implement simple logging yourself, using the print statement, but the safest bet is to use the logging module from the standard library. Project structure. All ten projects have a similar structure. First, the problem is outlined along with some useful tools for solving it. Then, after the necessary preparations (such as setting up tests), I present two successive implementations. Finally, I give pointers for further exploration.
- Page 367 and 368: 336 CHAPTER 15 ■ PYTHON AND THE W
- Page 369 and 370: 338 CHAPTER 15 ■ PYTHON AND THE W
- Page 372 and 373: CHAPTER 16 ■ ■ ■ Testing, 1-2
- Page 374 and 375: CHAPTER 16 ■ TESTING, 1-2-3 343 W
- Page 376 and 377: CHAPTER 16 ■ TESTING, 1-2-3 345 d
- Page 378 and 379: CHAPTER 16 ■ TESTING, 1-2-3 347 u
- Page 380 and 381: CHAPTER 16 ■ TESTING, 1-2-3 349 F
- Page 382 and 383: CHAPTER 16 ■ TESTING, 1-2-3 351 P
- Page 384 and 385: CHAPTER 16 ■ TESTING, 1-2-3 353 "
- Page 386: CHAPTER 16 ■ TESTING, 1-2-3 355 N
- Page 389 and 390: 358 CHAPTER 17 ■ EXTENDING PYTHON
- Page 391 and 392: 360 CHAPTER 17 ■ EXTENDING PYTHON
- Page 393 and 394: 362 CHAPTER 17 ■ EXTENDING PYTHON
- Page 395 and 396: 364 CHAPTER 17 ■ EXTENDING PYTHON
- Page 397 and 398: 366 CHAPTER 17 ■ EXTENDING PYTHON
- Page 399 and 400: 368 CHAPTER 17 ■ EXTENDING PYTHON
- Page 401 and 402: 370 CHAPTER 17 ■ EXTENDING PYTHON
- Page 404 and 405: CHAPTER 18 ■ ■ ■ Packaging Yo
- Page 406 and 407: CHAPTER 18 ■ PACKAGING YOUR PROGR
- Page 408 and 409: CHAPTER 18 ■ PACKAGING YOUR PROGR
- Page 410 and 411: CHAPTER 18 ■ PACKAGING YOUR PROGR
- Page 412 and 413: CHAPTER 19 ■ ■ ■ Playful Prog
- Page 414 and 415: CHAPTER 19 ■ PLAYFUL PROGRAMMING
- Page 416 and 417: CHAPTER 19 ■ PLAYFUL PROGRAMMING
- Page 420: CHAPTER 19 ■ PLAYFUL PROGRAMMING
- Page 423 and 424: 392 CHAPTER 20 ■ PROJECT 1: INSTA
- Page 425 and 426: 394 CHAPTER 20 ■ PROJECT 1: INSTA
- Page 427 and 428: 396 CHAPTER 20 ■ PROJECT 1: INSTA
- Page 429 and 430: 398 CHAPTER 20 ■ PROJECT 1: INSTA
- Page 431 and 432: 400 CHAPTER 20 ■ PROJECT 1: INSTA
- Page 433 and 434: 402 CHAPTER 20 ■ PROJECT 1: INSTA
- Page 435 and 436: 404 CHAPTER 20 ■ PROJECT 1: INSTA
- Page 437 and 438: 406 CHAPTER 20 ■ PROJECT 1: INSTA
- Page 439 and 440: 408 CHAPTER 20 ■ PROJECT 1: INSTA
- Page 442 and 443: CHAPTER 21 ■ ■ ■ Project 2: P
- Page 444 and 445: CHAPTER 21 ■ PROJECT 2: PAINTING
- Page 446 and 447: CHAPTER 21 ■ PROJECT 2: PAINTING
- Page 448 and 449: CHAPTER 21 ■ PROJECT 2: PAINTING
- Page 450 and 451: CHAPTER 21 ■ PROJECT 2: PAINTING
- Page 452 and 453: CHAPTER 22 ■ ■ ■ Project 3: X
- Page 454 and 455: CHAPTER 22 ■ PROJECT 3: XML FOR A
- Page 456 and 457: CHAPTER 22 ■ PROJECT 3: XML FOR A
- Page 458 and 459: CHAPTER 22 ■ PROJECT 3: XML FOR A
- Page 460 and 461: CHAPTER 22 ■ PROJECT 3: XML FOR A
- Page 462 and 463: CHAPTER 22 ■ PROJECT 3: XML FOR A
- Page 464 and 465: CHAPTER 22 ■ PROJECT 3: XML FOR A
- Page 466 and 467: CHAPTER 22 ■ PROJECT 3: XML FOR A
388 CHAPTER 19 ■ PLAYFUL PROGRAMMING<br />
Project Structure<br />
Now, about those projects . . . All the projects follow more or less the same structure, with the<br />
following sections:<br />
• What’s the problem? In this section the main goals of the project are outlined, including<br />
some background information.<br />
• Useful <strong>to</strong>ols. Here, I describe modules, classes, functions, and so on that might be useful<br />
for the project.<br />
• Preparations. Here we perform any preparations necessary before starting <strong>to</strong> program.<br />
This may include setting up the necessary framework for testing the implementation.<br />
• First implementation. This is the first whack—a tentative implementation <strong>to</strong> learn more<br />
about the problem.<br />
• Second implementation. After the first implementation, you will probably have a better<br />
understanding of things, which will enable you <strong>to</strong> create a new and improved version.<br />
• Further exploration. Finally, I give pointers for further experimentation and exploration.<br />
A Quick Summary<br />
In this chapter, I described some general principles and techniques for programming in <strong>Python</strong>,<br />
conveniently lumped under the heading “Playful Programming.” Here are the highlights:<br />
Flexibility. When designing and programming, you should aim for flexibility. Instead of<br />
clinging <strong>to</strong> your initial ideas, you should be willing <strong>to</strong>, and even prepared <strong>to</strong>, revise and<br />
change every aspect of your program as you gain insight in<strong>to</strong> the problem at hand.<br />
Pro<strong>to</strong>typing. One important technique for learning about a problem and possible implementations<br />
is <strong>to</strong> write a simple version of your program <strong>to</strong> see how it works. In <strong>Python</strong>, this<br />
is so easy that you can write several pro<strong>to</strong>types in the time it takes <strong>to</strong> write a single version<br />
in many other languages.<br />
Configuration. Extracting constants from your program makes it easier <strong>to</strong> change them at<br />
some later point. Putting them in a configuration file makes it possible for your user <strong>to</strong><br />
configure the program <strong>to</strong> behave like he or she wants it <strong>to</strong>.<br />
Logging. Logging can be quite useful for uncovering problems with your program—or just<br />
<strong>to</strong> moni<strong>to</strong>r its ordinary behavior. You can implement simple logging yourself, using the<br />
print statement, but the safest bet is <strong>to</strong> use the logging module from the standard library.<br />
Project structure. All ten projects have a similar structure. First, the problem is outlined<br />
along with some useful <strong>to</strong>ols for solving it. Then, after the necessary preparations (such as<br />
setting up tests), I present two successive implementations. Finally, I give pointers for<br />
further exploration.