The following is the long form of an author interview I gave for the PSF's first newsletter, which was produced in time to be distributed at the PyCon conference in February, 2010. An abbreviated version appeared in the newsletter due to space constraints, but the newsletter's editor, Serdar Tumgoren, was gracious enough to allow me to post the interview in its entirety here.
The newsletter version cut questions 5-8 and 10, and trimmed portions of the other responses. Among other things, the full version below also includes some potentially provocative Python 3.X issues which were cut in the newsletter's shorter form. This is all solicited opinion, of course, and my role is just that of Python pundit in some of this. As always, your mileage may vary.
For related information, see my books support site and Python training site.
I describe this in detail in the book's Preface, but in short: it's been updated to cover the current release of both Python 3.X and 2.X; to address some new advanced topics; and to expand on some prior topics that are now more pervasive in the Python world.
In terms of Python itself, we opted to cover both Python 2 and 3, in order to address both audiences in years to come. Specifically, this edition focuses on Python 3.1 primarily, but also presents Python 2.6 differences along the way. Based on everything I've seen, Python 2 will probably still have a significant user base for at least 5 more years. In fact, the Python 2.X line may very well be with us permanently, given how widely it is used today (there's still an awful lot of Fortran77 code out there, isn't there?). By covering both lines, we hope to address the needs of all our possible readers both during and after the transition, and help Python 3 gain traction in the process.
There was a surprisingly large amount of new language territory to cover. For instance, Python 3 comes with changed syntax (e.g., raise, except, and print); new tools (the nonlocal statement, set and dictionary comprehensions, function annotation, and extended sequence unpacking); and subtly different semantics (the new string model, dictionary views, the wider role of generators and iteration, and new-style classes). This is in addition to new tools added to both Python 2.6 and 3.X (class decorators, the new string format method, binary digit support, and so on). All these imply book growth, especially when presented in tandem with 2.X variations to a divided user community.
Besides language changes, this edition also has been augmented with a new OOP-tutorial chapter which works through a more realistic example, plus 4 new advanced topic chapters that explore Unicode, properties and descriptors, decorators, and metaclasses. These last 4 show up at the end and will be optional reading for many newcomers, though the Unicode chapter will probably be required for those who work outside the scope of ASCII text. In addition, some topics covered previously, such as generators and operator overloading, get an expanded look this time as well, because they are more prominent today.
Partly because this book is so widely read that it can actually be a major factor behind Python 3's adoption. Mostly, though, there was a clear need for a book that addresses the current state of flux head-on, and provides readers the tools they need to manage it today. That seems a lot more useful than pretending that the divide doesn't exist at all, especially given the size of this book's audience. Ignoring the needs of either half of the user base was not an option.
Because the book addresses both lines, readers can essentially hedge their bets on Python's future. At the same time, by showing the features of Python 3, it might inspire many to take the leap. Or not; the book's goal is to serve as a resource for both camps, and tell the Python 3 story honestly. Readers can decide what to do about 3.X for themselves.
We've also updated the Python Pocket Reference to cover both 2.X and 3.X too, by the way, for the same reasons--to help both during the transition, and after. It's 3.X biased, but explicitly lists 2.X differences too; that makes it usable as a translation resource today.
By design, it's a gradual, bottom-up, and hands-on introduction to the core Python language. This book has always been based on my experiences teaching Python to beginners in the 3-day training sessions I offer. For instance, the book comes with quizzes, exercises, and solutions. Because of that, it's more or less a self-paced equivalent to the training, though the book's completeness probably makes it more like a semester-long class.
Learning Python is also generally known as a book that focuses on fundamentals that span domains in a very in-depth way. For some people, learning Python means going through a 1 or 2 hour tutorial on the web; the problem with that approach is that they eventually get stuck by unusual cases (or wind up writing horribly non-Pythonic code that others must then maintain). The central goal of this book is to give readers a deep understanding so that even the unusual cases make sense, and to give them a solid foundation for writing code that jives with best Python practice.
It depends on what you call a "beginner." But from what I've seen among both Learning Python readers and students in my live classes, object-oriented programming is definitely near the top of the list. It's much more difficult to grasp than experienced software developers assume (many of whom take it for granted, but have trouble explaining its rationale when pressed). I handle this today in the book and classes by taking a multi-layered approach--I give the big picture void of syntax first; then show a few coding basics; and then work through a more realistic example use-case step by step, before even attempting more advanced OOP tools. OOP is a net win, of course, but given the extra complexity, beginners need to see some of the "why" before the "how."
For a better perspective on this, imagining having to explain descriptors, decorators, and metaclasses to a hardware testing person who's just shown up in class in their blue clean-room smock, and needs to know just enough Python to tweak a canned script that's suddenly become a requirement of their job. Much of Python's user base really doesn't care how cool such things may be! Trust me on this; my approach to teaching OOP evolved from watching very many eyes glaze over in real-time...
I take a similar piecemeal approach to generators, iterators, and comprehensions for the same reason--they are way too much for the average Python user to take in a single dose. In the new book, for example, these get two separate chapters, in two different parts. Naturally, different people learn in different ways, but the book uses approaches which have emerged from teaching thousands of actual Python beginners in the trenches.
Python 3 is clearly an improvement from a language design perspective, and its merits aren't hard to find. I very much hope it continues to be adopted. As someone who has been a Python fan since 1992, though, I tend to worry over its evolution more than some (well, that, and software developers have an innate tendency to focus on potential problems), so I'd like point out a few of what I see as 3.X's shortcomings.
For one, the new str.format() method strikes me as very odd--it seems to want to replace one complicated thing with another equally complicated, and functionally equivalent thing. Why? The rationale for adding this to Python seems way too thin to me. In the process, we've made the learning process more difficult for beginners, and threaten to break a ton of code if the well-worn and widely-used "%" format expression is ever removed altogether. It's been suggested on pydev that this may not happen until Python 4 now, so we may be stuck with the redundancy for years to come (or at least until Python programmers vote with their code: % may very well endure).
Dictionary views seem another questionable move to me--they're almost like sets, but not quite; why? And the 3.X open() call's signature seems far too complex (in fact, we had to rework the formatting in the Pocket Reference just to accommodate all its new arguments); if text and binary files take different arguments and imply different object types, why not have two separate calls? Files appear a bit half-baked in 3.X in general--I/O performance was terrible until 3.1, and BOM support in open() is just being discussed now. Some of this could be reasonably seen as a misstep for a community that has traditionally prided itself on quality.
I like 3.X, and don't mean offense to people who worked on any of its changes (and it's easy to complain after the fact, of course). But frankly, although Python 3 is a better language on the whole, many of its changes come off as largely academic, and appear to have been driven more by the subjective opinions of core developers than by feedback from real-world users. Aesthetics seems to have trounced practicality in Python 3 more often than it should have, and that's a bit out of character for Python.
As an educator, I'm also not thrilled with the way that Python 3 seems to make the assumption that people must already know some Python in order to learn Python. It's grown a lot more conceptual dependencies. Consider trying to explaining to a beginner the need for using list() around a range() or dict.keys(); or the keyword arguments syntax in print() and sorted() before they've had a chance to study function syntax details. Such new complexities and dependencies are one of the biggest downsides of Python 3 to me.
A big factor behind Python's success has been that it had a simple subset that was easy for non-wizards to learn. That's why it was deployed as a front-end scripting layer in so many systems. Python 3's extensions may make it a better language for experienced developers, and it's still clearly a better choice than any of the alternatives out there; but time will tell where its new designs fit in to the programming ecosystem at large.
Personally, I don't think Python 3 is just a language designed for language designers. I do, however, think we need to take such assertions more seriously than we have. After all, if you take away Python's focus on simplicity, it loses much of its strategic advantage over tools like Java. Hopefully, the changes moratorium will allow the Python community more time to consider such things.
I'm probably not the right person to ask. When I started writing the first Programming Python in 1995, I thought I would sell maybe a few thousand books; I was only wrong by a couple orders of magnitude... Seriously, I'm not sure anyone really knew that Python would become one of the top 4 or 5 languages in the world back then; many of us knew it had the potential, but this field changes more slowly than most people expect. It's largely been a make-it-up-as-you-go-along thing because of that unpredictability. Ten years is a long time in the software world, and I have no clue where Python will head next; I suppose the future can take care of itself.
I don't see any substantially new paradigms on the horizon (Prolog hasn't taken over the world, has it?), so I'll mostly pass on this. Honestly, I still see Python as the best option today, especially for an upcoming generation who rightly cannot imagine why anyone would possibly want to work as hard as they must in C++. Python can be tough too, but at least it's humane. One item of note: RIA toolkits like Flex, Silverlight and pyjamas seem interesting as a paradigm for doing user interfaces in browsers, though I'm a bit skeptical about their prospects, given their extra costs in code complexity (not to mention software stack depth!).
It varies from year to year, of course. In general, I focus more on writing when new books are underway, but training has tended to dominate. In my busiest training year, I did 43 Python classes, mostly out of town; that has a way of eating into writing schedules (and a normal personal life!). I scaled back on onsite classes for a couple years (partly to spend time focusing on the latest books) but am back on the trail again today. I'm off to teach Python in Albany next week, in fact. In February. Ah, the pageantry.
Probably to set their expectations realistically. You really need to be willing to focus in this field. Despite all the books that promise mastery in "24 hours," and claim accessibility to "Dummies" (whatever that means), learning to program well is a multi-year task. It requires both formal training from books and classes, as well as extensive hands-on practice.
Programming is also incredibly rewarding if you're willing to invest the time. But I think publishers of books that emphasize entertainment at the expense of technical depth have done a great disservice to both their readers, and the fields in which they seek to work. Not only are readers left ill-equipped and disappointed, but the entire software development field must deal with a lowered quality bar. Give the field the respect it deserves, and take the time to learn it well; you'll be glad you did.
And hopefully, publishers will someday give this field the same respect; I haven't seen a "Surgery for Dummies" yet, but anything's possible...
No (of course not--the 4th ed is still fresh off the printers!). I can imagine a futuristic world which Python 3 completely supersedes Python 2, and for which we'll want to update the book to strip out Python 2 material. Then again, I can also imagine a world in which people from all walks of life come together and live in harmony with one another; and with nature; and ride magic unicorns and various little furry creatures to lunch, where they feast together upon jelly-drop trees; and, and... All sarcasm aside, I enjoy writing, but after wrapping up 2 years updating 3 books, the idea of doing another one will sound about as much fun as root canal work :-).