Programming Python, 3rd Edition

Coming Attractions

What developments can Python users expect to see in the coming years? Python 3000, which is referred to in the foreword to the second edition as “intentionally vaporware,” will see the light of day after all as Python 3.0. After half a decade of talk, it’s finally time to start doing something about it. I’ve created a branch of the 2.5 source tree, and, along with a handful of developers, I’m working on transforming the code base into my vision for Python 3000. At the same time, I’m working with the community on a detailed definition of Python 3000; there’s a new mailing dedicated to Python 3000 and a series of PEPs, starting with PEP 3000.

This work is still in the early stages. Some changes, such as removing classic classes and string exceptions, adopting Unicode as the only character type, and changing integer division so that 1/2 returns 0.5 instead of truncating toward zero, have been planned for years. But many other changes are still being hotly debated, and new features are being proposed almost daily.

I see my own role in this debate as a force of moderation: there are many more good ideas than could possibly be implemented in the given time, and, taken together, they would change the language so much that it would be unrecognizable. My goal for Python 3000 is to fix some of my oldest design mistakes, especially the ones that can’t be fixed without breaking backward compatibility. That alone will be a huge task. For example, a consequence of the choice to use Unicode everywhere is the need for a total rewrite of the standard I/O library and a new data type to represent binary (“noncharacter”) data, dubbed “bytes.”

The biggest potential danger for Python 3000 is that of an “accidental paradigm shift”: a change, or perhaps a small set of changes that weren’t considered together, that would unintentionally cause a huge change to the way people program in Python. For example, adding optional static type checking to the language could easily have the effect of turning Python into “Java without braces”—which is definitely not what most users would like to see happen! For this reason, I am making it my personal responsibility to guide the Python 3000 development process. The new language should continue to represent my own esthetics for language design, not a design-by-committee compromise or a radical departure from today’s Python. And if we don’t get everything right, well, there’s always Python 4000....

The timeline for 3.0 is roughly as follows: I expect the first alpha release in about a year and the first production release a year later. I expect that it will then take another year to shake out various usability issues and get major third-party packages ported, and, finally, another year to gain widespread user acceptance. So, Mark should have about three to four years before he’ll have to start the next revision of this book.

To learn more about Python 3000 and how we plan to help users convert their code, start by reading PEP 3000. (To find PEP 3000 online, search for it in Google.)

In the meantime, Python 2.x is not dead yet. Python 2.5 will be released around the same time as this book (it’s in late alpha as I am writing this). Python’s normal release cycle produces a new release every 12–18 months. I fully expect version 2.6 to see the light of day while Python 3000 is still in alpha, and it’s likely that 2.7 will be released around the same time as 3.0 (and that more users will download 2.7 than 3.0). A 2.8 release is quite likely; such a release might back-port certain Python 3.0 features (while maintaining backward compatibility with 2.7) in order to help users migrate code. A 2.9 release might happen, depending on demand. But in any case, 2.10 will be right out!

(If you’re not familiar with Python’s release culture, releases like 2.4 and 2.5 are referred to as “major releases.” There are also “bug-fix releases,” such as 2.4.3. Bug-fix releases are just that: they fix bugs and, otherwise, maintain strict backward and forward compatibility within the same major release. Major releases introduce new features and maintain backward compatibility with at least one or two previous major releases, and, in most cases, many more than that. There’s no specific name for “earth-shattering” releases like 3.0, since they happen so rarely.)