Dr. Dobb's has announced the results of its annual Jolt Awards in the Best Books Category. The awards cover nominated books published during the twelve months ending June 30th. A total of 9 judges reviewed dozens of nominations to ultimately announce The Jolt Award for the year's best book, along with two Jolt Productivity and three Jolt Finalist awards.

HF: In a nutshell, with what kind of mindset would you suggest a reader approach your book?

MS: I hope that readers will take an open-minded approach. The book presents many ideas about how to solve certain kinds of problems, so it goes beyond books that cover the language's syntax, built-in functions, and standard library, to show how to put those things together to build useful components or applications.

HF: What is your hope for how a reader might be challenged by your work?

MS: The book shows how to do things that the reader might not have tried in Python before, or might have avoided because they assume or have been told that Python isn't good at certain things (e.g., is slow or can't do concurrency). For example, the original creator of the Graphite enterprise-scale monitoring tool wrote: "I was convinced that it would have to be rewritten in C for speed and that my Python implementation would only serve as a prototype." [1] But this need never arose in practice.

The only thing that I wouldn't write in Python is a fundamental data structure. This is because Python's built-in and standard library data structures (dict, list, tuple, collections. OrderedDict, etc.) are so efficient that I can't compete with them.

HF: What are some triggers/prompts in a Python developer's own career when he/she might feel ready to "take their Python programming to the next level" (as stated in your book's Intro)?

MS: There are two. First, if they love programming for its own sake and want to extend their range --- both in terms of ideas about how to do things in Python and in terms of what is possible with Python. Second, if they want to progress, to deepen their knowledge and confidence.

All Turing-complete programming languages can be used to do any kind of programming. The differences between languages is partly aesthetic -- for example, I find Python code beautiful -- and partly in its expressiveness. Some languages make it easy to express some things and hard to express other things. I find that Python's range of expressiveness is extremely broad, which means it is easy -- or at least straightforward -- to express anything you want with it. The book tries to show some of that expressiveness and some of that breadth.

which do you personally find of greatest interest? Which was the most enjoyable to write about?

MS: I like all those areas for different reasons. One of the pleasures of writing this book was that unlike a language textbook, I was able to pick and choose which topics to cover. Of course, there are other topics I love in Python that I could have covered but didn't have the space for-- for example, working with databases and the excellent apsw module for working with SQLite.

To address each part in more detail:

The original design patterns book was highly influential. So much so, that some of the design patterns are built right into Python. But some need to be implemented case by case and these I illustrate.

As for concurrency, it is the easiest way to wreck a program's performance and make it buggy and unreliable to boot! So I always advocate creating a non-concurrent program first. (This also means you have a program you can measure performance against.) But with due care, concurrency can produce significant performance improvements. And Python programmers have access to two different models of concurrency: multithreading (that most other languages offer) and multiprocessing (that Erlang offers). Additional concurrency models are available in third-party libraries.

I chose to write about high-level concurrency (and high-level networking) because application writers don't have the time or the need to do low-level coding when appropriate libraries are available. And, of course, Python has all the libraries you need (although some are outside the standard library).

I really like GUI applications -- to this day most of us use them on a regular basis, e.g., our web browser. And I find it interesting that although smartphones all have web browsers most people prefer to install apps (i.e., phone-specific GUI applications) for the sites they use most. My coverage is of desktop GUI programming because that's what I know and like best, but many of the ideas translate well to other kinds of GUI programming.

HF: Given your expertise in some other languages, such as GO, how would you overall describe Python's relationship with the canonical design patterns (per the first few chapters of your book)?

MS: Some of the design patterns are redundant in Python because they address specific deficiencies in C++ that Python doesn't have. Some design patterns are built into Python and are used all the time -- for example, decorators. As for the rest, as the book shows, they can all be implemented in Python, and in almost every case in a straightforward way.

HF: What are some myths in Python which your book aims to debunk?

MS: The myth that Python is slow and the myth that Python can't do concurrency. Of course Python is slow in an absolute sense compared to C. However, an awful lot of the Python core is written in C including its key data structures. Furthermore, slow in theory is very different from slow in practice.

For example, I have a non-concurrent program I wrote in C++ that is very CPU-bound. I re-wrote the program in Python using multiprocessing. On a single core machine this resulted in a 50% _decrease_ in speed; yes, Python was only half as fast. But on a dual core machine the speeds were about equal, and on a quad core machine the Python version is almost twice as fast. And, of course, the Python version will scale to as many cores as are available.

Naturally, if I rewrote the C++ version to use concurrency it would be the faster, but doing concurrency in Python is much easier than in C++, especially using multiprocessing rather than multithreading, because with multiprocessing, data is not shared by default. And multiprocessing isn't constrained by the GIL (Global Interpreter Lock).

I've reached the stage now where my first choice is always Python (Python 3 of course!), unless I'm forced to use something else (e.g., Python 2.7 with Google App Engine). I no longer assume I'll need to rewrite in C++ for speed because that isn't the case. And if I really did hit a speed limit I could always use Cython or PyPy -- or write the speed-critical parts in C and use ctypes -- but for me at least, that hasn't been needed. (I do use ctypes a lot though, not for speed, but simply to access functionality in third-party libraries.)

HF: In rough terms, what percentage of your book is conceptual versus practical/reference guide?

MS: The early chapters on design patterns do cover some concepts and big-picture ideas, but they are all grounded in examples and running code. And overall the entire book is practical. Every example runs and if it doesn't do something useful at least provides a skeleton that could be made into something useful. The book doesn't serve as a reference to Python in general, but it _does_ serve as a reference for implementing larger-scale ideas.

For example, I myself used the coverage of concurrent GUI programming as a reference for creating a CPU-intensive GUI application (that uses PySide rather than the Tkinter used in the book). What I particularly like about Python is that the bar to entry is very low: children can learn to program in Python. However, no matter how old or experienced you become, you will never hit a limit in Python. The language is both broad and deep, there's always more to learn, there's always scope for improving your code. And best of all, Python is actually fun to use.

Footnotes:

[1] Quoted from http://aosabook.org/en/graphite.html (section 7.10).

To learn more about Mark Summerfield, Python, GO, C++ and a variety of other programming languages which Mr. Summerfield covers, please visit his InformIT Author Page.