PEP 404 – Python 2.8 Un-release Schedule
- Barry Warsaw <barry at python.org>
This document describes the un-development and un-release schedule for Python 2.8.
Un-release Manager and Crew
|2.8 Un-release Manager||Cardinal Biggles|
The current un-schedule is:
- 2.8 final Never
Rule number six: there is no official Python 2.8 release. There never will be an official Python 2.8 release. It is an ex-release. Python 2.7 is the end of the Python 2 line of development.
The official upgrade path from Python 2.7 is to Python 3.
And Now For Something Completely Different
In all seriousness, there are important reasons why there won’t be an official Python 2.8 release, and why you should plan to migrate instead to Python 3.
Python is (as of this writing) more than 20 years old, and Guido and the community have learned a lot in those intervening years. Guido’s original concept for Python 3 was to make changes to the language primarily to remove the warts that had grown in the preceding versions. Python 3 was not to be a complete redesign, but instead an evolution of the language, and while maintaining full backward compatibility with Python 2 was explicitly off-the-table, neither were gratuitous changes in syntax or semantics acceptable. In most cases, Python 2 code can be translated fairly easily to Python 3, sometimes entirely mechanically by such tools as 2to3 (there’s also a non-trivial subset of the language that will run without modification on both 2.7 and 3.x).
Because maintaining multiple versions of Python is a significant drag on the resources of the Python developers, and because the improvements to the language and libraries embodied in Python 3 are so important, it was decided to end the Python 2 lineage with Python 2.7. Thus, all new development occurs in the Python 3 line of development, and there will never be an official Python 2.8 release. Python 2.7 will however be maintained for longer than the usual period of time.
Here are some highlights of the significant improvements in Python 3. You can read in more detail on the differences between Python 2 and Python 3. There are also many good guides on porting from Python 2 to Python 3.
Strings and bytes
Python 2’s basic original strings are called 8-bit strings, and
they play a dual role in Python 2 as both ASCII text and as byte
sequences. While Python 2 also has a unicode string type, the
fundamental ambiguity of the core string type, coupled with Python 2’s
default behavior of supporting automatic coercion from 8-bit strings
to unicode objects when the two are combined, often leads to
UnicodeErrors. Python 3’s standard string type is Unicode based, and
Python 3 adds a dedicated bytes type, but critically, no automatic coercion
between bytes and unicode strings is provided. The closest the language gets
to implicit coercion are a few text-based APIs that assume a default
encoding (usually UTF-8) if no encoding is explicitly stated. Thus, the core
interpreter, its I/O libraries, module names, etc. are clear in their
distinction between unicode strings and bytes. Python 3’s unicode
support even extends to the filesystem, so that non-ASCII file names are
This string/bytes clarity is often a source of difficulty in
transitioning existing code to Python 3, because many third party
libraries and applications are themselves ambiguous in this
distinction. Once migrated though, most
UnicodeErrors can be
Python 2 has two basic integer types, a native machine-sized
type, and an arbitrary length
long type. These have been merged in
Python 3 into a single
int type analogous to Python 2’s
In addition, integer division now produces floating point numbers for non-integer results.
Python 2 has two core class hierarchies, often called classic
classes and new-style classes. The latter allow for such things as
inheriting from the builtin basic types, support descriptor based tools
property builtin and provide a generally more sane and coherent
system for dealing with multiple inheritance. Python 3 provided the
opportunity to completely drop support for classic classes, so all classes
in Python 3 automatically use the new-style semantics (although that’s a
misnomer now). There is no need to explicitly inherit from
object or set
the default metatype to enable them (in fact, setting a default metatype at
the module level is no longer supported - the default metatype is always
The mechanism for explicitly specifying a metaclass has also changed to use
metaclass keyword argument in the class header line rather than a
__metaclass__ magic attribute in the class body.
There are many cases in Python 2 where multiple spellings of some
constructs exist, such as
repr() and backticks, or the two
<>. In all cases, Python 3 has chosen
exactly one spelling and removed the other (e.g.
In Python 3, implicit relative imports within packages are no longer
available - only absolute imports and explicit relative imports are
supported. In addition, star imports (e.g.
from x import *) are only
permitted in module level code.
Also, some areas of the standard library have been reorganized to make the naming scheme more intuitive. Some rarely used builtins have been relocated to standard library modules.
Iterators and views
Many APIs, which in Python 2 returned concrete lists, in Python 3 now return iterators or lightweight views.
This document has been placed in the public domain.
Last modified: 2021-02-09 16:54:26 GMT