Georg Brandl | c47408a | 2008-12-04 18:44:53 +0000 | [diff] [blame] | 1 | **************************** |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 2 | What's New In Python 3.1 |
Georg Brandl | c47408a | 2008-12-04 18:44:53 +0000 | [diff] [blame] | 3 | **************************** |
| 4 | |
| 5 | .. XXX Add trademark info for Apple, Microsoft. |
| 6 | |
Raymond Hettinger | 1f251a0 | 2009-04-04 10:47:35 +0000 | [diff] [blame] | 7 | :Author: Raymond Hettinger |
Benjamin Peterson | 3432829 | 2008-12-05 03:05:29 +0000 | [diff] [blame] | 8 | :Release: |release| |
| 9 | :Date: |today| |
Georg Brandl | c47408a | 2008-12-04 18:44:53 +0000 | [diff] [blame] | 10 | |
| 11 | .. $Id$ |
| 12 | Rules for maintenance: |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 13 | |
Georg Brandl | c47408a | 2008-12-04 18:44:53 +0000 | [diff] [blame] | 14 | * Anyone can add text to this document. Do not spend very much time |
| 15 | on the wording of your changes, because your text will probably |
| 16 | get rewritten to some degree. |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 17 | |
Georg Brandl | c47408a | 2008-12-04 18:44:53 +0000 | [diff] [blame] | 18 | * The maintainer will go through Misc/NEWS periodically and add |
| 19 | changes; it's therefore more important to add your changes to |
| 20 | Misc/NEWS than to this file. (Note: I didn't get to this for 3.0. |
| 21 | GvR.) |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 22 | |
Georg Brandl | c47408a | 2008-12-04 18:44:53 +0000 | [diff] [blame] | 23 | * This is not a complete list of every single change; completeness |
| 24 | is the purpose of Misc/NEWS. Some changes I consider too small |
| 25 | or esoteric to include. If such a change is added to the text, |
| 26 | I'll just remove it. (This is another reason you shouldn't spend |
| 27 | too much time on writing your addition.) |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 28 | |
Georg Brandl | c47408a | 2008-12-04 18:44:53 +0000 | [diff] [blame] | 29 | * If you want to draw your new text to the attention of the |
| 30 | maintainer, add 'XXX' to the beginning of the paragraph or |
| 31 | section. |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 32 | |
Georg Brandl | c47408a | 2008-12-04 18:44:53 +0000 | [diff] [blame] | 33 | * It's OK to just add a fragmentary note about a change. For |
| 34 | example: "XXX Describe the transmogrify() function added to the |
| 35 | socket module." The maintainer will research the change and |
| 36 | write the necessary text. |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 37 | |
Georg Brandl | c47408a | 2008-12-04 18:44:53 +0000 | [diff] [blame] | 38 | * You can comment out your additions if you like, but it's not |
| 39 | necessary (especially when a final release is some months away). |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 40 | |
Georg Brandl | c47408a | 2008-12-04 18:44:53 +0000 | [diff] [blame] | 41 | * Credit the author of a patch or bugfix. Just the name is |
| 42 | sufficient; the e-mail address isn't necessary. (Due to time |
| 43 | constraints I haven't managed to do this for 3.0. GvR.) |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 44 | |
Georg Brandl | c47408a | 2008-12-04 18:44:53 +0000 | [diff] [blame] | 45 | * It's helpful to add the bug/patch number as a comment: |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 46 | |
Georg Brandl | c47408a | 2008-12-04 18:44:53 +0000 | [diff] [blame] | 47 | % Patch 12345 |
| 48 | XXX Describe the transmogrify() function added to the socket |
| 49 | module. |
| 50 | (Contributed by P.Y. Developer.) |
Georg Brandl | 48310cd | 2009-01-03 21:18:54 +0000 | [diff] [blame] | 51 | |
Georg Brandl | c47408a | 2008-12-04 18:44:53 +0000 | [diff] [blame] | 52 | This saves the maintainer the effort of going through the SVN log |
| 53 | when researching a change. (Again, I didn't get to this for 3.0. |
| 54 | GvR.) |
| 55 | |
| 56 | This article explains the new features in Python 3.1, compared to 3.0. |
| 57 | |
| 58 | .. Compare with previous release in 2 - 3 sentences here. |
| 59 | .. add hyperlink when the documentation becomes available online. |
| 60 | |
| 61 | .. ====================================================================== |
| 62 | .. Large, PEP-level features and changes should be described here. |
| 63 | .. Should there be a new section here for 3k migration? |
| 64 | .. Or perhaps a more general section describing module changes/deprecation? |
| 65 | .. sets module deprecated |
| 66 | .. ====================================================================== |
| 67 | |
| 68 | |
Raymond Hettinger | 1f251a0 | 2009-04-04 10:47:35 +0000 | [diff] [blame] | 69 | PEP 372: Ordered Dictionaries |
| 70 | ============================= |
| 71 | |
| 72 | Regular Python dictionaries iterate over key/value pairs in arbitrary order. |
| 73 | Over the years, a number of authors have written alternative implementations |
| 74 | that remember the order that the keys were originally inserted. Based on |
| 75 | the experiences from those implementations, the :mod:`collections` module |
| 76 | now has an :class:`OrderedDict` class. |
| 77 | |
| 78 | The OrderedDict API is substantially the same as regular dictionaries |
| 79 | but will iterate over keys and values in a guaranteed order depending on |
| 80 | when a key was first inserted. If a new entry overwrites an existing entry, |
| 81 | the original insertion position is left unchanged. Deleting an entry and |
| 82 | reinserting it will move it to the end. |
| 83 | |
| 84 | The standard library now supports use of ordered dictionaries in several |
| 85 | modules. The :mod:`ConfigParser` modules uses them by default. This lets |
| 86 | configuration files be read, modified, and then written back in their original |
| 87 | order. The :mod:`collections` module's :meth:`namedtuple._asdict` method now |
| 88 | returns a dictionary with the values appearing in the same order as the |
| 89 | underlying tuple.count The :mod:`json` module is being built-out with an |
| 90 | *object_pairs_hook* to allow OrderedDicts to be built by the decoder. |
| 91 | Support was also builtin for third-party tools like PyYAML. |
| 92 | |
| 93 | .. seealso:: |
| 94 | |
| 95 | :pep:`372` - Ordered Dictionaries |
| 96 | PEP written by Armin Roancher and Raymond D. Hettinger; implemented by |
| 97 | Raymond Hettinger |
| 98 | |
| 99 | PEP 378: Format Specifier for Thousands Separator |
| 100 | ================================================= |
| 101 | |
| 102 | The builtin :func:`format` function and the :meth:`str.format` method use |
| 103 | a mini-language that now includes a simple, non-locale aware way to format |
| 104 | a number with a thousands separator. That provides a way to humanize a |
| 105 | program's output, improving its professional appearance and readability:: |
| 106 | |
| 107 | >>> format(Decimal('1234567.89'), ',f') |
| 108 | '1,234,567.89' |
| 109 | |
| 110 | The currently supported types are :class:`int` and :class:`Decimal`. |
| 111 | Support for :class:`float` is expected before the beta release. |
| 112 | Discussions are underway about how to specify alternative separators |
| 113 | like dots, spaces, apostrophes, or underscores. |
| 114 | |
| 115 | .. seealso:: |
| 116 | |
| 117 | :pep:`378` - Format Specifier for Thousands Separator |
| 118 | PEP written by Raymond Hettinger; implemented by Eric Smith and |
| 119 | Mark Dickinson. |
| 120 | |
| 121 | |
Mark Dickinson | 54bc1ec | 2008-12-17 16:19:07 +0000 | [diff] [blame] | 122 | Other Language Changes |
| 123 | ====================== |
| 124 | |
| 125 | Some smaller changes made to the core Python language are: |
| 126 | |
| 127 | * The :func:`int` type gained a ``bit_length`` method that returns the |
| 128 | number of bits necessary to represent its argument in binary:: |
| 129 | |
| 130 | >>> n = 37 |
| 131 | >>> bin(37) |
| 132 | '0b100101' |
| 133 | >>> n.bit_length() |
| 134 | 6 |
| 135 | >>> n = 2**123-1 |
| 136 | >>> n.bit_length() |
| 137 | 123 |
| 138 | >>> (n+1).bit_length() |
| 139 | 124 |
| 140 | |
| 141 | (Contributed by Fredrik Johansson and Victor Stinner; :issue:`3439`.) |
| 142 | |
Mark Dickinson | bd79264 | 2009-03-18 20:06:12 +0000 | [diff] [blame] | 143 | * Integers are now stored internally either in base 2**15 or in base |
| 144 | 2**30, the base being determined at build time. Previously, they |
| 145 | were always stored in base 2**15. Using base 2**30 gives |
| 146 | significant performance improvements on 64-bit machines, but |
| 147 | benchmark results on 32-bit machines have been mixed. Therefore, |
| 148 | the default is to use base 2**30 on 64-bit machines and base 2**15 |
| 149 | on 32-bit machines; on Unix, there's a new configure option |
| 150 | --enable-big-digits that can be used to override this default. |
| 151 | |
| 152 | Apart from the performance improvements this change should be |
| 153 | invisible to end users, with one exception: for testing and |
| 154 | debugging purposes there's a new structseq ``sys.int_info`` that |
| 155 | provides information about the internal format, giving the number of |
| 156 | bits per digit and the size in bytes of the C type used to store |
| 157 | each digit:: |
| 158 | |
| 159 | >>> import sys |
| 160 | >>> sys.int_info |
| 161 | sys.int_info(bits_per_digit=30, sizeof_digit=4) |
| 162 | |
Mark Dickinson | bd79264 | 2009-03-18 20:06:12 +0000 | [diff] [blame] | 163 | (Contributed by Mark Dickinson; :issue:`4258`.) |
| 164 | |
Mark Dickinson | 54bc1ec | 2008-12-17 16:19:07 +0000 | [diff] [blame] | 165 | |
Raymond Hettinger | 1f251a0 | 2009-04-04 10:47:35 +0000 | [diff] [blame] | 166 | * Added a :class:`collections.Counter` class to support convenient |
| 167 | counting of unique items in a sequence or iterable:: |
| 168 | |
| 169 | >>> Counter(['red', 'blue', 'red', 'green', 'blue', 'blue']) |
| 170 | Counter({'blue': 3, 'red': 2, 'green': 1}) |
| 171 | |
| 172 | (Contributed by Raymond Hettinger; :issue:`1696199`.) |
| 173 | |
| 174 | * The :class:`gzip.GzipFile` and :class:`bz2.BZ2File` classs now support |
| 175 | the context manager protocol. |
| 176 | |
| 177 | (Contributed by Jacques Frechet; :issue:`4272`.) |
| 178 | |
| 179 | * The :mod:`Decimal` module now supports two new methods to create a |
| 180 | decimal object that from a binary :class:`float`. The conversion is |
| 181 | exact but can sometimes be surprising:: |
| 182 | |
| 183 | >>> Decimal.from_float(1.1) |
| 184 | Decimal('1.100000000000000088817841970012523233890533447265625') |
| 185 | |
| 186 | The long decimal result shows the actual binary fraction being |
| 187 | stored for *1.1*. The fraction has many digits because *1.1* cannot |
| 188 | be exactly represented in binary. |
| 189 | |
| 190 | (Contributed by Raymond Hettinger and Mark Dickinson.) |
| 191 | |
Raymond Hettinger | e7ec57d | 2009-04-04 11:08:48 +0000 | [diff] [blame^] | 192 | * The fields in :func:`format` strings can now be automatically |
| 193 | numbered:: |
| 194 | |
| 195 | >>> 'Sir {} of {}'.format('Gallahad', 'Camelot') |
| 196 | 'Sir Gallahad of Camelot' |
| 197 | |
| 198 | Formerly, the string would have required numbered fields such as: |
| 199 | ``'Sir {0} of {1}'``. |
| 200 | |
| 201 | (Contributed by Eric Smith; :issue:`5237`.) |
| 202 | |
| 203 | * The :mod:`itertools` module grew two new functions. The |
| 204 | :func:`itertools.combinations_with_replacement` function is one of |
| 205 | four for generating combinatorics including permutations and Cartesian |
| 206 | products. The :func:`itertools.compress` function mimics its namesake |
| 207 | from APL. Also, the existing :func:`itertools.count` function now has |
| 208 | an optional *step* argument and can accept any type of counting |
| 209 | sequence including :class:`fractions.Fraction` and |
| 210 | :class:`decimal.Decimal`. |
| 211 | |
| 212 | (Contributed by Raymond Hettinger.) |
| 213 | |
Raymond Hettinger | 1f251a0 | 2009-04-04 10:47:35 +0000 | [diff] [blame] | 214 | |
Georg Brandl | c47408a | 2008-12-04 18:44:53 +0000 | [diff] [blame] | 215 | .. ====================================================================== |
Antoine Pitrou | b556452 | 2009-03-28 19:45:26 +0000 | [diff] [blame] | 216 | |
| 217 | |
| 218 | Optimizations |
| 219 | ------------- |
| 220 | |
| 221 | Major performance enhancements have been added: |
| 222 | |
| 223 | * The new I/O library (as defined in :pep:`3116`) was mostly written in |
| 224 | Python and quickly proved to be a problematic bottleneck in Python 3.0. |
| 225 | In Python 3.1, the I/O library has been entirely rewritten in C and is |
| 226 | 2 to 20 times faster depending on the task at hand. The pure Python |
| 227 | version is still available for experimentation purposes through |
| 228 | the ``_pyio`` module. |
| 229 | |
| 230 | (Contributed by Amaury Forgeot d'Arc and Antoine Pitrou.) |
| 231 | |
| 232 | * A new configure flag, ``--with-computed-gotos``, enables a faster opcode |
| 233 | dispatch mechanism on compilers which support it. Speedups of up to 20% |
| 234 | have been observed, depending on the system and compiler. |
| 235 | |
| 236 | (Contributed by Antoine Pitrou, :issue:`4753`.) |
| 237 | |
Raymond Hettinger | e7ec57d | 2009-04-04 11:08:48 +0000 | [diff] [blame^] | 238 | * Add a heuristic so that tuples and dicts containing only untrackable objects |
| 239 | are not tracked by the garbage collector. This can reduce the size of |
| 240 | collections and therefore the garbage collection overhead on long-running |
| 241 | programs, depending on their particular use of datatypes. |
| 242 | |
| 243 | (Contributed by Antoine Pitrou, :issue:`4688`.) |
| 244 | |
Raymond Hettinger | 1f251a0 | 2009-04-04 10:47:35 +0000 | [diff] [blame] | 245 | XXX The JSON module is getting a C extension for speed. |
Antoine Pitrou | b556452 | 2009-03-28 19:45:26 +0000 | [diff] [blame] | 246 | |
| 247 | .. ====================================================================== |