|
1 **************************** |
|
2 What's New in Python 2.6 |
|
3 **************************** |
|
4 |
|
5 .. XXX add trademark info for Apple, Microsoft, SourceForge. |
|
6 |
|
7 :Author: A.M. Kuchling (amk at amk.ca) |
|
8 :Release: |release| |
|
9 :Date: |today| |
|
10 |
|
11 .. $Id: 2.6.rst 67146 2008-11-07 08:56:27Z georg.brandl $ |
|
12 Rules for maintenance: |
|
13 |
|
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. |
|
17 |
|
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. |
|
21 |
|
22 * This is not a complete list of every single change; completeness |
|
23 is the purpose of Misc/NEWS. Some changes I consider too small |
|
24 or esoteric to include. If such a change is added to the text, |
|
25 I'll just remove it. (This is another reason you shouldn't spend |
|
26 too much time on writing your addition.) |
|
27 |
|
28 * If you want to draw your new text to the attention of the |
|
29 maintainer, add 'XXX' to the beginning of the paragraph or |
|
30 section. |
|
31 |
|
32 * It's OK to just add a fragmentary note about a change. For |
|
33 example: "XXX Describe the transmogrify() function added to the |
|
34 socket module." The maintainer will research the change and |
|
35 write the necessary text. |
|
36 |
|
37 * You can comment out your additions if you like, but it's not |
|
38 necessary (especially when a final release is some months away). |
|
39 |
|
40 * Credit the author of a patch or bugfix. Just the name is |
|
41 sufficient; the e-mail address isn't necessary. |
|
42 |
|
43 * It's helpful to add the bug/patch number in a parenthetical comment. |
|
44 |
|
45 XXX Describe the transmogrify() function added to the socket |
|
46 module. |
|
47 (Contributed by P.Y. Developer; :issue:`12345`.) |
|
48 |
|
49 This saves the maintainer some effort going through the SVN logs |
|
50 when researching a change. |
|
51 |
|
52 This article explains the new features in Python 2.6, released on October 1 |
|
53 2008. The release schedule is described in :pep:`361`. |
|
54 |
|
55 The major theme of Python 2.6 is preparing the migration path to |
|
56 Python 3.0, a major redesign of the language. Whenever possible, |
|
57 Python 2.6 incorporates new features and syntax from 3.0 while |
|
58 remaining compatible with existing code by not removing older features |
|
59 or syntax. When it's not possible to do that, Python 2.6 tries to do |
|
60 what it can, adding compatibility functions in a |
|
61 :mod:`future_builtins` module and a :option:`-3` switch to warn about |
|
62 usages that will become unsupported in 3.0. |
|
63 |
|
64 Some significant new packages have been added to the standard library, |
|
65 such as the :mod:`multiprocessing` and :mod:`json` modules, but |
|
66 there aren't many new features that aren't related to Python 3.0 in |
|
67 some way. |
|
68 |
|
69 Python 2.6 also sees a number of improvements and bugfixes throughout |
|
70 the source. A search through the change logs finds there were 259 |
|
71 patches applied and 612 bugs fixed between Python 2.5 and 2.6. Both |
|
72 figures are likely to be underestimates. |
|
73 |
|
74 This article doesn't attempt to provide a complete specification of |
|
75 the new features, but instead provides a convenient overview. For |
|
76 full details, you should refer to the documentation for Python 2.6. If |
|
77 you want to understand the rationale for the design and |
|
78 implementation, refer to the PEP for a particular new feature. |
|
79 Whenever possible, "What's New in Python" links to the bug/patch item |
|
80 for each change. |
|
81 |
|
82 .. Compare with previous release in 2 - 3 sentences here. |
|
83 add hyperlink when the documentation becomes available online. |
|
84 |
|
85 .. ======================================================================== |
|
86 .. Large, PEP-level features and changes should be described here. |
|
87 .. Should there be a new section here for 3k migration? |
|
88 .. Or perhaps a more general section describing module changes/deprecation? |
|
89 .. ======================================================================== |
|
90 |
|
91 Python 3.0 |
|
92 ================ |
|
93 |
|
94 The development cycle for Python versions 2.6 and 3.0 was |
|
95 synchronized, with the alpha and beta releases for both versions being |
|
96 made on the same days. The development of 3.0 has influenced many |
|
97 features in 2.6. |
|
98 |
|
99 Python 3.0 is a far-ranging redesign of Python that breaks |
|
100 compatibility with the 2.x series. This means that existing Python |
|
101 code will need some conversion in order to run on |
|
102 Python 3.0. However, not all the changes in 3.0 necessarily break |
|
103 compatibility. In cases where new features won't cause existing code |
|
104 to break, they've been backported to 2.6 and are described in this |
|
105 document in the appropriate place. Some of the 3.0-derived features |
|
106 are: |
|
107 |
|
108 * A :meth:`__complex__` method for converting objects to a complex number. |
|
109 * Alternate syntax for catching exceptions: ``except TypeError as exc``. |
|
110 * The addition of :func:`functools.reduce` as a synonym for the built-in |
|
111 :func:`reduce` function. |
|
112 |
|
113 Python 3.0 adds several new built-in functions and changes the |
|
114 semantics of some existing built-ins. Functions that are new in 3.0 |
|
115 such as :func:`bin` have simply been added to Python 2.6, but existing |
|
116 built-ins haven't been changed; instead, the :mod:`future_builtins` |
|
117 module has versions with the new 3.0 semantics. Code written to be |
|
118 compatible with 3.0 can do ``from future_builtins import hex, map`` as |
|
119 necessary. |
|
120 |
|
121 A new command-line switch, :option:`-3`, enables warnings |
|
122 about features that will be removed in Python 3.0. You can run code |
|
123 with this switch to see how much work will be necessary to port |
|
124 code to 3.0. The value of this switch is available |
|
125 to Python code as the boolean variable :data:`sys.py3kwarning`, |
|
126 and to C extension code as :cdata:`Py_Py3kWarningFlag`. |
|
127 |
|
128 .. seealso:: |
|
129 |
|
130 The 3xxx series of PEPs, which contains proposals for Python 3.0. |
|
131 :pep:`3000` describes the development process for Python 3.0. |
|
132 Start with :pep:`3100` that describes the general goals for Python |
|
133 3.0, and then explore the higher-numbered PEPS that propose |
|
134 specific features. |
|
135 |
|
136 |
|
137 Changes to the Development Process |
|
138 ================================================== |
|
139 |
|
140 While 2.6 was being developed, the Python development process |
|
141 underwent two significant changes: we switched from SourceForge's |
|
142 issue tracker to a customized Roundup installation, and the |
|
143 documentation was converted from LaTeX to reStructuredText. |
|
144 |
|
145 |
|
146 New Issue Tracker: Roundup |
|
147 -------------------------------------------------- |
|
148 |
|
149 For a long time, the Python developers had been growing increasingly |
|
150 annoyed by SourceForge's bug tracker. SourceForge's hosted solution |
|
151 doesn't permit much customization; for example, it wasn't possible to |
|
152 customize the life cycle of issues. |
|
153 |
|
154 The infrastructure committee of the Python Software Foundation |
|
155 therefore posted a call for issue trackers, asking volunteers to set |
|
156 up different products and import some of the bugs and patches from |
|
157 SourceForge. Four different trackers were examined: `Jira |
|
158 <http://www.atlassian.com/software/jira/>`__, |
|
159 `Launchpad <http://www.launchpad.net>`__, |
|
160 `Roundup <http://roundup.sourceforge.net/>`__, and |
|
161 `Trac <http://trac.edgewall.org/>`__. |
|
162 The committee eventually settled on Jira |
|
163 and Roundup as the two candidates. Jira is a commercial product that |
|
164 offers no-cost hosted instances to free-software projects; Roundup |
|
165 is an open-source project that requires volunteers |
|
166 to administer it and a server to host it. |
|
167 |
|
168 After posting a call for volunteers, a new Roundup installation was |
|
169 set up at http://bugs.python.org. One installation of Roundup can |
|
170 host multiple trackers, and this server now also hosts issue trackers |
|
171 for Jython and for the Python web site. It will surely find |
|
172 other uses in the future. Where possible, |
|
173 this edition of "What's New in Python" links to the bug/patch |
|
174 item for each change. |
|
175 |
|
176 Hosting of the Python bug tracker is kindly provided by |
|
177 `Upfront Systems <http://www.upfrontsystems.co.za/>`__ |
|
178 of Stellenbosch, South Africa. Martin von Loewis put a |
|
179 lot of effort into importing existing bugs and patches from |
|
180 SourceForge; his scripts for this import operation are at |
|
181 http://svn.python.org/view/tracker/importer/ and may be useful to |
|
182 other projects wishing to move from SourceForge to Roundup. |
|
183 |
|
184 .. seealso:: |
|
185 |
|
186 http://bugs.python.org |
|
187 The Python bug tracker. |
|
188 |
|
189 http://bugs.jython.org: |
|
190 The Jython bug tracker. |
|
191 |
|
192 http://roundup.sourceforge.net/ |
|
193 Roundup downloads and documentation. |
|
194 |
|
195 http://svn.python.org/view/tracker/importer/ |
|
196 Martin von Loewis's conversion scripts. |
|
197 |
|
198 New Documentation Format: reStructuredText Using Sphinx |
|
199 ----------------------------------------------------------- |
|
200 |
|
201 The Python documentation was written using LaTeX since the project |
|
202 started around 1989. In the 1980s and early 1990s, most documentation |
|
203 was printed out for later study, not viewed online. LaTeX was widely |
|
204 used because it provided attractive printed output while remaining |
|
205 straightforward to write once the basic rules of the markup were |
|
206 learned. |
|
207 |
|
208 Today LaTeX is still used for writing publications destined for |
|
209 printing, but the landscape for programming tools has shifted. We no |
|
210 longer print out reams of documentation; instead, we browse through it |
|
211 online and HTML has become the most important format to support. |
|
212 Unfortunately, converting LaTeX to HTML is fairly complicated and Fred |
|
213 L. Drake Jr., the long-time Python documentation editor, spent a lot |
|
214 of time maintaining the conversion process. Occasionally people would |
|
215 suggest converting the documentation into SGML and later XML, but |
|
216 performing a good conversion is a major task and no one ever committed |
|
217 the time required to finish the job. |
|
218 |
|
219 During the 2.6 development cycle, Georg Brandl put a lot of effort |
|
220 into building a new toolchain for processing the documentation. The |
|
221 resulting package is called Sphinx, and is available from |
|
222 http://sphinx.pocoo.org/. |
|
223 |
|
224 Sphinx concentrates on HTML output, producing attractively styled and |
|
225 modern HTML; printed output is still supported through conversion to |
|
226 LaTeX. The input format is reStructuredText, a markup syntax |
|
227 supporting custom extensions and directives that is commonly used in |
|
228 the Python community. |
|
229 |
|
230 Sphinx is a standalone package that can be used for writing, and |
|
231 almost two dozen other projects |
|
232 (`listed on the Sphinx web site <http://sphinx.pocoo.org/examples.html>`__) |
|
233 have adopted Sphinx as their documentation tool. |
|
234 |
|
235 .. seealso:: |
|
236 |
|
237 :ref:`documenting-index` |
|
238 Describes how to write for Python's documentation. |
|
239 |
|
240 `Sphinx <http://sphinx.pocoo.org/>`__ |
|
241 Documentation and code for the Sphinx toolchain. |
|
242 |
|
243 `Docutils <http://docutils.sf.net>`__ |
|
244 The underlying reStructuredText parser and toolset. |
|
245 |
|
246 |
|
247 PEP 343: The 'with' statement |
|
248 ============================= |
|
249 |
|
250 The previous version, Python 2.5, added the ':keyword:`with`' |
|
251 statement as an optional feature, to be enabled by a ``from __future__ |
|
252 import with_statement`` directive. In 2.6 the statement no longer needs to |
|
253 be specially enabled; this means that :keyword:`with` is now always a |
|
254 keyword. The rest of this section is a copy of the corresponding |
|
255 section from the "What's New in Python 2.5" document; if you're |
|
256 familiar with the ':keyword:`with`' statement |
|
257 from Python 2.5, you can skip this section. |
|
258 |
|
259 The ':keyword:`with`' statement clarifies code that previously would use |
|
260 ``try...finally`` blocks to ensure that clean-up code is executed. In this |
|
261 section, I'll discuss the statement as it will commonly be used. In the next |
|
262 section, I'll examine the implementation details and show how to write objects |
|
263 for use with this statement. |
|
264 |
|
265 The ':keyword:`with`' statement is a control-flow structure whose basic |
|
266 structure is:: |
|
267 |
|
268 with expression [as variable]: |
|
269 with-block |
|
270 |
|
271 The expression is evaluated, and it should result in an object that supports the |
|
272 context management protocol (that is, has :meth:`__enter__` and :meth:`__exit__` |
|
273 methods. |
|
274 |
|
275 The object's :meth:`__enter__` is called before *with-block* is executed and |
|
276 therefore can run set-up code. It also may return a value that is bound to the |
|
277 name *variable*, if given. (Note carefully that *variable* is *not* assigned |
|
278 the result of *expression*.) |
|
279 |
|
280 After execution of the *with-block* is finished, the object's :meth:`__exit__` |
|
281 method is called, even if the block raised an exception, and can therefore run |
|
282 clean-up code. |
|
283 |
|
284 Some standard Python objects now support the context management protocol and can |
|
285 be used with the ':keyword:`with`' statement. File objects are one example:: |
|
286 |
|
287 with open('/etc/passwd', 'r') as f: |
|
288 for line in f: |
|
289 print line |
|
290 ... more processing code ... |
|
291 |
|
292 After this statement has executed, the file object in *f* will have been |
|
293 automatically closed, even if the :keyword:`for` loop raised an exception part- |
|
294 way through the block. |
|
295 |
|
296 .. note:: |
|
297 |
|
298 In this case, *f* is the same object created by :func:`open`, because |
|
299 :meth:`file.__enter__` returns *self*. |
|
300 |
|
301 The :mod:`threading` module's locks and condition variables also support the |
|
302 ':keyword:`with`' statement:: |
|
303 |
|
304 lock = threading.Lock() |
|
305 with lock: |
|
306 # Critical section of code |
|
307 ... |
|
308 |
|
309 The lock is acquired before the block is executed and always released once the |
|
310 block is complete. |
|
311 |
|
312 The :func:`localcontext` function in the :mod:`decimal` module makes it easy |
|
313 to save and restore the current decimal context, which encapsulates the desired |
|
314 precision and rounding characteristics for computations:: |
|
315 |
|
316 from decimal import Decimal, Context, localcontext |
|
317 |
|
318 # Displays with default precision of 28 digits |
|
319 v = Decimal('578') |
|
320 print v.sqrt() |
|
321 |
|
322 with localcontext(Context(prec=16)): |
|
323 # All code in this block uses a precision of 16 digits. |
|
324 # The original context is restored on exiting the block. |
|
325 print v.sqrt() |
|
326 |
|
327 |
|
328 .. _new-26-context-managers: |
|
329 |
|
330 Writing Context Managers |
|
331 ------------------------ |
|
332 |
|
333 Under the hood, the ':keyword:`with`' statement is fairly complicated. Most |
|
334 people will only use ':keyword:`with`' in company with existing objects and |
|
335 don't need to know these details, so you can skip the rest of this section if |
|
336 you like. Authors of new objects will need to understand the details of the |
|
337 underlying implementation and should keep reading. |
|
338 |
|
339 A high-level explanation of the context management protocol is: |
|
340 |
|
341 * The expression is evaluated and should result in an object called a "context |
|
342 manager". The context manager must have :meth:`__enter__` and :meth:`__exit__` |
|
343 methods. |
|
344 |
|
345 * The context manager's :meth:`__enter__` method is called. The value returned |
|
346 is assigned to *VAR*. If no ``as VAR`` clause is present, the value is simply |
|
347 discarded. |
|
348 |
|
349 * The code in *BLOCK* is executed. |
|
350 |
|
351 * If *BLOCK* raises an exception, the :meth:`__exit__(type, value, traceback)` |
|
352 is called with the exception details, the same values returned by |
|
353 :func:`sys.exc_info`. The method's return value controls whether the exception |
|
354 is re-raised: any false value re-raises the exception, and ``True`` will result |
|
355 in suppressing it. You'll only rarely want to suppress the exception, because |
|
356 if you do the author of the code containing the ':keyword:`with`' statement will |
|
357 never realize anything went wrong. |
|
358 |
|
359 * If *BLOCK* didn't raise an exception, the :meth:`__exit__` method is still |
|
360 called, but *type*, *value*, and *traceback* are all ``None``. |
|
361 |
|
362 Let's think through an example. I won't present detailed code but will only |
|
363 sketch the methods necessary for a database that supports transactions. |
|
364 |
|
365 (For people unfamiliar with database terminology: a set of changes to the |
|
366 database are grouped into a transaction. Transactions can be either committed, |
|
367 meaning that all the changes are written into the database, or rolled back, |
|
368 meaning that the changes are all discarded and the database is unchanged. See |
|
369 any database textbook for more information.) |
|
370 |
|
371 Let's assume there's an object representing a database connection. Our goal will |
|
372 be to let the user write code like this:: |
|
373 |
|
374 db_connection = DatabaseConnection() |
|
375 with db_connection as cursor: |
|
376 cursor.execute('insert into ...') |
|
377 cursor.execute('delete from ...') |
|
378 # ... more operations ... |
|
379 |
|
380 The transaction should be committed if the code in the block runs flawlessly or |
|
381 rolled back if there's an exception. Here's the basic interface for |
|
382 :class:`DatabaseConnection` that I'll assume:: |
|
383 |
|
384 class DatabaseConnection: |
|
385 # Database interface |
|
386 def cursor(self): |
|
387 "Returns a cursor object and starts a new transaction" |
|
388 def commit(self): |
|
389 "Commits current transaction" |
|
390 def rollback(self): |
|
391 "Rolls back current transaction" |
|
392 |
|
393 The :meth:`__enter__` method is pretty easy, having only to start a new |
|
394 transaction. For this application the resulting cursor object would be a useful |
|
395 result, so the method will return it. The user can then add ``as cursor`` to |
|
396 their ':keyword:`with`' statement to bind the cursor to a variable name. :: |
|
397 |
|
398 class DatabaseConnection: |
|
399 ... |
|
400 def __enter__(self): |
|
401 # Code to start a new transaction |
|
402 cursor = self.cursor() |
|
403 return cursor |
|
404 |
|
405 The :meth:`__exit__` method is the most complicated because it's where most of |
|
406 the work has to be done. The method has to check if an exception occurred. If |
|
407 there was no exception, the transaction is committed. The transaction is rolled |
|
408 back if there was an exception. |
|
409 |
|
410 In the code below, execution will just fall off the end of the function, |
|
411 returning the default value of ``None``. ``None`` is false, so the exception |
|
412 will be re-raised automatically. If you wished, you could be more explicit and |
|
413 add a :keyword:`return` statement at the marked location. :: |
|
414 |
|
415 class DatabaseConnection: |
|
416 ... |
|
417 def __exit__(self, type, value, tb): |
|
418 if tb is None: |
|
419 # No exception, so commit |
|
420 self.commit() |
|
421 else: |
|
422 # Exception occurred, so rollback. |
|
423 self.rollback() |
|
424 # return False |
|
425 |
|
426 |
|
427 .. _module-contextlib: |
|
428 |
|
429 The contextlib module |
|
430 --------------------- |
|
431 |
|
432 The :mod:`contextlib` module provides some functions and a decorator that |
|
433 are useful when writing objects for use with the ':keyword:`with`' statement. |
|
434 |
|
435 The decorator is called :func:`contextmanager`, and lets you write a single |
|
436 generator function instead of defining a new class. The generator should yield |
|
437 exactly one value. The code up to the :keyword:`yield` will be executed as the |
|
438 :meth:`__enter__` method, and the value yielded will be the method's return |
|
439 value that will get bound to the variable in the ':keyword:`with`' statement's |
|
440 :keyword:`as` clause, if any. The code after the :keyword:`yield` will be |
|
441 executed in the :meth:`__exit__` method. Any exception raised in the block will |
|
442 be raised by the :keyword:`yield` statement. |
|
443 |
|
444 Using this decorator, our database example from the previous section |
|
445 could be written as:: |
|
446 |
|
447 from contextlib import contextmanager |
|
448 |
|
449 @contextmanager |
|
450 def db_transaction(connection): |
|
451 cursor = connection.cursor() |
|
452 try: |
|
453 yield cursor |
|
454 except: |
|
455 connection.rollback() |
|
456 raise |
|
457 else: |
|
458 connection.commit() |
|
459 |
|
460 db = DatabaseConnection() |
|
461 with db_transaction(db) as cursor: |
|
462 ... |
|
463 |
|
464 The :mod:`contextlib` module also has a :func:`nested(mgr1, mgr2, ...)` function |
|
465 that combines a number of context managers so you don't need to write nested |
|
466 ':keyword:`with`' statements. In this example, the single ':keyword:`with`' |
|
467 statement both starts a database transaction and acquires a thread lock:: |
|
468 |
|
469 lock = threading.Lock() |
|
470 with nested (db_transaction(db), lock) as (cursor, locked): |
|
471 ... |
|
472 |
|
473 Finally, the :func:`closing(object)` function returns *object* so that it can be |
|
474 bound to a variable, and calls ``object.close`` at the end of the block. :: |
|
475 |
|
476 import urllib, sys |
|
477 from contextlib import closing |
|
478 |
|
479 with closing(urllib.urlopen('http://www.yahoo.com')) as f: |
|
480 for line in f: |
|
481 sys.stdout.write(line) |
|
482 |
|
483 |
|
484 .. seealso:: |
|
485 |
|
486 :pep:`343` - The "with" statement |
|
487 PEP written by Guido van Rossum and Nick Coghlan; implemented by Mike Bland, |
|
488 Guido van Rossum, and Neal Norwitz. The PEP shows the code generated for a |
|
489 ':keyword:`with`' statement, which can be helpful in learning how the statement |
|
490 works. |
|
491 |
|
492 The documentation for the :mod:`contextlib` module. |
|
493 |
|
494 .. ====================================================================== |
|
495 |
|
496 .. _pep-0366: |
|
497 |
|
498 PEP 366: Explicit Relative Imports From a Main Module |
|
499 ============================================================ |
|
500 |
|
501 Python's :option:`-m` switch allows running a module as a script. |
|
502 When you ran a module that was located inside a package, relative |
|
503 imports didn't work correctly. |
|
504 |
|
505 The fix for Python 2.6 adds a :attr:`__package__` attribute to |
|
506 modules. When this attribute is present, relative imports will be |
|
507 relative to the value of this attribute instead of the |
|
508 :attr:`__name__` attribute. |
|
509 |
|
510 PEP 302-style importers can then set :attr:`__package__` as necessary. |
|
511 The :mod:`runpy` module that implements the :option:`-m` switch now |
|
512 does this, so relative imports will now work correctly in scripts |
|
513 running from inside a package. |
|
514 |
|
515 .. ====================================================================== |
|
516 |
|
517 .. _pep-0370: |
|
518 |
|
519 PEP 370: Per-user ``site-packages`` Directory |
|
520 ===================================================== |
|
521 |
|
522 When you run Python, the module search path ``sys.path`` usually |
|
523 includes a directory whose path ends in ``"site-packages"``. This |
|
524 directory is intended to hold locally-installed packages available to |
|
525 all users using a machine or a particular site installation. |
|
526 |
|
527 Python 2.6 introduces a convention for user-specific site directories. |
|
528 The directory varies depending on the platform: |
|
529 |
|
530 * Unix and Mac OS X: :file:`~/.local/` |
|
531 * Windows: :file:`%APPDATA%/Python` |
|
532 |
|
533 Within this directory, there will be version-specific subdirectories, |
|
534 such as :file:`lib/python2.6/site-packages` on Unix/Mac OS and |
|
535 :file:`Python26/site-packages` on Windows. |
|
536 |
|
537 If you don't like the default directory, it can be overridden by an |
|
538 environment variable. :envvar:`PYTHONUSERBASE` sets the root |
|
539 directory used for all Python versions supporting this feature. On |
|
540 Windows, the directory for application-specific data can be changed by |
|
541 setting the :envvar:`APPDATA` environment variable. You can also |
|
542 modify the :file:`site.py` file for your Python installation. |
|
543 |
|
544 The feature can be disabled entirely by running Python with the |
|
545 :option:`-s` option or setting the :envvar:`PYTHONNOUSERSITE` |
|
546 environment variable. |
|
547 |
|
548 .. seealso:: |
|
549 |
|
550 :pep:`370` - Per-user ``site-packages`` Directory |
|
551 PEP written and implemented by Christian Heimes. |
|
552 |
|
553 |
|
554 .. ====================================================================== |
|
555 |
|
556 .. _pep-0371: |
|
557 |
|
558 PEP 371: The ``multiprocessing`` Package |
|
559 ===================================================== |
|
560 |
|
561 The new :mod:`multiprocessing` package lets Python programs create new |
|
562 processes that will perform a computation and return a result to the |
|
563 parent. The parent and child processes can communicate using queues |
|
564 and pipes, synchronize their operations using locks and semaphores, |
|
565 and can share simple arrays of data. |
|
566 |
|
567 The :mod:`multiprocessing` module started out as an exact emulation of |
|
568 the :mod:`threading` module using processes instead of threads. That |
|
569 goal was discarded along the path to Python 2.6, but the general |
|
570 approach of the module is still similar. The fundamental class |
|
571 is the :class:`Process`, which is passed a callable object and |
|
572 a collection of arguments. The :meth:`start` method |
|
573 sets the callable running in a subprocess, after which you can call |
|
574 the :meth:`is_alive` method to check whether the subprocess is still running |
|
575 and the :meth:`join` method to wait for the process to exit. |
|
576 |
|
577 Here's a simple example where the subprocess will calculate a |
|
578 factorial. The function doing the calculation is written strangely so |
|
579 that it takes significantly longer when the input argument is a |
|
580 multiple of 4. |
|
581 |
|
582 :: |
|
583 |
|
584 import time |
|
585 from multiprocessing import Process, Queue |
|
586 |
|
587 |
|
588 def factorial(queue, N): |
|
589 "Compute a factorial." |
|
590 # If N is a multiple of 4, this function will take much longer. |
|
591 if (N % 4) == 0: |
|
592 time.sleep(.05 * N/4) |
|
593 |
|
594 # Calculate the result |
|
595 fact = 1L |
|
596 for i in range(1, N+1): |
|
597 fact = fact * i |
|
598 |
|
599 # Put the result on the queue |
|
600 queue.put(fact) |
|
601 |
|
602 if __name__ == '__main__': |
|
603 queue = Queue() |
|
604 |
|
605 N = 5 |
|
606 |
|
607 p = Process(target=factorial, args=(queue, N)) |
|
608 p.start() |
|
609 p.join() |
|
610 |
|
611 result = queue.get() |
|
612 print 'Factorial', N, '=', result |
|
613 |
|
614 A :class:`Queue` is used to communicate the input parameter *N* and |
|
615 the result. The :class:`Queue` object is stored in a global variable. |
|
616 The child process will use the value of the variable when the child |
|
617 was created; because it's a :class:`Queue`, parent and child can use |
|
618 the object to communicate. (If the parent were to change the value of |
|
619 the global variable, the child's value would be unaffected, and vice |
|
620 versa.) |
|
621 |
|
622 Two other classes, :class:`Pool` and :class:`Manager`, provide |
|
623 higher-level interfaces. :class:`Pool` will create a fixed number of |
|
624 worker processes, and requests can then be distributed to the workers |
|
625 by calling :meth:`apply` or :meth:`apply_async` to add a single request, |
|
626 and :meth:`map` or :meth:`map_async` to add a number of |
|
627 requests. The following code uses a :class:`Pool` to spread requests |
|
628 across 5 worker processes and retrieve a list of results:: |
|
629 |
|
630 from multiprocessing import Pool |
|
631 |
|
632 def factorial(N, dictionary): |
|
633 "Compute a factorial." |
|
634 ... |
|
635 p = Pool(5) |
|
636 result = p.map(factorial, range(1, 1000, 10)) |
|
637 for v in result: |
|
638 print v |
|
639 |
|
640 This produces the following output:: |
|
641 |
|
642 1 |
|
643 39916800 |
|
644 51090942171709440000 |
|
645 8222838654177922817725562880000000 |
|
646 33452526613163807108170062053440751665152000000000 |
|
647 ... |
|
648 |
|
649 The other high-level interface, the :class:`Manager` class, creates a |
|
650 separate server process that can hold master copies of Python data |
|
651 structures. Other processes can then access and modify these data |
|
652 structures using proxy objects. The following example creates a |
|
653 shared dictionary by calling the :meth:`dict` method; the worker |
|
654 processes then insert values into the dictionary. (Locking is not |
|
655 done for you automatically, which doesn't matter in this example. |
|
656 :class:`Manager`'s methods also include :meth:`Lock`, :meth:`RLock`, |
|
657 and :meth:`Semaphore` to create shared locks.) |
|
658 |
|
659 :: |
|
660 |
|
661 import time |
|
662 from multiprocessing import Pool, Manager |
|
663 |
|
664 def factorial(N, dictionary): |
|
665 "Compute a factorial." |
|
666 # Calculate the result |
|
667 fact = 1L |
|
668 for i in range(1, N+1): |
|
669 fact = fact * i |
|
670 |
|
671 # Store result in dictionary |
|
672 dictionary[N] = fact |
|
673 |
|
674 if __name__ == '__main__': |
|
675 p = Pool(5) |
|
676 mgr = Manager() |
|
677 d = mgr.dict() # Create shared dictionary |
|
678 |
|
679 # Run tasks using the pool |
|
680 for N in range(1, 1000, 10): |
|
681 p.apply_async(factorial, (N, d)) |
|
682 |
|
683 # Mark pool as closed -- no more tasks can be added. |
|
684 p.close() |
|
685 |
|
686 # Wait for tasks to exit |
|
687 p.join() |
|
688 |
|
689 # Output results |
|
690 for k, v in sorted(d.items()): |
|
691 print k, v |
|
692 |
|
693 This will produce the output:: |
|
694 |
|
695 1 1 |
|
696 11 39916800 |
|
697 21 51090942171709440000 |
|
698 31 8222838654177922817725562880000000 |
|
699 41 33452526613163807108170062053440751665152000000000 |
|
700 51 15511187532873822802242430164693032110632597200169861120000... |
|
701 |
|
702 .. seealso:: |
|
703 |
|
704 The documentation for the :mod:`multiprocessing` module. |
|
705 |
|
706 :pep:`371` - Addition of the multiprocessing package |
|
707 PEP written by Jesse Noller and Richard Oudkerk; |
|
708 implemented by Richard Oudkerk and Jesse Noller. |
|
709 |
|
710 |
|
711 .. ====================================================================== |
|
712 |
|
713 .. _pep-3101: |
|
714 |
|
715 PEP 3101: Advanced String Formatting |
|
716 ===================================================== |
|
717 |
|
718 In Python 3.0, the `%` operator is supplemented by a more powerful string |
|
719 formatting method, :meth:`format`. Support for the :meth:`str.format` method |
|
720 has been backported to Python 2.6. |
|
721 |
|
722 In 2.6, both 8-bit and Unicode strings have a `.format()` method that |
|
723 treats the string as a template and takes the arguments to be formatted. |
|
724 The formatting template uses curly brackets (`{`, `}`) as special characters:: |
|
725 |
|
726 >>> # Substitute positional argument 0 into the string. |
|
727 >>> "User ID: {0}".format("root") |
|
728 'User ID: root' |
|
729 >>> # Use the named keyword arguments |
|
730 >>> "User ID: {uid} Last seen: {last_login}".format( |
|
731 ... uid="root", |
|
732 ... last_login = "5 Mar 2008 07:20") |
|
733 'User ID: root Last seen: 5 Mar 2008 07:20' |
|
734 |
|
735 Curly brackets can be escaped by doubling them:: |
|
736 |
|
737 >>> format("Empty dict: {{}}") |
|
738 "Empty dict: {}" |
|
739 |
|
740 Field names can be integers indicating positional arguments, such as |
|
741 ``{0}``, ``{1}``, etc. or names of keyword arguments. You can also |
|
742 supply compound field names that read attributes or access dictionary keys:: |
|
743 |
|
744 >>> import sys |
|
745 >>> print 'Platform: {0.platform}\nPython version: {0.version}'.format(sys) |
|
746 Platform: darwin |
|
747 Python version: 2.6a1+ (trunk:61261M, Mar 5 2008, 20:29:41) |
|
748 [GCC 4.0.1 (Apple Computer, Inc. build 5367)]' |
|
749 |
|
750 >>> import mimetypes |
|
751 >>> 'Content-type: {0[.mp4]}'.format(mimetypes.types_map) |
|
752 'Content-type: video/mp4' |
|
753 |
|
754 Note that when using dictionary-style notation such as ``[.mp4]``, you |
|
755 don't need to put any quotation marks around the string; it will look |
|
756 up the value using ``.mp4`` as the key. Strings beginning with a |
|
757 number will be converted to an integer. You can't write more |
|
758 complicated expressions inside a format string. |
|
759 |
|
760 So far we've shown how to specify which field to substitute into the |
|
761 resulting string. The precise formatting used is also controllable by |
|
762 adding a colon followed by a format specifier. For example:: |
|
763 |
|
764 >>> # Field 0: left justify, pad to 15 characters |
|
765 >>> # Field 1: right justify, pad to 6 characters |
|
766 >>> fmt = '{0:15} ${1:>6}' |
|
767 >>> fmt.format('Registration', 35) |
|
768 'Registration $ 35' |
|
769 >>> fmt.format('Tutorial', 50) |
|
770 'Tutorial $ 50' |
|
771 >>> fmt.format('Banquet', 125) |
|
772 'Banquet $ 125' |
|
773 |
|
774 Format specifiers can reference other fields through nesting:: |
|
775 |
|
776 >>> fmt = '{0:{1}}' |
|
777 >>> width = 15 |
|
778 >>> fmt.format('Invoice #1234', width) |
|
779 'Invoice #1234 ' |
|
780 >>> width = 35 |
|
781 >>> fmt.format('Invoice #1234', width) |
|
782 'Invoice #1234 ' |
|
783 |
|
784 The alignment of a field within the desired width can be specified: |
|
785 |
|
786 ================ ============================================ |
|
787 Character Effect |
|
788 ================ ============================================ |
|
789 < (default) Left-align |
|
790 > Right-align |
|
791 ^ Center |
|
792 = (For numeric types only) Pad after the sign. |
|
793 ================ ============================================ |
|
794 |
|
795 Format specifiers can also include a presentation type, which |
|
796 controls how the value is formatted. For example, floating-point numbers |
|
797 can be formatted as a general number or in exponential notation:: |
|
798 |
|
799 >>> '{0:g}'.format(3.75) |
|
800 '3.75' |
|
801 >>> '{0:e}'.format(3.75) |
|
802 '3.750000e+00' |
|
803 |
|
804 A variety of presentation types are available. Consult the 2.6 |
|
805 documentation for a :ref:`complete list <formatstrings>`; here's a sample: |
|
806 |
|
807 ===== ======================================================================== |
|
808 ``b`` Binary. Outputs the number in base 2. |
|
809 ``c`` Character. Converts the integer to the corresponding Unicode character |
|
810 before printing. |
|
811 ``d`` Decimal Integer. Outputs the number in base 10. |
|
812 ``o`` Octal format. Outputs the number in base 8. |
|
813 ``x`` Hex format. Outputs the number in base 16, using lower-case letters for |
|
814 the digits above 9. |
|
815 ``e`` Exponent notation. Prints the number in scientific notation using the |
|
816 letter 'e' to indicate the exponent. |
|
817 ``g`` General format. This prints the number as a fixed-point number, unless |
|
818 the number is too large, in which case it switches to 'e' exponent |
|
819 notation. |
|
820 ``n`` Number. This is the same as 'g' (for floats) or 'd' (for integers), |
|
821 except that it uses the current locale setting to insert the appropriate |
|
822 number separator characters. |
|
823 ``%`` Percentage. Multiplies the number by 100 and displays in fixed ('f') |
|
824 format, followed by a percent sign. |
|
825 ===== ======================================================================== |
|
826 |
|
827 Classes and types can define a :meth:`__format__` method to control how they're |
|
828 formatted. It receives a single argument, the format specifier:: |
|
829 |
|
830 def __format__(self, format_spec): |
|
831 if isinstance(format_spec, unicode): |
|
832 return unicode(str(self)) |
|
833 else: |
|
834 return str(self) |
|
835 |
|
836 There's also a :func:`format` built-in that will format a single |
|
837 value. It calls the type's :meth:`__format__` method with the |
|
838 provided specifier:: |
|
839 |
|
840 >>> format(75.6564, '.2f') |
|
841 '75.66' |
|
842 |
|
843 |
|
844 .. seealso:: |
|
845 |
|
846 :ref:`formatstrings` |
|
847 The reference documentation for format fields. |
|
848 |
|
849 :pep:`3101` - Advanced String Formatting |
|
850 PEP written by Talin. Implemented by Eric Smith. |
|
851 |
|
852 .. ====================================================================== |
|
853 |
|
854 .. _pep-3105: |
|
855 |
|
856 PEP 3105: ``print`` As a Function |
|
857 ===================================================== |
|
858 |
|
859 The ``print`` statement becomes the :func:`print` function in Python 3.0. |
|
860 Making :func:`print` a function makes it possible to replace the function |
|
861 by doing ``def print(...)`` or importing a new function from somewhere else. |
|
862 |
|
863 Python 2.6 has a ``__future__`` import that removes ``print`` as language |
|
864 syntax, letting you use the functional form instead. For example:: |
|
865 |
|
866 >>> from __future__ import print_function |
|
867 >>> print('# of entries', len(dictionary), file=sys.stderr) |
|
868 |
|
869 The signature of the new function is:: |
|
870 |
|
871 def print(*args, sep=' ', end='\n', file=None) |
|
872 |
|
873 |
|
874 The parameters are: |
|
875 |
|
876 * *args*: positional arguments whose values will be printed out. |
|
877 * *sep*: the separator, which will be printed between arguments. |
|
878 * *end*: the ending text, which will be printed after all of the |
|
879 arguments have been output. |
|
880 * *file*: the file object to which the output will be sent. |
|
881 |
|
882 .. seealso:: |
|
883 |
|
884 :pep:`3105` - Make print a function |
|
885 PEP written by Georg Brandl. |
|
886 |
|
887 .. ====================================================================== |
|
888 |
|
889 .. _pep-3110: |
|
890 |
|
891 PEP 3110: Exception-Handling Changes |
|
892 ===================================================== |
|
893 |
|
894 One error that Python programmers occasionally make |
|
895 is writing the following code:: |
|
896 |
|
897 try: |
|
898 ... |
|
899 except TypeError, ValueError: # Wrong! |
|
900 ... |
|
901 |
|
902 The author is probably trying to catch both :exc:`TypeError` and |
|
903 :exc:`ValueError` exceptions, but this code actually does something |
|
904 different: it will catch :exc:`TypeError` and bind the resulting |
|
905 exception object to the local name ``"ValueError"``. The |
|
906 :exc:`ValueError` exception will not be caught at all. The correct |
|
907 code specifies a tuple of exceptions:: |
|
908 |
|
909 try: |
|
910 ... |
|
911 except (TypeError, ValueError): |
|
912 ... |
|
913 |
|
914 This error happens because the use of the comma here is ambiguous: |
|
915 does it indicate two different nodes in the parse tree, or a single |
|
916 node that's a tuple? |
|
917 |
|
918 Python 3.0 makes this unambiguous by replacing the comma with the word |
|
919 "as". To catch an exception and store the exception object in the |
|
920 variable ``exc``, you must write:: |
|
921 |
|
922 try: |
|
923 ... |
|
924 except TypeError as exc: |
|
925 ... |
|
926 |
|
927 Python 3.0 will only support the use of "as", and therefore interprets |
|
928 the first example as catching two different exceptions. Python 2.6 |
|
929 supports both the comma and "as", so existing code will continue to |
|
930 work. We therefore suggest using "as" when writing new Python code |
|
931 that will only be executed with 2.6. |
|
932 |
|
933 .. seealso:: |
|
934 |
|
935 :pep:`3110` - Catching Exceptions in Python 3000 |
|
936 PEP written and implemented by Collin Winter. |
|
937 |
|
938 .. ====================================================================== |
|
939 |
|
940 .. _pep-3112: |
|
941 |
|
942 PEP 3112: Byte Literals |
|
943 ===================================================== |
|
944 |
|
945 Python 3.0 adopts Unicode as the language's fundamental string type and |
|
946 denotes 8-bit literals differently, either as ``b'string'`` |
|
947 or using a :class:`bytes` constructor. For future compatibility, |
|
948 Python 2.6 adds :class:`bytes` as a synonym for the :class:`str` type, |
|
949 and it also supports the ``b''`` notation. |
|
950 |
|
951 |
|
952 The 2.6 :class:`str` differs from 3.0's :class:`bytes` type in various |
|
953 ways; most notably, the constructor is completely different. In 3.0, |
|
954 ``bytes([65, 66, 67])`` is 3 elements long, containing the bytes |
|
955 representing ``ABC``; in 2.6, ``bytes([65, 66, 67])`` returns the |
|
956 12-byte string representing the :func:`str` of the list. |
|
957 |
|
958 The primary use of :class:`bytes` in 2.6 will be to write tests of |
|
959 object type such as ``isinstance(x, bytes)``. This will help the 2to3 |
|
960 converter, which can't tell whether 2.x code intends strings to |
|
961 contain either characters or 8-bit bytes; you can now |
|
962 use either :class:`bytes` or :class:`str` to represent your intention |
|
963 exactly, and the resulting code will also be correct in Python 3.0. |
|
964 |
|
965 There's also a ``__future__`` import that causes all string literals |
|
966 to become Unicode strings. This means that ``\u`` escape sequences |
|
967 can be used to include Unicode characters:: |
|
968 |
|
969 |
|
970 from __future__ import unicode_literals |
|
971 |
|
972 s = ('\u751f\u3080\u304e\u3000\u751f\u3054' |
|
973 '\u3081\u3000\u751f\u305f\u307e\u3054') |
|
974 |
|
975 print len(s) # 12 Unicode characters |
|
976 |
|
977 At the C level, Python 3.0 will rename the existing 8-bit |
|
978 string type, called :ctype:`PyStringObject` in Python 2.x, |
|
979 to :ctype:`PyBytesObject`. Python 2.6 uses ``#define`` |
|
980 to support using the names :cfunc:`PyBytesObject`, |
|
981 :cfunc:`PyBytes_Check`, :cfunc:`PyBytes_FromStringAndSize`, |
|
982 and all the other functions and macros used with strings. |
|
983 |
|
984 Instances of the :class:`bytes` type are immutable just |
|
985 as strings are. A new :class:`bytearray` type stores a mutable |
|
986 sequence of bytes:: |
|
987 |
|
988 >>> bytearray([65, 66, 67]) |
|
989 bytearray(b'ABC') |
|
990 >>> b = bytearray(u'\u21ef\u3244', 'utf-8') |
|
991 >>> b |
|
992 bytearray(b'\xe2\x87\xaf\xe3\x89\x84') |
|
993 >>> b[0] = '\xe3' |
|
994 >>> b |
|
995 bytearray(b'\xe3\x87\xaf\xe3\x89\x84') |
|
996 >>> unicode(str(b), 'utf-8') |
|
997 u'\u31ef \u3244' |
|
998 |
|
999 Byte arrays support most of the methods of string types, such as |
|
1000 :meth:`startswith`/:meth:`endswith`, :meth:`find`/:meth:`rfind`, |
|
1001 and some of the methods of lists, such as :meth:`append`, |
|
1002 :meth:`pop`, and :meth:`reverse`. |
|
1003 |
|
1004 :: |
|
1005 |
|
1006 >>> b = bytearray('ABC') |
|
1007 >>> b.append('d') |
|
1008 >>> b.append(ord('e')) |
|
1009 >>> b |
|
1010 bytearray(b'ABCde') |
|
1011 |
|
1012 There's also a corresponding C API, with |
|
1013 :cfunc:`PyByteArray_FromObject`, |
|
1014 :cfunc:`PyByteArray_FromStringAndSize`, |
|
1015 and various other functions. |
|
1016 |
|
1017 .. seealso:: |
|
1018 |
|
1019 :pep:`3112` - Bytes literals in Python 3000 |
|
1020 PEP written by Jason Orendorff; backported to 2.6 by Christian Heimes. |
|
1021 |
|
1022 .. ====================================================================== |
|
1023 |
|
1024 .. _pep-3116: |
|
1025 |
|
1026 PEP 3116: New I/O Library |
|
1027 ===================================================== |
|
1028 |
|
1029 Python's built-in file objects support a number of methods, but |
|
1030 file-like objects don't necessarily support all of them. Objects that |
|
1031 imitate files usually support :meth:`read` and :meth:`write`, but they |
|
1032 may not support :meth:`readline`, for example. Python 3.0 introduces |
|
1033 a layered I/O library in the :mod:`io` module that separates buffering |
|
1034 and text-handling features from the fundamental read and write |
|
1035 operations. |
|
1036 |
|
1037 There are three levels of abstract base classes provided by |
|
1038 the :mod:`io` module: |
|
1039 |
|
1040 * :class:`RawIOBase` defines raw I/O operations: :meth:`read`, |
|
1041 :meth:`readinto`, |
|
1042 :meth:`write`, :meth:`seek`, :meth:`tell`, :meth:`truncate`, |
|
1043 and :meth:`close`. |
|
1044 Most of the methods of this class will often map to a single system call. |
|
1045 There are also :meth:`readable`, :meth:`writable`, and :meth:`seekable` |
|
1046 methods for determining what operations a given object will allow. |
|
1047 |
|
1048 Python 3.0 has concrete implementations of this class for files and |
|
1049 sockets, but Python 2.6 hasn't restructured its file and socket objects |
|
1050 in this way. |
|
1051 |
|
1052 .. XXX should 2.6 register them in io.py? |
|
1053 |
|
1054 * :class:`BufferedIOBase` is an abstract base class that |
|
1055 buffers data in memory to reduce the number of |
|
1056 system calls used, making I/O processing more efficient. |
|
1057 It supports all of the methods of :class:`RawIOBase`, |
|
1058 and adds a :attr:`raw` attribute holding the underlying raw object. |
|
1059 |
|
1060 There are five concrete classes implementing this ABC. |
|
1061 :class:`BufferedWriter` and :class:`BufferedReader` are for objects |
|
1062 that support write-only or read-only usage that have a :meth:`seek` |
|
1063 method for random access. :class:`BufferedRandom` objects support |
|
1064 read and write access upon the same underlying stream, and |
|
1065 :class:`BufferedRWPair` is for objects such as TTYs that have both |
|
1066 read and write operations acting upon unconnected streams of data. |
|
1067 The :class:`BytesIO` class supports reading, writing, and seeking |
|
1068 over an in-memory buffer. |
|
1069 |
|
1070 * :class:`TextIOBase`: Provides functions for reading and writing |
|
1071 strings (remember, strings will be Unicode in Python 3.0), |
|
1072 and supporting universal newlines. :class:`TextIOBase` defines |
|
1073 the :meth:`readline` method and supports iteration upon |
|
1074 objects. |
|
1075 |
|
1076 There are two concrete implementations. :class:`TextIOWrapper` |
|
1077 wraps a buffered I/O object, supporting all of the methods for |
|
1078 text I/O and adding a :attr:`buffer` attribute for access |
|
1079 to the underlying object. :class:`StringIO` simply buffers |
|
1080 everything in memory without ever writing anything to disk. |
|
1081 |
|
1082 (In Python 2.6, :class:`io.StringIO` is implemented in |
|
1083 pure Python, so it's pretty slow. You should therefore stick with the |
|
1084 existing :mod:`StringIO` module or :mod:`cStringIO` for now. At some |
|
1085 point Python 3.0's :mod:`io` module will be rewritten into C for speed, |
|
1086 and perhaps the C implementation will be backported to the 2.x releases.) |
|
1087 |
|
1088 In Python 2.6, the underlying implementations haven't been |
|
1089 restructured to build on top of the :mod:`io` module's classes. The |
|
1090 module is being provided to make it easier to write code that's |
|
1091 forward-compatible with 3.0, and to save developers the effort of writing |
|
1092 their own implementations of buffering and text I/O. |
|
1093 |
|
1094 .. seealso:: |
|
1095 |
|
1096 :pep:`3116` - New I/O |
|
1097 PEP written by Daniel Stutzbach, Mike Verdone, and Guido van Rossum. |
|
1098 Code by Guido van Rossum, Georg Brandl, Walter Doerwald, |
|
1099 Jeremy Hylton, Martin von Loewis, Tony Lownds, and others. |
|
1100 |
|
1101 .. ====================================================================== |
|
1102 |
|
1103 .. _pep-3118: |
|
1104 |
|
1105 PEP 3118: Revised Buffer Protocol |
|
1106 ===================================================== |
|
1107 |
|
1108 The buffer protocol is a C-level API that lets Python types |
|
1109 exchange pointers into their internal representations. A |
|
1110 memory-mapped file can be viewed as a buffer of characters, for |
|
1111 example, and this lets another module such as :mod:`re` |
|
1112 treat memory-mapped files as a string of characters to be searched. |
|
1113 |
|
1114 The primary users of the buffer protocol are numeric-processing |
|
1115 packages such as NumPy, which expose the internal representation |
|
1116 of arrays so that callers can write data directly into an array instead |
|
1117 of going through a slower API. This PEP updates the buffer protocol in light of experience |
|
1118 from NumPy development, adding a number of new features |
|
1119 such as indicating the shape of an array or locking a memory region. |
|
1120 |
|
1121 The most important new C API function is |
|
1122 ``PyObject_GetBuffer(PyObject *obj, Py_buffer *view, int flags)``, which |
|
1123 takes an object and a set of flags, and fills in the |
|
1124 ``Py_buffer`` structure with information |
|
1125 about the object's memory representation. Objects |
|
1126 can use this operation to lock memory in place |
|
1127 while an external caller could be modifying the contents, |
|
1128 so there's a corresponding ``PyBuffer_Release(Py_buffer *view)`` to |
|
1129 indicate that the external caller is done. |
|
1130 |
|
1131 .. XXX PyObject_GetBuffer not documented in c-api |
|
1132 |
|
1133 The *flags* argument to :cfunc:`PyObject_GetBuffer` specifies |
|
1134 constraints upon the memory returned. Some examples are: |
|
1135 |
|
1136 * :const:`PyBUF_WRITABLE` indicates that the memory must be writable. |
|
1137 |
|
1138 * :const:`PyBUF_LOCK` requests a read-only or exclusive lock on the memory. |
|
1139 |
|
1140 * :const:`PyBUF_C_CONTIGUOUS` and :const:`PyBUF_F_CONTIGUOUS` |
|
1141 requests a C-contiguous (last dimension varies the fastest) or |
|
1142 Fortran-contiguous (first dimension varies the fastest) array layout. |
|
1143 |
|
1144 Two new argument codes for :cfunc:`PyArg_ParseTuple`, |
|
1145 ``s*`` and ``z*``, return locked buffer objects for a parameter. |
|
1146 |
|
1147 .. seealso:: |
|
1148 |
|
1149 :pep:`3118` - Revising the buffer protocol |
|
1150 PEP written by Travis Oliphant and Carl Banks; implemented by |
|
1151 Travis Oliphant. |
|
1152 |
|
1153 |
|
1154 .. ====================================================================== |
|
1155 |
|
1156 .. _pep-3119: |
|
1157 |
|
1158 PEP 3119: Abstract Base Classes |
|
1159 ===================================================== |
|
1160 |
|
1161 Some object-oriented languages such as Java support interfaces, |
|
1162 declaring that a class has a given set of methods or supports a given |
|
1163 access protocol. Abstract Base Classes (or ABCs) are an equivalent |
|
1164 feature for Python. The ABC support consists of an :mod:`abc` module |
|
1165 containing a metaclass called :class:`ABCMeta`, special handling of |
|
1166 this metaclass by the :func:`isinstance` and :func:`issubclass` |
|
1167 built-ins, and a collection of basic ABCs that the Python developers |
|
1168 think will be widely useful. Future versions of Python will probably |
|
1169 add more ABCs. |
|
1170 |
|
1171 Let's say you have a particular class and wish to know whether it supports |
|
1172 dictionary-style access. The phrase "dictionary-style" is vague, however. |
|
1173 It probably means that accessing items with ``obj[1]`` works. |
|
1174 Does it imply that setting items with ``obj[2] = value`` works? |
|
1175 Or that the object will have :meth:`keys`, :meth:`values`, and :meth:`items` |
|
1176 methods? What about the iterative variants such as :meth:`iterkeys`? :meth:`copy` |
|
1177 and :meth:`update`? Iterating over the object with :func:`iter`? |
|
1178 |
|
1179 The Python 2.6 :mod:`collections` module includes a number of |
|
1180 different ABCs that represent these distinctions. :class:`Iterable` |
|
1181 indicates that a class defines :meth:`__iter__`, and |
|
1182 :class:`Container` means the class defines a :meth:`__contains__` |
|
1183 method and therefore supports ``x in y`` expressions. The basic |
|
1184 dictionary interface of getting items, setting items, and |
|
1185 :meth:`keys`, :meth:`values`, and :meth:`items`, is defined by the |
|
1186 :class:`MutableMapping` ABC. |
|
1187 |
|
1188 You can derive your own classes from a particular ABC |
|
1189 to indicate they support that ABC's interface:: |
|
1190 |
|
1191 import collections |
|
1192 |
|
1193 class Storage(collections.MutableMapping): |
|
1194 ... |
|
1195 |
|
1196 |
|
1197 Alternatively, you could write the class without deriving from |
|
1198 the desired ABC and instead register the class by |
|
1199 calling the ABC's :meth:`register` method:: |
|
1200 |
|
1201 import collections |
|
1202 |
|
1203 class Storage: |
|
1204 ... |
|
1205 |
|
1206 collections.MutableMapping.register(Storage) |
|
1207 |
|
1208 For classes that you write, deriving from the ABC is probably clearer. |
|
1209 The :meth:`register` method is useful when you've written a new |
|
1210 ABC that can describe an existing type or class, or if you want |
|
1211 to declare that some third-party class implements an ABC. |
|
1212 For example, if you defined a :class:`PrintableType` ABC, |
|
1213 it's legal to do:: |
|
1214 |
|
1215 # Register Python's types |
|
1216 PrintableType.register(int) |
|
1217 PrintableType.register(float) |
|
1218 PrintableType.register(str) |
|
1219 |
|
1220 Classes should obey the semantics specified by an ABC, but |
|
1221 Python can't check this; it's up to the class author to |
|
1222 understand the ABC's requirements and to implement the code accordingly. |
|
1223 |
|
1224 To check whether an object supports a particular interface, you can |
|
1225 now write:: |
|
1226 |
|
1227 def func(d): |
|
1228 if not isinstance(d, collections.MutableMapping): |
|
1229 raise ValueError("Mapping object expected, not %r" % d) |
|
1230 |
|
1231 Don't feel that you must now begin writing lots of checks as in the |
|
1232 above example. Python has a strong tradition of duck-typing, where |
|
1233 explicit type-checking is never done and code simply calls methods on |
|
1234 an object, trusting that those methods will be there and raising an |
|
1235 exception if they aren't. Be judicious in checking for ABCs and only |
|
1236 do it where it's absolutely necessary. |
|
1237 |
|
1238 You can write your own ABCs by using ``abc.ABCMeta`` as the |
|
1239 metaclass in a class definition:: |
|
1240 |
|
1241 from abc import ABCMeta, abstractmethod |
|
1242 |
|
1243 class Drawable(): |
|
1244 __metaclass__ = ABCMeta |
|
1245 |
|
1246 @abstractmethod |
|
1247 def draw(self, x, y, scale=1.0): |
|
1248 pass |
|
1249 |
|
1250 def draw_doubled(self, x, y): |
|
1251 self.draw(x, y, scale=2.0) |
|
1252 |
|
1253 |
|
1254 class Square(Drawable): |
|
1255 def draw(self, x, y, scale): |
|
1256 ... |
|
1257 |
|
1258 |
|
1259 In the :class:`Drawable` ABC above, the :meth:`draw_doubled` method |
|
1260 renders the object at twice its size and can be implemented in terms |
|
1261 of other methods described in :class:`Drawable`. Classes implementing |
|
1262 this ABC therefore don't need to provide their own implementation |
|
1263 of :meth:`draw_doubled`, though they can do so. An implementation |
|
1264 of :meth:`draw` is necessary, though; the ABC can't provide |
|
1265 a useful generic implementation. |
|
1266 |
|
1267 You can apply the ``@abstractmethod`` decorator to methods such as |
|
1268 :meth:`draw` that must be implemented; Python will then raise an |
|
1269 exception for classes that don't define the method. |
|
1270 Note that the exception is only raised when you actually |
|
1271 try to create an instance of a subclass lacking the method:: |
|
1272 |
|
1273 >>> class Circle(Drawable): |
|
1274 ... pass |
|
1275 ... |
|
1276 >>> c = Circle() |
|
1277 Traceback (most recent call last): |
|
1278 File "<stdin>", line 1, in <module> |
|
1279 TypeError: Can't instantiate abstract class Circle with abstract methods draw |
|
1280 >>> |
|
1281 |
|
1282 Abstract data attributes can be declared using the |
|
1283 ``@abstractproperty`` decorator:: |
|
1284 |
|
1285 from abc import abstractproperty |
|
1286 ... |
|
1287 |
|
1288 @abstractproperty |
|
1289 def readonly(self): |
|
1290 return self._x |
|
1291 |
|
1292 Subclasses must then define a :meth:`readonly` property. |
|
1293 |
|
1294 .. seealso:: |
|
1295 |
|
1296 :pep:`3119` - Introducing Abstract Base Classes |
|
1297 PEP written by Guido van Rossum and Talin. |
|
1298 Implemented by Guido van Rossum. |
|
1299 Backported to 2.6 by Benjamin Aranguren, with Alex Martelli. |
|
1300 |
|
1301 .. ====================================================================== |
|
1302 |
|
1303 .. _pep-3127: |
|
1304 |
|
1305 PEP 3127: Integer Literal Support and Syntax |
|
1306 ===================================================== |
|
1307 |
|
1308 Python 3.0 changes the syntax for octal (base-8) integer literals, |
|
1309 prefixing them with "0o" or "0O" instead of a leading zero, and adds |
|
1310 support for binary (base-2) integer literals, signalled by a "0b" or |
|
1311 "0B" prefix. |
|
1312 |
|
1313 Python 2.6 doesn't drop support for a leading 0 signalling |
|
1314 an octal number, but it does add support for "0o" and "0b":: |
|
1315 |
|
1316 >>> 0o21, 2*8 + 1 |
|
1317 (17, 17) |
|
1318 >>> 0b101111 |
|
1319 47 |
|
1320 |
|
1321 The :func:`oct` built-in still returns numbers |
|
1322 prefixed with a leading zero, and a new :func:`bin` |
|
1323 built-in returns the binary representation for a number:: |
|
1324 |
|
1325 >>> oct(42) |
|
1326 '052' |
|
1327 >>> future_builtins.oct(42) |
|
1328 '0o52' |
|
1329 >>> bin(173) |
|
1330 '0b10101101' |
|
1331 |
|
1332 The :func:`int` and :func:`long` built-ins will now accept the "0o" |
|
1333 and "0b" prefixes when base-8 or base-2 are requested, or when the |
|
1334 *base* argument is zero (signalling that the base used should be |
|
1335 determined from the string):: |
|
1336 |
|
1337 >>> int ('0o52', 0) |
|
1338 42 |
|
1339 >>> int('1101', 2) |
|
1340 13 |
|
1341 >>> int('0b1101', 2) |
|
1342 13 |
|
1343 >>> int('0b1101', 0) |
|
1344 13 |
|
1345 |
|
1346 |
|
1347 .. seealso:: |
|
1348 |
|
1349 :pep:`3127` - Integer Literal Support and Syntax |
|
1350 PEP written by Patrick Maupin; backported to 2.6 by |
|
1351 Eric Smith. |
|
1352 |
|
1353 .. ====================================================================== |
|
1354 |
|
1355 .. _pep-3129: |
|
1356 |
|
1357 PEP 3129: Class Decorators |
|
1358 ===================================================== |
|
1359 |
|
1360 Decorators have been extended from functions to classes. It's now legal to |
|
1361 write:: |
|
1362 |
|
1363 @foo |
|
1364 @bar |
|
1365 class A: |
|
1366 pass |
|
1367 |
|
1368 This is equivalent to:: |
|
1369 |
|
1370 class A: |
|
1371 pass |
|
1372 |
|
1373 A = foo(bar(A)) |
|
1374 |
|
1375 .. seealso:: |
|
1376 |
|
1377 :pep:`3129` - Class Decorators |
|
1378 PEP written by Collin Winter. |
|
1379 |
|
1380 .. ====================================================================== |
|
1381 |
|
1382 .. _pep-3141: |
|
1383 |
|
1384 PEP 3141: A Type Hierarchy for Numbers |
|
1385 ===================================================== |
|
1386 |
|
1387 Python 3.0 adds several abstract base classes for numeric types |
|
1388 inspired by Scheme's numeric tower. These classes were backported to |
|
1389 2.6 as the :mod:`numbers` module. |
|
1390 |
|
1391 The most general ABC is :class:`Number`. It defines no operations at |
|
1392 all, and only exists to allow checking if an object is a number by |
|
1393 doing ``isinstance(obj, Number)``. |
|
1394 |
|
1395 :class:`Complex` is a subclass of :class:`Number`. Complex numbers |
|
1396 can undergo the basic operations of addition, subtraction, |
|
1397 multiplication, division, and exponentiation, and you can retrieve the |
|
1398 real and imaginary parts and obtain a number's conjugate. Python's built-in |
|
1399 complex type is an implementation of :class:`Complex`. |
|
1400 |
|
1401 :class:`Real` further derives from :class:`Complex`, and adds |
|
1402 operations that only work on real numbers: :func:`floor`, :func:`trunc`, |
|
1403 rounding, taking the remainder mod N, floor division, |
|
1404 and comparisons. |
|
1405 |
|
1406 :class:`Rational` numbers derive from :class:`Real`, have |
|
1407 :attr:`numerator` and :attr:`denominator` properties, and can be |
|
1408 converted to floats. Python 2.6 adds a simple rational-number class, |
|
1409 :class:`Fraction`, in the :mod:`fractions` module. (It's called |
|
1410 :class:`Fraction` instead of :class:`Rational` to avoid |
|
1411 a name clash with :class:`numbers.Rational`.) |
|
1412 |
|
1413 :class:`Integral` numbers derive from :class:`Rational`, and |
|
1414 can be shifted left and right with ``<<`` and ``>>``, |
|
1415 combined using bitwise operations such as ``&`` and ``|``, |
|
1416 and can be used as array indexes and slice boundaries. |
|
1417 |
|
1418 In Python 3.0, the PEP slightly redefines the existing built-ins |
|
1419 :func:`round`, :func:`math.floor`, :func:`math.ceil`, and adds a new |
|
1420 one, :func:`math.trunc`, that's been backported to Python 2.6. |
|
1421 :func:`math.trunc` rounds toward zero, returning the closest |
|
1422 :class:`Integral` that's between the function's argument and zero. |
|
1423 |
|
1424 .. seealso:: |
|
1425 |
|
1426 :pep:`3141` - A Type Hierarchy for Numbers |
|
1427 PEP written by Jeffrey Yasskin. |
|
1428 |
|
1429 `Scheme's numerical tower <http://www.gnu.org/software/guile/manual/html_node/Numerical-Tower.html#Numerical-Tower>`__, from the Guile manual. |
|
1430 |
|
1431 `Scheme's number datatypes <http://schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-9.html#%_sec_6.2>`__ from the R5RS Scheme specification. |
|
1432 |
|
1433 |
|
1434 The :mod:`fractions` Module |
|
1435 -------------------------------------------------- |
|
1436 |
|
1437 To fill out the hierarchy of numeric types, the :mod:`fractions` |
|
1438 module provides a rational-number class. Rational numbers store their |
|
1439 values as a numerator and denominator forming a fraction, and can |
|
1440 exactly represent numbers such as ``2/3`` that floating-point numbers |
|
1441 can only approximate. |
|
1442 |
|
1443 The :class:`Fraction` constructor takes two :class:`Integral` values |
|
1444 that will be the numerator and denominator of the resulting fraction. :: |
|
1445 |
|
1446 >>> from fractions import Fraction |
|
1447 >>> a = Fraction(2, 3) |
|
1448 >>> b = Fraction(2, 5) |
|
1449 >>> float(a), float(b) |
|
1450 (0.66666666666666663, 0.40000000000000002) |
|
1451 >>> a+b |
|
1452 Fraction(16, 15) |
|
1453 >>> a/b |
|
1454 Fraction(5, 3) |
|
1455 |
|
1456 For converting floating-point numbers to rationals, |
|
1457 the float type now has an :meth:`as_integer_ratio()` method that returns |
|
1458 the numerator and denominator for a fraction that evaluates to the same |
|
1459 floating-point value:: |
|
1460 |
|
1461 >>> (2.5) .as_integer_ratio() |
|
1462 (5, 2) |
|
1463 >>> (3.1415) .as_integer_ratio() |
|
1464 (7074029114692207L, 2251799813685248L) |
|
1465 >>> (1./3) .as_integer_ratio() |
|
1466 (6004799503160661L, 18014398509481984L) |
|
1467 |
|
1468 Note that values that can only be approximated by floating-point |
|
1469 numbers, such as 1./3, are not simplified to the number being |
|
1470 approximated; the fraction attempts to match the floating-point value |
|
1471 **exactly**. |
|
1472 |
|
1473 The :mod:`fractions` module is based upon an implementation by Sjoerd |
|
1474 Mullender that was in Python's :file:`Demo/classes/` directory for a |
|
1475 long time. This implementation was significantly updated by Jeffrey |
|
1476 Yasskin. |
|
1477 |
|
1478 |
|
1479 Other Language Changes |
|
1480 ====================== |
|
1481 |
|
1482 Some smaller changes made to the core Python language are: |
|
1483 |
|
1484 * The :func:`hasattr` function was catching and ignoring all errors, |
|
1485 under the assumption that they meant a :meth:`__getattr__` method |
|
1486 was failing somehow and the return value of :func:`hasattr` would |
|
1487 therefore be ``False``. This logic shouldn't be applied to |
|
1488 :exc:`KeyboardInterrupt` and :exc:`SystemExit`, however; Python 2.6 |
|
1489 will no longer discard such exceptions when :func:`hasattr` |
|
1490 encounters them. (Fixed by Benjamin Peterson; :issue:`2196`.) |
|
1491 |
|
1492 * When calling a function using the ``**`` syntax to provide keyword |
|
1493 arguments, you are no longer required to use a Python dictionary; |
|
1494 any mapping will now work:: |
|
1495 |
|
1496 >>> def f(**kw): |
|
1497 ... print sorted(kw) |
|
1498 ... |
|
1499 >>> ud=UserDict.UserDict() |
|
1500 >>> ud['a'] = 1 |
|
1501 >>> ud['b'] = 'string' |
|
1502 >>> f(**ud) |
|
1503 ['a', 'b'] |
|
1504 |
|
1505 (Contributed by Alexander Belopolsky; :issue:`1686487`.) |
|
1506 |
|
1507 It's also become legal to provide keyword arguments after a ``*args`` argument |
|
1508 to a function call. :: |
|
1509 |
|
1510 >>> def f(*args, **kw): |
|
1511 ... print args, kw |
|
1512 ... |
|
1513 >>> f(1,2,3, *(4,5,6), keyword=13) |
|
1514 (1, 2, 3, 4, 5, 6) {'keyword': 13} |
|
1515 |
|
1516 Previously this would have been a syntax error. |
|
1517 (Contributed by Amaury Forgeot d'Arc; :issue:`3473`.) |
|
1518 |
|
1519 * A new built-in, ``next(iterator, [default])`` returns the next item |
|
1520 from the specified iterator. If the *default* argument is supplied, |
|
1521 it will be returned if *iterator* has been exhausted; otherwise, |
|
1522 the :exc:`StopIteration` exception will be raised. (Backported |
|
1523 in :issue:`2719`.) |
|
1524 |
|
1525 * Tuples now have :meth:`index` and :meth:`count` methods matching the |
|
1526 list type's :meth:`index` and :meth:`count` methods:: |
|
1527 |
|
1528 >>> t = (0,1,2,3,4,0,1,2) |
|
1529 >>> t.index(3) |
|
1530 3 |
|
1531 >>> t.count(0) |
|
1532 2 |
|
1533 |
|
1534 (Contributed by Raymond Hettinger) |
|
1535 |
|
1536 * The built-in types now have improved support for extended slicing syntax, |
|
1537 accepting various combinations of ``(start, stop, step)``. |
|
1538 Previously, the support was partial and certain corner cases wouldn't work. |
|
1539 (Implemented by Thomas Wouters.) |
|
1540 |
|
1541 .. Revision 57619 |
|
1542 |
|
1543 * Properties now have three attributes, :attr:`getter`, :attr:`setter` |
|
1544 and :attr:`deleter`, that are decorators providing useful shortcuts |
|
1545 for adding a getter, setter or deleter function to an existing |
|
1546 property. You would use them like this:: |
|
1547 |
|
1548 class C(object): |
|
1549 @property |
|
1550 def x(self): |
|
1551 return self._x |
|
1552 |
|
1553 @x.setter |
|
1554 def x(self, value): |
|
1555 self._x = value |
|
1556 |
|
1557 @x.deleter |
|
1558 def x(self): |
|
1559 del self._x |
|
1560 |
|
1561 class D(C): |
|
1562 @C.x.getter |
|
1563 def x(self): |
|
1564 return self._x * 2 |
|
1565 |
|
1566 @x.setter |
|
1567 def x(self, value): |
|
1568 self._x = value / 2 |
|
1569 |
|
1570 * Several methods of the built-in set types now accept multiple iterables: |
|
1571 :meth:`intersection`, |
|
1572 :meth:`intersection_update`, |
|
1573 :meth:`union`, :meth:`update`, |
|
1574 :meth:`difference` and :meth:`difference_update`. |
|
1575 |
|
1576 :: |
|
1577 |
|
1578 >>> s=set('1234567890') |
|
1579 >>> s.intersection('abc123', 'cdf246') # Intersection between all inputs |
|
1580 set(['2']) |
|
1581 >>> s.difference('246', '789') |
|
1582 set(['1', '0', '3', '5']) |
|
1583 |
|
1584 (Contributed by Raymond Hettinger.) |
|
1585 |
|
1586 * Many floating-point features were added. The :func:`float` function |
|
1587 will now turn the string ``nan`` into an |
|
1588 IEEE 754 Not A Number value, and ``+inf`` and ``-inf`` into |
|
1589 positive or negative infinity. This works on any platform with |
|
1590 IEEE 754 semantics. (Contributed by Christian Heimes; :issue:`1635`.) |
|
1591 |
|
1592 Other functions in the :mod:`math` module, :func:`isinf` and |
|
1593 :func:`isnan`, return true if their floating-point argument is |
|
1594 infinite or Not A Number. (:issue:`1640`) |
|
1595 |
|
1596 Conversion functions were added to convert floating-point numbers |
|
1597 into hexadecimal strings (:issue:`3008`). These functions |
|
1598 convert floats to and from a string representation without |
|
1599 introducing rounding errors from the conversion between decimal and |
|
1600 binary. Floats have a :meth:`hex` method that returns a string |
|
1601 representation, and the ``float.fromhex()`` method converts a string |
|
1602 back into a number:: |
|
1603 |
|
1604 >>> a = 3.75 |
|
1605 >>> a.hex() |
|
1606 '0x1.e000000000000p+1' |
|
1607 >>> float.fromhex('0x1.e000000000000p+1') |
|
1608 3.75 |
|
1609 >>> b=1./3 |
|
1610 >>> b.hex() |
|
1611 '0x1.5555555555555p-2' |
|
1612 |
|
1613 * A numerical nicety: when creating a complex number from two floats |
|
1614 on systems that support signed zeros (-0 and +0), the |
|
1615 :func:`complex` constructor will now preserve the sign |
|
1616 of the zero. (Fixed by Mark T. Dickinson; :issue:`1507`.) |
|
1617 |
|
1618 * Classes that inherit a :meth:`__hash__` method from a parent class |
|
1619 can set ``__hash__ = None`` to indicate that the class isn't |
|
1620 hashable. This will make ``hash(obj)`` raise a :exc:`TypeError` |
|
1621 and the class will not be indicated as implementing the |
|
1622 :class:`Hashable` ABC. |
|
1623 |
|
1624 You should do this when you've defined a :meth:`__cmp__` or |
|
1625 :meth:`__eq__` method that compares objects by their value rather |
|
1626 than by identity. All objects have a default hash method that uses |
|
1627 ``id(obj)`` as the hash value. There's no tidy way to remove the |
|
1628 :meth:`__hash__` method inherited from a parent class, so |
|
1629 assigning ``None`` was implemented as an override. At the |
|
1630 C level, extensions can set ``tp_hash`` to |
|
1631 :cfunc:`PyObject_HashNotImplemented`. |
|
1632 (Fixed by Nick Coghlan and Amaury Forgeot d'Arc; :issue:`2235`.) |
|
1633 |
|
1634 * Changes to the :class:`Exception` interface |
|
1635 as dictated by :pep:`352` continue to be made. For 2.6, |
|
1636 the :attr:`message` attribute is being deprecated in favor of the |
|
1637 :attr:`args` attribute. |
|
1638 |
|
1639 * The :exc:`GeneratorExit` exception now subclasses |
|
1640 :exc:`BaseException` instead of :exc:`Exception`. This means |
|
1641 that an exception handler that does ``except Exception:`` |
|
1642 will not inadvertently catch :exc:`GeneratorExit`. |
|
1643 (Contributed by Chad Austin; :issue:`1537`.) |
|
1644 |
|
1645 * Generator objects now have a :attr:`gi_code` attribute that refers to |
|
1646 the original code object backing the generator. |
|
1647 (Contributed by Collin Winter; :issue:`1473257`.) |
|
1648 |
|
1649 * The :func:`compile` built-in function now accepts keyword arguments |
|
1650 as well as positional parameters. (Contributed by Thomas Wouters; |
|
1651 :issue:`1444529`.) |
|
1652 |
|
1653 * The :func:`complex` constructor now accepts strings containing |
|
1654 parenthesized complex numbers, meaning that ``complex(repr(cplx))`` |
|
1655 will now round-trip values. For example, ``complex('(3+4j)')`` |
|
1656 now returns the value (3+4j). (:issue:`1491866`) |
|
1657 |
|
1658 * The string :meth:`translate` method now accepts ``None`` as the |
|
1659 translation table parameter, which is treated as the identity |
|
1660 transformation. This makes it easier to carry out operations |
|
1661 that only delete characters. (Contributed by Bengt Richter and |
|
1662 implemented by Raymond Hettinger; :issue:`1193128`.) |
|
1663 |
|
1664 * The built-in :func:`dir` function now checks for a :meth:`__dir__` |
|
1665 method on the objects it receives. This method must return a list |
|
1666 of strings containing the names of valid attributes for the object, |
|
1667 and lets the object control the value that :func:`dir` produces. |
|
1668 Objects that have :meth:`__getattr__` or :meth:`__getattribute__` |
|
1669 methods can use this to advertise pseudo-attributes they will honor. |
|
1670 (:issue:`1591665`) |
|
1671 |
|
1672 * Instance method objects have new attributes for the object and function |
|
1673 comprising the method; the new synonym for :attr:`im_self` is |
|
1674 :attr:`__self__`, and :attr:`im_func` is also available as :attr:`__func__`. |
|
1675 The old names are still supported in Python 2.6, but are gone in 3.0. |
|
1676 |
|
1677 * An obscure change: when you use the the :func:`locals` function inside a |
|
1678 :keyword:`class` statement, the resulting dictionary no longer returns free |
|
1679 variables. (Free variables, in this case, are variables referenced in the |
|
1680 :keyword:`class` statement that aren't attributes of the class.) |
|
1681 |
|
1682 .. ====================================================================== |
|
1683 |
|
1684 |
|
1685 Optimizations |
|
1686 ------------- |
|
1687 |
|
1688 * The :mod:`warnings` module has been rewritten in C. This makes |
|
1689 it possible to invoke warnings from the parser, and may also |
|
1690 make the interpreter's startup faster. |
|
1691 (Contributed by Neal Norwitz and Brett Cannon; :issue:`1631171`.) |
|
1692 |
|
1693 * Type objects now have a cache of methods that can reduce |
|
1694 the work required to find the correct method implementation |
|
1695 for a particular class; once cached, the interpreter doesn't need to |
|
1696 traverse base classes to figure out the right method to call. |
|
1697 The cache is cleared if a base class or the class itself is modified, |
|
1698 so the cache should remain correct even in the face of Python's dynamic |
|
1699 nature. |
|
1700 (Original optimization implemented by Armin Rigo, updated for |
|
1701 Python 2.6 by Kevin Jacobs; :issue:`1700288`.) |
|
1702 |
|
1703 By default, this change is only applied to types that are included with |
|
1704 the Python core. Extension modules may not necessarily be compatible with |
|
1705 this cache, |
|
1706 so they must explicitly add :cmacro:`Py_TPFLAGS_HAVE_VERSION_TAG` |
|
1707 to the module's ``tp_flags`` field to enable the method cache. |
|
1708 (To be compatible with the method cache, the extension module's code |
|
1709 must not directly access and modify the ``tp_dict`` member of |
|
1710 any of the types it implements. Most modules don't do this, |
|
1711 but it's impossible for the Python interpreter to determine that. |
|
1712 See :issue:`1878` for some discussion.) |
|
1713 |
|
1714 * Function calls that use keyword arguments are significantly faster |
|
1715 by doing a quick pointer comparison, usually saving the time of a |
|
1716 full string comparison. (Contributed by Raymond Hettinger, after an |
|
1717 initial implementation by Antoine Pitrou; :issue:`1819`.) |
|
1718 |
|
1719 * All of the functions in the :mod:`struct` module have been rewritten in |
|
1720 C, thanks to work at the Need For Speed sprint. |
|
1721 (Contributed by Raymond Hettinger.) |
|
1722 |
|
1723 * Some of the standard built-in types now set a bit in their type |
|
1724 objects. This speeds up checking whether an object is a subclass of |
|
1725 one of these types. (Contributed by Neal Norwitz.) |
|
1726 |
|
1727 * Unicode strings now use faster code for detecting |
|
1728 whitespace and line breaks; this speeds up the :meth:`split` method |
|
1729 by about 25% and :meth:`splitlines` by 35%. |
|
1730 (Contributed by Antoine Pitrou.) Memory usage is reduced |
|
1731 by using pymalloc for the Unicode string's data. |
|
1732 |
|
1733 * The ``with`` statement now stores the :meth:`__exit__` method on the stack, |
|
1734 producing a small speedup. (Implemented by Jeffrey Yasskin.) |
|
1735 |
|
1736 * To reduce memory usage, the garbage collector will now clear internal |
|
1737 free lists when garbage-collecting the highest generation of objects. |
|
1738 This may return memory to the operating system sooner. |
|
1739 |
|
1740 .. ====================================================================== |
|
1741 |
|
1742 .. _new-26-interpreter: |
|
1743 |
|
1744 Interpreter Changes |
|
1745 ------------------------------- |
|
1746 |
|
1747 Two command-line options have been reserved for use by other Python |
|
1748 implementations. The :option:`-J` switch has been reserved for use by |
|
1749 Jython for Jython-specific options, such as switches that are passed to |
|
1750 the underlying JVM. :option:`-X` has been reserved for options |
|
1751 specific to a particular implementation of Python such as CPython, |
|
1752 Jython, or IronPython. If either option is used with Python 2.6, the |
|
1753 interpreter will report that the option isn't currently used. |
|
1754 |
|
1755 Python can now be prevented from writing :file:`.pyc` or :file:`.pyo` |
|
1756 files by supplying the :option:`-B` switch to the Python interpreter, |
|
1757 or by setting the :envvar:`PYTHONDONTWRITEBYTECODE` environment |
|
1758 variable before running the interpreter. This setting is available to |
|
1759 Python programs as the ``sys.dont_write_bytecode`` variable, and |
|
1760 Python code can change the value to modify the interpreter's |
|
1761 behaviour. (Contributed by Neal Norwitz and Georg Brandl.) |
|
1762 |
|
1763 The encoding used for standard input, output, and standard error can |
|
1764 be specified by setting the :envvar:`PYTHONIOENCODING` environment |
|
1765 variable before running the interpreter. The value should be a string |
|
1766 in the form ``<encoding>`` or ``<encoding>:<errorhandler>``. |
|
1767 The *encoding* part specifies the encoding's name, e.g. ``utf-8`` or |
|
1768 ``latin-1``; the optional *errorhandler* part specifies |
|
1769 what to do with characters that can't be handled by the encoding, |
|
1770 and should be one of "error", "ignore", or "replace". (Contributed |
|
1771 by Martin von Loewis.) |
|
1772 |
|
1773 .. ====================================================================== |
|
1774 |
|
1775 New, Improved, and Deprecated Modules |
|
1776 ===================================== |
|
1777 |
|
1778 As in every release, Python's standard library received a number of |
|
1779 enhancements and bug fixes. Here's a partial list of the most notable |
|
1780 changes, sorted alphabetically by module name. Consult the |
|
1781 :file:`Misc/NEWS` file in the source tree for a more complete list of |
|
1782 changes, or look through the Subversion logs for all the details. |
|
1783 |
|
1784 * (3.0-warning mode) Python 3.0 will feature a reorganized standard |
|
1785 library that will drop many outdated modules and rename others. |
|
1786 Python 2.6 running in 3.0-warning mode will warn about these modules |
|
1787 when they are imported. |
|
1788 |
|
1789 The list of deprecated modules is: |
|
1790 :mod:`audiodev`, |
|
1791 :mod:`bgenlocations`, |
|
1792 :mod:`buildtools`, |
|
1793 :mod:`bundlebuilder`, |
|
1794 :mod:`Canvas`, |
|
1795 :mod:`compiler`, |
|
1796 :mod:`dircache`, |
|
1797 :mod:`dl`, |
|
1798 :mod:`fpformat`, |
|
1799 :mod:`gensuitemodule`, |
|
1800 :mod:`ihooks`, |
|
1801 :mod:`imageop`, |
|
1802 :mod:`imgfile`, |
|
1803 :mod:`linuxaudiodev`, |
|
1804 :mod:`mhlib`, |
|
1805 :mod:`mimetools`, |
|
1806 :mod:`multifile`, |
|
1807 :mod:`new`, |
|
1808 :mod:`pure`, |
|
1809 :mod:`statvfs`, |
|
1810 :mod:`sunaudiodev`, |
|
1811 :mod:`test.testall`, and |
|
1812 :mod:`toaiff`. |
|
1813 |
|
1814 * The :mod:`asyncore` and :mod:`asynchat` modules are |
|
1815 being actively maintained again, and a number of patches and bugfixes |
|
1816 were applied. (Maintained by Josiah Carlson; see :issue:`1736190` for |
|
1817 one patch.) |
|
1818 |
|
1819 * The :mod:`bsddb` module also has a new maintainer, Jesús Cea, and the package |
|
1820 is now available as a standalone package. The web page for the package is |
|
1821 `www.jcea.es/programacion/pybsddb.htm |
|
1822 <http://www.jcea.es/programacion/pybsddb.htm>`__. |
|
1823 The plan is to remove the package from the standard library |
|
1824 in Python 3.0, because its pace of releases is much more frequent than |
|
1825 Python's. |
|
1826 |
|
1827 The :mod:`bsddb.dbshelve` module now uses the highest pickling protocol |
|
1828 available, instead of restricting itself to protocol 1. |
|
1829 (Contributed by W. Barnes; :issue:`1551443`.) |
|
1830 |
|
1831 * The :mod:`cgi` module will now read variables from the query string |
|
1832 of an HTTP POST request. This makes it possible to use form actions |
|
1833 with URLs that include query strings such as |
|
1834 "/cgi-bin/add.py?category=1". (Contributed by Alexandre Fiori and |
|
1835 Nubis; :issue:`1817`.) |
|
1836 |
|
1837 The :func:`parse_qs` and :func:`parse_qsl` functions have been |
|
1838 relocated from the :mod:`cgi` module to the :mod:`urlparse` module. |
|
1839 The versions still available in the :mod:`cgi` module will |
|
1840 trigger :exc:`PendingDeprecationWarning` messages in 2.6 |
|
1841 (:issue:`600362`). |
|
1842 |
|
1843 * The :mod:`cmath` module underwent extensive revision, |
|
1844 contributed by Mark Dickinson and Christian Heimes. |
|
1845 Five new functions were added: |
|
1846 |
|
1847 * :func:`polar` converts a complex number to polar form, returning |
|
1848 the modulus and argument of the complex number. |
|
1849 |
|
1850 * :func:`rect` does the opposite, turning a modulus, argument pair |
|
1851 back into the corresponding complex number. |
|
1852 |
|
1853 * :func:`phase` returns the argument (also called the angle) of a complex |
|
1854 number. |
|
1855 |
|
1856 * :func:`isnan` returns True if either |
|
1857 the real or imaginary part of its argument is a NaN. |
|
1858 |
|
1859 * :func:`isinf` returns True if either the real or imaginary part of |
|
1860 its argument is infinite. |
|
1861 |
|
1862 The revisions also improved the numerical soundness of the |
|
1863 :mod:`cmath` module. For all functions, the real and imaginary |
|
1864 parts of the results are accurate to within a few units of least |
|
1865 precision (ulps) whenever possible. See :issue:`1381` for the |
|
1866 details. The branch cuts for :func:`asinh`, :func:`atanh`: and |
|
1867 :func:`atan` have also been corrected. |
|
1868 |
|
1869 The tests for the module have been greatly expanded; nearly 2000 new |
|
1870 test cases exercise the algebraic functions. |
|
1871 |
|
1872 On IEEE 754 platforms, the :mod:`cmath` module now handles IEEE 754 |
|
1873 special values and floating-point exceptions in a manner consistent |
|
1874 with Annex 'G' of the C99 standard. |
|
1875 |
|
1876 * A new data type in the :mod:`collections` module: :class:`namedtuple(typename, |
|
1877 fieldnames)` is a factory function that creates subclasses of the standard tuple |
|
1878 whose fields are accessible by name as well as index. For example:: |
|
1879 |
|
1880 >>> var_type = collections.namedtuple('variable', |
|
1881 ... 'id name type size') |
|
1882 >>> # Names are separated by spaces or commas. |
|
1883 >>> # 'id, name, type, size' would also work. |
|
1884 >>> var_type._fields |
|
1885 ('id', 'name', 'type', 'size') |
|
1886 |
|
1887 >>> var = var_type(1, 'frequency', 'int', 4) |
|
1888 >>> print var[0], var.id # Equivalent |
|
1889 1 1 |
|
1890 >>> print var[2], var.type # Equivalent |
|
1891 int int |
|
1892 >>> var._asdict() |
|
1893 {'size': 4, 'type': 'int', 'id': 1, 'name': 'frequency'} |
|
1894 >>> v2 = var._replace(name='amplitude') |
|
1895 >>> v2 |
|
1896 variable(id=1, name='amplitude', type='int', size=4) |
|
1897 |
|
1898 Several places in the standard library that returned tuples have |
|
1899 been modified to return :class:`namedtuple` instances. For example, |
|
1900 the :meth:`Decimal.as_tuple` method now returns a named tuple with |
|
1901 :attr:`sign`, :attr:`digits`, and :attr:`exponent` fields. |
|
1902 |
|
1903 (Contributed by Raymond Hettinger.) |
|
1904 |
|
1905 * Another change to the :mod:`collections` module is that the |
|
1906 :class:`deque` type now supports an optional *maxlen* parameter; |
|
1907 if supplied, the deque's size will be restricted to no more |
|
1908 than *maxlen* items. Adding more items to a full deque causes |
|
1909 old items to be discarded. |
|
1910 |
|
1911 :: |
|
1912 |
|
1913 >>> from collections import deque |
|
1914 >>> dq=deque(maxlen=3) |
|
1915 >>> dq |
|
1916 deque([], maxlen=3) |
|
1917 >>> dq.append(1) ; dq.append(2) ; dq.append(3) |
|
1918 >>> dq |
|
1919 deque([1, 2, 3], maxlen=3) |
|
1920 >>> dq.append(4) |
|
1921 >>> dq |
|
1922 deque([2, 3, 4], maxlen=3) |
|
1923 |
|
1924 (Contributed by Raymond Hettinger.) |
|
1925 |
|
1926 * The :mod:`Cookie` module's :class:`Morsel` objects now support an |
|
1927 :attr:`httponly` attribute. In some browsers. cookies with this attribute |
|
1928 set cannot be accessed or manipulated by JavaScript code. |
|
1929 (Contributed by Arvin Schnell; :issue:`1638033`.) |
|
1930 |
|
1931 * A new window method in the :mod:`curses` module, |
|
1932 :meth:`chgat`, changes the display attributes for a certain number of |
|
1933 characters on a single line. (Contributed by Fabian Kreutz.) |
|
1934 |
|
1935 :: |
|
1936 |
|
1937 # Boldface text starting at y=0,x=21 |
|
1938 # and affecting the rest of the line. |
|
1939 stdscr.chgat(0, 21, curses.A_BOLD) |
|
1940 |
|
1941 The :class:`Textbox` class in the :mod:`curses.textpad` module |
|
1942 now supports editing in insert mode as well as overwrite mode. |
|
1943 Insert mode is enabled by supplying a true value for the *insert_mode* |
|
1944 parameter when creating the :class:`Textbox` instance. |
|
1945 |
|
1946 * The :mod:`datetime` module's :meth:`strftime` methods now support a |
|
1947 ``%f`` format code that expands to the number of microseconds in the |
|
1948 object, zero-padded on |
|
1949 the left to six places. (Contributed by Skip Montanaro; :issue:`1158`.) |
|
1950 |
|
1951 * The :mod:`decimal` module was updated to version 1.66 of |
|
1952 `the General Decimal Specification <http://www2.hursley.ibm.com/decimal/decarith.html>`__. New features |
|
1953 include some methods for some basic mathematical functions such as |
|
1954 :meth:`exp` and :meth:`log10`:: |
|
1955 |
|
1956 >>> Decimal(1).exp() |
|
1957 Decimal("2.718281828459045235360287471") |
|
1958 >>> Decimal("2.7182818").ln() |
|
1959 Decimal("0.9999999895305022877376682436") |
|
1960 >>> Decimal(1000).log10() |
|
1961 Decimal("3") |
|
1962 |
|
1963 The :meth:`as_tuple` method of :class:`Decimal` objects now returns a |
|
1964 named tuple with :attr:`sign`, :attr:`digits`, and :attr:`exponent` fields. |
|
1965 |
|
1966 (Implemented by Facundo Batista and Mark Dickinson. Named tuple |
|
1967 support added by Raymond Hettinger.) |
|
1968 |
|
1969 * The :mod:`difflib` module's :class:`SequenceMatcher` class |
|
1970 now returns named tuples representing matches, |
|
1971 with :attr:`a`, :attr:`b`, and :attr:`size` attributes. |
|
1972 (Contributed by Raymond Hettinger.) |
|
1973 |
|
1974 * An optional ``timeout`` parameter, specifying a timeout measured in |
|
1975 seconds, was added to the :class:`ftplib.FTP` class constructor as |
|
1976 well as the :meth:`connect` method. (Added by Facundo Batista.) |
|
1977 Also, the :class:`FTP` class's :meth:`storbinary` and |
|
1978 :meth:`storlines` now take an optional *callback* parameter that |
|
1979 will be called with each block of data after the data has been sent. |
|
1980 (Contributed by Phil Schwartz; :issue:`1221598`.) |
|
1981 |
|
1982 * The :func:`reduce` built-in function is also available in the |
|
1983 :mod:`functools` module. In Python 3.0, the built-in has been |
|
1984 dropped and :func:`reduce` is only available from :mod:`functools`; |
|
1985 currently there are no plans to drop the built-in in the 2.x series. |
|
1986 (Patched by Christian Heimes; :issue:`1739906`.) |
|
1987 |
|
1988 * When possible, the :mod:`getpass` module will now use |
|
1989 :file:`/dev/tty` to print a prompt message and read the password, |
|
1990 falling back to standard error and standard input. If the |
|
1991 password may be echoed to the terminal, a warning is printed before |
|
1992 the prompt is displayed. (Contributed by Gregory P. Smith.) |
|
1993 |
|
1994 * The :func:`glob.glob` function can now return Unicode filenames if |
|
1995 a Unicode path was used and Unicode filenames are matched within the |
|
1996 directory. (:issue:`1001604`) |
|
1997 |
|
1998 * The :mod:`gopherlib` module has been removed. |
|
1999 |
|
2000 * A new function in the :mod:`heapq` module, ``merge(iter1, iter2, ...)``, |
|
2001 takes any number of iterables returning data in sorted |
|
2002 order, and returns a new generator that returns the contents of all |
|
2003 the iterators, also in sorted order. For example:: |
|
2004 |
|
2005 >>> list(heapq.merge([1, 3, 5, 9], [2, 8, 16])) |
|
2006 [1, 2, 3, 5, 8, 9, 16] |
|
2007 |
|
2008 Another new function, ``heappushpop(heap, item)``, |
|
2009 pushes *item* onto *heap*, then pops off and returns the smallest item. |
|
2010 This is more efficient than making a call to :func:`heappush` and then |
|
2011 :func:`heappop`. |
|
2012 |
|
2013 :mod:`heapq` is now implemented to only use less-than comparison, |
|
2014 instead of the less-than-or-equal comparison it previously used. |
|
2015 This makes :mod:`heapq`'s usage of a type match the |
|
2016 :meth:`list.sort` method. |
|
2017 (Contributed by Raymond Hettinger.) |
|
2018 |
|
2019 * An optional ``timeout`` parameter, specifying a timeout measured in |
|
2020 seconds, was added to the :class:`httplib.HTTPConnection` and |
|
2021 :class:`HTTPSConnection` class constructors. (Added by Facundo |
|
2022 Batista.) |
|
2023 |
|
2024 * Most of the :mod:`inspect` module's functions, such as |
|
2025 :func:`getmoduleinfo` and :func:`getargs`, now return named tuples. |
|
2026 In addition to behaving like tuples, the elements of the return value |
|
2027 can also be accessed as attributes. |
|
2028 (Contributed by Raymond Hettinger.) |
|
2029 |
|
2030 Some new functions in the module include |
|
2031 :func:`isgenerator`, :func:`isgeneratorfunction`, |
|
2032 and :func:`isabstract`. |
|
2033 |
|
2034 * The :mod:`itertools` module gained several new functions. |
|
2035 |
|
2036 ``izip_longest(iter1, iter2, ...[, fillvalue])`` makes tuples from |
|
2037 each of the elements; if some of the iterables are shorter than |
|
2038 others, the missing values are set to *fillvalue*. For example:: |
|
2039 |
|
2040 >>> tuple(itertools.izip_longest([1,2,3], [1,2,3,4,5])) |
|
2041 ((1, 1), (2, 2), (3, 3), (None, 4), (None, 5)) |
|
2042 |
|
2043 ``product(iter1, iter2, ..., [repeat=N])`` returns the Cartesian product |
|
2044 of the supplied iterables, a set of tuples containing |
|
2045 every possible combination of the elements returned from each iterable. :: |
|
2046 |
|
2047 >>> list(itertools.product([1,2,3], [4,5,6])) |
|
2048 [(1, 4), (1, 5), (1, 6), |
|
2049 (2, 4), (2, 5), (2, 6), |
|
2050 (3, 4), (3, 5), (3, 6)] |
|
2051 |
|
2052 The optional *repeat* keyword argument is used for taking the |
|
2053 product of an iterable or a set of iterables with themselves, |
|
2054 repeated *N* times. With a single iterable argument, *N*-tuples |
|
2055 are returned:: |
|
2056 |
|
2057 >>> list(itertools.product([1,2], repeat=3)) |
|
2058 [(1, 1, 1), (1, 1, 2), (1, 2, 1), (1, 2, 2), |
|
2059 (2, 1, 1), (2, 1, 2), (2, 2, 1), (2, 2, 2)] |
|
2060 |
|
2061 With two iterables, *2N*-tuples are returned. :: |
|
2062 |
|
2063 >>> list(itertools.product([1,2], [3,4], repeat=2)) |
|
2064 [(1, 3, 1, 3), (1, 3, 1, 4), (1, 3, 2, 3), (1, 3, 2, 4), |
|
2065 (1, 4, 1, 3), (1, 4, 1, 4), (1, 4, 2, 3), (1, 4, 2, 4), |
|
2066 (2, 3, 1, 3), (2, 3, 1, 4), (2, 3, 2, 3), (2, 3, 2, 4), |
|
2067 (2, 4, 1, 3), (2, 4, 1, 4), (2, 4, 2, 3), (2, 4, 2, 4)] |
|
2068 |
|
2069 ``combinations(iterable, r)`` returns sub-sequences of length *r* from |
|
2070 the elements of *iterable*. :: |
|
2071 |
|
2072 >>> list(itertools.combinations('123', 2)) |
|
2073 [('1', '2'), ('1', '3'), ('2', '3')] |
|
2074 >>> list(itertools.combinations('123', 3)) |
|
2075 [('1', '2', '3')] |
|
2076 >>> list(itertools.combinations('1234', 3)) |
|
2077 [('1', '2', '3'), ('1', '2', '4'), |
|
2078 ('1', '3', '4'), ('2', '3', '4')] |
|
2079 |
|
2080 ``permutations(iter[, r])`` returns all the permutations of length *r* of |
|
2081 the iterable's elements. If *r* is not specified, it will default to the |
|
2082 number of elements produced by the iterable. :: |
|
2083 |
|
2084 >>> list(itertools.permutations([1,2,3,4], 2)) |
|
2085 [(1, 2), (1, 3), (1, 4), |
|
2086 (2, 1), (2, 3), (2, 4), |
|
2087 (3, 1), (3, 2), (3, 4), |
|
2088 (4, 1), (4, 2), (4, 3)] |
|
2089 |
|
2090 ``itertools.chain(*iterables)`` is an existing function in |
|
2091 :mod:`itertools` that gained a new constructor in Python 2.6. |
|
2092 ``itertools.chain.from_iterable(iterable)`` takes a single |
|
2093 iterable that should return other iterables. :func:`chain` will |
|
2094 then return all the elements of the first iterable, then |
|
2095 all the elements of the second, and so on. :: |
|
2096 |
|
2097 >>> list(itertools.chain.from_iterable([[1,2,3], [4,5,6]])) |
|
2098 [1, 2, 3, 4, 5, 6] |
|
2099 |
|
2100 (All contributed by Raymond Hettinger.) |
|
2101 |
|
2102 * The :mod:`logging` module's :class:`FileHandler` class |
|
2103 and its subclasses :class:`WatchedFileHandler`, :class:`RotatingFileHandler`, |
|
2104 and :class:`TimedRotatingFileHandler` now |
|
2105 have an optional *delay* parameter to their constructors. If *delay* |
|
2106 is true, opening of the log file is deferred until the first |
|
2107 :meth:`emit` call is made. (Contributed by Vinay Sajip.) |
|
2108 |
|
2109 :class:`TimedRotatingFileHandler` also has a *utc* constructor |
|
2110 parameter. If the argument is true, UTC time will be used |
|
2111 in determining when midnight occurs and in generating filenames; |
|
2112 otherwise local time will be used. |
|
2113 |
|
2114 * Several new functions were added to the :mod:`math` module: |
|
2115 |
|
2116 * :func:`~math.isinf` and :func:`~math.isnan` determine whether a given float |
|
2117 is a (positive or negative) infinity or a NaN (Not a Number), respectively. |
|
2118 |
|
2119 * :func:`~math.copysign` copies the sign bit of an IEEE 754 number, |
|
2120 returning the absolute value of *x* combined with the sign bit of |
|
2121 *y*. For example, ``math.copysign(1, -0.0)`` returns -1.0. |
|
2122 (Contributed by Christian Heimes.) |
|
2123 |
|
2124 * :func:`~math.factorial` computes the factorial of a number. |
|
2125 (Contributed by Raymond Hettinger; :issue:`2138`.) |
|
2126 |
|
2127 * :func:`~math.fsum` adds up the stream of numbers from an iterable, |
|
2128 and is careful to avoid loss of precision through using partial sums. |
|
2129 (Contributed by Jean Brouwers, Raymond Hettinger, and Mark Dickinson; |
|
2130 :issue:`2819`.) |
|
2131 |
|
2132 * :func:`~math.acosh`, :func:`~math.asinh` |
|
2133 and :func:`~math.atanh` compute the inverse hyperbolic functions. |
|
2134 |
|
2135 * :func:`~math.log1p` returns the natural logarithm of *1+x* |
|
2136 (base *e*). |
|
2137 |
|
2138 * :func:`trunc` rounds a number toward zero, returning the closest |
|
2139 :class:`Integral` that's between the function's argument and zero. |
|
2140 Added as part of the backport of |
|
2141 `PEP 3141's type hierarchy for numbers <#pep-3141>`__. |
|
2142 |
|
2143 * The :mod:`math` module has been improved to give more consistent |
|
2144 behaviour across platforms, especially with respect to handling of |
|
2145 floating-point exceptions and IEEE 754 special values. |
|
2146 |
|
2147 Whenever possible, the module follows the recommendations of the C99 |
|
2148 standard about 754's special values. For example, ``sqrt(-1.)`` |
|
2149 should now give a :exc:`ValueError` across almost all platforms, |
|
2150 while ``sqrt(float('NaN'))`` should return a NaN on all IEEE 754 |
|
2151 platforms. Where Annex 'F' of the C99 standard recommends signaling |
|
2152 'divide-by-zero' or 'invalid', Python will raise :exc:`ValueError`. |
|
2153 Where Annex 'F' of the C99 standard recommends signaling 'overflow', |
|
2154 Python will raise :exc:`OverflowError`. (See :issue:`711019` and |
|
2155 :issue:`1640`.) |
|
2156 |
|
2157 (Contributed by Christian Heimes and Mark Dickinson.) |
|
2158 |
|
2159 * The :mod:`MimeWriter` module and :mod:`mimify` module |
|
2160 have been deprecated; use the :mod:`email` |
|
2161 package instead. |
|
2162 |
|
2163 * The :mod:`md5` module has been deprecated; use the :mod:`hashlib` module |
|
2164 instead. |
|
2165 |
|
2166 * :class:`mmap` objects now have a :meth:`rfind` method that searches for a |
|
2167 substring beginning at the end of the string and searching |
|
2168 backwards. The :meth:`find` method also gained an *end* parameter |
|
2169 giving an index at which to stop searching. |
|
2170 (Contributed by John Lenton.) |
|
2171 |
|
2172 * The :mod:`operator` module gained a |
|
2173 :func:`methodcaller` function that takes a name and an optional |
|
2174 set of arguments, returning a callable that will call |
|
2175 the named function on any arguments passed to it. For example:: |
|
2176 |
|
2177 >>> # Equivalent to lambda s: s.replace('old', 'new') |
|
2178 >>> replacer = operator.methodcaller('replace', 'old', 'new') |
|
2179 >>> replacer('old wine in old bottles') |
|
2180 'new wine in new bottles' |
|
2181 |
|
2182 (Contributed by Georg Brandl, after a suggestion by Gregory Petrosyan.) |
|
2183 |
|
2184 The :func:`attrgetter` function now accepts dotted names and performs |
|
2185 the corresponding attribute lookups:: |
|
2186 |
|
2187 >>> inst_name = operator.attrgetter( |
|
2188 ... '__class__.__name__') |
|
2189 >>> inst_name('') |
|
2190 'str' |
|
2191 >>> inst_name(help) |
|
2192 '_Helper' |
|
2193 |
|
2194 (Contributed by Georg Brandl, after a suggestion by Barry Warsaw.) |
|
2195 |
|
2196 * The :mod:`os` module now wraps several new system calls. |
|
2197 ``fchmod(fd, mode)`` and ``fchown(fd, uid, gid)`` change the mode |
|
2198 and ownership of an opened file, and ``lchmod(path, mode)`` changes |
|
2199 the mode of a symlink. (Contributed by Georg Brandl and Christian |
|
2200 Heimes.) |
|
2201 |
|
2202 :func:`chflags` and :func:`lchflags` are wrappers for the |
|
2203 corresponding system calls (where they're available), changing the |
|
2204 flags set on a file. Constants for the flag values are defined in |
|
2205 the :mod:`stat` module; some possible values include |
|
2206 :const:`UF_IMMUTABLE` to signal the file may not be changed and |
|
2207 :const:`UF_APPEND` to indicate that data can only be appended to the |
|
2208 file. (Contributed by M. Levinson.) |
|
2209 |
|
2210 ``os.closerange(low, high)`` efficiently closes all file descriptors |
|
2211 from *low* to *high*, ignoring any errors and not including *high* itself. |
|
2212 This function is now used by the :mod:`subprocess` module to make starting |
|
2213 processes faster. (Contributed by Georg Brandl; :issue:`1663329`.) |
|
2214 |
|
2215 * The ``os.environ`` object's :meth:`clear` method will now unset the |
|
2216 environment variables using :func:`os.unsetenv` in addition to clearing |
|
2217 the object's keys. (Contributed by Martin Horcicka; :issue:`1181`.) |
|
2218 |
|
2219 * The :func:`os.walk` function now has a ``followlinks`` parameter. If |
|
2220 set to True, it will follow symlinks pointing to directories and |
|
2221 visit the directory's contents. For backward compatibility, the |
|
2222 parameter's default value is false. Note that the function can fall |
|
2223 into an infinite recursion if there's a symlink that points to a |
|
2224 parent directory. (:issue:`1273829`) |
|
2225 |
|
2226 * In the :mod:`os.path` module, the :func:`splitext` function |
|
2227 has been changed to not split on leading period characters. |
|
2228 This produces better results when operating on Unix's dot-files. |
|
2229 For example, ``os.path.splitext('.ipython')`` |
|
2230 now returns ``('.ipython', '')`` instead of ``('', '.ipython')``. |
|
2231 (:issue:`115886`) |
|
2232 |
|
2233 A new function, ``os.path.relpath(path, start='.')``, returns a relative path |
|
2234 from the ``start`` path, if it's supplied, or from the current |
|
2235 working directory to the destination ``path``. (Contributed by |
|
2236 Richard Barran; :issue:`1339796`.) |
|
2237 |
|
2238 On Windows, :func:`os.path.expandvars` will now expand environment variables |
|
2239 given in the form "%var%", and "~user" will be expanded into the |
|
2240 user's home directory path. (Contributed by Josiah Carlson; |
|
2241 :issue:`957650`.) |
|
2242 |
|
2243 * The Python debugger provided by the :mod:`pdb` module |
|
2244 gained a new command: "run" restarts the Python program being debugged |
|
2245 and can optionally take new command-line arguments for the program. |
|
2246 (Contributed by Rocky Bernstein; :issue:`1393667`.) |
|
2247 |
|
2248 * The :mod:`posixfile` module has been deprecated; :func:`fcntl.lockf` |
|
2249 provides better locking. |
|
2250 |
|
2251 The :func:`post_mortem` function, used to begin debugging a |
|
2252 traceback, will now use the traceback returned by :func:`sys.exc_info` |
|
2253 if no traceback is supplied. (Contributed by Facundo Batista; |
|
2254 :issue:`1106316`.) |
|
2255 |
|
2256 * The :mod:`pickletools` module now has an :func:`optimize` function |
|
2257 that takes a string containing a pickle and removes some unused |
|
2258 opcodes, returning a shorter pickle that contains the same data structure. |
|
2259 (Contributed by Raymond Hettinger.) |
|
2260 |
|
2261 * The :mod:`popen2` module has been deprecated; use the :mod:`subprocess` |
|
2262 module. |
|
2263 |
|
2264 * A :func:`get_data` function was added to the :mod:`pkgutil` |
|
2265 module that returns the contents of resource files included |
|
2266 with an installed Python package. For example:: |
|
2267 |
|
2268 >>> import pkgutil |
|
2269 >>> print pkgutil.get_data('test', 'exception_hierarchy.txt') |
|
2270 BaseException |
|
2271 +-- SystemExit |
|
2272 +-- KeyboardInterrupt |
|
2273 +-- GeneratorExit |
|
2274 +-- Exception |
|
2275 +-- StopIteration |
|
2276 +-- StandardError |
|
2277 ... |
|
2278 |
|
2279 (Contributed by Paul Moore; :issue:`2439`.) |
|
2280 |
|
2281 * The :mod:`pyexpat` module's :class:`Parser` objects now allow setting |
|
2282 their :attr:`buffer_size` attribute to change the size of the buffer |
|
2283 used to hold character data. |
|
2284 (Contributed by Achim Gaedke; :issue:`1137`.) |
|
2285 |
|
2286 * The :mod:`Queue` module now provides queue variants that retrieve entries |
|
2287 in different orders. The :class:`PriorityQueue` class stores |
|
2288 queued items in a heap and retrieves them in priority order, |
|
2289 and :class:`LifoQueue` retrieves the most recently added entries first, |
|
2290 meaning that it behaves like a stack. |
|
2291 (Contributed by Raymond Hettinger.) |
|
2292 |
|
2293 * The :mod:`random` module's :class:`Random` objects can |
|
2294 now be pickled on a 32-bit system and unpickled on a 64-bit |
|
2295 system, and vice versa. Unfortunately, this change also means |
|
2296 that Python 2.6's :class:`Random` objects can't be unpickled correctly |
|
2297 on earlier versions of Python. |
|
2298 (Contributed by Shawn Ligocki; :issue:`1727780`.) |
|
2299 |
|
2300 The new ``triangular(low, high, mode)`` function returns random |
|
2301 numbers following a triangular distribution. The returned values |
|
2302 are between *low* and *high*, not including *high* itself, and |
|
2303 with *mode* as the most frequently occurring value |
|
2304 in the distribution. (Contributed by Wladmir van der Laan and |
|
2305 Raymond Hettinger; :issue:`1681432`.) |
|
2306 |
|
2307 * Long regular expression searches carried out by the :mod:`re` |
|
2308 module will check for signals being delivered, so |
|
2309 time-consuming searches can now be interrupted. |
|
2310 (Contributed by Josh Hoyt and Ralf Schmitt; :issue:`846388`.) |
|
2311 |
|
2312 The regular expression module is implemented by compiling bytecodes |
|
2313 for a tiny regex-specific virtual machine. Untrusted code |
|
2314 could create malicious strings of bytecode directly and cause crashes, |
|
2315 so Python 2.6 includes a verifier for the regex bytecode. |
|
2316 (Contributed by Guido van Rossum from work for Google App Engine; |
|
2317 :issue:`3487`.) |
|
2318 |
|
2319 * The :mod:`rgbimg` module has been removed. |
|
2320 |
|
2321 * The :mod:`rlcompleter` module's :meth:`Completer.complete()` method |
|
2322 will now ignore exceptions triggered while evaluating a name. |
|
2323 (Fixed by Lorenz Quack; :issue:`2250`.) |
|
2324 |
|
2325 * The :mod:`sched` module's :class:`scheduler` instances now |
|
2326 have a read-only :attr:`queue` attribute that returns the |
|
2327 contents of the scheduler's queue, represented as a list of |
|
2328 named tuples with the fields ``(time, priority, action, argument)``. |
|
2329 (Contributed by Raymond Hettinger; :issue:`1861`.) |
|
2330 |
|
2331 * The :mod:`select` module now has wrapper functions |
|
2332 for the Linux :cfunc:`epoll` and BSD :cfunc:`kqueue` system calls. |
|
2333 :meth:`modify` method was added to the existing :class:`poll` |
|
2334 objects; ``pollobj.modify(fd, eventmask)`` takes a file descriptor |
|
2335 or file object and an event mask, modifying the recorded event mask |
|
2336 for that file. |
|
2337 (Contributed by Christian Heimes; :issue:`1657`.) |
|
2338 |
|
2339 * The :mod:`sets` module has been deprecated; it's better to |
|
2340 use the built-in :class:`set` and :class:`frozenset` types. |
|
2341 |
|
2342 * The :mod:`sha` module has been deprecated; use the :mod:`hashlib` module |
|
2343 instead. |
|
2344 |
|
2345 * The :func:`shutil.copytree` function now has an optional *ignore* argument |
|
2346 that takes a callable object. This callable will receive each directory path |
|
2347 and a list of the directory's contents, and returns a list of names that |
|
2348 will be ignored, not copied. |
|
2349 |
|
2350 The :mod:`shutil` module also provides an :func:`ignore_patterns` |
|
2351 function for use with this new parameter. :func:`ignore_patterns` |
|
2352 takes an arbitrary number of glob-style patterns and returns a |
|
2353 callable that will ignore any files and directories that match any |
|
2354 of these patterns. The following example copies a directory tree, |
|
2355 but skips both :file:`.svn` directories and Emacs backup files, |
|
2356 which have names ending with '~':: |
|
2357 |
|
2358 shutil.copytree('Doc/library', '/tmp/library', |
|
2359 ignore=shutil.ignore_patterns('*~', '.svn')) |
|
2360 |
|
2361 (Contributed by Tarek Ziadé; :issue:`2663`.) |
|
2362 |
|
2363 * Integrating signal handling with GUI handling event loops |
|
2364 like those used by Tkinter or GTk+ has long been a problem; most |
|
2365 software ends up polling, waking up every fraction of a second to check |
|
2366 if any GUI events have occurred. |
|
2367 The :mod:`signal` module can now make this more efficient. |
|
2368 Calling ``signal.set_wakeup_fd(fd)`` sets a file descriptor |
|
2369 to be used; when a signal is received, a byte is written to that |
|
2370 file descriptor. There's also a C-level function, |
|
2371 :cfunc:`PySignal_SetWakeupFd`, for setting the descriptor. |
|
2372 |
|
2373 Event loops will use this by opening a pipe to create two descriptors, |
|
2374 one for reading and one for writing. The writable descriptor |
|
2375 will be passed to :func:`set_wakeup_fd`, and the readable descriptor |
|
2376 will be added to the list of descriptors monitored by the event loop via |
|
2377 :cfunc:`select` or :cfunc:`poll`. |
|
2378 On receiving a signal, a byte will be written and the main event loop |
|
2379 will be woken up, avoiding the need to poll. |
|
2380 |
|
2381 (Contributed by Adam Olsen; :issue:`1583`.) |
|
2382 |
|
2383 The :func:`siginterrupt` function is now available from Python code, |
|
2384 and allows changing whether signals can interrupt system calls or not. |
|
2385 (Contributed by Ralf Schmitt.) |
|
2386 |
|
2387 The :func:`setitimer` and :func:`getitimer` functions have also been |
|
2388 added (where they're available). :func:`setitimer` |
|
2389 allows setting interval timers that will cause a signal to be |
|
2390 delivered to the process after a specified time, measured in |
|
2391 wall-clock time, consumed process time, or combined process+system |
|
2392 time. (Contributed by Guilherme Polo; :issue:`2240`.) |
|
2393 |
|
2394 * The :mod:`smtplib` module now supports SMTP over SSL thanks to the |
|
2395 addition of the :class:`SMTP_SSL` class. This class supports an |
|
2396 interface identical to the existing :class:`SMTP` class. |
|
2397 (Contributed by Monty Taylor.) Both class constructors also have an |
|
2398 optional ``timeout`` parameter that specifies a timeout for the |
|
2399 initial connection attempt, measured in seconds. (Contributed by |
|
2400 Facundo Batista.) |
|
2401 |
|
2402 An implementation of the LMTP protocol (:rfc:`2033`) was also added |
|
2403 to the module. LMTP is used in place of SMTP when transferring |
|
2404 e-mail between agents that don't manage a mail queue. (LMTP |
|
2405 implemented by Leif Hedstrom; :issue:`957003`.) |
|
2406 |
|
2407 SMTP.starttls() now complies with :rfc:`3207` and forgets any |
|
2408 knowledge obtained from the server not obtained from the TLS |
|
2409 negotiation itself. (Patch contributed by Bill Fenner; |
|
2410 :issue:`829951`.) |
|
2411 |
|
2412 * The :mod:`socket` module now supports TIPC (http://tipc.sf.net), |
|
2413 a high-performance non-IP-based protocol designed for use in clustered |
|
2414 environments. TIPC addresses are 4- or 5-tuples. |
|
2415 (Contributed by Alberto Bertogli; :issue:`1646`.) |
|
2416 |
|
2417 A new function, :func:`create_connection`, takes an address |
|
2418 and connects to it using an optional timeout value, returning |
|
2419 the connected socket object. |
|
2420 |
|
2421 * The base classes in the :mod:`SocketServer` module now support |
|
2422 calling a :meth:`handle_timeout` method after a span of inactivity |
|
2423 specified by the server's :attr:`timeout` attribute. (Contributed |
|
2424 by Michael Pomraning.) The :meth:`serve_forever` method |
|
2425 now takes an optional poll interval measured in seconds, |
|
2426 controlling how often the server will check for a shutdown request. |
|
2427 (Contributed by Pedro Werneck and Jeffrey Yasskin; |
|
2428 :issue:`742598`, :issue:`1193577`.) |
|
2429 |
|
2430 * The :mod:`sqlite3` module, maintained by Gerhard Haering, |
|
2431 has been updated from version 2.3.2 in Python 2.5 to |
|
2432 version 2.4.1. |
|
2433 |
|
2434 * The :mod:`struct` module now supports the C99 :ctype:`_Bool` type, |
|
2435 using the format character ``'?'``. |
|
2436 (Contributed by David Remahl.) |
|
2437 |
|
2438 * The :class:`Popen` objects provided by the :mod:`subprocess` module |
|
2439 now have :meth:`terminate`, :meth:`kill`, and :meth:`send_signal` methods. |
|
2440 On Windows, :meth:`send_signal` only supports the :const:`SIGTERM` |
|
2441 signal, and all these methods are aliases for the Win32 API function |
|
2442 :cfunc:`TerminateProcess`. |
|
2443 (Contributed by Christian Heimes.) |
|
2444 |
|
2445 * A new variable in the :mod:`sys` module, :attr:`float_info`, is an |
|
2446 object containing information derived from the :file:`float.h` file |
|
2447 about the platform's floating-point support. Attributes of this |
|
2448 object include :attr:`mant_dig` (number of digits in the mantissa), |
|
2449 :attr:`epsilon` (smallest difference between 1.0 and the next |
|
2450 largest value representable), and several others. (Contributed by |
|
2451 Christian Heimes; :issue:`1534`.) |
|
2452 |
|
2453 Another new variable, :attr:`dont_write_bytecode`, controls whether Python |
|
2454 writes any :file:`.pyc` or :file:`.pyo` files on importing a module. |
|
2455 If this variable is true, the compiled files are not written. The |
|
2456 variable is initially set on start-up by supplying the :option:`-B` |
|
2457 switch to the Python interpreter, or by setting the |
|
2458 :envvar:`PYTHONDONTWRITEBYTECODE` environment variable before |
|
2459 running the interpreter. Python code can subsequently |
|
2460 change the value of this variable to control whether bytecode files |
|
2461 are written or not. |
|
2462 (Contributed by Neal Norwitz and Georg Brandl.) |
|
2463 |
|
2464 Information about the command-line arguments supplied to the Python |
|
2465 interpreter is available by reading attributes of a named |
|
2466 tuple available as ``sys.flags``. For example, the :attr:`verbose` |
|
2467 attribute is true if Python |
|
2468 was executed in verbose mode, :attr:`debug` is true in debugging mode, etc. |
|
2469 These attributes are all read-only. |
|
2470 (Contributed by Christian Heimes.) |
|
2471 |
|
2472 A new function, :func:`getsizeof`, takes a Python object and returns |
|
2473 the amount of memory used by the object, measured in bytes. Built-in |
|
2474 objects return correct results; third-party extensions may not, |
|
2475 but can define a :meth:`__sizeof__` method to return the |
|
2476 object's size. |
|
2477 (Contributed by Robert Schuppenies; :issue:`2898`.) |
|
2478 |
|
2479 It's now possible to determine the current profiler and tracer functions |
|
2480 by calling :func:`sys.getprofile` and :func:`sys.gettrace`. |
|
2481 (Contributed by Georg Brandl; :issue:`1648`.) |
|
2482 |
|
2483 * The :mod:`tarfile` module now supports POSIX.1-2001 (pax) tarfiles in |
|
2484 addition to the POSIX.1-1988 (ustar) and GNU tar formats that were |
|
2485 already supported. The default format is GNU tar; specify the |
|
2486 ``format`` parameter to open a file using a different format:: |
|
2487 |
|
2488 tar = tarfile.open("output.tar", "w", |
|
2489 format=tarfile.PAX_FORMAT) |
|
2490 |
|
2491 The new ``encoding`` and ``errors`` parameters specify an encoding and |
|
2492 an error handling scheme for character conversions. ``'strict'``, |
|
2493 ``'ignore'``, and ``'replace'`` are the three standard ways Python can |
|
2494 handle errors,; |
|
2495 ``'utf-8'`` is a special value that replaces bad characters with |
|
2496 their UTF-8 representation. (Character conversions occur because the |
|
2497 PAX format supports Unicode filenames, defaulting to UTF-8 encoding.) |
|
2498 |
|
2499 The :meth:`TarFile.add` method now accepts an ``exclude`` argument that's |
|
2500 a function that can be used to exclude certain filenames from |
|
2501 an archive. |
|
2502 The function must take a filename and return true if the file |
|
2503 should be excluded or false if it should be archived. |
|
2504 The function is applied to both the name initially passed to :meth:`add` |
|
2505 and to the names of files in recursively-added directories. |
|
2506 |
|
2507 (All changes contributed by Lars Gustäbel). |
|
2508 |
|
2509 * An optional ``timeout`` parameter was added to the |
|
2510 :class:`telnetlib.Telnet` class constructor, specifying a timeout |
|
2511 measured in seconds. (Added by Facundo Batista.) |
|
2512 |
|
2513 * The :class:`tempfile.NamedTemporaryFile` class usually deletes |
|
2514 the temporary file it created when the file is closed. This |
|
2515 behaviour can now be changed by passing ``delete=False`` to the |
|
2516 constructor. (Contributed by Damien Miller; :issue:`1537850`.) |
|
2517 |
|
2518 A new class, :class:`SpooledTemporaryFile`, behaves like |
|
2519 a temporary file but stores its data in memory until a maximum size is |
|
2520 exceeded. On reaching that limit, the contents will be written to |
|
2521 an on-disk temporary file. (Contributed by Dustin J. Mitchell.) |
|
2522 |
|
2523 The :class:`NamedTemporaryFile` and :class:`SpooledTemporaryFile` classes |
|
2524 both work as context managers, so you can write |
|
2525 ``with tempfile.NamedTemporaryFile() as tmp: ...``. |
|
2526 (Contributed by Alexander Belopolsky; :issue:`2021`.) |
|
2527 |
|
2528 * The :mod:`test.test_support` module gained a number |
|
2529 of context managers useful for writing tests. |
|
2530 :func:`EnvironmentVarGuard` is a |
|
2531 context manager that temporarily changes environment variables and |
|
2532 automatically restores them to their old values. |
|
2533 |
|
2534 Another context manager, :class:`TransientResource`, can surround calls |
|
2535 to resources that may or may not be available; it will catch and |
|
2536 ignore a specified list of exceptions. For example, |
|
2537 a network test may ignore certain failures when connecting to an |
|
2538 external web site:: |
|
2539 |
|
2540 with test_support.TransientResource(IOError, |
|
2541 errno=errno.ETIMEDOUT): |
|
2542 f = urllib.urlopen('https://sf.net') |
|
2543 ... |
|
2544 |
|
2545 Finally, :func:`check_warnings` resets the :mod:`warning` module's |
|
2546 warning filters and returns an object that will record all warning |
|
2547 messages triggered (:issue:`3781`):: |
|
2548 |
|
2549 with test_support.check_warnings() as wrec: |
|
2550 warnings.simplefilter("always") |
|
2551 # ... code that triggers a warning ... |
|
2552 assert str(wrec.message) == "function is outdated" |
|
2553 assert len(wrec.warnings) == 1, "Multiple warnings raised" |
|
2554 |
|
2555 (Contributed by Brett Cannon.) |
|
2556 |
|
2557 * The :mod:`textwrap` module can now preserve existing whitespace |
|
2558 at the beginnings and ends of the newly-created lines |
|
2559 by specifying ``drop_whitespace=False`` |
|
2560 as an argument:: |
|
2561 |
|
2562 >>> S = """This sentence has a bunch of |
|
2563 ... extra whitespace.""" |
|
2564 >>> print textwrap.fill(S, width=15) |
|
2565 This sentence |
|
2566 has a bunch |
|
2567 of extra |
|
2568 whitespace. |
|
2569 >>> print textwrap.fill(S, drop_whitespace=False, width=15) |
|
2570 This sentence |
|
2571 has a bunch |
|
2572 of extra |
|
2573 whitespace. |
|
2574 >>> |
|
2575 |
|
2576 (Contributed by Dwayne Bailey; :issue:`1581073`.) |
|
2577 |
|
2578 * The :mod:`threading` module API is being changed to use properties |
|
2579 such as :attr:`daemon` instead of :meth:`setDaemon` and |
|
2580 :meth:`isDaemon` methods, and some methods have been renamed to use |
|
2581 underscores instead of camel-case; for example, the |
|
2582 :meth:`activeCount` method is renamed to :meth:`active_count`. Both |
|
2583 the 2.6 and 3.0 versions of the module support the same properties |
|
2584 and renamed methods, but don't remove the old methods. No date has been set |
|
2585 for the deprecation of the old APIs in Python 3.x; the old APIs won't |
|
2586 be removed in any 2.x version. |
|
2587 (Carried out by several people, most notably Benjamin Peterson.) |
|
2588 |
|
2589 The :mod:`threading` module's :class:`Thread` objects |
|
2590 gained an :attr:`ident` property that returns the thread's |
|
2591 identifier, a nonzero integer. (Contributed by Gregory P. Smith; |
|
2592 :issue:`2871`.) |
|
2593 |
|
2594 * The :mod:`timeit` module now accepts callables as well as strings |
|
2595 for the statement being timed and for the setup code. |
|
2596 Two convenience functions were added for creating |
|
2597 :class:`Timer` instances: |
|
2598 ``repeat(stmt, setup, time, repeat, number)`` and |
|
2599 ``timeit(stmt, setup, time, number)`` create an instance and call |
|
2600 the corresponding method. (Contributed by Erik Demaine; |
|
2601 :issue:`1533909`.) |
|
2602 |
|
2603 * The :mod:`Tkinter` module now accepts lists and tuples for options, |
|
2604 separating the elements by spaces before passing the resulting value to |
|
2605 Tcl/Tk. |
|
2606 (Contributed by Guilherme Polo; :issue:`2906`.) |
|
2607 |
|
2608 * The :mod:`turtle` module for turtle graphics was greatly enhanced by |
|
2609 Gregor Lingl. New features in the module include: |
|
2610 |
|
2611 * Better animation of turtle movement and rotation. |
|
2612 * Control over turtle movement using the new :meth:`delay`, |
|
2613 :meth:`tracer`, and :meth:`speed` methods. |
|
2614 * The ability to set new shapes for the turtle, and to |
|
2615 define a new coordinate system. |
|
2616 * Turtles now have an :meth:`undo()` method that can roll back actions. |
|
2617 * Simple support for reacting to input events such as mouse and keyboard |
|
2618 activity, making it possible to write simple games. |
|
2619 * A :file:`turtle.cfg` file can be used to customize the starting appearance |
|
2620 of the turtle's screen. |
|
2621 * The module's docstrings can be replaced by new docstrings that have been |
|
2622 translated into another language. |
|
2623 |
|
2624 (:issue:`1513695`) |
|
2625 |
|
2626 * An optional ``timeout`` parameter was added to the |
|
2627 :func:`urllib.urlopen` function and the |
|
2628 :class:`urllib.ftpwrapper` class constructor, as well as the |
|
2629 :func:`urllib2.urlopen` function. The parameter specifies a timeout |
|
2630 measured in seconds. For example:: |
|
2631 |
|
2632 >>> u = urllib2.urlopen("http://slow.example.com", |
|
2633 timeout=3) |
|
2634 Traceback (most recent call last): |
|
2635 ... |
|
2636 urllib2.URLError: <urlopen error timed out> |
|
2637 >>> |
|
2638 |
|
2639 (Added by Facundo Batista.) |
|
2640 |
|
2641 * The Unicode database provided by the :mod:`unicodedata` module |
|
2642 has been updated to version 5.1.0. (Updated by |
|
2643 Martin von Loewis; :issue:`3811`.) |
|
2644 |
|
2645 * The :mod:`warnings` module's :func:`formatwarning` and :func:`showwarning` |
|
2646 gained an optional *line* argument that can be used to supply the |
|
2647 line of source code. (Added as part of :issue:`1631171`, which re-implemented |
|
2648 part of the :mod:`warnings` module in C code.) |
|
2649 |
|
2650 A new function, :func:`catch_warnings`, is a context manager |
|
2651 intended for testing purposes that lets you temporarily modify the |
|
2652 warning filters and then restore their original values (:issue:`3781`). |
|
2653 |
|
2654 * The XML-RPC :class:`SimpleXMLRPCServer` and :class:`DocXMLRPCServer` |
|
2655 classes can now be prevented from immediately opening and binding to |
|
2656 their socket by passing True as the ``bind_and_activate`` |
|
2657 constructor parameter. This can be used to modify the instance's |
|
2658 :attr:`allow_reuse_address` attribute before calling the |
|
2659 :meth:`server_bind` and :meth:`server_activate` methods to |
|
2660 open the socket and begin listening for connections. |
|
2661 (Contributed by Peter Parente; :issue:`1599845`.) |
|
2662 |
|
2663 :class:`SimpleXMLRPCServer` also has a :attr:`_send_traceback_header` |
|
2664 attribute; if true, the exception and formatted traceback are returned |
|
2665 as HTTP headers "X-Exception" and "X-Traceback". This feature is |
|
2666 for debugging purposes only and should not be used on production servers |
|
2667 because the tracebacks might reveal passwords or other sensitive |
|
2668 information. (Contributed by Alan McIntyre as part of his |
|
2669 project for Google's Summer of Code 2007.) |
|
2670 |
|
2671 * The :mod:`xmlrpclib` module no longer automatically converts |
|
2672 :class:`datetime.date` and :class:`datetime.time` to the |
|
2673 :class:`xmlrpclib.DateTime` type; the conversion semantics were |
|
2674 not necessarily correct for all applications. Code using |
|
2675 :mod:`xmlrpclib` should convert :class:`date` and :class:`time` |
|
2676 instances. (:issue:`1330538`) The code can also handle |
|
2677 dates before 1900 (contributed by Ralf Schmitt; :issue:`2014`) |
|
2678 and 64-bit integers represented by using ``<i8>`` in XML-RPC responses |
|
2679 (contributed by Riku Lindblad; :issue:`2985`). |
|
2680 |
|
2681 * The :mod:`zipfile` module's :class:`ZipFile` class now has |
|
2682 :meth:`extract` and :meth:`extractall` methods that will unpack |
|
2683 a single file or all the files in the archive to the current directory, or |
|
2684 to a specified directory:: |
|
2685 |
|
2686 z = zipfile.ZipFile('python-251.zip') |
|
2687 |
|
2688 # Unpack a single file, writing it relative |
|
2689 # to the /tmp directory. |
|
2690 z.extract('Python/sysmodule.c', '/tmp') |
|
2691 |
|
2692 # Unpack all the files in the archive. |
|
2693 z.extractall() |
|
2694 |
|
2695 (Contributed by Alan McIntyre; :issue:`467924`.) |
|
2696 |
|
2697 The :meth:`open`, :meth:`read` and :meth:`extract` methods can now |
|
2698 take either a filename or a :class:`ZipInfo` object. This is useful when an |
|
2699 archive accidentally contains a duplicated filename. |
|
2700 (Contributed by Graham Horler; :issue:`1775025`.) |
|
2701 |
|
2702 Finally, :mod:`zipfile` now supports using Unicode filenames |
|
2703 for archived files. (Contributed by Alexey Borzenkov; :issue:`1734346`.) |
|
2704 |
|
2705 .. ====================================================================== |
|
2706 .. whole new modules get described in subsections here |
|
2707 |
|
2708 The :mod:`ast` module |
|
2709 ---------------------- |
|
2710 |
|
2711 The :mod:`ast` module provides an Abstract Syntax Tree |
|
2712 representation of Python code, and Armin Ronacher |
|
2713 contributed a set of helper functions that perform a variety of |
|
2714 common tasks. These will be useful for HTML templating |
|
2715 packages, code analyzers, and similar tools that process |
|
2716 Python code. |
|
2717 |
|
2718 The :func:`parse` function takes an expression and returns an AST. |
|
2719 The :func:`dump` function outputs a representation of a tree, suitable |
|
2720 for debugging:: |
|
2721 |
|
2722 import ast |
|
2723 |
|
2724 t = ast.parse(""" |
|
2725 d = {} |
|
2726 for i in 'abcdefghijklm': |
|
2727 d[i + i] = ord(i) - ord('a') + 1 |
|
2728 print d |
|
2729 """) |
|
2730 print ast.dump(t) |
|
2731 |
|
2732 This outputs a deeply nested tree:: |
|
2733 |
|
2734 Module(body=[ |
|
2735 Assign(targets=[ |
|
2736 Name(id='d', ctx=Store()) |
|
2737 ], value=Dict(keys=[], values=[])) |
|
2738 For(target=Name(id='i', ctx=Store()), |
|
2739 iter=Str(s='abcdefghijklm'), body=[ |
|
2740 Assign(targets=[ |
|
2741 Subscript(value= |
|
2742 Name(id='d', ctx=Load()), |
|
2743 slice= |
|
2744 Index(value= |
|
2745 BinOp(left=Name(id='i', ctx=Load()), op=Add(), |
|
2746 right=Name(id='i', ctx=Load()))), ctx=Store()) |
|
2747 ], value= |
|
2748 BinOp(left= |
|
2749 BinOp(left= |
|
2750 Call(func= |
|
2751 Name(id='ord', ctx=Load()), args=[ |
|
2752 Name(id='i', ctx=Load()) |
|
2753 ], keywords=[], starargs=None, kwargs=None), |
|
2754 op=Sub(), right=Call(func= |
|
2755 Name(id='ord', ctx=Load()), args=[ |
|
2756 Str(s='a') |
|
2757 ], keywords=[], starargs=None, kwargs=None)), |
|
2758 op=Add(), right=Num(n=1))) |
|
2759 ], orelse=[]) |
|
2760 Print(dest=None, values=[ |
|
2761 Name(id='d', ctx=Load()) |
|
2762 ], nl=True) |
|
2763 ]) |
|
2764 |
|
2765 The :func:`literal_eval` method takes a string or an AST |
|
2766 representing a literal expression, parses and evaluates it, and |
|
2767 returns the resulting value. A literal expression is a Python |
|
2768 expression containing only strings, numbers, dictionaries, |
|
2769 etc. but no statements or function calls. If you need to |
|
2770 evaluate an expression but cannot accept the security risk of using an |
|
2771 :func:`eval` call, :func:`literal_eval` will handle it safely:: |
|
2772 |
|
2773 >>> literal = '("a", "b", {2:4, 3:8, 1:2})' |
|
2774 >>> print ast.literal_eval(literal) |
|
2775 ('a', 'b', {1: 2, 2: 4, 3: 8}) |
|
2776 >>> print ast.literal_eval('"a" + "b"') |
|
2777 Traceback (most recent call last): |
|
2778 ... |
|
2779 ValueError: malformed string |
|
2780 |
|
2781 The module also includes :class:`NodeVisitor` and |
|
2782 :class:`NodeTransformer` classes for traversing and modifying an AST, |
|
2783 and functions for common transformations such as changing line |
|
2784 numbers. |
|
2785 |
|
2786 .. ====================================================================== |
|
2787 |
|
2788 The :mod:`future_builtins` module |
|
2789 -------------------------------------- |
|
2790 |
|
2791 Python 3.0 makes many changes to the repertoire of built-in |
|
2792 functions, and most of the changes can't be introduced in the Python |
|
2793 2.x series because they would break compatibility. |
|
2794 The :mod:`future_builtins` module provides versions |
|
2795 of these built-in functions that can be imported when writing |
|
2796 3.0-compatible code. |
|
2797 |
|
2798 The functions in this module currently include: |
|
2799 |
|
2800 * ``ascii(obj)``: equivalent to :func:`repr`. In Python 3.0, |
|
2801 :func:`repr` will return a Unicode string, while :func:`ascii` will |
|
2802 return a pure ASCII bytestring. |
|
2803 |
|
2804 * ``filter(predicate, iterable)``, |
|
2805 ``map(func, iterable1, ...)``: the 3.0 versions |
|
2806 return iterators, unlike the 2.x built-ins which return lists. |
|
2807 |
|
2808 * ``hex(value)``, ``oct(value)``: instead of calling the |
|
2809 :meth:`__hex__` or :meth:`__oct__` methods, these versions will |
|
2810 call the :meth:`__index__` method and convert the result to hexadecimal |
|
2811 or octal. :func:`oct` will use the new ``0o`` notation for its |
|
2812 result. |
|
2813 |
|
2814 .. ====================================================================== |
|
2815 |
|
2816 The :mod:`json` module: JavaScript Object Notation |
|
2817 -------------------------------------------------------------------- |
|
2818 |
|
2819 The new :mod:`json` module supports the encoding and decoding of Python types in |
|
2820 JSON (Javascript Object Notation). JSON is a lightweight interchange format |
|
2821 often used in web applications. For more information about JSON, see |
|
2822 http://www.json.org. |
|
2823 |
|
2824 :mod:`json` comes with support for decoding and encoding most builtin Python |
|
2825 types. The following example encodes and decodes a dictionary:: |
|
2826 |
|
2827 >>> import json |
|
2828 >>> data = {"spam" : "foo", "parrot" : 42} |
|
2829 >>> in_json = json.dumps(data) # Encode the data |
|
2830 >>> in_json |
|
2831 '{"parrot": 42, "spam": "foo"}' |
|
2832 >>> json.loads(in_json) # Decode into a Python object |
|
2833 {"spam" : "foo", "parrot" : 42} |
|
2834 |
|
2835 It's also possible to write your own decoders and encoders to support |
|
2836 more types. Pretty-printing of the JSON strings is also supported. |
|
2837 |
|
2838 :mod:`json` (originally called simplejson) was written by Bob |
|
2839 Ippolito. |
|
2840 |
|
2841 |
|
2842 .. ====================================================================== |
|
2843 |
|
2844 The :mod:`plistlib` module: A Property-List Parser |
|
2845 -------------------------------------------------- |
|
2846 |
|
2847 The ``.plist`` format is commonly used on Mac OS X to |
|
2848 store basic data types (numbers, strings, lists, |
|
2849 and dictionaries) by serializing them into an XML-based format. |
|
2850 It resembles the XML-RPC serialization of data types. |
|
2851 |
|
2852 Despite being primarily used on Mac OS X, the format |
|
2853 has nothing Mac-specific about it and the Python implementation works |
|
2854 on any platform that Python supports, so the :mod:`plistlib` module |
|
2855 has been promoted to the standard library. |
|
2856 |
|
2857 Using the module is simple:: |
|
2858 |
|
2859 import sys |
|
2860 import plistlib |
|
2861 import datetime |
|
2862 |
|
2863 # Create data structure |
|
2864 data_struct = dict(lastAccessed=datetime.datetime.now(), |
|
2865 version=1, |
|
2866 categories=('Personal','Shared','Private')) |
|
2867 |
|
2868 # Create string containing XML. |
|
2869 plist_str = plistlib.writePlistToString(data_struct) |
|
2870 new_struct = plistlib.readPlistFromString(plist_str) |
|
2871 print data_struct |
|
2872 print new_struct |
|
2873 |
|
2874 # Write data structure to a file and read it back. |
|
2875 plistlib.writePlist(data_struct, '/tmp/customizations.plist') |
|
2876 new_struct = plistlib.readPlist('/tmp/customizations.plist') |
|
2877 |
|
2878 # read/writePlist accepts file-like objects as well as paths. |
|
2879 plistlib.writePlist(data_struct, sys.stdout) |
|
2880 |
|
2881 .. ====================================================================== |
|
2882 |
|
2883 ctypes Enhancements |
|
2884 -------------------------------------------------- |
|
2885 |
|
2886 Thomas Heller continued to maintain and enhance the |
|
2887 :mod:`ctypes` module. |
|
2888 |
|
2889 :mod:`ctypes` now supports a :class:`c_bool` datatype |
|
2890 that represents the C99 ``bool`` type. (Contributed by David Remahl; |
|
2891 :issue:`1649190`.) |
|
2892 |
|
2893 The :mod:`ctypes` string, buffer and array types have improved |
|
2894 support for extended slicing syntax, |
|
2895 where various combinations of ``(start, stop, step)`` are supplied. |
|
2896 (Implemented by Thomas Wouters.) |
|
2897 |
|
2898 .. Revision 57769 |
|
2899 |
|
2900 All :mod:`ctypes` data types now support |
|
2901 :meth:`from_buffer` and :meth:`from_buffer_copy` |
|
2902 methods that create a ctypes instance based on a |
|
2903 provided buffer object. :meth:`from_buffer_copy` copies |
|
2904 the contents of the object, |
|
2905 while :meth:`from_buffer` will share the same memory area. |
|
2906 |
|
2907 A new calling convention tells :mod:`ctypes` to clear the ``errno`` or |
|
2908 Win32 LastError variables at the outset of each wrapped call. |
|
2909 (Implemented by Thomas Heller; :issue:`1798`.) |
|
2910 |
|
2911 You can now retrieve the Unix ``errno`` variable after a function |
|
2912 call. When creating a wrapped function, you can supply |
|
2913 ``use_errno=True`` as a keyword parameter to the :func:`DLL` function |
|
2914 and then call the module-level methods :meth:`set_errno` and |
|
2915 :meth:`get_errno` to set and retrieve the error value. |
|
2916 |
|
2917 The Win32 LastError variable is similarly supported by |
|
2918 the :func:`DLL`, :func:`OleDLL`, and :func:`WinDLL` functions. |
|
2919 You supply ``use_last_error=True`` as a keyword parameter |
|
2920 and then call the module-level methods :meth:`set_last_error` |
|
2921 and :meth:`get_last_error`. |
|
2922 |
|
2923 The :func:`byref` function, used to retrieve a pointer to a ctypes |
|
2924 instance, now has an optional *offset* parameter that is a byte |
|
2925 count that will be added to the returned pointer. |
|
2926 |
|
2927 .. ====================================================================== |
|
2928 |
|
2929 Improved SSL Support |
|
2930 -------------------------------------------------- |
|
2931 |
|
2932 Bill Janssen made extensive improvements to Python 2.6's support for |
|
2933 the Secure Sockets Layer by adding a new module, :mod:`ssl`, that's |
|
2934 built atop the `OpenSSL <http://www.openssl.org/>`__ library. |
|
2935 This new module provides more control over the protocol negotiated, |
|
2936 the X.509 certificates used, and has better support for writing SSL |
|
2937 servers (as opposed to clients) in Python. The existing SSL support |
|
2938 in the :mod:`socket` module hasn't been removed and continues to work, |
|
2939 though it will be removed in Python 3.0. |
|
2940 |
|
2941 To use the new module, you must first create a TCP connection in the |
|
2942 usual way and then pass it to the :func:`ssl.wrap_socket` function. |
|
2943 It's possible to specify whether a certificate is required, and to |
|
2944 obtain certificate info by calling the :meth:`getpeercert` method. |
|
2945 |
|
2946 .. seealso:: |
|
2947 |
|
2948 The documentation for the :mod:`ssl` module. |
|
2949 |
|
2950 .. ====================================================================== |
|
2951 |
|
2952 |
|
2953 Build and C API Changes |
|
2954 ======================= |
|
2955 |
|
2956 Changes to Python's build process and to the C API include: |
|
2957 |
|
2958 * Python now must be compiled with C89 compilers (after 19 |
|
2959 years!). This means that the Python source tree has dropped its |
|
2960 own implementations of :cfunc:`memmove` and :cfunc:`strerror`, which |
|
2961 are in the C89 standard library. |
|
2962 |
|
2963 * Python 2.6 can be built with Microsoft Visual Studio 2008 (version |
|
2964 9.0), and this is the new default compiler. See the |
|
2965 :file:`PCbuild` directory for the build files. (Implemented by |
|
2966 Christian Heimes.) |
|
2967 |
|
2968 * On Mac OS X, Python 2.6 can be compiled as a 4-way universal build. |
|
2969 The :program:`configure` script |
|
2970 can take a :option:`--with-universal-archs=[32-bit|64-bit|all]` |
|
2971 switch, controlling whether the binaries are built for 32-bit |
|
2972 architectures (x86, PowerPC), 64-bit (x86-64 and PPC-64), or both. |
|
2973 (Contributed by Ronald Oussoren.) |
|
2974 |
|
2975 * The BerkeleyDB module now has a C API object, available as |
|
2976 ``bsddb.db.api``. This object can be used by other C extensions |
|
2977 that wish to use the :mod:`bsddb` module for their own purposes. |
|
2978 (Contributed by Duncan Grisby; :issue:`1551895`.) |
|
2979 |
|
2980 * The new buffer interface, previously described in |
|
2981 `the PEP 3118 section <#pep-3118-revised-buffer-protocol>`__, |
|
2982 adds :cfunc:`PyObject_GetBuffer` and :cfunc:`PyBuffer_Release`, |
|
2983 as well as a few other functions. |
|
2984 |
|
2985 * Python's use of the C stdio library is now thread-safe, or at least |
|
2986 as thread-safe as the underlying library is. A long-standing potential |
|
2987 bug occurred if one thread closed a file object while another thread |
|
2988 was reading from or writing to the object. In 2.6 file objects |
|
2989 have a reference count, manipulated by the |
|
2990 :cfunc:`PyFile_IncUseCount` and :cfunc:`PyFile_DecUseCount` |
|
2991 functions. File objects can't be closed unless the reference count |
|
2992 is zero. :cfunc:`PyFile_IncUseCount` should be called while the GIL |
|
2993 is still held, before carrying out an I/O operation using the |
|
2994 ``FILE *`` pointer, and :cfunc:`PyFile_DecUseCount` should be called |
|
2995 immediately after the GIL is re-acquired. |
|
2996 (Contributed by Antoine Pitrou and Gregory P. Smith.) |
|
2997 |
|
2998 * Importing modules simultaneously in two different threads no longer |
|
2999 deadlocks; it will now raise an :exc:`ImportError`. A new API |
|
3000 function, :cfunc:`PyImport_ImportModuleNoBlock`, will look for a |
|
3001 module in ``sys.modules`` first, then try to import it after |
|
3002 acquiring an import lock. If the import lock is held by another |
|
3003 thread, an :exc:`ImportError` is raised. |
|
3004 (Contributed by Christian Heimes.) |
|
3005 |
|
3006 * Several functions return information about the platform's |
|
3007 floating-point support. :cfunc:`PyFloat_GetMax` returns |
|
3008 the maximum representable floating point value, |
|
3009 and :cfunc:`PyFloat_GetMin` returns the minimum |
|
3010 positive value. :cfunc:`PyFloat_GetInfo` returns an object |
|
3011 containing more information from the :file:`float.h` file, such as |
|
3012 ``"mant_dig"`` (number of digits in the mantissa), ``"epsilon"`` |
|
3013 (smallest difference between 1.0 and the next largest value |
|
3014 representable), and several others. |
|
3015 (Contributed by Christian Heimes; :issue:`1534`.) |
|
3016 |
|
3017 * C functions and methods that use |
|
3018 :cfunc:`PyComplex_AsCComplex` will now accept arguments that |
|
3019 have a :meth:`__complex__` method. In particular, the functions in the |
|
3020 :mod:`cmath` module will now accept objects with this method. |
|
3021 This is a backport of a Python 3.0 change. |
|
3022 (Contributed by Mark Dickinson; :issue:`1675423`.) |
|
3023 |
|
3024 * Python's C API now includes two functions for case-insensitive string |
|
3025 comparisons, ``PyOS_stricmp(char*, char*)`` |
|
3026 and ``PyOS_strnicmp(char*, char*, Py_ssize_t)``. |
|
3027 (Contributed by Christian Heimes; :issue:`1635`.) |
|
3028 |
|
3029 * Many C extensions define their own little macro for adding |
|
3030 integers and strings to the module's dictionary in the |
|
3031 ``init*`` function. Python 2.6 finally defines standard macros |
|
3032 for adding values to a module, :cmacro:`PyModule_AddStringMacro` |
|
3033 and :cmacro:`PyModule_AddIntMacro()`. (Contributed by |
|
3034 Christian Heimes.) |
|
3035 |
|
3036 * Some macros were renamed in both 3.0 and 2.6 to make it clearer that |
|
3037 they are macros, |
|
3038 not functions. :cmacro:`Py_Size()` became :cmacro:`Py_SIZE()`, |
|
3039 :cmacro:`Py_Type()` became :cmacro:`Py_TYPE()`, and |
|
3040 :cmacro:`Py_Refcnt()` became :cmacro:`Py_REFCNT()`. |
|
3041 The mixed-case macros are still available |
|
3042 in Python 2.6 for backward compatibility. |
|
3043 (:issue:`1629`) |
|
3044 |
|
3045 * Distutils now places C extensions it builds in a |
|
3046 different directory when running on a debug version of Python. |
|
3047 (Contributed by Collin Winter; :issue:`1530959`.) |
|
3048 |
|
3049 * Several basic data types, such as integers and strings, maintain |
|
3050 internal free lists of objects that can be re-used. The data |
|
3051 structures for these free lists now follow a naming convention: the |
|
3052 variable is always named ``free_list``, the counter is always named |
|
3053 ``numfree``, and a macro ``Py<typename>_MAXFREELIST`` is |
|
3054 always defined. |
|
3055 |
|
3056 * A new Makefile target, "make patchcheck", prepares the Python source tree |
|
3057 for making a patch: it fixes trailing whitespace in all modified |
|
3058 ``.py`` files, checks whether the documentation has been changed, |
|
3059 and reports whether the :file:`Misc/ACKS` and :file:`Misc/NEWS` files |
|
3060 have been updated. |
|
3061 (Contributed by Brett Cannon.) |
|
3062 |
|
3063 Another new target, "make profile-opt", compiles a Python binary |
|
3064 using GCC's profile-guided optimization. It compiles Python with |
|
3065 profiling enabled, runs the test suite to obtain a set of profiling |
|
3066 results, and then compiles using these results for optimization. |
|
3067 (Contributed by Gregory P. Smith.) |
|
3068 |
|
3069 .. ====================================================================== |
|
3070 |
|
3071 Port-Specific Changes: Windows |
|
3072 ----------------------------------- |
|
3073 |
|
3074 * The support for Windows 95, 98, ME and NT4 has been dropped. |
|
3075 Python 2.6 requires at least Windows 2000 SP4. |
|
3076 |
|
3077 * The new default compiler on Windows is Visual Studio 2008 (version |
|
3078 9.0). The build directories for Visual Studio 2003 (version 7.1) and |
|
3079 2005 (version 8.0) were moved into the PC/ directory. The new |
|
3080 :file:`PCbuild` directory supports cross compilation for X64, debug |
|
3081 builds and Profile Guided Optimization (PGO). PGO builds are roughly |
|
3082 10% faster than normal builds. (Contributed by Christian Heimes |
|
3083 with help from Amaury Forgeot d'Arc and Martin von Loewis.) |
|
3084 |
|
3085 * The :mod:`msvcrt` module now supports |
|
3086 both the normal and wide char variants of the console I/O |
|
3087 API. The :func:`getwch` function reads a keypress and returns a Unicode |
|
3088 value, as does the :func:`getwche` function. The :func:`putwch` function |
|
3089 takes a Unicode character and writes it to the console. |
|
3090 (Contributed by Christian Heimes.) |
|
3091 |
|
3092 * :func:`os.path.expandvars` will now expand environment variables in |
|
3093 the form "%var%", and "~user" will be expanded into the user's home |
|
3094 directory path. (Contributed by Josiah Carlson; :issue:`957650`.) |
|
3095 |
|
3096 * The :mod:`socket` module's socket objects now have an |
|
3097 :meth:`ioctl` method that provides a limited interface to the |
|
3098 :cfunc:`WSAIoctl` system interface. |
|
3099 |
|
3100 * The :mod:`_winreg` module now has a function, |
|
3101 :func:`ExpandEnvironmentStrings`, |
|
3102 that expands environment variable references such as ``%NAME%`` |
|
3103 in an input string. The handle objects provided by this |
|
3104 module now support the context protocol, so they can be used |
|
3105 in :keyword:`with` statements. (Contributed by Christian Heimes.) |
|
3106 |
|
3107 :mod:`_winreg` also has better support for x64 systems, |
|
3108 exposing the :func:`DisableReflectionKey`, :func:`EnableReflectionKey`, |
|
3109 and :func:`QueryReflectionKey` functions, which enable and disable |
|
3110 registry reflection for 32-bit processes running on 64-bit systems. |
|
3111 (:issue:`1753245`) |
|
3112 |
|
3113 * The :mod:`msilib` module's :class:`Record` object |
|
3114 gained :meth:`GetInteger` and :meth:`GetString` methods that |
|
3115 return field values as an integer or a string. |
|
3116 (Contributed by Floris Bruynooghe; :issue:`2125`.) |
|
3117 |
|
3118 .. ====================================================================== |
|
3119 |
|
3120 Port-Specific Changes: Mac OS X |
|
3121 ----------------------------------- |
|
3122 |
|
3123 * When compiling a framework build of Python, you can now specify the |
|
3124 framework name to be used by providing the |
|
3125 :option:`--with-framework-name=` option to the |
|
3126 :program:`configure` script. |
|
3127 |
|
3128 * The :mod:`macfs` module has been removed. This in turn required the |
|
3129 :func:`macostools.touched` function to be removed because it depended on the |
|
3130 :mod:`macfs` module. (:issue:`1490190`) |
|
3131 |
|
3132 * Many other Mac OS modules have been deprecated and will removed in |
|
3133 Python 3.0: |
|
3134 :mod:`_builtinSuites`, |
|
3135 :mod:`aepack`, |
|
3136 :mod:`aetools`, |
|
3137 :mod:`aetypes`, |
|
3138 :mod:`applesingle`, |
|
3139 :mod:`appletrawmain`, |
|
3140 :mod:`appletrunner`, |
|
3141 :mod:`argvemulator`, |
|
3142 :mod:`Audio_mac`, |
|
3143 :mod:`autoGIL`, |
|
3144 :mod:`Carbon`, |
|
3145 :mod:`cfmfile`, |
|
3146 :mod:`CodeWarrior`, |
|
3147 :mod:`ColorPicker`, |
|
3148 :mod:`EasyDialogs`, |
|
3149 :mod:`Explorer`, |
|
3150 :mod:`Finder`, |
|
3151 :mod:`FrameWork`, |
|
3152 :mod:`findertools`, |
|
3153 :mod:`ic`, |
|
3154 :mod:`icglue`, |
|
3155 :mod:`icopen`, |
|
3156 :mod:`macerrors`, |
|
3157 :mod:`MacOS`, |
|
3158 :mod:`macfs`, |
|
3159 :mod:`macostools`, |
|
3160 :mod:`macresource`, |
|
3161 :mod:`MiniAEFrame`, |
|
3162 :mod:`Nav`, |
|
3163 :mod:`Netscape`, |
|
3164 :mod:`OSATerminology`, |
|
3165 :mod:`pimp`, |
|
3166 :mod:`PixMapWrapper`, |
|
3167 :mod:`StdSuites`, |
|
3168 :mod:`SystemEvents`, |
|
3169 :mod:`Terminal`, and |
|
3170 :mod:`terminalcommand`. |
|
3171 |
|
3172 .. ====================================================================== |
|
3173 |
|
3174 Port-Specific Changes: IRIX |
|
3175 ----------------------------------- |
|
3176 |
|
3177 A number of old IRIX-specific modules were deprecated and will |
|
3178 be removed in Python 3.0: |
|
3179 :mod:`al` and :mod:`AL`, |
|
3180 :mod:`cd`, |
|
3181 :mod:`cddb`, |
|
3182 :mod:`cdplayer`, |
|
3183 :mod:`CL` and :mod:`cl`, |
|
3184 :mod:`DEVICE`, |
|
3185 :mod:`ERRNO`, |
|
3186 :mod:`FILE`, |
|
3187 :mod:`FL` and :mod:`fl`, |
|
3188 :mod:`flp`, |
|
3189 :mod:`fm`, |
|
3190 :mod:`GET`, |
|
3191 :mod:`GLWS`, |
|
3192 :mod:`GL` and :mod:`gl`, |
|
3193 :mod:`IN`, |
|
3194 :mod:`IOCTL`, |
|
3195 :mod:`jpeg`, |
|
3196 :mod:`panelparser`, |
|
3197 :mod:`readcd`, |
|
3198 :mod:`SV` and :mod:`sv`, |
|
3199 :mod:`torgb`, |
|
3200 :mod:`videoreader`, and |
|
3201 :mod:`WAIT`. |
|
3202 |
|
3203 .. ====================================================================== |
|
3204 |
|
3205 |
|
3206 Porting to Python 2.6 |
|
3207 ===================== |
|
3208 |
|
3209 This section lists previously described changes and other bugfixes |
|
3210 that may require changes to your code: |
|
3211 |
|
3212 * Classes that aren't supposed to be hashable should |
|
3213 set ``__hash__ = None`` in their definitions to indicate |
|
3214 the fact. |
|
3215 |
|
3216 * The :meth:`__init__` method of :class:`collections.deque` |
|
3217 now clears any existing contents of the deque |
|
3218 before adding elements from the iterable. This change makes the |
|
3219 behavior match ``list.__init__()``. |
|
3220 |
|
3221 * :meth:`object.__init__` previously accepted arbitrary arguments and |
|
3222 keyword arguments, ignoring them. In Python 2.6, this is no longer |
|
3223 allowed and will result in a :exc:`TypeError`. This will affect |
|
3224 :meth:`__init__` methods that end up calling the corresponding |
|
3225 method on :class:`object` (perhaps through using :func:`super`). |
|
3226 See :issue:`1683368` for discussion. |
|
3227 |
|
3228 * The :class:`Decimal` constructor now accepts leading and trailing |
|
3229 whitespace when passed a string. Previously it would raise an |
|
3230 :exc:`InvalidOperation` exception. On the other hand, the |
|
3231 :meth:`create_decimal` method of :class:`Context` objects now |
|
3232 explicitly disallows extra whitespace, raising a |
|
3233 :exc:`ConversionSyntax` exception. |
|
3234 |
|
3235 * Due to an implementation accident, if you passed a file path to |
|
3236 the built-in :func:`__import__` function, it would actually import |
|
3237 the specified file. This was never intended to work, however, and |
|
3238 the implementation now explicitly checks for this case and raises |
|
3239 an :exc:`ImportError`. |
|
3240 |
|
3241 * C API: the :cfunc:`PyImport_Import` and :cfunc:`PyImport_ImportModule` |
|
3242 functions now default to absolute imports, not relative imports. |
|
3243 This will affect C extensions that import other modules. |
|
3244 |
|
3245 * C API: extension data types that shouldn't be hashable |
|
3246 should define their ``tp_hash`` slot to |
|
3247 :cfunc:`PyObject_HashNotImplemented`. |
|
3248 |
|
3249 * The :mod:`socket` module exception :exc:`socket.error` now inherits |
|
3250 from :exc:`IOError`. Previously it wasn't a subclass of |
|
3251 :exc:`StandardError` but now it is, through :exc:`IOError`. |
|
3252 (Implemented by Gregory P. Smith; :issue:`1706815`.) |
|
3253 |
|
3254 * The :mod:`xmlrpclib` module no longer automatically converts |
|
3255 :class:`datetime.date` and :class:`datetime.time` to the |
|
3256 :class:`xmlrpclib.DateTime` type; the conversion semantics were |
|
3257 not necessarily correct for all applications. Code using |
|
3258 :mod:`xmlrpclib` should convert :class:`date` and :class:`time` |
|
3259 instances. (:issue:`1330538`) |
|
3260 |
|
3261 * (3.0-warning mode) The :class:`Exception` class now warns |
|
3262 when accessed using slicing or index access; having |
|
3263 :class:`Exception` behave like a tuple is being phased out. |
|
3264 |
|
3265 * (3.0-warning mode) inequality comparisons between two dictionaries |
|
3266 or two objects that don't implement comparison methods are reported |
|
3267 as warnings. ``dict1 == dict2`` still works, but ``dict1 < dict2`` |
|
3268 is being phased out. |
|
3269 |
|
3270 Comparisons between cells, which are an implementation detail of Python's |
|
3271 scoping rules, also cause warnings because such comparisons are forbidden |
|
3272 entirely in 3.0. |
|
3273 |
|
3274 .. ====================================================================== |
|
3275 |
|
3276 |
|
3277 .. _26acks: |
|
3278 |
|
3279 Acknowledgements |
|
3280 ================ |
|
3281 |
|
3282 The author would like to thank the following people for offering |
|
3283 suggestions, corrections and assistance with various drafts of this |
|
3284 article: Georg Brandl, Steve Brown, Nick Coghlan, Ralph Corderoy, |
|
3285 Jim Jewett, Kent Johnson, Chris Lambacher, Martin Michlmayr, |
|
3286 Antoine Pitrou, Brian Warner. |
|
3287 |