This document describes the un-development and un-release schedule for Python2.8.
| Position | Name |
|---|---|
| 2.8 Un-release Manager | Cardinal Biggles |
The current un-schedule is:
Rule number six: there isno official Python 2.8 release. There never willbe an official Python 2.8 release. It is an ex-release. Python 2.7is the end of the Python 2 line of development.
The official upgrade path from Python 2.7 is to Python 3.
In all seriousness, there are important reasons why there won’t be anofficial Python 2.8 release, and why you should plan to migrateinstead to Python 3.
Python is (as of this writing) more than 20 years old, and Guido and thecommunity have learned a lot in those intervening years. Guido’soriginal concept for Python 3 was to make changes to the languageprimarily to remove the warts that had grown in the precedingversions. Python 3 was not to be a complete redesign, but instead anevolution of the language, and while maintaining full backwardcompatibility with Python 2 was explicitly off-the-table, neither weregratuitous changes in syntax or semantics acceptable. In most cases,Python 2 code can be translated fairly easily to Python 3, sometimesentirely mechanically by such tools as2to3 (there’s also a non-trivialsubset of the language that will run without modification on both 2.7 and3.x).
Because maintaining multiple versions of Python is a significant dragon the resources of the Python developers, and because theimprovements to the language and libraries embodied in Python 3 are soimportant, it was decided to end the Python 2 lineage with Python2.7. Thus, all new development occurs in the Python 3 line ofdevelopment, and there will never be an official Python 2.8 release.Python 2.7 will however be maintained for longer than the usual periodof time.
Here are some highlights of the significant improvements in Python 3.You can read in more detail on thedifferences between Python 2 andPython 3. There are also many good guides onporting from Python 2to Python 3.
Python 2’s basic original strings are called 8-bit strings, andthey play a dual role in Python 2 as both ASCII text and as bytesequences. While Python 2 also has a unicode string type, thefundamental ambiguity of the core string type, coupled with Python 2’sdefault behavior of supporting automatic coercion from 8-bit stringsto unicode objects when the two are combined, often leads toUnicodeErrors. Python 3’s standard string type is Unicode based, andPython 3 adds a dedicated bytes type, but critically, no automatic coercionbetween bytes and unicode strings is provided. The closest the language getsto implicit coercion are a few text-based APIs that assume a defaultencoding (usually UTF-8) if no encoding is explicitly stated. Thus, the coreinterpreter, its I/O libraries, module names, etc. are clear in theirdistinction between unicode strings and bytes. Python 3’s unicodesupport even extends to the filesystem, so that non-ASCII file names arenatively supported.
This string/bytes clarity is often a source of difficulty intransitioning existing code to Python 3, because many third partylibraries and applications are themselves ambiguous in thisdistinction. Once migrated though, mostUnicodeErrors can beeliminated.
Python 2 has two basic integer types, a native machine-sizedinttype, and an arbitrary lengthlong type. These have been merged inPython 3 into a singleint type analogous to Python 2’slongtype.
In addition, integer division now produces floating point numbers fornon-integer results.
Python 2 has two core class hierarchies, often calledclassicclasses andnew-style classes. The latter allow for such things asinheriting from the builtin basic types, support descriptor based toolslike theproperty builtin and provide a generally more sane and coherentsystem for dealing with multiple inheritance. Python 3 provided theopportunity to completely drop support for classic classes, so all classesin Python 3 automatically use the new-style semantics (although that’s amisnomer now). There is no need to explicitly inherit fromobject or setthe default metatype to enable them (in fact, setting a default metatype atthe module level is no longer supported - the default metatype is alwaysobject).
The mechanism for explicitly specifying a metaclass has also changed to useametaclass 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 someconstructs exist, such asrepr() andbackticks, or the twoinequality operators!= and<>. In all cases, Python 3 has chosenexactly one spelling and removed the other (e.g.repr() and!=were kept).
In Python 3, implicit relative imports within packages are no longeravailable - only absolute imports and explicit relative imports aresupported. In addition, star imports (e.g.fromximport*) are onlypermitted in module level code.
Also, some areas of the standard library have been reorganized to makethe naming scheme more intuitive. Some rarely used builtins have beenrelocated to standard library modules.
Many APIs, which in Python 2 returned concrete lists, in Python 3 nowreturn iterators or lightweightviews.
This document has been placed in the public domain.
Source:https://github.com/python/peps/blob/main/peps/pep-0404.rst
Last modified:2025-02-01 08:55:40 GMT