![[Home page]](PythonPowered.gif "Home page"){kind=small}
| Books | Code | Blog | Python | Author | Train | Find | ©M.Lutz |
Below are book notes which are either related to the first printing of this book (September 2009), or significatly older than the first reprint (January 2010).
I've now had a chance to inspect the first reprint described on the main update page. It's dated "[1/10]" (January), even though the changes cutoff was actually in December. All the changes dated on or before December 15, 2009 were incorporated into this reprint, and have now been moved off to separate pages as described on the main page. The ebook versions of this book from O'Reilly also reflect all the changes that made it into this first reprint.
In addition, the paper version of this reprint uses a thinner and lighter paper stock, making the printed book between 1/2 inch and 1 inch thinner, and noticeably lighter (it's at least 5/8" thinner on its paper side when both are compressed). As discussed in this book's "blog" section, size isn't everything, of course, and it's up to readers to judge the merits of this change for themselves. From a first impressions perspective, the thinner format does feel a bit less intimidating. The new stock may have also improved paper quality in general (it's brighter, doesn't yellow on the sides, and yields straighter edges), though this is also for readers to decide.
As you'll probably notice once you get into this book, there have been quite a few language changes in Python 3.X (see the Preface for tables summarizing many of them). To put it bluntly, most existing 2.X code won't run under 3.X, and some that may run will run incorrectly due to subtle changes in semantics.
This makes moving some existing code to 3.X challenging, and has made it difficult for many widely used Python tools and systems to migrate to 3.X. Given the vast amount of existing 2.X code being used in the world today, this is a major issue for most Python users. Indeed, many programmers are currently facing a "chicken and egg" sort of dilemma: they cannot move to 3.X even if they want to, because of dependencies on existing 2.X systems.
Perhaps worse, Python core developers were already discussing additional language changes in upcoming 3.X releases -- some of which seemed, arguably, to have few compelling real-world use cases, and little or no end-user input. The 3.X line seemed in danger of becoming a case of aesthetics and academics trumping practicality and pragmatics, something entirely contrary to Python's core world view, and something which further clouded 3.X's future.
Probably the best news on this front is that Python core developers have realized that they need to stop changing the language in order to allow both programmers and software packages a chance to catch up. Shortly after this book was published, a moratorium prohibiting future Python changes was adopted. You can read its full text at: www.python.org/dev/peps/pep-3003/. In short, Python will remain as it is now, in 3.1 form, for the next few years (technically, the PEP calls for at least two years after 3.1's release). In other words, you can be sure that the coverage of Python in this edition of the book will be fully relevant and valid for the next few years.
Personally, I think this is very good news for Python. Given that Python 3.X still has yet to gain traction one year after its release, continuing to add changes, above and beyond those for which the jury is still out, could have very well made 3.X the "New Coke" of Python: an experiment that would ultimately fail to be adopted by its ecosystem. With the moratorium, 3.X adoption seems much more likely in the coming years. Highly popular Python extensions such as NumPy, Django, and Twisted, will now at least be able to target a 3.X baseline, and can be reasonably expected to migrate. In the meantime, I hope that this 2.X + 3.X book will address the needs of a Python community in transition during this period and beyond.
We've received some negative feedback about the thickness and heft of the first printing of this book, as well as the quality of the paper used for it. These two issues are directly related. The paper used exhibits wrinkles, jagged book edges, and so on; unfortunately it also makes the book larger than it might have been. So far these issues have been raised by just two people, who do not necessarily represent thousands of readers, of course. Moreover, neither of these was about book content. Based on positive feedback from others, this seems to be more about first impressions than usability in general. Frankly, though, I was surprised by the printed size and quality too, and I think this merits a few words here.
Naturally, some of this book's size stems from its subject matter: the need to cover both Python 2.X and 3.X, and all their new features. Because the Python world is currently in transition between the 2.X and 3.X lines, we opted to provide complete coverage of both, to be relevant to all of this book's readers over the next few years. At the same time, Python has grown more complex in general, and this book mirrors that growth. A watered-down treatment or single-version scope would have both yielded a smaller book, but wouldn't reflect the reality of Python today, and would not provide our readers with the tools they need. For more background, see the discussion of Python complexity later on this webpage, and the Page 756 clarification above for a prime example of the importance of in-depth Python coverage.
Having said that, the size issue was also aggravated by the choice of paper used for the first printing of the paper book. To put a quantitative spin on this, as printed this 1,200-page book is physically as thick and large as the 1,600-page Programming Python 3rd Edition! That is, due to the choice of paper used, this book is as big as one that is 33% longer in actual page count. This much is an artifact of production, not content.
Furthermore, the 2nd Edition of Programming Python was at least 1/4 inch thinner than the new Learning Python, despite the fact that it was also nearly 100 pages longer and included a CD. In other words, the choice of paper by itself added more than 1/4 inch to the book's size. By contrast, thanks to paper choice the new 4th Edition of Python Pocket Reference is almost identical in size to its 3rd edition, even though it grew from 150 to 200 pages (again, 33%).
Beyond this impact on size, a few readers have also stated that the first printing's paper seems as if it may have some durability issues in general. This can vary per reader, of course (spilling your coffee on any book is a generally bad thing!), but it is a concern to some. Although the choice of paper type and quality is crucial to usability, it's part of an overall book cost model used by the publisher, and is beyond an author's control. In fact, authors aren't able to see the printed text until it has started shipping.
O'Reilly is addressing this by switching immediately to the thinner, lighter, and higher-quality paper used in Programming Python for all future print runs of this book. Although it will still be a substantial book, this change will make for a much more manageable size. Also note that this book is available in a variety of searchable and portable ebook formats (PDF, mobi, epub, safari). At the risk of being labeled subversive, though, many readers still consider a paper book's lack of connectivity to be a feature, not a liability.
[Update Nov-28-09]: Per O'Reilly, books printed after mid December 2009, the next reprint date, will be printed on lighter and thinner paper stock. This change will address paper quality concerns, and reduce the physical size and weight of the book substantially. Although size and paper issues have been raised by only a few readers among many, it's good to see O'Reilly's proactive response.
[Update Jan-17-10]: See the first printing update near the top of this page; with the thinner, lighter paper stock used in the reprint, the printed book is now between 1/2 inch and 1 inch thinner (roughly 5/8"), and substantially lighter. To some readers, the paper quality may seem better as well (brighter, straighter edges).
We haven't received any complaints about this, but I wish to say a few words about some of the forward dependencies in both Python and this book. As mentioned in the Preface, some parts of Python today seem to assume you already must know Python in order to learn Python -- the language's design implies conceptual forward dependencies that can be challenging for both authors and readers of books. Often, the best a linear book can do is ask readers to take some concepts for granted until it's possible to cover them in full. Though less clear cut, some of Python's new complexities might also pose challenges to the long held belief in Python's ease of use in general.
Though still comparatively simple, Python today is much more laden with conceptual hurdles than it once was. For example, things like keyword arguments, though part of more advanced function call syntax, often confront beginners early on in the context of print(), str.format(), list.sort(), and dict(name=value). Moreover, understanding the need to wrap newly iterable tools like range(), zip(), and dict.keys() in a list() call in order to display their values requires substantial foreknowledge about the iteration protocol, a very non-trivial topic. The magic behind sorted(dict) and file line iteration has similar prerequisites for similar reasons.
Nor is this limited to keyword arguments and iteration. Other forward dependencies in Python are not hard to find, if viewed through the eyes of true Python beginners, this book's audience. The need to use parenthesis at all in 3.X's print(), for example, depends upon function call expressions in general just to perform basic printing. File interfaces also can become early prerequisites, because 3.X's flavor of exec() now requires mastery of files in order to be useful as an interactive development paradigm (made all the more crucial by the fact that reload() is no longer a simple built-in in 3.X). Even the more advanced *args call syntax is also a requirement for common use cases of methods like str.format() and Fraction.as_integer_ratio(); though less heavy, typical usage of the "%" format expression has long required dictionary knowledge as well.
As an extreme example, decorators, now pervasive in popular Python frameworks often used by relative newcomers, can require even deeper prerequisite knowledge (if not outright blind faith!). This is true for both their developers, and even mildly curious end users. To truly understand what "@decorator" will do to a function you code, you need fairly deep knowledge of Python in general. In the book, decorators are deferred until after functions have been fully covered (in fact, not until classes are presented) and are treated as an advanced topic. This may not be ideal for readers who encounter these in frameworks immediately, of course; such topics may require a nonlinear approach for some readers, but not most.
By contrast, almost all readers will be exposed very early to other forward dependency contexts such as print(), str.format(), list(), and dict(), so these cannot be deferred as easily. Covering functions in detail before basic printing would make for a very chaotic introductory text. And covering iteration up front is virtually impossible -- that would also require covering call expressions, looping statements, methods, other iteration contexts, and object semantics in general, just to clarify to beginners why they must call list() to view a dictionary's keys or an integer range.
In fact, a complete iteration treatment encompasses even more complex subjects, such as the yield statement, generator expressions, and the __iter__ and __next__ operator overloading protocols: topics associated with advanced function and class usage. For users seeking in-depth and satisfying explanations, these are now prerequisite to the simple task of printing a dictionary's keys. This design seems less than beginner friendly, given that many Python users might otherwise never need to become familiar with such tools at all. At the least, this is far too heavy a topic for a first encounter with Python.
In a linear and bottom-up book like this, such forward dependencies inevitably mean that the full story behind some topics must be deferred until after their first sketchy appearances. Iteration in the book, for example, is covered first in conjunction with looping statements; again at functions; and finally for class operator overloading. It's a piecemeal story, but is eventually disclosed in full. Other topics such as keyword arguments are similarly delayed.
When this type of incremental coverage occurs, readers may either wait for full coverage later; skip ahead using links in the book itself; or seek elaboration by using reference manuals and books. As also mentioned in the Preface, this book is designed to be a gradual tutorial which becomes more detailed as you read further ahead, and is meant to be supplemented by a reference such as Python Pocket Reference. Although the book does present all of Python eventually, some readers may occasionally wish to flip ahead, or use such a companion reference book in parallel to hunt for more details along the way.
For more on this subject, see the clarifications for pages 91, 185, 186, and 217 earlier on this webpage for three specific instances of this in the book. At the end of the day, Python imposes more conceptual forward dependencies today than it once did, and this is at times mirrored by this book. Though recent changes have improved the language's utility, it's not clear that Python developers fully appreciated the impact that some of their designs would have on newcomers trying to learn the language (as usual in such projects, Python's evolution is directed by Python's experts, not its beginners). As you read this book, you'll notice that it attempts to note most forward references, but not all. Again, when a topic is introduced partially, either read on for the rest of the story, or skip ahead as you wish; it's your book, after all.
On a broader level, some worry that Python may have become too complicated to be accessible to beginners -- that its target audience may have shifted more towards experienced programmers in recent releases. This seems an open question to me. Personally, I think that Python is still easier to learn than any other popular programming language available, and many can get by at least temporarily with a simplified subset (in fact, this is a basic working assumption of the first portions of Learning Python: details are filled in gradually). After all, there are today multiple books designed for teaching Python programming to children, so the simple parts are still simple.
Especially in 3.X, though, the language has grown new complexities and dependencies that require fairly big leaps of faith for beginners. When one also factors in generators, Unicode, decorators, context managers, metaclasses, new-style class extensions, two string formatting options, and the like, Python today is a more powerful language but also a more challenging one. As a case in point, the latest Learning Python is 1200 pages; roughly 150 pages of this is optional advanced material at the end, and some space is required to address both 2.X and 3.X. Still, this reflects the fact that truly mastering core Python today requires more of a commitment than it once did. Whether that will impact Python's educational scope in general has yet to be seen. The goal of Learning Python is to present the full story honestly; it's up to readers to judge any such larger implications.
Newer notes: see the recent notes page
Back to this book's main updates page