•  Table of Contents
•  Index
•  Reviews
•  Reader Reviews
  Errata
 

777

Programming Python, 2nd Edition
By Mark Lutz
   
Publisher : O'Reilly
Pub Date : March 2001
ISBN : 0-596-00085-5
Pages : 1256

Programming Python focuses on advanced applications of Python. Endorsed by Python creator Guido van Rossum, it demonstrates advanced Python techniques, and addresses software design issues such as reusability and object-oriented programming. The enclosed platform-neutral CD-ROM has book examples and various Python-related packages, including the full Python Version 2.0 source code distribution.

Copyright

Foreword

Preface

"And Now for Something Completely Different . . . Again"

Signs of the Python Times

Why This Edition?

Major Changes in This Edition

Using the Examples and Demos

Conventions Used in This Book

Where to Look for Updates

Contacting O'Reilly

Acknowledgments

Chapter 1. Introducing Python

1.1 "And Now for Something Completely Different"

1.2 The Life of Python

1.3 The Compulsory Features List

1.4 What's Python Good For?

1.5 What's Python Not Good For?

Part I: System Interfaces

Chapter 2. System Tools

2.1 "The os.path to Knowledge"

2.2 Why Python Here?

2.3 System Scripting Overview

2.4 The sys Module

2.5 The os Module

2.6 Script Execution Context

2.7 Current Working Directory

2.8 Command-Line Arguments

2.9 Shell Environment Variables

2.10 Standard Streams

2.11 File Tools

2.12 Directory Tools

Chapter 3. Parallel System Tools

3.1 "Telling the Monkeys What to Do"

3.2 Forking Processes

3.3 Threads

3.4 Program Exits

3.5 Interprocess Communication

3.6 Pipes

3.7 Signals

3.8 Launching Programs on Windows

3.9 Other System Tools

Chapter 4. Larger System Examples I

4.1 "Splits and Joins and Alien Invasions"

4.2 Splitting and Joining Files

4.3 Generating Forward-Link Web Pages

4.4 A Regression Test Script

4.5 Packing and Unpacking Files

4.6 User-Friendly Program Launchers

Chapter 5. Larger System Examples II

5.1 "The Greps of Wrath"

5.2 Fixing DOS Line Ends

5.3 Fixing DOS Filenames

5.4 Searching Directory Trees

5.5 Visitor: Walking Trees Generically

5.6 Copying Directory Trees

5.7 Deleting Directory Trees

5.8 Comparing Directory Trees

Part II: GUI Programming

Chapter 6. Graphical User Interfaces

6.1 "Here's Looking at You, Kid"

6.2 Python GUI Development Options

6.3 Tkinter Overview

6.4 Climbing the GUI Learning Curve

6.5 The End of the Tutorial

6.6 Python/Tkinter for Tcl/Tk Converts

Chapter 7. A Tkinter Tour, Part 1

7.1 "Widgets and Gadgets and GUIs, Oh My!"

7.2 Configuring Widget Appearance

7.3 Toplevel Windows

7.4 Dialogs

7.5 Binding Events

7.6 Message and Entry

7.7 Checkbutton, Radiobutton, and Scale

7.8 Running GUI Code Three Ways

7.9 Images

Chapter 8. A Tkinter Tour, Part 2

8.1 "On Today's Menu: Spam, Spam, and Spam"

8.2 Menus

8.3 Listboxes and Scrollbars

8.4 Text

8.5 Canvas

8.6 Grids

8.7 Time Tools, Threads, and Animation

8.8 The End of the Tour

8.9 The PyDemos and PyGadgets Launchers

Chapter 9. Larger GUI Examples

9.1 "Building a Better Mouse Trap"

9.2 Advanced GUI Coding Techniques

9.3 Complete Program Examples

9.4 PyEdit: A Text Editor Program/Object

9.5 PyView: An Image and Notes Slideshow

9.6 PyDraw: Painting and Moving Graphics

9.7 PyClock: An Analog/Digital Clock Widget

9.8 PyToe: A Tic-Tac-Toe Game Widget

9.9 Where to Go from Here

Part III: Internet Scripting

Chapter 10. Network Scripting

10.1 "Tune in, Log on, and Drop out"

10.2 Plumbing the Internet

10.3 Socket Programming

10.4 Handling Multiple Clients

10.5 A Simple Python File Server

Chapter 11. Client-Side Scripting

11.1 "Socket to Me!"

11.2 Transferring Files over the Net

11.3 Processing Internet Email

11.4 The PyMailGui Email Client

11.5 Other Client-Side Tools

Chapter 12. Server-Side Scripting

12.1 "Oh What a Tangled Web We Weave"

12.2 What's a Server-Side CGI Script?

12.3 Climbing the CGI Learning Curve

12.4 The Hello World Selector

12.5 Coding for Maintainability

12.6 More on HTML and URL Escapes

12.7 Sending Files to Clients and Servers

Chapter 13. Larger Web Site Examples I

13.1 "Things to Do When Visiting Chicago"

13.2 The PyMailCgi Web Site

13.3 The Root Page

13.4 Sending Mail by SMTP

13.5 Reading POP Email

13.6 Utility Modules

13.7 CGI Script Trade-offs

Chapter 14. Larger Web Site Examples II

14.1 "Typos Happen"

14.2 The PyErrata Web Site

14.3 The Root Page

14.4 Browsing PyErrata Reports

14.5 Submitting PyErrata Reports

14.6 PyErrata Database Interfaces

14.7 Administrative Tools

14.8 Designing for Reuse and Growth

Chapter 15. Advanced Internet Topics

15.1 "Surfing on the Shoulders of Giants"

15.2 Zope: A Web Publishing Framework

15.3 HTMLgen: Web Pages from Objects

15.4 JPython ( Jython): Python for Java

15.5 Grail: A Python-Based Web Browser

15.6 Python Restricted Execution Mode

15.7 XML Processing Tools

15.8 Windows Web Scripting Extensions

15.9 Python Server Pages

15.10 Rolling Your Own Servers in Python

Part IV: Assorted Topics

Chapter 16. Databases and Persistence

16.1 "Give Me an Order of Persistence, but Hold the Pickles"

16.2 Persistence Options in Python

16.3 DBM Files

16.4 Pickled Objects

16.5 Shelve Files

16.6 SQL Database Interfaces

16.7 PyForm: A Persistent Object Viewer

Chapter 17. Data Structures

17.1 "Roses Are Red, Violets Are Blue; Lists Are Mutable, and So Is Class Foo"

17.2 Implementing Stacks

17.3 Implementing Sets

17.4 Binary Search Trees

17.5 Graph Searching

17.6 Reversing Sequences

17.7 Permuting Sequences

17.8 Sorting Sequences

17.9 Data Structures Versus Python Built-ins

17.10 PyTree: A Generic Tree Object Viewer

Chapter 18. Text and Language

18.1 "See Jack Hack. Hack, Jack, Hack"

18.2 Strategies for Parsing Text in Python

18.3 String Module Utilities

18.4 Regular Expression Matching

18.5 Parser Generators

18.6 Hand-Coded Parsers

18.7 PyCalc: A Calculator Program/Object

Part V: Integration

Chapter 19. Extending Python

19.1 "I Am Lost at C"

19.2 C Extensions Overview

19.3 A Simple C Extension Module

19.4 The SWIG Integration Code Generator

19.5 Wrapping C Environment Calls

19.6 A C Extension Module String Stack

19.7 A C Extension Type String Stack

19.8 Wrapping C++ Classes with SWIG

Chapter 20. Embedding Python

20.1 "Add Python. Mix Well. Repeat."

20.2 C Embedding API Overview

20.3 Basic Embedding Techniques

20.4 Registering Callback Handler Objects

20.5 Using Python Classes in C

20.6 ppembed: A High-Level Embedding API

20.7 Other Integration Topics

Part VI: The End

Chapter 21. Conclusion: Python and the Development Cycle

21.1 "That's the End of the Book, Now Here's the Meaning of Life"

21.2 "Something's Wrong with the Way We Program Computers"

21.3 The "Gilligan Factor"

21.4 Doing the Right Thing

21.5 Enter Python

21.6 But What About That Bottleneck?

21.7 On Sinking the Titanic

21.8 So What's Python: The Sequel

21.9 In the Final Analysis...

21.10 Postscript to the Second Edition

Appendix A. Recent Python Changes

Section A.1. Major Changes in 2.0

Section A.2. Major Changes in 1.6

Section A.3. Major Changes Between 1.3 and 1.5.2

Appendix B. Pragmatics

Section B.1. Installing Python

Section B.2. Book Examples Distribution

Section B.3. Environment Configuration

Section B.4. Running Python Programs

Section B.5. Python Internet Resources

Appendix C. Python Versus C++

Colophon

Index

Copyright

Copyright © 2001 O'Reilly & Associates, Inc. All rights reserved.

Printed in the United States of America.

Published by O'Reilly & Associates, Inc., 101 Morris Street, Sebastopol, CA 95472.

Nutshell Handbook, the Nutshell Handbook logo, and the O'Reilly logo are registered trademarks of O'Reilly & Associates, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O'Reilly & Associates, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. The association between the image of an African rock python and the topic of Python programming is a trademark of O'Reilly & Associates, Inc.

While every precaution has been taken in the preparation of this book, the publisher assumes no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.

Foreword

Less than five years ago, I wrote the Foreword for the first edition of Programming Python. Since then, the book has changed about as much as the language and the Python community! I no longer feel the need to defend Python: the statistics and developments listed in Mark's Preface speak for themselves.

In the past year, Python has made great strides. We released Python 2.0, a big step forward, with new standard library features such as Unicode and XML support, and several new syntactic constructs, including augmented assignment: you can now write x += 1 instead of x = x+1. A few people wondered what the big deal was (answer: instead of x, imagine dict[key] or list[index]), but overall this was a big hit with those users who were already used to augmented assignment in other languages.

Less warm was the welcome for the extended print statement, print>>file, a shortcut for printing to a different file object than standard output. Personally, it's the Python 2.0 feature I use most frequently, but most people who opened their mouths about it found it an abomination. The discussion thread on the newsgroup berating this simple language extension was one of the longest ever-apart from the never-ending Python versus Perl thread.

Which brings me to the next topic. (No, not Python versus Perl. There are better places to pick a fight than a Foreword.) I mean the speed of Python's evolution, a topic dear to the heart of the author of this book. Every time I add a feature to Python, another patch of Mark's hair turns gray-there goes another chapter out of date! Especially the slew of new features added to Python 2.0, which appeared just as he was working on this second edition, made him worry: what if Python 2.1 added as many new things? The book would be out of date as soon as it was published!

Relax, Mark. Python will continue to evolve, but I promise that I won't remove things that are in active use! For example, there was a lot of worry about the string module. Now that string objects have methods, the string module is mostly redundant. I wish I could declare it obsolete (or deprecated) to encourage Python programmers to start using string methods instead. But given that a large majority of existing Python code-even many standard library modules-imports the string module, this change is obviously not going to happen overnight. The first likely opportunity to remove the string module will be when we introduce Python 3000; and even at that point, there will probably be a string module in the backwards compatibility library for use with old code.

Python 3000?! Yes, that's the nickname for the next generation of the Python interpreter. The name may be considered a pun on Windows 2000, or a reference to Mystery Science Theater 3000, a suitably Pythonesque TV show with a cult following. When will Python 3000 be released? Not for a loooooong time-although you won't quite have to wait until the year 3000.

Originally, Python 3000 was intended to be a complete rewrite and redesign of the language. It would allow me to make incompatible changes in order to fix problems with the language design that weren't solvable in a backwards compatible way. The current plan, however, is that the necessary changes will be introduced gradually into the current Python 2.x line of development, with a clear transition path that includes a period of backwards compatibility support.

Take, for example, integer division. In line with C, Python currently defines x/y with two integer arguments to have an integer result. In other words, 1/2 yields 0! While most dyed-in-the-wool programmers expect this, it's a continuing source of confusion for newbies, who make up an ever-larger fraction of the (exponentially growing) Python user population. From a numerical perspective, it really makes more sense for the / operator to yield the same value regardless of the type of the operands: after all, that's what all other numeric operators do. But we can't simply change Python so that 1/2 yields 0.5, because (like removing the string module) it would break too much existing code. What to do?

The solution, too complex to describe here in detail, will have to span several Python releases, and involves gradually increasing pressure on Python programmers (first through documentation, then through deprecation warnings, and eventually through errors) to change their code. By the way, a framework for issuing warnings will be introduced as part of Python 2.1. Sorry, Mark!

So don't expect the announcement of the release of Python 3000 any time soon. Instead, one day you may find that you are already using Python 3000-only it won't be called that, but rather something like Python 2.8.7. And most of what you've learned in this book will still apply! Still, in the meantime, references to Python 3000 will abound; just know that this is intentionally vaporware in the purest sense of the word. Rather than worry about Python 3000, continue to use and learn more about the Python version that you do have.

I'd like to say a few words about Python's current development model. Until early 2000, there were hundreds of contributors to Python, but essentially all contributions had to go through my inbox. To propose a change to Python, you would mail me a context diff, which I would apply to my work version of Python, and if I liked it, I would check it into my CVS source tree. (CVS is a source code version management system, and the subject of several books.) Bug reports followed the same path, except I also ended up having to come up with the patch. Clearly, with the increasing number of contributions, my inbox became a bottleneck. What to do?

Fortunately, Python wasn't the only open source project with this problem, and a few smart people at VA Linux came up with a solution: SourceForge! This is a dynamic web site with a complete set of distributed project management tools available: a public CVS repository, mailing lists (using Mailman, a very popular Python application!), discussion forums, bug and patch managers, and a download area, all made available to any open source project for the asking.

We currently have a development group of 30 volunteers with SourceForge checkin privileges, and a development mailing list comprising twice as many folks. The privileged volunteers have all sworn their allegiance to the BDFL (Benevolent Dictator For Life-that's me :-). Introduction of major new features is regulated via a lightweight system of proposals and feedback called Python Enhancement Proposals (PEPs). Our PEP system proved so successful that it was copied almost verbatim by the Tcl community when they made a similar transition from Cathedral to Bazaar.

So, it is with confidence in Python's future that I give the floor to Mark Lutz. Excellent job, Mark. And to finish with my favorite Monty Python quote: Take it away, Eric, the orchestra leader!

Guido van Rossum
Reston, Virginia, January 2001