184 lines
6.3 KiB
ReStructuredText
184 lines
6.3 KiB
ReStructuredText
PEP: 404
|
|
Title: Python 2.8 Un-release Schedule
|
|
Author: Barry Warsaw <barry@python.org>
|
|
Status: Final
|
|
Type: Informational
|
|
Topic: Release
|
|
Content-Type: text/x-rst
|
|
Created: 09-Nov-2011
|
|
Python-Version: 2.8
|
|
|
|
|
|
Abstract
|
|
========
|
|
|
|
This document describes the un-development and un-release schedule for Python
|
|
2.8.
|
|
|
|
|
|
Un-release Manager and Crew
|
|
===========================
|
|
|
|
============================ ==================
|
|
Position Name
|
|
============================ ==================
|
|
2.8 Un-release Manager Cardinal Biggles
|
|
============================ ==================
|
|
|
|
|
|
Un-release Schedule
|
|
===================
|
|
|
|
The current un-schedule is:
|
|
|
|
- 2.8 final Never
|
|
|
|
|
|
Official pronouncement
|
|
======================
|
|
|
|
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.
|
|
|
|
|
|
Upgrade path
|
|
============
|
|
|
|
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
|
|
``UnicodeError``\ s. 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
|
|
natively supported.
|
|
|
|
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 ``UnicodeError``\ s can be
|
|
eliminated.
|
|
|
|
|
|
Numbers
|
|
-------
|
|
|
|
Python 2 has two basic integer types, a native machine-sized ``int``
|
|
type, and an arbitrary length ``long`` type. These have been merged in
|
|
Python 3 into a single ``int`` type analogous to Python 2's ``long``
|
|
type.
|
|
|
|
In addition, integer division now produces floating point numbers for
|
|
non-integer results.
|
|
|
|
|
|
Classes
|
|
-------
|
|
|
|
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
|
|
like the ``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
|
|
``object``).
|
|
|
|
The mechanism for explicitly specifying a metaclass has also changed to use
|
|
a ``metaclass`` keyword argument in the class header line rather than a
|
|
``__metaclass__`` magic attribute in the class body.
|
|
|
|
|
|
Multiple spellings
|
|
------------------
|
|
|
|
There are many cases in Python 2 where multiple spellings of some
|
|
constructs exist, such as ``repr()`` and *backticks*, or the two
|
|
inequality operators ``!=`` and ``<>``. In all cases, Python 3 has chosen
|
|
exactly one spelling and removed the other (e.g. ``repr()`` and ``!=``
|
|
were kept).
|
|
|
|
|
|
Imports
|
|
-------
|
|
|
|
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*.
|
|
|
|
|
|
Copyright
|
|
=========
|
|
|
|
This document has been placed in the public domain.
|
|
|
|
|
|
.. _`2to3`: http://docs.python.org/library/2to3.html
|
|
.. _differences: http://docs.python.org/release/3.0.1/whatsnew/3.0.html
|
|
.. _porting: http://python3porting.com/
|
|
|