mirror of https://github.com/python/cpython
816 lines
30 KiB
ReStructuredText
816 lines
30 KiB
ReStructuredText
****************************
|
|
What's New In Python 3.0
|
|
****************************
|
|
|
|
.. XXX Add trademark info for Apple, Microsoft.
|
|
|
|
.. XXX Remove duplicates; just put info in the most relevant section.
|
|
|
|
:Author: Guido van Rossum
|
|
:Release: |release|
|
|
:Date: |today|
|
|
|
|
.. $Id$
|
|
Rules for maintenance:
|
|
|
|
* Anyone can add text to this document. Do not spend very much time
|
|
on the wording of your changes, because your text will probably
|
|
get rewritten to some degree.
|
|
|
|
* The maintainer will go through Misc/NEWS periodically and add
|
|
changes; it's therefore more important to add your changes to
|
|
Misc/NEWS than to this file.
|
|
|
|
* This is not a complete list of every single change; completeness
|
|
is the purpose of Misc/NEWS. Some changes I consider too small
|
|
or esoteric to include. If such a change is added to the text,
|
|
I'll just remove it. (This is another reason you shouldn't spend
|
|
too much time on writing your addition.)
|
|
|
|
* If you want to draw your new text to the attention of the
|
|
maintainer, add 'XXX' to the beginning of the paragraph or
|
|
section.
|
|
|
|
* It's OK to just add a fragmentary note about a change. For
|
|
example: "XXX Describe the transmogrify() function added to the
|
|
socket module." The maintainer will research the change and
|
|
write the necessary text.
|
|
|
|
* You can comment out your additions if you like, but it's not
|
|
necessary (especially when a final release is some months away).
|
|
|
|
* Credit the author of a patch or bugfix. Just the name is
|
|
sufficient; the e-mail address isn't necessary.
|
|
|
|
* It's helpful to add the bug/patch number as a comment:
|
|
|
|
% Patch 12345
|
|
XXX Describe the transmogrify() function added to the socket
|
|
module.
|
|
(Contributed by P.Y. Developer.)
|
|
|
|
This saves the maintainer the effort of going through the SVN log
|
|
when researching a change.
|
|
|
|
This article explains the new features in Python 3.0, compared to 2.6.
|
|
Python 3.0, also known as "Python 3000" or "Py3k", is the first ever
|
|
*intentionally incompatible* release. There are more changes than in
|
|
a typical release, and more that are important for all Python users.
|
|
Nevertheless, after digesting the changes, you'll find that Python
|
|
really hasn't changed all that much -- by and large, we're merely
|
|
fixing well-known annoyances and warts.
|
|
|
|
This article doesn't attempt to provide a complete specification of
|
|
the new features, but instead provides a convenient overview. For
|
|
full details, you should refer to the documentation for Python 3.0. If
|
|
you want to understand the complete implementation and design
|
|
rationale, refer to the PEP for a particular new feature.
|
|
|
|
.. Compare with previous release in 2 - 3 sentences here.
|
|
.. add hyperlink when the documentation becomes available online.
|
|
|
|
.. ======================================================================
|
|
.. Large, PEP-level features and changes should be described here.
|
|
.. Should there be a new section here for 3k migration?
|
|
.. Or perhaps a more general section describing module changes/deprecation?
|
|
.. sets module deprecated
|
|
.. ======================================================================
|
|
|
|
|
|
Common Stumbling Blocks
|
|
=======================
|
|
|
|
This section lists those few changes that are most likely to trip you
|
|
up if you're used to Python 2.5.
|
|
|
|
Print Is A Function
|
|
-------------------
|
|
|
|
The :keyword:`print` statement has been replaced with a :func:`print`
|
|
function, with keyword arguments to replace most of the special syntax
|
|
of the old :keyword:`print` statement (:pep:`3105`). Examples::
|
|
|
|
Old: print "The answer is", 2*2
|
|
New: print("The answer is", 2*2)
|
|
|
|
Old: print x, # Trailing comma suppresses newline
|
|
New: print(x, end=" ") # Appends a space instead of a newline
|
|
|
|
Old: print # Prints a newline
|
|
New: print() # You must call the function!
|
|
|
|
Old: print >>sys.stderr, "fatal error"
|
|
New: print("fatal error", file=sys.stderr)
|
|
|
|
Old: print (x, y) # prints repr((x, y))
|
|
New: print((x, y)) # Not the same as print(x, y)!
|
|
|
|
You can also customize the separator between items, e.g.::
|
|
|
|
print("There are <", 2**32, "> possibilities!", sep="")
|
|
|
|
which produces::
|
|
|
|
There are <4294967296> possibilities!
|
|
|
|
Note:
|
|
|
|
* The :func:`print` function doesn't support the "softspace" feature of
|
|
the old :keyword:`print` statement. For example, in Python 2.x,
|
|
``print "A\n", "B"`` would write ``"A\nB\n"``; but in Python 3.0,
|
|
``print("A\n", "B")`` writes ``"A\n B\n"``.
|
|
|
|
* Initially, you'll be finding yourself typing the old ``print x``
|
|
a lot in interactive mode. Time to retrain your fingers to type
|
|
``print(x)`` instead!
|
|
|
|
* When using the ``2to3`` source-to-source conversion tool, all
|
|
:keyword:`print` statements are automatically converted to
|
|
:func:`print` function calls, so this is mostly a non-issue for
|
|
larger projects.
|
|
|
|
Text Strings Vs. Bytes
|
|
----------------------
|
|
|
|
Everything you thought you knew about binary data and Unicode has
|
|
changed. There's a longer section below; here's a summary of the
|
|
changes:
|
|
|
|
* Python 3.0 uses *strings* and *bytes* instead of *Unicode strings*
|
|
and *8-bit strings*. The difference is that any attempt to mix
|
|
strings and bytes in Python 3.0 raises a TypeError exception,
|
|
whereas if you were to mix Unicode and 8-bit strings in Python 2.x,
|
|
you would only get an exception if the 8-bit string contained
|
|
non-ASCII values. As a consequence, pretty much all code that
|
|
uses Unicode, encodings or binary data most likely has to change.
|
|
The change is for the better, as in the 2.x world there were
|
|
numerous bugs having to do with mixing encoded and unencoded text.
|
|
|
|
* Files opened as text files (still the default mode for :func:`open`)
|
|
always use an encoding to map between strings (in memory) and bytes
|
|
(on disk). Binary files (opened with a ``b`` in the mode argument)
|
|
always use bytes in memory. This means that if a file is opened
|
|
using an incorrect mode or encoding, I/O will likely fail. There is
|
|
a platform-dependent default encoding, which on Unixy platforms can
|
|
be set with the ``LANG`` environment variable (and sometimes also
|
|
with some other platform-specific locale-related environment
|
|
variables). In many cases, but not all, the system default is
|
|
UTF-8; you should never count on this default. Any application
|
|
reading or writing more than pure ASCII text should probably have a
|
|
way to override the encoding.
|
|
|
|
* The builtin :class:`basestring` abstract type was removed. Use
|
|
:class:`str` instead. The :class:`str` and :class:`bytes` types
|
|
don't have functionality enough in common to warrant a shared base
|
|
class.
|
|
|
|
* See also the :ref:`unicode-howto`, which was updated for Python 3.0.
|
|
|
|
Views And Interators Instead Of Lists
|
|
-------------------------------------
|
|
|
|
Some well-known APIs no longer return lists:
|
|
|
|
* :class:`dict` methods :meth:`dict.keys`, :meth:`dict.items` and
|
|
:meth:`dict.values` return "views" instead of lists. For example,
|
|
this no longer works: ``k = d.keys(); k.sort()``. Use ``k =
|
|
sorted(d)`` instead.
|
|
|
|
* Also, the :meth:`dict.iterkeys`, :meth:`dict.iteritems` and
|
|
:meth:`dict.itervalues` methods are no longer supported.
|
|
|
|
* :func:`map` and :func:`filter` return iterators. A quick fix is e.g.
|
|
``list(map(...))``, but a better fix is often to use a list
|
|
comprehension (especially when the original code uses :keyword:`lambda`).
|
|
Particularly tricky is :func:`map` invoked for the side effects of the
|
|
function; the correct transformation is to use a for-loop.
|
|
|
|
* :func:`range` now behaves like :func:`xrange` used to behave.
|
|
The latter no longer exists.
|
|
|
|
* :func:`zip` now returns an iterator.
|
|
|
|
* XXX More below?
|
|
|
|
Ordering Comparisons
|
|
--------------------
|
|
|
|
Python 3.0 has simplified the rules for ordering comparisons:
|
|
|
|
* The ordering comparison operators (``<``, ``<=``, ``>=``, ``>``)
|
|
raise a TypeError exception when the operands don't have a
|
|
meaningful natural ordering. Thus, expressions like ``1 < ''``, ``0
|
|
> None`` or ``len <= len`` are no longer valid. A corollary is that
|
|
sorting a heterogeneous list no longer makes sense -- all the
|
|
elements must be comparable to each other. Note that this does not
|
|
apply to the ``==`` and ``!=`` operators: objects of different
|
|
uncomparable types always compare unequal to each other, and an
|
|
object always compares equal to itself (i.e., ``x is y`` implies ``x
|
|
= y``; this is true even for ``NaN``).
|
|
|
|
* :meth:`builtin.sorted` and :meth:`list.sort` no longer accept the *cmp*
|
|
argument providing a comparison function. Use the *key* argument
|
|
instead. N.B. the *key* and *reverse* arguments are now "keyword-only".
|
|
|
|
* The :func:`cmp` function is gone, and the :meth:`__cmp__` special
|
|
method is no longer supported. Use :meth:`__lt__` for sorting,
|
|
:meth:`__eq__` with :meth:`__hash__`, and other rich comparisons as
|
|
needed. if you really need the :func:`cmp` functionality, the
|
|
expression ``(a > b) - (a < b)`` is equivalent to ``cmp(a, b)``.
|
|
|
|
* XXX More below?
|
|
|
|
Integers
|
|
--------
|
|
|
|
* :pep:`0237`: :class:`long` renamed to :class:`int`. That is, there
|
|
is only one built-in integral type, named :class:`int`; but it
|
|
behaves mostly like the old :class:`long` type.
|
|
|
|
* The :func:`repr` of a long integer doesn't include the trailing ``L``
|
|
anymore, so code that unconditionally strips that character will
|
|
chop off the last digit instead. (Use :func:`str` instead.)
|
|
|
|
* The :data:`sys.maxint` constant was removed, since there is no
|
|
longer a limit to the value of ints. However, :data:`sys.maxsize`
|
|
can be used as an integer larger than any practical list or string
|
|
index. It conforms to the implementation's "natural" integer size
|
|
and is typically the same as :data:`sys.maxint` in previous releases
|
|
on the same platform (assuming the same build options).
|
|
|
|
* ``1/2`` returns a float. Use ``1//2`` to get the truncating behavior.
|
|
(The latter syntax has existed for years, at least since Python 2.2.)
|
|
See :pep:`0238`.
|
|
|
|
|
|
Overview Of Syntactic Changes
|
|
=============================
|
|
|
|
This section gives a brief overview of every *syntactic* change.
|
|
Several of these are discussed at greater length later.
|
|
|
|
Additions
|
|
---------
|
|
|
|
* Function argument and return value annotations (see below). XXX
|
|
|
|
* :pep:`3102`: Keyword-only arguments. Named parameters occurring
|
|
after ``*args`` in the parameter list *must* be specified using
|
|
keyword syntax in the call. You can also use a bare ``*`` in the
|
|
parameter list to indicate that you don't accept a variable-length
|
|
argument list, but you do have keyword-only arguments.
|
|
|
|
* Keyword arguments are allowed after the list of base classes in a
|
|
class definition. This is used by the new convention for specifying
|
|
a metaclass, but can be used for other purposes as well, as long as
|
|
the metaclass supports it.
|
|
|
|
* :pep:`3104`: :keyword:`nonlocal` statement. Using ``nonlocal x``
|
|
you can now assign directly to a variable in an outer (but
|
|
non-global) scope. :keyword:`nonlocal` is a new reserved word.
|
|
|
|
* :pep:`3132`: Extended Iterable Unpacking. You can now write things
|
|
like ``a, b, *rest = some_sequence``. And even ``*rest, a =
|
|
stuff``. The ``rest`` object is always a (possibly empty) list; the
|
|
right-hand side may be any iterable. Example::
|
|
|
|
(a, *rest, b) = range(5)
|
|
|
|
This sets *a* to ``0``, *b* to ``4``, and \*rest to ``[1, 2, 3]``.
|
|
|
|
* Dictionary comprehensions: ``{k: v for k, v in stuff}`` means the
|
|
same thing as ``dict(stuff)`` but is more flexible.
|
|
|
|
* Set literals, e.g. ``{1, 2}``. Note that ``{}`` is an empty
|
|
dictionary; use ``set()`` for an empty set. Set comprehensions are
|
|
also supported; ``{x for x in stuff}`` means the same thing as
|
|
``set(stuff)`` but is more flexible.
|
|
|
|
* New octal literals, e.g. ``0o720`` (already in 2.6). The old octal
|
|
literals (``0720``) are gone.
|
|
|
|
* New binary literals, e.g. ``0b1010`` (already in 2.6).
|
|
|
|
* Bytes literals are introduced with a leading ``b`` or ``B``.
|
|
|
|
Changes
|
|
-------
|
|
|
|
* New :keyword:`raise` statement syntax: ``raise [expr [from expr]]``.
|
|
Also note that string exceptions are no longer legal (:pep:`0352`).
|
|
|
|
* :keyword:`as` and :keyword:`with` are now reserved words. (Since
|
|
2.6, actually.)
|
|
|
|
* :keyword:`True`, :keyword:`False`, and :keyword:`None` are reserved
|
|
words. (2.6 partially enforced the restrictions on :keyword:`None`
|
|
already.)
|
|
|
|
* Change from :keyword:`except` *exc*, *var* to
|
|
:keyword:`except` *exc* :keyword:`as` *var*. See :pep:`3110`.
|
|
|
|
* List comprehensions no longer support the syntactic form
|
|
``[... for var in item1, item2, ...]``. Use
|
|
``[... for var in (item1, item2, ...)]`` instead.
|
|
Also note that list comprehensions have different semantics: they
|
|
are closer to syntactic sugar for a generator expression inside a
|
|
:func:`list` constructor, and in particular the loop control
|
|
variables are no longer leaked into the surrounding scope.
|
|
|
|
* The *ellipsis* (``...``) can be used as an atomic expression
|
|
anywhere. (Previously it was only allowed in slices.) Also, it
|
|
*must* now be spelled as ``...``. (Previously it could also be
|
|
spelled as ``. . .``, by a mere accident of the grammar.)
|
|
|
|
Removals
|
|
--------
|
|
|
|
* :pep:`3113`: Tuple parameter unpacking removed. You can no longer
|
|
write ``def foo(a, (b, c)): ...``.
|
|
Use ``def foo(a, b_c): b, c = b_c`` instead.
|
|
|
|
* Removed backticks (use :func:`repr` instead).
|
|
|
|
* Removed ``<>`` (use ``!=`` instead).
|
|
|
|
* Removed keyword: :func:`exec` is no longer a keyword; it remains as
|
|
a function. (Fortunately the function syntax was also accepted in
|
|
2.x.) Also note that :func:`exec` no longer takes a stream argument;
|
|
instead of ``exec(f)`` you can use ``exec(f.read())``.
|
|
|
|
* Integer literals no longer support a trailing ``l`` or ``L``.
|
|
|
|
* String literals no longer support a leading ``u`` or ``U``.
|
|
|
|
* The :keyword:`from` *module* :keyword:`import` ``*`` syntax is only
|
|
allowed at the module level, no longer inside functions.
|
|
|
|
* The only acceptable syntax for relative imports is :keyword:`from`
|
|
``.``[*module*] :keyword:`import` *name*; :keyword:`import` forms
|
|
not starting with ``.`` are always interpreted as absolute imports.
|
|
(:pep:`0328`)
|
|
|
|
|
|
|
|
Changes Already Present In Python 2.6
|
|
=====================================
|
|
|
|
Since many users presumably make the jump straight from Python 2.5 to
|
|
Python 3.0, this section reminds the reader of new features that were
|
|
originally designed for Python 3.0 but that were back-ported to Python
|
|
2.6. The corresponding sections in :ref:`whats-new-in-2.6` should be
|
|
consulted for longer descriptions.
|
|
|
|
* :ref:`pep-0343`. The :keyword:`with` statement is now a standard
|
|
feature and no longer needs to be imported from the ``__future__``.
|
|
Also check out :ref:`new-26-context-managers` and
|
|
:ref:`new-module-contextlib`.
|
|
|
|
* :ref:`pep-0366`. This enhances the usefulness of the :option:`-m`
|
|
option when the referenced module lives in a package.
|
|
|
|
* :ref:`pep-0370`.
|
|
|
|
* :ref:`pep-0371`.
|
|
|
|
* :ref:`pep-3101`. Note: the 2.6 description mentions the
|
|
:meth:`format` method for both 8-bit and Unicode strings. In 3.0,
|
|
only the :class:`str` type (text strings with Unicode support)
|
|
supports this method; the :class:`bytes` type does not. The plan is
|
|
to eventually make this the only API for string formatting, and to
|
|
start deprecating the ``%`` operator in Python 3.1.
|
|
|
|
* :ref:`pep-3105`. This is now a standard feature and no longer needs
|
|
to be imported from :mod:`__future__`.
|
|
|
|
* :ref:`pep-3110`. The :keyword:`except` *exc* :keyword:`as` *var*
|
|
syntax is now standard and :keyword:`except` *exc*, *var* is no
|
|
longer supported. (Of course, the :keyword:`as` *var* part is still
|
|
optional.)
|
|
|
|
* :ref:`pep-3112`. The ``b"..."`` string literal notation (and its
|
|
variants like ``b'...'``, ``b"""..."""``, and ``br"..."``) now
|
|
produces a literal of type :class:`bytes`. More about
|
|
:class:`bytes` below.
|
|
|
|
* :ref:`pep-3116`. The :mod:`io` module is now the standard way of
|
|
doing file I/O, and the initial values of :data:`sys.stdin`,
|
|
:data:`sys.stdout` and :data:`sys.stderr` are now instances of
|
|
:class:`io.TextIOBase`. The builtin :func:`open` function is now an
|
|
alias for :func:`io.open` and has additional keyword arguments
|
|
*encoding*, *errors*, *newline* and *closefd*. Also note that an
|
|
invalid *mode* argument now raises :exc:`ValueError`, not
|
|
:exc:`IOError`.
|
|
|
|
* :ref:`pep-3118`. The old builtin :func:`buffer` is now really gone;
|
|
the new builtin :func:`memoryview` provides (mostly) similar
|
|
functionality.
|
|
|
|
* :ref:`pep-3119`. The :mod:`abc` module and the ABCs defined in the
|
|
:mod:`collections` module plays a slightly more prominent role in
|
|
the language now, and builtin collection types like :class:`dict`
|
|
and :class:`list` conform to the :class:`collections.MutableMapping`
|
|
and :class:`collections.MutableSequence` ABC, respectively.
|
|
|
|
* :ref:`pep-3127`. As mentioned above, the new octal literal
|
|
notation is the only one supported, and binary literals have been
|
|
added.
|
|
|
|
* :ref:`pep-3129`. This speaks for itself.
|
|
|
|
* :ref:`pep-3141`. The :mod:`numbers` module is another new use of
|
|
ABCs, defining Python's "numeric tower". Also note the new
|
|
:mod:`fractions` module.
|
|
|
|
|
|
Library Changes
|
|
===============
|
|
|
|
Due to time constraints, this document does not exhaustively cover
|
|
the very extensive changes to the library.
|
|
|
|
XXX Brief overview of what's changed in the library.
|
|
|
|
* :pep:`3108`: stdlib reorganization.
|
|
|
|
* Killed :mod:`sets`. Use the builtin :func:`set` function.
|
|
|
|
* XXX macfs, new, reconvert, stringold, xmllib, pcre, pypcre, strop
|
|
|
|
* XXX :pep:`4`
|
|
|
|
* XXX lib-old: Para, addpack, cmp, cmpcache, codehack, dircmp, dump,
|
|
find, fmt, grep, lockfile, newdir, ni, packmail, poly, rand,
|
|
statcache, tb, tzparse, util, whatsound, whrandom, zmod
|
|
|
|
* XXX Removed sys.exitfunc
|
|
|
|
* XXX Removed sys.exc_clear
|
|
|
|
* XXX Removed sys.exc_type, exc_value, exc_traceback. (sys.last_type
|
|
etc. remain.)
|
|
|
|
* XXX array.read, array.write
|
|
|
|
* XXX operator.sequenceIncludes
|
|
|
|
* XXX thread.acquire_lock and thread.release_lock
|
|
|
|
* XXX UserXXX -> XXXMixin?
|
|
|
|
* XXX removed random.jumpahead API
|
|
|
|
* XXX cookie module revamps
|
|
|
|
* XXX heapq revamp
|
|
|
|
|
|
Strings And Bytes
|
|
=================
|
|
|
|
This section discusses the many changes in string
|
|
|
|
* There is only one string type; its name is :class:`str` but its behavior and
|
|
implementation are like :class:`unicode` in 2.x.
|
|
|
|
* The :class:`basestring` superclass has been removed. The ``2to3`` tool
|
|
replaces every occurrence of :class:`basestring` with :class:`str`.
|
|
|
|
* :pep:`3137`: There is a new type, :class:`bytes`, to represent
|
|
binary data (and encoded text, which is treated as binary data until
|
|
you decide to decode it). The :class:`str` and :class:`bytes` types
|
|
cannot be mixed; you must always explicitly convert between them,
|
|
using the :meth:`str.encode` (str -> bytes) or :meth:`bytes.decode`
|
|
(bytes -> str) methods.
|
|
|
|
.. XXX add bytearray
|
|
|
|
* All backslashes in raw strings are interpreted literally. This means that
|
|
``'\U'`` and ``'\u'`` escapes in raw strings are not treated specially.
|
|
|
|
* :pep:`3138`: :func:`repr` of a string no longer escapes all
|
|
non-ASCII characters. XXX
|
|
|
|
* :pep:`3112`: Bytes literals, e.g. ``b"abc"``, create :class:`bytes`
|
|
instances.
|
|
|
|
* :pep:`3120`: UTF-8 default source encoding.
|
|
|
|
* :pep:`3131`: Non-ASCII identifiers. (However, the standard library remains
|
|
ASCII-only with the exception of contributor names in comments.)
|
|
|
|
* :pep:`3116`: New I/O Implementation. The API is nearly 100% backwards
|
|
compatible, but completely reimplemented (currently mostly in Python). Also,
|
|
binary files use bytes instead of strings.
|
|
|
|
* The :mod:`StringIO` and :mod:`cStringIO` modules are gone. Instead, import
|
|
:class:`io.StringIO` or :class:`io.BytesIO`.
|
|
|
|
|
|
|
|
:pep:`3101`: A New Approach To String Formatting
|
|
================================================
|
|
|
|
* A new system for built-in string formatting operations replaces the
|
|
``%`` string formatting operator. (However, the ``%`` operator is
|
|
still supported; it will be deprecated in Python 3.1 and removed
|
|
from the language at some later time.)
|
|
|
|
.. XXX expand this
|
|
|
|
|
|
:pep:`3106`: Revamping dict :meth:`dict.keys`, :meth:`dict.items` and :meth:`dict.values`
|
|
=========================================================================================
|
|
|
|
.. XXX expand this (but note that the "pitfalls" section currently has
|
|
.. XXX more detail :-)
|
|
|
|
* The :meth:`dict.iterkeys`, :meth:`dict.itervalues` and :meth:`dict.iteritems`
|
|
methods have been removed.
|
|
|
|
* :meth:`dict.keys`, :meth:`dict.values` and :meth:`dict.items` return objects
|
|
with set behavior that reference the underlying dict; these are often
|
|
referred to as *dictionary views*.
|
|
|
|
|
|
:pep:`3107`: Function Annotations
|
|
=================================
|
|
|
|
.. XXX expand this
|
|
|
|
* A standardized way of annotating a function's parameters and return values.
|
|
|
|
|
|
Exception Stuff
|
|
===============
|
|
|
|
* :pep:`0352`: All exceptions must be derived (directly or indirectly)
|
|
from :exc:`BaseException`. This is the root of the exception
|
|
hierarchy. Most exceptions should actually be derived from
|
|
:exc:`Exception`. This is not a new recommendation, but the
|
|
*requirement* to inherit from :exc:`BaseException` is new. (Python
|
|
2.6 still allowed classic classes to be raised, and placed no
|
|
restriction on what you can catch.)
|
|
|
|
* :exc:`StandardError` was removed (in 2.6, actually).
|
|
|
|
* Dropping sequence behavior (slicing!) and :attr:`message` attribute of
|
|
exception instances.
|
|
|
|
* :pep:`3109`: Raising exceptions. You must now use ``raise Exception(args)``
|
|
instead of ``raise Exception, args``.
|
|
|
|
* :pep:`3110`: Catching exceptions. You must now use ``except SomeException as
|
|
identifier:`` instead of ``except Exception, identifier:``
|
|
|
|
* :pep:`3134`: Exception chaining. XXX
|
|
|
|
* A few exception messages are improved when Windows fails to load an extension
|
|
module. For example, ``error code 193`` is now ``%1 is not a valid Win32
|
|
application``. Strings now deal with non-English locales.
|
|
|
|
|
|
New Class And Metaclass Stuff
|
|
=============================
|
|
|
|
* Classic classes are gone.
|
|
|
|
* :pep:`3115`: New Metaclass Syntax.
|
|
|
|
* :pep:`3119`: Abstract Base Classes (ABCs); ``@abstractmethod`` and
|
|
``@abstractproperty`` decorators; collection ABCs.
|
|
|
|
* :pep:`3129`: Class decorators.
|
|
|
|
* :pep:`3141`: Numeric ABCs.
|
|
|
|
|
|
Other Language Changes
|
|
======================
|
|
|
|
* Moved :func:`intern` to :func:`sys.intern`.
|
|
|
|
* ``!=`` now returns the opposite of ``==``, unless ``==`` returns
|
|
``NotImplemented``.
|
|
|
|
* The concept of "unbound methods" was removed from the language.
|
|
When referencing a method as a class attribute, you now get a plain
|
|
function object.
|
|
|
|
* :meth:`__getslice__`, :meth:`__setslice__` and :meth:`__delslice__`
|
|
were killed. The syntax ``a[i:j]`` now translates to
|
|
``a.__getitem__(slice(i, j))`` (or :meth:`__setitem__` or
|
|
:meth:`__delitem__`, when used as an assignment or deletion target,
|
|
respectively).
|
|
|
|
* :pep:`3111`: :func:`raw_input` renamed to :func:`input`. That is,
|
|
the new :func:`input` function reads a line from :data:`sys.stdin`
|
|
and returns it with the trailing newline stripped. It raises
|
|
:exc:`EOFError` if the input is terminated prematurely. To get the
|
|
old behavior of :func:`input`, use ``eval(input())``.
|
|
|
|
* :func:`xrange` renamed to :func:`range`, so :func:`range` will no
|
|
longer produce a list but an iterable yielding integers when
|
|
iterated over. XXX dupe
|
|
|
|
* :pep:`3114`: ``.next()`` renamed to :meth:`__next__`, new builtin
|
|
:func:`next` to call the :meth:`__next__` method on an object.
|
|
|
|
* :pep:`3135`: New :func:`super`. You can now invoke :func:`super`
|
|
without arguments and the right class and instance will
|
|
automatically be chosen. With arguments, its behavior is unchanged.
|
|
|
|
* :func:`zip`, :func:`map` and :func:`filter` return iterators.
|
|
|
|
* :data:`string.letters` and its friends (:data:`string.lowercase` and
|
|
:data:`string.uppercase`) are gone. Use
|
|
:data:`string.ascii_letters` etc. instead. (The reason for the
|
|
removal is that :data:string.letters` and friends had
|
|
locale-specific behavior, which is a bad idea for such
|
|
attractively-named global "constants".)
|
|
|
|
* Removed: :func:`apply`. Instead of ``apply(f, args)`` use
|
|
``f(*args)``.
|
|
|
|
* Removed :func:`callable`. Instead of ``callable(f)`` you can use
|
|
``hasattr(f, '__call__')``. The :func:`operator.isCallable` function
|
|
is also gone.
|
|
|
|
* Removed :func:`coerce`. This function no longer serves a purpose
|
|
now that classic classes are gone.
|
|
|
|
* Removed :func:`execfile`. Instead of ``execfile(fn)`` use
|
|
``exec(open(fn).read())``.
|
|
|
|
* Removed :class:`file`. Use :func:`open`.
|
|
|
|
* Removed :func:`reduce`. Use :func:`functools.reduce` if you really
|
|
need it; however, 99 percent of the time an explicit :keyword:`for`
|
|
loop is more readable.
|
|
|
|
* Removed :func:`reload`. Use :func:`imp.reload`.
|
|
|
|
* Removed. :meth:`dict.has_key` -- use the :keyword:`in` operator
|
|
instead.
|
|
|
|
* The :meth:`__oct__` and :meth:`__hex__` special methods are removed
|
|
-- :func:`oct` and :func:`hex` use :meth:`__index__` now to convert
|
|
the argument to an integer.
|
|
|
|
* Removed support for :attr:`__members__` and :attr:`__methods__`.
|
|
|
|
* Renamed the boolean conversion C-level slot and method:
|
|
``nb_nonzero`` is now ``nb_bool`` and :meth:`__nonzero__` is now
|
|
:meth:`__bool__`.
|
|
|
|
* Renamed module :mod:`__builtin__` to :mod:`builtins` (removing the
|
|
underscores, adding an 's'). The :data:`__builtins__` variable
|
|
found in most global namespaces is unchanged. To modify a builtin,
|
|
you should use :mod:`builtins`, not :data:`__builtins__`!
|
|
|
|
* Renamed function attributes :attr:`func_whatever` to
|
|
:attr:`__whatever__`. XXX list every single one.
|
|
|
|
* Removed :exc:`StandardError`.
|
|
|
|
* Removed METH_OLDARGS and WITH_CYCLE_GC. XXX more.
|
|
|
|
.. ======================================================================
|
|
|
|
|
|
Optimizations
|
|
-------------
|
|
|
|
The net result of the 3.0 generalizations is that Python 3.0 runs the
|
|
pystone benchmark around 10% slower than Python 2.5. Most likely the
|
|
biggest cause is the removal of special-casing for small integers.
|
|
There's room for improvement, but it will happen after 3.0 is
|
|
released!
|
|
|
|
.. ======================================================================
|
|
|
|
|
|
New, Improved, And Deprecated Modules
|
|
=====================================
|
|
|
|
As usual, Python's standard library received a number of enhancements and bug
|
|
fixes. Here's a partial list of the most notable changes, sorted alphabetically
|
|
by module name. Consult the :file:`Misc/NEWS` file in the source tree for a more
|
|
complete list of changes, or look through the Subversion logs for all the
|
|
details.
|
|
|
|
* The :mod:`cPickle` module is gone. Use :mod:`pickle` instead. Eventually
|
|
we'll have a transparent accelerator module.
|
|
|
|
* The :mod:`imageop` module is gone.
|
|
|
|
* The :mod:`audiodev`, :mod:`Bastion`, :mod:`bsddb185`, :mod:`exceptions`,
|
|
:mod:`linuxaudiodev`, :mod:`md5`, :mod:`MimeWriter`, :mod:`mimify`,
|
|
:mod:`popen2`, :mod:`rexec`, :mod:`sets`, :mod:`sha`, :mod:`stringold`,
|
|
:mod:`strop`, :mod:`sunaudiodev`, :mod:`timing`, and :mod:`xmllib` modules are
|
|
gone.
|
|
|
|
* The :mod:`bsddb` module is gone. It is being maintained externally
|
|
with its own release schedule better mirroring that of BerkeleyDB.
|
|
See http://www.jcea.es/programacion/pybsddb.htm.
|
|
|
|
* The :mod:`new` module is gone.
|
|
|
|
* The functions :func:`os.tmpnam`, :func:`os.tempnam` and :func:`os.tmpfile`
|
|
have been removed in favor of the :mod:`tempfile` module.
|
|
|
|
* The :mod:`tokenize` module has been changed to work with bytes. The main
|
|
entry point is now :func:`tokenize.tokenize`, instead of generate_tokens.
|
|
|
|
.. ======================================================================
|
|
.. whole new modules get described in subsections here
|
|
|
|
.. ======================================================================
|
|
|
|
|
|
Build And C API Changes
|
|
=======================
|
|
|
|
Changes to Python's build process and to the C API include:
|
|
|
|
* :pep:`3118`: New Buffer API. XXX
|
|
|
|
* :pep:`3121`: Extension Module Initialization & Finalization. XXX
|
|
|
|
* :pep:`3123`: Making :cmacro:`PyObject_HEAD` conform to standard C. XXX
|
|
|
|
* No more C API support for restricted execution.
|
|
|
|
* :cfunc:`PyNumber_Coerce`, :cfunc:`PyNumber_CoerceEx`, :cfunc:`PyMember_Get`,
|
|
and :cfunc:`PyMember_Set` C APIs are removed.
|
|
|
|
* New C API :cfunc:`PyImport_ImportModuleNoBlock`, works like
|
|
:cfunc:`PyImport_ImportModule` but won't block on the import lock (returning
|
|
an error instead).
|
|
|
|
.. ======================================================================
|
|
|
|
|
|
Port-Specific Changes
|
|
---------------------
|
|
|
|
XXX Platform-specific changes go here.
|
|
|
|
* XXX BeOS, RISCOS, Irix, Tru64 support
|
|
|
|
.. ======================================================================
|
|
|
|
|
|
.. _30section-other:
|
|
|
|
Other Changes And Fixes
|
|
=======================
|
|
|
|
As usual, there were a bunch of other improvements and bugfixes
|
|
scattered throughout the source tree. A search through the change
|
|
logs finds there were XXX patches applied and YYY bugs fixed between
|
|
Python 2.6 and 3.0. Both figures are likely to be underestimates.
|
|
|
|
XXX Some of the more notable changes are:
|
|
|
|
* XXX Details go here.
|
|
|
|
.. ======================================================================
|
|
|
|
|
|
Porting To Python 3.0
|
|
=====================
|
|
|
|
For porting existing Python 2.5 or 2.6 source code to Python 3.0, the
|
|
best strategy is the following:
|
|
|
|
0. (Prerequisite:) Start with excellent test coverage.
|
|
|
|
1. Port to Python 2.6. This should be no more work than the average
|
|
port from Python 2.x to Python 2.(x+1). Make sure all your tests
|
|
pass.
|
|
|
|
2. (Still using 2.6:) Turn on the :option:`-3` command line switch.
|
|
This enables warnings about features that will be removed (or
|
|
change) in 3.0. Run your test suite again, and fix code that you
|
|
get warnings about until there are no warnings left, and all your
|
|
tests still pass.
|
|
|
|
3. Run the ``2to3`` source-to-source translator over your source code
|
|
tree. (See :ref:`2to3-reference` for more on this tool.) Run the
|
|
result of the translation under Python 3.0. Manually fix up any
|
|
remaining issues, fixing problems until all tests pass again.
|
|
|
|
It is not recommended to try to write source code that runs unchanged
|
|
under both Python 2.6 and 3.0; you'd have to use a very contorted
|
|
coding style, e.g. avoiding :keyword:`print` statements, metaclasses,
|
|
and much more. If you are maintaining a library that needs to support
|
|
both Python 2.6 and Python 3.0, the best approach is to modify step 3
|
|
above by editing the 2.6 version of the source code and running the
|
|
``2to3`` translator again, rather than editing the 3.0 version of the
|
|
source code.
|
|
|
|
For porting C extensions to Python 3.0, please see :ref:`cporting-howto`.
|
|
|
|
.. ======================================================================
|