| **************************** |
| What's New in Python 3.0 |
| **************************** |
| |
| :Author: Guido van Rossum |
| :Release: 0.1 |
| |
| .. 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, comparing to 2.6 |
| (or in some cases 2.5, since 2.6 isn't released yet). |
| |
| The best estimate for a release date is August 2008. |
| |
| 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 briefly lists the changes that are more likely to trip |
| people up, without necessarily raising obvious errors. These are all |
| explained in more detail below. (I'm not listing syntactic changes |
| and removed or renamed features here, since those tend to produce hard |
| and fast errors; it's the subtle behavioral changes in code that |
| remains syntactically valid that trips people up. I'm also omitting |
| changes to rarely used features.) |
| |
| * Python 3.0 uses strings and bytes instead of the Unicode strings and |
| 8-bit strings. This means that pretty much all code that uses |
| Unicode, encodings or binary data in any way 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. |
| |
| * Text files enforce an encoding; binary files use bytes. This means |
| that if a file is opened using an incorrect mode or encoding, I/O |
| will likely fail. |
| |
| * Bytes aren't hashable, and don't support certain operations like |
| ``b.lower()``, ``b.strip()`` or ``b.split()``. |
| For the latter two, use ``b.strip(b" \t\r\n\f")`` or |
| ``b.split(b" \t\r\n\f")``. |
| |
| * ``map()`` and ``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 ``lambda``). |
| Particularly tricky is ``map()`` invoked for the side effects of the |
| function; the correct transformation is to use a for-loop. |
| |
| * ``dict`` methods ``.keys()``, ``.items()`` and ``.values()`` return |
| views instead of lists. For example, this no longer works: |
| ``k = d.keys(); k.sort()``. Use ``k = sorted(d)`` instead. |
| |
| * ``1/2`` returns a float. Use ``1//2`` to get the truncating behavior. |
| |
| * Code that unconditionally strips the trailing ``L`` from the ``repr()`` |
| of a long integer will chop off the last digit instead. |
| |
| * The ``print()`` function doesn't support the "softspace" feature of |
| the old ``print`` statement. For example, in Python 2.x, |
| ``print "A\n", "B\n"`` would write ``"A\nB\n"``; but in Python 3.0, |
| ``print("A\n", "B\n")`` writes ``"A\n B\n"``. |
| |
| * Also, ``print`` and ``print (x, y)`` behave differently without |
| warning: the former used to add a newline in 2.x, but does nothing |
| in 3.0; the latter used to print the ``repr()`` of a tuple in 2.x, |
| but prints the individual values in 3.0. |
| |
| * You'll be finding yourself typing ``print x`` a lot in interactive |
| mode. Time to retrain your fingers. :-) |
| |
| |
| Strings and Bytes |
| ================= |
| |
| * There is only one string type; its name is ``str`` but its behavior |
| and implementation are more like ``unicode`` in 2.x. |
| |
| * PEP 358: There is a new type, ``bytes``, to represent binary data |
| (and encoded text, which is treated as binary data until you decide |
| to decode it). The ``str`` and ``bytes`` types cannot be mixed; you |
| must always explicitly convert between them, using the ``.encode()`` |
| (str -> bytes) or ``.decode()`` (bytes -> str) methods. Comparing a |
| bytes and a str instance for equality raises a TypeError; this |
| catches common mistakes. |
| |
| * PEP 3112: Bytes literals. E.g. b"abc". |
| |
| * 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 ``StringIO`` and ``cStringIO`` modules are gone. Instead, |
| import ``StringIO`` or ``BytesIO`` from the ``io`` module. |
| |
| |
| PEP 3101: A New Approach to String Formatting |
| ============================================= |
| |
| XXX |
| |
| |
| PEP 3106: Revamping ``.keys()``, ``.items()`` and ``.values()`` |
| =============================================================== |
| |
| XXX |
| |
| |
| PEP 3107: Function Annotations |
| ============================== |
| |
| XXX |
| |
| |
| Exception Stuff |
| =============== |
| |
| * PEP 352: Exceptions must derive from BaseException. This is the |
| root of the exception hierarchy. |
| |
| * StandardException was removed (already in 2.6). |
| |
| * Dropping sequence behavior (slicing!) and ``.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. |
| |
| * PEP 3134: Exception chaining. (The ``__context__`` feature from the |
| PEP hasn't been implemented yet in 3.0a1.) |
| |
| |
| 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 |
| ====================== |
| |
| Here are most of the changes that Python 3.0 makes to the core Python |
| language and built-in functions. |
| |
| * Removed backticks (use ``repr()`` instead). |
| |
| * Removed ``<>`` (use ``!=`` instead). |
| |
| * ``as`` and ``with`` are keywords. |
| |
| * PEP 237: ``long`` renamed to ``int``. That is, there is only one |
| built-in integral type, named ``int``; but it behaves like the old |
| ``long`` type. |
| |
| * PEP 238: int division returns a float. |
| |
| * The ordering operators behave differently: for example, ``x < y`` |
| where ``x`` and ``y`` have incompatible types raises ``TypeError`` |
| instead of returning a pseudo-random boolean. |
| |
| * ``__getslice__()`` and friends killed. The syntax ``a[i:j]`` now |
| translates to ``a.__getitem__(slice(i, j))`` (or ``__setitem__`` |
| or ``__delitem__``, depending on context). |
| |
| * 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. |
| |
| * PEP 3104: ``nonlocal`` statement. Using ``nonlocal x`` you can now |
| assign directly to a variable in an outer (but non-global) scope. |
| |
| * PEP 3105: ``print`` is now a function. Keyword arguments |
| ``file=sys.stdout``, ``sep=" "`` and ``end="\n"`` let you customize |
| it. |
| |
| * PEP 3111: ``raw_input()`` renamed to ``input()``. That is, the new |
| ``input()`` function reads a line from ``sys.stdin`` and returns it |
| with the trailing newline stripped. It raises ``EOFError`` if the |
| input is terminated prematurely. To get the old behavior of |
| ``input()``, use ``eval(input())``. |
| |
| * ``xrange()`` renamed to ``range()``. |
| |
| * 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. |
| |
| * PEP 3114: ``.next()`` renamed to ``.__next__()``, new builtin |
| ``next()`` to call the ``__next__()`` method on an object. |
| |
| * PEP 3127: New octal literals; binary literals and ``bin()``. |
| Instead of ``0666``, you write ``0o666``. The oct() function is |
| modified accordingly. Also, ``0b1010`` equals 10, and ``bin(10)`` |
| returns ``"0b1010"``. ``0666`` is now a ``SyntaxError``. |
| |
| * 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 list; the right-hand |
| side may be any iterable. |
| |
| * PEP 3135: New ``super()``. You can now invoke ``super()`` without |
| arguments and the right class and instance will automatically be |
| chosen. With arguments, its behavior is unchanged. |
| |
| * ``zip()``, ``map()`` and ``filter()`` return iterators. |
| |
| * ``string.letters`` and its friends (``.lowercase`` and |
| ``.uppercase``) are gone. Use ``string.ascii_letters`` |
| etc. instead. |
| |
| * Removed: ``apply()``, ``callable()``, ``coerce()``, ``execfile()``, |
| ``file()``, ``reduce()``, ``reload()``. |
| |
| * Removed: ``dict.has_key()``. |
| |
| * ``exec`` is now a function. |
| |
| |
| .. ====================================================================== |
| |
| |
| Optimizations |
| ------------- |
| |
| * Detailed changes are listed here. |
| |
| The net result of the 3.0 generalizations is that Python 3.0 runs the |
| pystone benchmark around 33% slower than Python 2.5. There's room for |
| improvement; we expect to be optimizing string and integer operations |
| significantly before the final 3.0 release! |
| |
| .. ====================================================================== |
| |
| |
| 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 ``cPickle`` module is gone. Use ``pickle`` instead. Eventually |
| we'll have a transparent accelerator module. |
| |
| .. ====================================================================== |
| .. 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. |
| |
| * PEP 3121: Extension Module Initialization & Finalization. |
| |
| * PEP 3123: Making ``PyObject_HEAD`` conform to standard C. |
| |
| .. ====================================================================== |
| |
| |
| Port-Specific Changes |
| --------------------- |
| |
| Platform-specific changes go here. |
| |
| .. ====================================================================== |
| |
| |
| .. _section-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. |
| |
| Some of the more notable changes are: |
| |
| * Details go here. |
| |
| .. ====================================================================== |
| |
| |
| Porting to Python 3.0 |
| ===================== |
| |
| This section lists previously described changes that may require |
| changes to your code: |
| |
| * Everything is all in the details! |
| |
| .. ====================================================================== |
| |
| |
| .. _acks: |
| |
| Acknowledgements |
| ================ |
| |
| The author would like to thank the following people for offering |
| suggestions, corrections and assistance with various drafts of this |
| article: Georg Brandl. |
| |