Python 2.6 is a hybrid interpreter. That means it can run both 1.x and 2.x software as well as some 3.x code. Some will argue that Python releases dating back to 2.2 have already been mixed interpreters because they support creation of both classic classes as well as new-style classes, but that is as far as they go.

Version 2.6 is many steps ahead, and if they are eventually released, versions 2.7 and beyond will be even more so. The 2.6 release is the first version with specific 3.0 features backported to it. The most significant of these features are summarized here:

This appendix does not discuss other new features of 2.6 that are standalone features, meaning they do not have any consequences for porting applications to 3.x. So without further ado . . .

Previous versions of Python featured two integer types, int and long. The original ints were limited in size to the architecture of the platform on which the code ran (i.e., 32-bit, 64-bit), while longs were unlimited in size except in terms of how much virtual memory the operating system provided. The process of unifying these two types into a single int type began in Python 2.2 and will be complete in version 3.0.^a The new single int type will be unlimited in size, and the previous L or l designation for longs is removed. You can read more about this change in PEP 237.

As of 2.6, there is little trace of long integers, save for the support of the trailing L. It is included for backward-compatibility purposes, to support all code that uses longs. Nevertheless, users should be actively purging long integers from their existing code and should no longer use longs in any new code written against Python 2.6+.

Python 3 features a minor revision to the alternative base format for integers. It has basically streamlined the syntax to make it consistent with the existing hexadecimal format, prefixed with a leading 0x (or 0X for capital letters)—for example, 0x80, 0xffff, 0xDEADBEEF.

A new binary literal lets you provide the bits to an integer number, prefixed with a leading 0b (e.g., 0b0110). The original octal representation began with a single 0, but this format proved confusing to some users, so it has been changed to 0o to bring it in line with hexadecimal and binary literals as just described. In other words, 0177 is no longer allowed; you must use 0o177 instead. Here are some examples:

A change that has been a long time coming, yet remains controversial to many, is the change to the division operator (/). The traditional division operation works in the following way: Given two integer operands, / performs integer floor division. If there is at least one float involved, true division occurs:

It’s no secret that one of the most common causes of breakage between Python 2.x and 3.x applications is the change in the print statement, which becomes a built-in function in version 3.x. This change allows print() to be more flexible, upgradeable, and swappable if desired.

Python 2.6+ supports either the print statement or the print() built-in function. The default is the former usage, as it should be in a 2.x language. To discard the print statement and go with only the function in a “Python 3 mode” application, you would simply import print_function from __future__:

The preceding example demonstrates the power of print() being a function. Using the print statement, we display the strings "foo" and "bar" to the user, but we cannot change the default delimiter or separator between strings, which is a space. In contrast, print() makes this functionality available in its call as the argument sep, which replaces the default—and allows print to evolve and progress.

Note that this is a “one-way” import, meaning that there is no way to revert print() back to a function. Even issuing a "del print_function" will not have any effect. This major change is detailed in PEP 3105.

In Python 3.x, the reduce() function, which is neither readily understood nor commonly used by many programmers today, has been “demoted” (much to the chagrin of many Python functional programmers) from being a built-in function to become a functools module attribute. It is available in functools beginning in 2.6.

One key theme in Python 3.x is the migration to greater use of iterators, especially for built-in functions and methods that have historically returned lists. Still other iterators are changing because of the updates to integers. The following are the most high-profile built-in functions changed in Python 3.x:

Starting in Python 2.6, programmers can access the new and updated functions by importing the future_builtins module. Here is an example demonstrating both the old and new oct() and zip() functions:

If you want to use only the Python 3.x versions of these functions in your current Python 2.x environment, you can override the old ones by importing all the new functions into your namespace. The following example demonstrates this process with oct():

To smooth the way for using bytes objects in Python 3.x, you can optionally prepend a regular ASCII/binary string in Python 2.6 with a leading b or B, thereby creating bytes literals (b'' or B'') as synonyms for str literals (''). The leading indicator has no bearing on any str object itself or any of the object’s operations (it is purely decorative), but it does prepare you for situations in Python 3 where you need to create such a literal. You can find out more about bytes literals in PEP 3112

Python 3’s syntax for catching and handling a single exception looks like this:

The e variable contains the instance of the exception that provides the reason why the error was thrown. It is optional, as is the entire as e phrase. Thus this change really applies only to those users who save this value.

The equivalent Python 2 syntax uses a comma instead of the as keyword:

This change was made in Python 3.x because of the confusion that occurs when programmers attempt to handle more than one exception with the same handler.

To catch multiple exceptions with the same handler, beginners often write this (invalid) code:

In fact, if you are trying to catch more than one exception, you need to use a tuple containing the exceptions:

The as keyword in Python 3.0 (and 2.6+) is intended to ensure that the comma in the original syntax is no longer a source of confusion. However, the parentheses are still required when you are trying to catch more than one type of exception using the same handler:

For porting efforts, Python 2.6+ accepts either the comma or as when defining exception handlers that save the instance. In contrast; only the idiom with as is permitted in Python 3. More information about this change can be found in PEP 3110.

The change in raising exceptions found in Python 3.x really isn’t a change at all; in fact, it doesn’t even have anything to do with the transition efforts associated with Python 2.6. Python 3’s syntax for raising exceptions (providing the optional reason for the exception) looks like this:

Long-time Python users have probably been using the following idiom (although both approaches are supported in all 2.x releases):

To emphasize that raising exceptions is equivalent to instantiating an exception class and to provide some additional flexibility, Python 3 supports only the first idiom. The good news is that you don’t have to wait until you adopt 2.6 to start using this technique—the syntax with parentheses has actually been valid since the Python 1 days.