Beginning Python - From Novice to Professional

Beginning Python - From Novice to Professional Beginning Python - From Novice to Professional

16.01.2014 Views

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.

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.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!