peps/pep-0404.txt at main · python/peps

Cannot retrieve contributors at this time

183 lines (133 sloc) 6.33 KB

	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/