Postscript to the Second Edition

One of the luxuries of updating a book like this is that you get an opportunity to debate yourself, or at least your opinions, from years past. With the benefit of five years retrospect, Id like to add a few comments to the original conclusion.

.10.1 Integration Isn Everything

The conclusion for this books first edition stressed the importance of Pythons role as an integration tool. Although the themes underscored there are still valid, I should point out that not all Python applications rely explicitly on the ability to be mixed with components written in other languages. Many developers now use Python in standalone mode, either not having or not noticing integration layers.

For instance, developers who code CGI Internet scripts with Python often code in pure Python. Somewhere down the call chain, C libraries are called (to access sockets, databases, and so on), but Python coders often don need to care. In fact, this has proven to be true in my own recent experience as well. While working on the new GUI, system, and Internet examples for this edition, I worked purely in Python for long periods of time. A few months later I also worked on a Python/C++ integration framework, but this integration project was entirely separate from the pure Python book examples programming effort. Many projects are implemented in Python alone.

That is not to say that Pythons integration potential is not one of its most profound attributes -- indeed, most Python systems are composed of combinations of Python and C. However, in many cases, the integration layer is implemented once by a handful of advanced developers, while others perform the bulk of the programming in Python alone. If you e fortunate enough to count yourself among the latter group, Pythons overall ease of use may seem more crucial than its integration role.

.10.2 The End of the Java Wars

In 1995, the Python community perceived a conflict between Java and Python in terms of competition for developer mind-share -- hence the sidebar "Python versus Java: Round 1?" in the first edition. Since then, this has become virtually a nonissue; Ive even deleted this sidebar completely.

This cooling of hostilities has come about partly because Javas role is now better understood: Java is recognized as a systems development language, not a scripting language. That is essentially what the sidebar proposed. Javas complexity is on the order of C++s (from which it is derived), making it impractical for scripting work, where short development cycles are at a premium. This is by design -- Java is meant for tasks where the extra complexity may make sense. Given the great disparity in their roles, the Python/Java conflict has fizzled.

The truce has also been called on account of the new JPython implementation of Python. JPython was described in Chapter 15 ; in short, it integrates Python and Java programs such that applications can be developed as hybrids: parts can be coded in Python when scripting is warranted, and in Java for performance-intensive parts. This is exactly the argument made for C/C++ integration in the conclusion of the first edition; thanks to JPython, the same reasoning behind hybrid systems now applies to Java-based applications.

The claims made by the old Java sidebar are still true -- Python is simpler, more open, and easier to learn and apply. But that is as it should be: as a scripting language, Python naturally complements systems languages like Java and C++, rather than competing with them. There are still some who would argue that Python is better suited for many applications now coded in Java. But just as for Python and C and C++, Python and Java seem to work best as a team.

Its also worth noting that as I write these words, Microsoft has just announced a new, proprietary language called C# that seems to be intended as a substitute for Java in Microsofts systems language offerings. Moreover, a new Python port to the C#/.NET environment has been announced as well. See Chapter 15 for details -- this port is roughly to C# what JPython is to Java. Time will tell if C# and Java will do battle for mindshare. But given that Python integrates with both, the outcome of these clashes between mega-companies is largely irrelevant; Pythonistas can watch calmly from the sidelines this time around.

.10.3 We e Not Off That Island Yet

As I mentioned in the preface to this edition, Python has come far in the last five years. Companies around the world have adopted it, and Python now boasts a user base estimated at half a million strong. Yet for all the progress, there is still work to be done, both in improving and popularizing Python, and in simplifying software development in general.

As I travel around the world teaching Python classes at companies and organizations, I still meet many people who are utterly frustrated with the development tools they are required to use in their jobs. Some even change jobs (or careers) because of such frustrations. Even well after the onset of the Internet revolution, development is still harder than it needs to be.

On the other hand, I also meet people who find Python so much fun to use, they can imagine going back to their old ways. They use Python both on and off the job for the pure pleasure of programming.

Five years from now, I hope to report that I meet many more people in the latter category than the former. After all, Guido may have appeared on the covers of Linux Journal and Dr. Dobbs since the first edition of this book, but we still have a bit more work to do before he makes the cover of Rolling Stone.

A Morality Tale of Perl Versus Python

(The following was posted recently to the rec.humor.funny Usenet newsgroup by Larry Hastings, and is reprinted here with the original authors permission. I don necessarily condone language wars; okay?)

This has been percolating in the back of my mind for a while. Its a scene from The Empire Strikes Back, reinterpreted to serve a valuable moral lesson for aspiring programmers.

EXTERIOR: DAGOBAH -- DAY

With Yoda strapped to his back, Luke climbs up one of the many thick vines that grow in the swamp until he reaches the Dagobah statistics lab. Panting heavily, he continues his exercises -- grepping, installing new packages, logging in as root, and writing replacements for two-year-old shell scripts in Python.

YODA: Code! Yes. A programmers strength flows from code maintainability. But beware of Perl. Terse syntax . . . more than one way to do it . . . default variables. The dark side of code maintainability are they. Easily they flow, quick to join you when code you write. If once you start down the dark path, forever will it dominate your destiny, consume you it will.

LUKE: Is Perl better than Python?

YODA: No . . . no . . . no. Quicker, easier, more seductive.

LUKE: But how will I know why Python is better than Perl?

YODA: You will know. When your code you try to read six months from now.