Changeset 388 for python/vendor/current/Doc/whatsnew
- Timestamp:
- Mar 19, 2014, 11:11:30 AM (11 years ago)
- Location:
- python/vendor/current/Doc/whatsnew
- Files:
-
- 1 added
- 8 edited
Legend:
- Unmodified
- Added
- Removed
-
python/vendor/current/Doc/whatsnew/2.0.rst
r2 r388 657 657 arguments accepted by some methods. Some methods would take multiple arguments 658 658 and treat them as a tuple, particularly various list methods such as 659 :meth:` .append` and :meth:`.insert`. In earlier versions of Python, if ``L`` is659 :meth:`append` and :meth:`insert`. In earlier versions of Python, if ``L`` is 660 660 a list, ``L.append( 1,2 )`` appends the tuple ``(1,2)`` to the list. In Python 661 661 2.0 this causes a :exc:`TypeError` exception to be raised, with the message: -
python/vendor/current/Doc/whatsnew/2.1.rst
r2 r388 732 732 733 733 For a fuller discussion of the line I/O changes, see the python-dev summary for 734 January 1-15, 2001 at http://www.python.org/dev/summary/2001-01-1 .html.734 January 1-15, 2001 at http://www.python.org/dev/summary/2001-01-1/. 735 735 736 736 * A new method, :meth:`popitem`, was added to dictionaries to enable -
python/vendor/current/Doc/whatsnew/2.2.rst
r2 r388 31 31 32 32 33 .. see also (now defunct)33 .. see also, now defunct 34 34 35 35 http://www.unixreview.com/documents/s=1356/urm0109h/0109h.htm … … 451 451 return a new iterator for the object; if the object is its own iterator, this 452 452 method can just return ``self``. In particular, iterators will usually be their 453 own iterators. Extension types implemented in C can implement a : attr:`tp_iter`453 own iterators. Extension types implemented in C can implement a :c:member:`~PyTypeObject.tp_iter` 454 454 function in order to return an iterator, and extension types that want to behave 455 as iterators can define a : attr:`tp_iternext` function.455 as iterators can define a :c:member:`~PyTypeObject.tp_iternext` function. 456 456 457 457 So, after all this, what do iterators actually do? They have one required … … 479 479 expects something for which :func:`iter` will return an iterator. For backward 480 480 compatibility and convenience, an iterator is automatically constructed for 481 sequences that don't implement :meth:`__iter__` or a : attr:`tp_iter` slot, so481 sequences that don't implement :meth:`__iter__` or a :c:member:`~PyTypeObject.tp_iter` slot, so 482 482 ``for i in [1,2,3]`` will still work. Wherever the Python interpreter loops 483 483 over a sequence, it's been changed to use the iterator protocol. This means you … … 755 755 * Classes can define methods called :meth:`__truediv__` and :meth:`__floordiv__` 756 756 to overload the two division operators. At the C level, there are also slots in 757 the :c type:`PyNumberMethods` structure so extension types can define the two757 the :c:type:`PyNumberMethods` structure so extension types can define the two 758 758 operators. 759 759 … … 984 984 985 985 * Two new format characters were added to the :mod:`struct` module for 64-bit 986 integers on platforms that support the C :c type:`long long` type. ``q`` is for986 integers on platforms that support the C :c:type:`long long` type. ``q`` is for 987 987 a signed 64-bit integer, and ``Q`` is for an unsigned one. The value is 988 988 returned in Python's long integer type. (Contributed by Tim Peters.) … … 1058 1058 of profiling and tracing. This will be of interest to authors of development 1059 1059 environments for Python. Two new C functions were added to Python's API, 1060 :c func:`PyEval_SetProfile` and :cfunc:`PyEval_SetTrace`. The existing1060 :c:func:`PyEval_SetProfile` and :c:func:`PyEval_SetTrace`. The existing 1061 1061 :func:`sys.setprofile` and :func:`sys.settrace` functions still exist, and have 1062 1062 simply been changed to use the new C-level interface. (Contributed by Fred L. … … 1064 1064 1065 1065 * Another low-level API, primarily of interest to implementors of Python 1066 debuggers and development tools, was added. :c func:`PyInterpreterState_Head` and1067 :c func:`PyInterpreterState_Next` let a caller walk through all the existing1068 interpreter objects; :c func:`PyInterpreterState_ThreadHead` and1069 :c func:`PyThreadState_Next` allow looping over all the thread states for a given1066 debuggers and development tools, was added. :c:func:`PyInterpreterState_Head` and 1067 :c:func:`PyInterpreterState_Next` let a caller walk through all the existing 1068 interpreter objects; :c:func:`PyInterpreterState_ThreadHead` and 1069 :c:func:`PyThreadState_Next` allow looping over all the thread states for a given 1070 1070 interpreter. (Contributed by David Beazley.) 1071 1071 … … 1079 1079 To upgrade an extension module to the new API, perform the following steps: 1080 1080 1081 * Rename :c func:`Py_TPFLAGS_GC` to :cfunc:`PyTPFLAGS_HAVE_GC`.1082 1083 * Use :c func:`PyObject_GC_New` or :cfunc:`PyObject_GC_NewVar` to allocate1084 objects, and :c func:`PyObject_GC_Del` to deallocate them.1085 1086 * Rename :c func:`PyObject_GC_Init` to :cfunc:`PyObject_GC_Track` and1087 :c func:`PyObject_GC_Fini` to :cfunc:`PyObject_GC_UnTrack`.1088 1089 * Remove :c func:`PyGC_HEAD_SIZE` from object size calculations.1090 1091 * Remove calls to :c func:`PyObject_AS_GC` and :cfunc:`PyObject_FROM_GC`.1092 1093 * A new ``et`` format sequence was added to :c func:`PyArg_ParseTuple`; ``et``1081 * Rename :c:func:`Py_TPFLAGS_GC` to :c:func:`PyTPFLAGS_HAVE_GC`. 1082 1083 * Use :c:func:`PyObject_GC_New` or :c:func:`PyObject_GC_NewVar` to allocate 1084 objects, and :c:func:`PyObject_GC_Del` to deallocate them. 1085 1086 * Rename :c:func:`PyObject_GC_Init` to :c:func:`PyObject_GC_Track` and 1087 :c:func:`PyObject_GC_Fini` to :c:func:`PyObject_GC_UnTrack`. 1088 1089 * Remove :c:func:`PyGC_HEAD_SIZE` from object size calculations. 1090 1091 * Remove calls to :c:func:`PyObject_AS_GC` and :c:func:`PyObject_FROM_GC`. 1092 1093 * A new ``et`` format sequence was added to :c:func:`PyArg_ParseTuple`; ``et`` 1094 1094 takes both a parameter and an encoding name, and converts the parameter to the 1095 1095 given encoding if the parameter turns out to be a Unicode string, or leaves it … … 1100 1100 support on Windows described in the following section.) 1101 1101 1102 * A different argument parsing function, :c func:`PyArg_UnpackTuple`, has been1102 * A different argument parsing function, :c:func:`PyArg_UnpackTuple`, has been 1103 1103 added that's simpler and presumably faster. Instead of specifying a format 1104 1104 string, the caller simply gives the minimum and maximum number of arguments 1105 expected, and a set of pointers to :c type:`PyObject\*` variables that will be1105 expected, and a set of pointers to :c:type:`PyObject\*` variables that will be 1106 1106 filled in with argument values. 1107 1107 … … 1112 1112 :const:`METH_OLDARGS` style of writing C methods is now officially deprecated. 1113 1113 1114 * Two new wrapper functions, :c func:`PyOS_snprintf` and :cfunc:`PyOS_vsnprintf`1114 * Two new wrapper functions, :c:func:`PyOS_snprintf` and :c:func:`PyOS_vsnprintf` 1115 1115 were added to provide cross-platform implementations for the relatively new 1116 :c func:`snprintf` and :cfunc:`vsnprintf` C lib APIs. In contrast to the standard1117 :c func:`sprintf` and :cfunc:`vsprintf` functions, the Python versions check the1116 :c:func:`snprintf` and :c:func:`vsnprintf` C lib APIs. In contrast to the standard 1117 :c:func:`sprintf` and :c:func:`vsprintf` functions, the Python versions check the 1118 1118 bounds of the buffer used to protect against buffer overruns. (Contributed by 1119 1119 M.-A. Lemburg.) 1120 1120 1121 * The :c func:`_PyTuple_Resize` function has lost an unused parameter, so now it1121 * The :c:func:`_PyTuple_Resize` function has lost an unused parameter, so now it 1122 1122 takes 2 parameters instead of 3. The third argument was never used, and can 1123 1123 simply be discarded when porting code from earlier versions to Python 2.2. … … 1220 1220 :meth:`tolist` method and the :attr:`start`, :attr:`stop`, and :attr:`step` 1221 1221 attributes are also being deprecated. At the C level, the fourth argument to 1222 the :c func:`PyRange_New` function, ``repeat``, has also been deprecated.1222 the :c:func:`PyRange_New` function, ``repeat``, has also been deprecated. 1223 1223 1224 1224 * There were a bunch of patches to the dictionary implementation, mostly to fix … … 1243 1243 in case they're also usable as modules. (Implemented by David Bolen.) 1244 1244 1245 * On platforms where Python uses the C :c func:`dlopen` function to load1246 extension modules, it's now possible to set the flags used by :c func:`dlopen`1245 * On platforms where Python uses the C :c:func:`dlopen` function to load 1246 extension modules, it's now possible to set the flags used by :c:func:`dlopen` 1247 1247 using the :func:`sys.getdlopenflags` and :func:`sys.setdlopenflags` functions. 1248 1248 (Contributed by Bram Stolk.) -
python/vendor/current/Doc/whatsnew/2.3.rst
r2 r388 367 367 368 368 369 .. index:: 370 single: universal newlines; What's new 371 369 372 PEP 278: Universal Newline Support 370 373 ================================== … … 377 380 two-character sequence of a carriage return plus a newline. 378 381 379 Python's file objects can now support end of line conventions other than the one380 followed by the platform on which Python is running. Opening a file with the 381 mode ``'U'`` or ``'rU'`` will open a file for reading in universal newline mode. 382 All three line ending conventions will be translated to a ``'\n'`` in the 383 strings returned by the various file methods such as :meth:`read` and 384 :meth:`read line`.382 Python's file objects can now support end of line conventions other than the 383 one followed by the platform on which Python is running. Opening a file with 384 the mode ``'U'`` or ``'rU'`` will open a file for reading in :term:`universal 385 newlines` mode. All three line ending conventions will be translated to a 386 ``'\n'`` in the strings returned by the various file methods such as 387 :meth:`read` and :meth:`readline`. 385 388 386 389 Universal newline support is also used when importing modules and when executing … … 1799 1802 Pymalloc, a specialized object allocator written by Vladimir Marangozov, was a 1800 1803 feature added to Python 2.1. Pymalloc is intended to be faster than the system 1801 :c func:`malloc` and to have less memory overhead for allocation patterns typical1802 of Python programs. The allocator uses C's :c func:`malloc` function to get large1804 :c:func:`malloc` and to have less memory overhead for allocation patterns typical 1805 of Python programs. The allocator uses C's :c:func:`malloc` function to get large 1803 1806 pools of memory and then fulfills smaller memory requests from these pools. 1804 1807 … … 1816 1819 There's one particularly common error that causes problems. There are a number 1817 1820 of memory allocation functions in Python's C API that have previously just been 1818 aliases for the C library's :c func:`malloc` and :cfunc:`free`, meaning that if1821 aliases for the C library's :c:func:`malloc` and :c:func:`free`, meaning that if 1819 1822 you accidentally called mismatched functions the error wouldn't be noticeable. 1820 1823 When the object allocator is enabled, these functions aren't aliases of 1821 :c func:`malloc` and :cfunc:`free` any more, and calling the wrong function to1824 :c:func:`malloc` and :c:func:`free` any more, and calling the wrong function to 1822 1825 free memory may get you a core dump. For example, if memory was allocated using 1823 :c func:`PyObject_Malloc`, it has to be freed using :cfunc:`PyObject_Free`, not1824 :c func:`free`. A few modules included with Python fell afoul of this and had to1826 :c:func:`PyObject_Malloc`, it has to be freed using :c:func:`PyObject_Free`, not 1827 :c:func:`free`. A few modules included with Python fell afoul of this and had to 1825 1828 be fixed; doubtless there are more third-party modules that will have the same 1826 1829 problem. … … 1833 1836 1834 1837 * To allocate and free an undistinguished chunk of memory use the "raw memory" 1835 family: :c func:`PyMem_Malloc`, :cfunc:`PyMem_Realloc`, and :cfunc:`PyMem_Free`.1838 family: :c:func:`PyMem_Malloc`, :c:func:`PyMem_Realloc`, and :c:func:`PyMem_Free`. 1836 1839 1837 1840 * The "object memory" family is the interface to the pymalloc facility described 1838 1841 above and is biased towards a large number of "small" allocations: 1839 :c func:`PyObject_Malloc`, :cfunc:`PyObject_Realloc`, and :cfunc:`PyObject_Free`.1842 :c:func:`PyObject_Malloc`, :c:func:`PyObject_Realloc`, and :c:func:`PyObject_Free`. 1840 1843 1841 1844 * To allocate and free Python objects, use the "object" family 1842 :c func:`PyObject_New`, :cfunc:`PyObject_NewVar`, and :cfunc:`PyObject_Del`.1845 :c:func:`PyObject_New`, :c:func:`PyObject_NewVar`, and :c:func:`PyObject_Del`. 1843 1846 1844 1847 Thanks to lots of work by Tim Peters, pymalloc in 2.3 also provides debugging … … 1879 1882 Python's :program:`configure` script. (Contributed by Ondrej Palkovsky.) 1880 1883 1881 * The :c macro:`DL_EXPORT` and :cmacro:`DL_IMPORT` macros are now deprecated.1884 * The :c:macro:`DL_EXPORT` and :c:macro:`DL_IMPORT` macros are now deprecated. 1882 1885 Initialization functions for Python extension modules should now be declared 1883 using the new macro :c macro:`PyMODINIT_FUNC`, while the Python core will1884 generally use the :c macro:`PyAPI_FUNC` and :cmacro:`PyAPI_DATA` macros.1886 using the new macro :c:macro:`PyMODINIT_FUNC`, while the Python core will 1887 generally use the :c:macro:`PyAPI_FUNC` and :c:macro:`PyAPI_DATA` macros. 1885 1888 1886 1889 * The interpreter can be compiled without any docstrings for the built-in … … 1890 1893 by Gustavo Niemeyer.) 1891 1894 1892 * The :c func:`PyArg_NoArgs` macro is now deprecated, and code that uses it1895 * The :c:func:`PyArg_NoArgs` macro is now deprecated, and code that uses it 1893 1896 should be changed. For Python 2.2 and later, the method definition table can 1894 1897 specify the :const:`METH_NOARGS` flag, signalling that there are no arguments, … … 1897 1900 "")`` instead, but this will be slower than using :const:`METH_NOARGS`. 1898 1901 1899 * :c func:`PyArg_ParseTuple` accepts new format characters for various sizes of1900 unsigned integers: ``B`` for :c type:`unsigned char`, ``H`` for :ctype:`unsigned1901 short int`, ``I`` for :c type:`unsigned int`, and ``K`` for :ctype:`unsigned1902 * :c:func:`PyArg_ParseTuple` accepts new format characters for various sizes of 1903 unsigned integers: ``B`` for :c:type:`unsigned char`, ``H`` for :c:type:`unsigned 1904 short int`, ``I`` for :c:type:`unsigned int`, and ``K`` for :c:type:`unsigned 1902 1905 long long`. 1903 1906 1904 * A new function, :c func:`PyObject_DelItemString(mapping, char \*key)` was added1907 * A new function, :c:func:`PyObject_DelItemString(mapping, char \*key)` was added 1905 1908 as shorthand for ``PyObject_DelItem(mapping, PyString_New(key))``. 1906 1909 … … 1912 1915 * It's now possible to define class and static methods for a C extension type by 1913 1916 setting either the :const:`METH_CLASS` or :const:`METH_STATIC` flags in a 1914 method's :c type:`PyMethodDef` structure.1917 method's :c:type:`PyMethodDef` structure. 1915 1918 1916 1919 * Python now includes a copy of the Expat XML parser's source code, removing any -
python/vendor/current/Doc/whatsnew/2.4.rst
r2 r388 412 412 subprocess and the parent. 413 413 414 .. index:: 415 single: universal newlines; What's new 416 414 417 The constructor has a number of handy options: 415 418 … … 425 428 426 429 * *universal_newlines* opens the child's input and output using Python's 427 universal newlinefeature.430 :term:`universal newlines` feature. 428 431 429 432 Once you've created the :class:`Popen` instance, you can call its :meth:`wait` … … 471 474 472 475 Python has always supported floating-point (FP) numbers, based on the underlying 473 C :c type:`double` type, as a data type. However, while most programming476 C :c:type:`double` type, as a data type. However, while most programming 474 477 languages provide a floating-point type, many people (even programmers) are 475 478 unaware that floating-point numbers don't represent certain decimal fractions … … 500 503 501 504 Modern systems usually provide floating-point support that conforms to a 502 standard called IEEE 754. C's :c type:`double` type is usually implemented as a505 standard called IEEE 754. C's :c:type:`double` type is usually implemented as a 503 506 64-bit IEEE 754 number, which uses 52 bits of space for the mantissa. This 504 507 means that numbers can only be specified to 52 bits of precision. If you're … … 738 741 functions in Python's implementation required that the numeric locale remain set 739 742 to the ``'C'`` locale. Often this was because the code was using the C 740 library's :c func:`atof` function.743 library's :c:func:`atof` function. 741 744 742 745 Not setting the numeric locale caused trouble for extensions that used third- … … 748 751 API that perform ASCII-only conversions, ignoring the locale setting: 749 752 750 * :c func:`PyOS_ascii_strtod(str, ptr)` and :cfunc:`PyOS_ascii_atof(str, ptr)`751 both convert a string to a C :c type:`double`.752 753 * :c func:`PyOS_ascii_formatd(buffer, buf_len, format, d)` converts a754 :c type:`double` to an ASCII string.753 * :c:func:`PyOS_ascii_strtod(str, ptr)` and :c:func:`PyOS_ascii_atof(str, ptr)` 754 both convert a string to a C :c:type:`double`. 755 756 * :c:func:`PyOS_ascii_formatd(buffer, buf_len, format, d)` converts a 757 :c:type:`double` to an ASCII string. 755 758 756 759 The code for these functions came from the GLib library … … 940 943 space efficiency. Appending and popping from lists now runs faster due to more 941 944 efficient code paths and less frequent use of the underlying system 942 :c func:`realloc`. List comprehensions also benefit. :meth:`list.extend` was945 :c:func:`realloc`. List comprehensions also benefit. :meth:`list.extend` was 943 946 also optimized and no longer converts its argument into a temporary list before 944 947 extending the base list. (Contributed by Raymond Hettinger.) … … 949 952 950 953 * The methods :meth:`list.__getitem__`, :meth:`dict.__getitem__`, and 951 :meth:`dict.__contains__` are arenow implemented as :class:`method_descriptor`954 :meth:`dict.__contains__` are now implemented as :class:`method_descriptor` 952 955 objects rather than :class:`wrapper_descriptor` objects. This form of access 953 956 doubles their performance and makes them more suitable for use as arguments to … … 1068 1071 3.0 version of the package uses a new incremental parser for MIME messages, 1069 1072 available in the :mod:`email.FeedParser` module. The new parser doesn't require 1070 reading the entire message into memory, and doesn't throwexceptions if a1073 reading the entire message into memory, and doesn't raise exceptions if a 1071 1074 message is malformed; instead it records any problems in the :attr:`defect` 1072 1075 attribute of the message. (Developed by Anthony Baxter, Barry Warsaw, Thomas … … 1447 1450 1448 1451 * Three new convenience macros were added for common return values from 1449 extension functions: :c macro:`Py_RETURN_NONE`, :cmacro:`Py_RETURN_TRUE`, and1450 :c macro:`Py_RETURN_FALSE`. (Contributed by Brett Cannon.)1451 1452 * Another new macro, :c macro:`Py_CLEAR(obj)`, decreases the reference count of1452 extension functions: :c:macro:`Py_RETURN_NONE`, :c:macro:`Py_RETURN_TRUE`, and 1453 :c:macro:`Py_RETURN_FALSE`. (Contributed by Brett Cannon.) 1454 1455 * Another new macro, :c:macro:`Py_CLEAR(obj)`, decreases the reference count of 1453 1456 *obj* and sets *obj* to the null pointer. (Contributed by Jim Fulton.) 1454 1457 1455 * A new function, :c func:`PyTuple_Pack(N, obj1, obj2, ..., objN)`, constructs1458 * A new function, :c:func:`PyTuple_Pack(N, obj1, obj2, ..., objN)`, constructs 1456 1459 tuples from a variable length argument list of Python objects. (Contributed by 1457 1460 Raymond Hettinger.) 1458 1461 1459 * A new function, :c func:`PyDict_Contains(d, k)`, implements fast dictionary1462 * A new function, :c:func:`PyDict_Contains(d, k)`, implements fast dictionary 1460 1463 lookups without masking exceptions raised during the look-up process. 1461 1464 (Contributed by Raymond Hettinger.) 1462 1465 1463 * The :c macro:`Py_IS_NAN(X)` macro returns 1 if its float or double argument1466 * The :c:macro:`Py_IS_NAN(X)` macro returns 1 if its float or double argument 1464 1467 *X* is a NaN. (Contributed by Tim Peters.) 1465 1468 1466 1469 * C code can avoid unnecessary locking by using the new 1467 :c func:`PyEval_ThreadsInitialized` function to tell if any thread operations1470 :c:func:`PyEval_ThreadsInitialized` function to tell if any thread operations 1468 1471 have been performed. If this function returns false, no lock operations are 1469 1472 needed. (Contributed by Nick Coghlan.) 1470 1473 1471 * A new function, :c func:`PyArg_VaParseTupleAndKeywords`, is the same as1472 :c func:`PyArg_ParseTupleAndKeywords` but takes a :ctype:`va_list` instead of a1474 * A new function, :c:func:`PyArg_VaParseTupleAndKeywords`, is the same as 1475 :c:func:`PyArg_ParseTupleAndKeywords` but takes a :c:type:`va_list` instead of a 1473 1476 number of arguments. (Contributed by Greg Chapman.) 1474 1477 1475 1478 * A new method flag, :const:`METH_COEXISTS`, allows a function defined in slots 1476 to co-exist with a :c type:`PyCFunction` having the same name. This can halve1479 to co-exist with a :c:type:`PyCFunction` having the same name. This can halve 1477 1480 the access time for a method such as :meth:`set.__contains__`. (Contributed by 1478 1481 Raymond Hettinger.) … … 1488 1491 register". (Contributed by Jeremy Hylton.) 1489 1492 1490 * The :c type:`tracebackobject` type has been renamed to1491 :c type:`PyTracebackObject`.1493 * The :c:type:`tracebackobject` type has been renamed to 1494 :c:type:`PyTracebackObject`. 1492 1495 1493 1496 .. ====================================================================== … … 1556 1559 1557 1560 The author would like to thank the following people for offering suggestions, 1558 corrections and assistance with various drafts of this article: Koray Can, Hye-1559 Shik Chang, Michael Dyck, Raymond Hettinger, Brian Hurt, Hamish Lawson, Fredrik 1560 Lundh, Sean Reifschneider, Sadruddin Rejeb.1561 1561 corrections and assistance with various drafts of this article: Koray Can, 1562 Hye-Shik Chang, Michael Dyck, Raymond Hettinger, Brian Hurt, Hamish Lawson, 1563 Fredrik Lundh, Sean Reifschneider, Sadruddin Rejeb. 1564 -
python/vendor/current/Doc/whatsnew/2.5.rst
r2 r388 871 871 ======================================== 872 872 873 A wide-ranging change to Python's C API, using a new :c type:`Py_ssize_t` type874 definition instead of :c type:`int`, will permit the interpreter to handle more873 A wide-ranging change to Python's C API, using a new :c:type:`Py_ssize_t` type 874 definition instead of :c:type:`int`, will permit the interpreter to handle more 875 875 data on 64-bit platforms. This change doesn't affect Python's capacity on 32-bit 876 876 platforms. 877 877 878 Various pieces of the Python interpreter used C's :c type:`int` type to store878 Various pieces of the Python interpreter used C's :c:type:`int` type to store 879 879 sizes or counts; for example, the number of items in a list or tuple were stored 880 in an :c type:`int`. The C compilers for most 64-bit platforms still define881 :c type:`int` as a 32-bit type, so that meant that lists could only hold up to880 in an :c:type:`int`. The C compilers for most 64-bit platforms still define 881 :c:type:`int` as a 32-bit type, so that meant that lists could only hold up to 882 882 ``2**31 - 1`` = 2147483647 items. (There are actually a few different 883 883 programming models that 64-bit C compilers can use -- see 884 884 http://www.unix.org/version2/whatsnew/lp64_wp.html for a discussion -- but the 885 most commonly available model leaves :c type:`int` as 32 bits.)885 most commonly available model leaves :c:type:`int` as 32 bits.) 886 886 887 887 A limit of 2147483647 items doesn't really matter on a 32-bit platform because 888 888 you'll run out of memory before hitting the length limit. Each list item 889 889 requires space for a pointer, which is 4 bytes, plus space for a 890 :c type:`PyObject` representing the item. 2147483647\*4 is already more bytes890 :c:type:`PyObject` representing the item. 2147483647\*4 is already more bytes 891 891 than a 32-bit address space can contain. 892 892 … … 895 895 unreasonable that Python programmers might construct lists that large. 896 896 Therefore, the Python interpreter had to be changed to use some type other than 897 :c type:`int`, and this will be a 64-bit type on 64-bit platforms. The change897 :c:type:`int`, and this will be a 64-bit type on 64-bit platforms. The change 898 898 will cause incompatibilities on 64-bit machines, so it was deemed worth making 899 899 the transition now, while the number of 64-bit users is still relatively small. … … 903 903 This change most strongly affects authors of C extension modules. Python 904 904 strings and container types such as lists and tuples now use 905 :c type:`Py_ssize_t` to store their size. Functions such as906 :c func:`PyList_Size` now return :ctype:`Py_ssize_t`. Code in extension modules907 may therefore need to have some variables changed to :c type:`Py_ssize_t`.908 909 The :c func:`PyArg_ParseTuple` and :cfunc:`Py_BuildValue` functions have a new910 conversion code, ``n``, for :c type:`Py_ssize_t`. :cfunc:`PyArg_ParseTuple`'s911 ``s#`` and ``t#`` still output :c type:`int` by default, but you can define the912 macro :c macro:`PY_SSIZE_T_CLEAN` before including :file:`Python.h` to make913 them return :c type:`Py_ssize_t`.905 :c:type:`Py_ssize_t` to store their size. Functions such as 906 :c:func:`PyList_Size` now return :c:type:`Py_ssize_t`. Code in extension modules 907 may therefore need to have some variables changed to :c:type:`Py_ssize_t`. 908 909 The :c:func:`PyArg_ParseTuple` and :c:func:`Py_BuildValue` functions have a new 910 conversion code, ``n``, for :c:type:`Py_ssize_t`. :c:func:`PyArg_ParseTuple`'s 911 ``s#`` and ``t#`` still output :c:type:`int` by default, but you can define the 912 macro :c:macro:`PY_SSIZE_T_CLEAN` before including :file:`Python.h` to make 913 them return :c:type:`Py_ssize_t`. 914 914 915 915 :pep:`353` has a section on conversion guidelines that extension authors should … … 955 955 956 956 A corresponding :attr:`nb_index` slot was added to the C-level 957 :c type:`PyNumberMethods` structure to let C extensions implement this protocol.958 :c func:`PyNumber_Index(obj)` can be used in extension code to call the957 :c:type:`PyNumberMethods` structure to let C extensions implement this protocol. 958 :c:func:`PyNumber_Index(obj)` can be used in extension code to call the 959 959 :meth:`__index__` function and retrieve its result. 960 960 … … 1180 1180 1181 1181 * The :mod:`re` module got a 1 or 2% speedup by switching to Python's allocator 1182 functions instead of the system's :c func:`malloc` and :cfunc:`free`.1182 functions instead of the system's :c:func:`malloc` and :c:func:`free`. 1183 1183 (Contributed by Jack Diederich at the NeedForSpeed sprint.) 1184 1184 … … 1204 1204 1205 1205 * Importing now caches the paths tried, recording whether they exist or not so 1206 that the interpreter makes fewer :c func:`open` and :cfunc:`stat` calls on1206 that the interpreter makes fewer :c:func:`open` and :c:func:`stat` calls on 1207 1207 startup. (Contributed by Martin von Löwis and Georg Brandl.) 1208 1208 … … 1339 1339 .. XXX need to provide some more detail here 1340 1340 1341 .. index:: 1342 single: universal newlines; What's new 1343 1341 1344 * The :mod:`fileinput` module was made more flexible. Unicode filenames are now 1342 1345 supported, and a *mode* parameter that defaults to ``"r"`` was added to the 1343 :func:`input` function to allow opening files in binary or universal-newline 1344 mode. Another new parameter, *openhook*, lets you use a function other than 1345 :func:`open` to open the input files. Once you're iterating over the set of 1346 files, the :class:`FileInput` object's new :meth:`fileno` returns the file 1347 descriptor for the currently opened file. (Contributed by Georg Brandl.) 1346 :func:`input` function to allow opening files in binary or :term:`universal 1347 newlines` mode. Another new parameter, *openhook*, lets you use a function 1348 other than :func:`open` to open the input files. Once you're iterating over 1349 the set of files, the :class:`FileInput` object's new :meth:`fileno` returns 1350 the file descriptor for the currently opened file. (Contributed by Georg 1351 Brandl.) 1348 1352 1349 1353 * In the :mod:`gc` module, the new :func:`get_count` function returns a 3-tuple … … 1460 1464 On FreeBSD, the :func:`os.stat` function now returns times with nanosecond 1461 1465 resolution, and the returned object now has :attr:`st_gen` and 1462 :attr:`st_birthtime`. The :attr:`st_flags` memberis also available, if the1466 :attr:`st_birthtime`. The :attr:`st_flags` attribute is also available, if the 1463 1467 platform supports it. (Contributed by Antti Louko and Diego Pettenò.) 1464 1468 … … 1569 1573 1570 1574 This information is also available to C extensions via the 1571 :c func:`Py_GetBuildInfo` function that returns a string of build information1575 :c:func:`Py_GetBuildInfo` function that returns a string of build information 1572 1576 like this: ``"trunk:45355:45356M, Apr 13 2006, 07:42:19"``. (Contributed by 1573 1577 Barry Warsaw.) … … 1691 1695 1692 1696 Type constructors for the various C types are provided: :func:`c_int`, 1693 :func:`c_float`, :func:`c_double`, :func:`c_char_p` (equivalent to :c type:`char1697 :func:`c_float`, :func:`c_double`, :func:`c_char_p` (equivalent to :c:type:`char 1694 1698 \*`), and so forth. Unlike Python's types, the C versions are all mutable; you 1695 1699 can assign to their :attr:`value` attribute to change the wrapped value. Python … … 1721 1725 interpreter lock before calling a function, because the lock must be held when 1722 1726 calling into the interpreter's code. There's a :class:`py_object()` type 1723 constructor that will create a :c type:`PyObject \*` pointer. A simple usage::1727 constructor that will create a :c:type:`PyObject \*` pointer. A simple usage:: 1724 1728 1725 1729 import ctypes … … 1766 1770 1767 1771 ElementTree represents an XML document as a tree of element nodes. The text 1768 content of the document is stored as the :attr:` .text` and :attr:`.tail`1772 content of the document is stored as the :attr:`text` and :attr:`tail` 1769 1773 attributes of (This is one of the major differences between ElementTree and 1770 1774 the Document Object Model; in the DOM there are many different types of node, … … 2088 2092 2089 2093 * The largest change to the C API came from :pep:`353`, which modifies the 2090 interpreter to use a :c type:`Py_ssize_t` type definition instead of2091 :c type:`int`. See the earlier section :ref:`pep-353` for a discussion of this2094 interpreter to use a :c:type:`Py_ssize_t` type definition instead of 2095 :c:type:`int`. See the earlier section :ref:`pep-353` for a discussion of this 2092 2096 change. 2093 2097 … … 2114 2118 the various AST nodes in :file:`Parser/Python.asdl`. A Python script reads this 2115 2119 file and generates a set of C structure definitions in 2116 :file:`Include/Python-ast.h`. The :c func:`PyParser_ASTFromString` and2117 :c func:`PyParser_ASTFromFile`, defined in :file:`Include/pythonrun.h`, take2120 :file:`Include/Python-ast.h`. The :c:func:`PyParser_ASTFromString` and 2121 :c:func:`PyParser_ASTFromFile`, defined in :file:`Include/pythonrun.h`, take 2118 2122 Python source as input and return the root of an AST representing the contents. 2119 This AST can then be turned into a code object by :c func:`PyAST_Compile`. For2123 This AST can then be turned into a code object by :c:func:`PyAST_Compile`. For 2120 2124 more information, read the source code, and then ask questions on python-dev. 2121 2125 … … 2139 2143 Note that this change means extension modules must be more careful when 2140 2144 allocating memory. Python's API has many different functions for allocating 2141 memory that are grouped into families. For example, :c func:`PyMem_Malloc`,2142 :c func:`PyMem_Realloc`, and :cfunc:`PyMem_Free` are one family that allocates2143 raw memory, while :c func:`PyObject_Malloc`, :cfunc:`PyObject_Realloc`, and2144 :c func:`PyObject_Free` are another family that's supposed to be used for2145 memory that are grouped into families. For example, :c:func:`PyMem_Malloc`, 2146 :c:func:`PyMem_Realloc`, and :c:func:`PyMem_Free` are one family that allocates 2147 raw memory, while :c:func:`PyObject_Malloc`, :c:func:`PyObject_Realloc`, and 2148 :c:func:`PyObject_Free` are another family that's supposed to be used for 2145 2149 creating Python objects. 2146 2150 2147 2151 Previously these different families all reduced to the platform's 2148 :c func:`malloc` and :cfunc:`free` functions. This meant it didn't matter if2149 you got things wrong and allocated memory with the :c func:`PyMem` function but2150 freed it with the :c func:`PyObject` function. With 2.5's changes to obmalloc,2152 :c:func:`malloc` and :c:func:`free` functions. This meant it didn't matter if 2153 you got things wrong and allocated memory with the :c:func:`PyMem` function but 2154 freed it with the :c:func:`PyObject` function. With 2.5's changes to obmalloc, 2151 2155 these families now do different things and mismatches will probably result in a 2152 2156 segfault. You should carefully test your C extension modules with Python 2.5. 2153 2157 2154 * The built-in set types now have an official C API. Call :c func:`PySet_New`2155 and :c func:`PyFrozenSet_New` to create a new set, :cfunc:`PySet_Add` and2156 :c func:`PySet_Discard` to add and remove elements, and :cfunc:`PySet_Contains`2157 and :c func:`PySet_Size` to examine the set's state. (Contributed by Raymond2158 * The built-in set types now have an official C API. Call :c:func:`PySet_New` 2159 and :c:func:`PyFrozenSet_New` to create a new set, :c:func:`PySet_Add` and 2160 :c:func:`PySet_Discard` to add and remove elements, and :c:func:`PySet_Contains` 2161 and :c:func:`PySet_Size` to examine the set's state. (Contributed by Raymond 2158 2162 Hettinger.) 2159 2163 2160 2164 * C code can now obtain information about the exact revision of the Python 2161 interpreter by calling the :c func:`Py_GetBuildInfo` function that returns a2165 interpreter by calling the :c:func:`Py_GetBuildInfo` function that returns a 2162 2166 string of build information like this: ``"trunk:45355:45356M, Apr 13 2006, 2163 2167 07:42:19"``. (Contributed by Barry Warsaw.) … … 2165 2169 * Two new macros can be used to indicate C functions that are local to the 2166 2170 current file so that a faster calling convention can be used. 2167 :c func:`Py_LOCAL(type)` declares the function as returning a value of the2171 :c:func:`Py_LOCAL(type)` declares the function as returning a value of the 2168 2172 specified *type* and uses a fast-calling qualifier. 2169 :c func:`Py_LOCAL_INLINE(type)` does the same thing and also requests the2170 function be inlined. If :c func:`PY_LOCAL_AGGRESSIVE` is defined before2173 :c:func:`Py_LOCAL_INLINE(type)` does the same thing and also requests the 2174 function be inlined. If :c:func:`PY_LOCAL_AGGRESSIVE` is defined before 2171 2175 :file:`python.h` is included, a set of more aggressive optimizations are enabled 2172 2176 for the module; you should benchmark the results to find out if these … … 2174 2178 the NeedForSpeed sprint.) 2175 2179 2176 * :c func:`PyErr_NewException(name, base, dict)` can now accept a tuple of base2180 * :c:func:`PyErr_NewException(name, base, dict)` can now accept a tuple of base 2177 2181 classes as its *base* argument. (Contributed by Georg Brandl.) 2178 2182 2179 * The :c func:`PyErr_Warn` function for issuing warnings is now deprecated in2180 favour of :c func:`PyErr_WarnEx(category, message, stacklevel)` which lets you2183 * The :c:func:`PyErr_Warn` function for issuing warnings is now deprecated in 2184 favour of :c:func:`PyErr_WarnEx(category, message, stacklevel)` which lets you 2181 2185 specify the number of stack frames separating this function and the caller. A 2182 *stacklevel* of 1 is the function calling :c func:`PyErr_WarnEx`, 2 is the2186 *stacklevel* of 1 is the function calling :c:func:`PyErr_WarnEx`, 2 is the 2183 2187 function above that, and so forth. (Added by Neal Norwitz.) 2184 2188 … … 2187 2191 Martin von Löwis, Skip Montanaro.) 2188 2192 2189 * The :c func:`PyRange_New` function was removed. It was never documented, never2193 * The :c:func:`PyRange_New` function was removed. It was never documented, never 2190 2194 used in the core code, and had dangerously lax error checking. In the unlikely 2191 2195 case that your extensions were using it, you can replace it by something like … … 2204 2208 2205 2209 * MacOS X (10.3 and higher): dynamic loading of modules now uses the 2206 :c func:`dlopen` function instead of MacOS-specific functions.2210 :c:func:`dlopen` function instead of MacOS-specific functions. 2207 2211 2208 2212 * MacOS X: an :option:`--enable-universalsdk` switch was added to the … … 2260 2264 checking. 2261 2265 2262 * C API: Many functions now use :c type:`Py_ssize_t` instead of :ctype:`int` to2266 * C API: Many functions now use :c:type:`Py_ssize_t` instead of :c:type:`int` to 2263 2267 allow processing more data on 64-bit machines. Extension code may need to make 2264 2268 the same change to avoid warnings and to support 64-bit machines. See the … … 2266 2270 2267 2271 * C API: The obmalloc changes mean that you must be careful to not mix usage 2268 of the :c func:`PyMem_\*` and :cfunc:`PyObject_\*` families of functions. Memory2269 allocated with one family's :c func:`\*_Malloc` must be freed with the2270 corresponding family's :c func:`\*_Free` function.2272 of the :c:func:`PyMem_\*` and :c:func:`PyObject_\*` families of functions. Memory 2273 allocated with one family's :c:func:`\*_Malloc` must be freed with the 2274 corresponding family's :c:func:`\*_Free` function. 2271 2275 2272 2276 .. ====================================================================== -
python/vendor/current/Doc/whatsnew/2.6.rst
r2 r388 6 6 7 7 :Author: A.M. Kuchling (amk at amk.ca) 8 :Release: |release| 9 :Date: |today| 10 11 .. $Id: 2.6.rst 78304 2010-02-22 14:55:17Z andrew.kuchling $ 8 9 .. $Id$ 12 10 Rules for maintenance: 13 11 … … 110 108 111 109 Python 3.0 adds several new built-in functions and changes the 112 semantics of some existing built -ins. Functions that are new in 3.0110 semantics of some existing builtins. Functions that are new in 3.0 113 111 such as :func:`bin` have simply been added to Python 2.6, but existing 114 built -ins haven't been changed; instead, the :mod:`future_builtins`112 builtins haven't been changed; instead, the :mod:`future_builtins` 115 113 module has versions with the new 3.0 semantics. Code written to be 116 114 compatible with 3.0 can do ``from future_builtins import hex, map`` as … … 122 120 code to 3.0. The value of this switch is available 123 121 to Python code as the boolean variable :data:`sys.py3kwarning`, 124 and to C extension code as :c data:`Py_Py3kWarningFlag`.122 and to C extension code as :c:data:`Py_Py3kWarningFlag`. 125 123 126 124 .. seealso:: … … 233 231 .. seealso:: 234 232 235 :ref:`documenting-index`233 `Documenting Python <http://docs.python.org/devguide/documenting.html>`__ 236 234 Describes how to write for Python's documentation. 237 235 … … 612 610 print 'Factorial', N, '=', result 613 611 614 A :class:`Queue` is used to communicate the input parameter *N* and615 the result.The :class:`Queue` object is stored in a global variable.612 A :class:`Queue` is used to communicate the result of the factorial. 613 The :class:`Queue` object is stored in a global variable. 616 614 The child process will use the value of the variable when the child 617 615 was created; because it's a :class:`Queue`, parent and child can use … … 834 832 return str(self) 835 833 836 There's also a :func:`format` built -in that will format a single834 There's also a :func:`format` builtin that will format a single 837 835 value. It calls the type's :meth:`__format__` method with the 838 836 provided specifier:: … … 976 974 977 975 At the C level, Python 3.0 will rename the existing 8-bit 978 string type, called :c type:`PyStringObject` in Python 2.x,979 to :c type:`PyBytesObject`. Python 2.6 uses ``#define``980 to support using the names :c func:`PyBytesObject`,981 :c func:`PyBytes_Check`, :cfunc:`PyBytes_FromStringAndSize`,976 string type, called :c:type:`PyStringObject` in Python 2.x, 977 to :c:type:`PyBytesObject`. Python 2.6 uses ``#define`` 978 to support using the names :c:func:`PyBytesObject`, 979 :c:func:`PyBytes_Check`, :c:func:`PyBytes_FromStringAndSize`, 982 980 and all the other functions and macros used with strings. 983 981 … … 1011 1009 1012 1010 There's also a corresponding C API, with 1013 :c func:`PyByteArray_FromObject`,1014 :c func:`PyByteArray_FromStringAndSize`,1011 :c:func:`PyByteArray_FromObject`, 1012 :c:func:`PyByteArray_FromStringAndSize`, 1015 1013 and various other functions. 1016 1014 … … 1068 1066 over an in-memory buffer. 1069 1067 1068 .. index:: 1069 single: universal newlines; What's new 1070 1070 1071 * :class:`TextIOBase`: Provides functions for reading and writing 1071 1072 strings (remember, strings will be Unicode in Python 3.0), 1072 and supporting universal newlines. :class:`TextIOBase` defines1073 and supporting :term:`universal newlines`. :class:`TextIOBase` defines 1073 1074 the :meth:`readline` method and supports iteration upon 1074 1075 objects. … … 1131 1132 .. XXX PyObject_GetBuffer not documented in c-api 1132 1133 1133 The *flags* argument to :c func:`PyObject_GetBuffer` specifies1134 The *flags* argument to :c:func:`PyObject_GetBuffer` specifies 1134 1135 constraints upon the memory returned. Some examples are: 1135 1136 … … 1142 1143 Fortran-contiguous (first dimension varies the fastest) array layout. 1143 1144 1144 Two new argument codes for :c func:`PyArg_ParseTuple`,1145 Two new argument codes for :c:func:`PyArg_ParseTuple`, 1145 1146 ``s*`` and ``z*``, return locked buffer objects for a parameter. 1146 1147 … … 1165 1166 containing a metaclass called :class:`ABCMeta`, special handling of 1166 1167 this metaclass by the :func:`isinstance` and :func:`issubclass` 1167 built -ins, and a collection of basic ABCs that the Python developers1168 builtins, and a collection of basic ABCs that the Python developers 1168 1169 think will be widely useful. Future versions of Python will probably 1169 1170 add more ABCs. … … 1319 1320 47 1320 1321 1321 The :func:`oct` built -in still returns numbers1322 The :func:`oct` builtin still returns numbers 1322 1323 prefixed with a leading zero, and a new :func:`bin` 1323 built -in returns the binary representation for a number::1324 builtin returns the binary representation for a number:: 1324 1325 1325 1326 >>> oct(42) … … 1330 1331 '0b10101101' 1331 1332 1332 The :func:`int` and :func:`long` built -ins will now accept the "0o"1333 The :func:`int` and :func:`long` builtins will now accept the "0o" 1333 1334 and "0b" prefixes when base-8 or base-2 are requested, or when the 1334 1335 *base* argument is zero (signalling that the base used should be … … 1416 1417 and can be used as array indexes and slice boundaries. 1417 1418 1418 In Python 3.0, the PEP slightly redefines the existing built -ins1419 In Python 3.0, the PEP slightly redefines the existing builtins 1419 1420 :func:`round`, :func:`math.floor`, :func:`math.ceil`, and adds a new 1420 1421 one, :func:`math.trunc`, that's been backported to Python 2.6. … … 1524 1525 (Contributed by Amaury Forgeot d'Arc; :issue:`3473`.) 1525 1526 1526 * A new built -in, ``next(iterator, [default])`` returns the next item1527 * A new builtin, ``next(iterator, [default])`` returns the next item 1527 1528 from the specified iterator. If the *default* argument is supplied, 1528 1529 it will be returned if *iterator* has been exhausted; otherwise, … … 1636 1637 assigning ``None`` was implemented as an override. At the 1637 1638 C level, extensions can set ``tp_hash`` to 1638 :c func:`PyObject_HashNotImplemented`.1639 :c:func:`PyObject_HashNotImplemented`. 1639 1640 (Fixed by Nick Coghlan and Amaury Forgeot d'Arc; :issue:`2235`.) 1640 1641 … … 1706 1707 the Python core. Extension modules may not necessarily be compatible with 1707 1708 this cache, 1708 so they must explicitly add :c macro:`Py_TPFLAGS_HAVE_VERSION_TAG`1709 so they must explicitly add :c:macro:`Py_TPFLAGS_HAVE_VERSION_TAG` 1709 1710 to the module's ``tp_flags`` field to enable the method cache. 1710 1711 (To be compatible with the method cache, the extension module's code … … 1789 1790 one patch.) 1790 1791 1791 * The :mod:`bsddb` module also has a new maintainer, Jesús Cea , and the package1792 * The :mod:`bsddb` module also has a new maintainer, Jesús Cea Avion, and the package 1792 1793 is now available as a standalone package. The web page for the package is 1793 1794 `www.jcea.es/programacion/pybsddb.htm … … 1953 1954 1954 1955 * The :func:`reduce` built-in function is also available in the 1955 :mod:`functools` module. In Python 3.0, the built -in has been1956 :mod:`functools` module. In Python 3.0, the builtin has been 1956 1957 dropped and :func:`reduce` is only available from :mod:`functools`; 1957 currently there are no plans to drop the built -in in the 2.x series.1958 currently there are no plans to drop the builtin in the 2.x series. 1958 1959 (Patched by Christian Heimes; :issue:`1739906`.) 1959 1960 … … 2192 2193 For example, ``os.path.splitext('.ipython')`` 2193 2194 now returns ``('.ipython', '')`` instead of ``('', '.ipython')``. 2194 (:issue:`11 5886`)2195 (:issue:`1115886`) 2195 2196 2196 2197 A new function, ``os.path.relpath(path, start='.')``, returns a relative path … … 2285 2286 2286 2287 * The :mod:`select` module now has wrapper functions 2287 for the Linux :c func:`epoll` and BSD :cfunc:`kqueue` system calls.2288 for the Linux :c:func:`epoll` and BSD :c:func:`kqueue` system calls. 2288 2289 :meth:`modify` method was added to the existing :class:`poll` 2289 2290 objects; ``pollobj.modify(fd, eventmask)`` takes a file descriptor … … 2318 2319 to be used; when a signal is received, a byte is written to that 2319 2320 file descriptor. There's also a C-level function, 2320 :c func:`PySignal_SetWakeupFd`, for setting the descriptor.2321 :c:func:`PySignal_SetWakeupFd`, for setting the descriptor. 2321 2322 2322 2323 Event loops will use this by opening a pipe to create two descriptors, … … 2324 2325 will be passed to :func:`set_wakeup_fd`, and the readable descriptor 2325 2326 will be added to the list of descriptors monitored by the event loop via 2326 :c func:`select` or :cfunc:`poll`.2327 :c:func:`select` or :c:func:`poll`. 2327 2328 On receiving a signal, a byte will be written and the main event loop 2328 2329 will be woken up, avoiding the need to poll. … … 2385 2386 version 2.4.1. 2386 2387 2387 * The :mod:`struct` module now supports the C99 :c type:`_Bool` type,2388 * The :mod:`struct` module now supports the C99 :c:type:`_Bool` type, 2388 2389 using the format character ``'?'``. 2389 2390 (Contributed by David Remahl.) … … 2393 2394 On Windows, :meth:`send_signal` only supports the :const:`SIGTERM` 2394 2395 signal, and all these methods are aliases for the Win32 API function 2395 :c func:`TerminateProcess`.2396 :c:func:`TerminateProcess`. 2396 2397 (Contributed by Christian Heimes.) 2397 2398 … … 2757 2758 * ``filter(predicate, iterable)``, 2758 2759 ``map(func, iterable1, ...)``: the 3.0 versions 2759 return iterators, unlike the 2.x built -ins which return lists.2760 return iterators, unlike the 2.x builtins which return lists. 2760 2761 2761 2762 * ``hex(value)``, ``oct(value)``: instead of calling the … … 2978 2979 * Python now must be compiled with C89 compilers (after 19 2979 2980 years!). This means that the Python source tree has dropped its 2980 own implementations of :c func:`memmove` and :cfunc:`strerror`, which2981 own implementations of :c:func:`memmove` and :c:func:`strerror`, which 2981 2982 are in the C89 standard library. 2982 2983 … … 3000 3001 * The new buffer interface, previously described in 3001 3002 `the PEP 3118 section <#pep-3118-revised-buffer-protocol>`__, 3002 adds :c func:`PyObject_GetBuffer` and :cfunc:`PyBuffer_Release`,3003 adds :c:func:`PyObject_GetBuffer` and :c:func:`PyBuffer_Release`, 3003 3004 as well as a few other functions. 3004 3005 … … 3008 3009 was reading from or writing to the object. In 2.6 file objects 3009 3010 have a reference count, manipulated by the 3010 :c func:`PyFile_IncUseCount` and :cfunc:`PyFile_DecUseCount`3011 :c:func:`PyFile_IncUseCount` and :c:func:`PyFile_DecUseCount` 3011 3012 functions. File objects can't be closed unless the reference count 3012 is zero. :c func:`PyFile_IncUseCount` should be called while the GIL3013 is zero. :c:func:`PyFile_IncUseCount` should be called while the GIL 3013 3014 is still held, before carrying out an I/O operation using the 3014 ``FILE *`` pointer, and :c func:`PyFile_DecUseCount` should be called3015 ``FILE *`` pointer, and :c:func:`PyFile_DecUseCount` should be called 3015 3016 immediately after the GIL is re-acquired. 3016 3017 (Contributed by Antoine Pitrou and Gregory P. Smith.) … … 3018 3019 * Importing modules simultaneously in two different threads no longer 3019 3020 deadlocks; it will now raise an :exc:`ImportError`. A new API 3020 function, :c func:`PyImport_ImportModuleNoBlock`, will look for a3021 function, :c:func:`PyImport_ImportModuleNoBlock`, will look for a 3021 3022 module in ``sys.modules`` first, then try to import it after 3022 3023 acquiring an import lock. If the import lock is held by another … … 3025 3026 3026 3027 * Several functions return information about the platform's 3027 floating-point support. :c func:`PyFloat_GetMax` returns3028 floating-point support. :c:func:`PyFloat_GetMax` returns 3028 3029 the maximum representable floating point value, 3029 and :c func:`PyFloat_GetMin` returns the minimum3030 positive value. :c func:`PyFloat_GetInfo` returns an object3030 and :c:func:`PyFloat_GetMin` returns the minimum 3031 positive value. :c:func:`PyFloat_GetInfo` returns an object 3031 3032 containing more information from the :file:`float.h` file, such as 3032 3033 ``"mant_dig"`` (number of digits in the mantissa), ``"epsilon"`` … … 3036 3037 3037 3038 * C functions and methods that use 3038 :c func:`PyComplex_AsCComplex` will now accept arguments that3039 :c:func:`PyComplex_AsCComplex` will now accept arguments that 3039 3040 have a :meth:`__complex__` method. In particular, the functions in the 3040 3041 :mod:`cmath` module will now accept objects with this method. … … 3050 3051 integers and strings to the module's dictionary in the 3051 3052 ``init*`` function. Python 2.6 finally defines standard macros 3052 for adding values to a module, :c macro:`PyModule_AddStringMacro`3053 and :c macro:`PyModule_AddIntMacro()`. (Contributed by3053 for adding values to a module, :c:macro:`PyModule_AddStringMacro` 3054 and :c:macro:`PyModule_AddIntMacro()`. (Contributed by 3054 3055 Christian Heimes.) 3055 3056 3056 3057 * Some macros were renamed in both 3.0 and 2.6 to make it clearer that 3057 3058 they are macros, 3058 not functions. :c macro:`Py_Size()` became :cmacro:`Py_SIZE()`,3059 :c macro:`Py_Type()` became :cmacro:`Py_TYPE()`, and3060 :c macro:`Py_Refcnt()` became :cmacro:`Py_REFCNT()`.3059 not functions. :c:macro:`Py_Size()` became :c:macro:`Py_SIZE()`, 3060 :c:macro:`Py_Type()` became :c:macro:`Py_TYPE()`, and 3061 :c:macro:`Py_Refcnt()` became :c:macro:`Py_REFCNT()`. 3061 3062 The mixed-case macros are still available 3062 3063 in Python 2.6 for backward compatibility. … … 3116 3117 * The :mod:`socket` module's socket objects now have an 3117 3118 :meth:`ioctl` method that provides a limited interface to the 3118 :c func:`WSAIoctl` system interface.3119 :c:func:`WSAIoctl` system interface. 3119 3120 3120 3121 * The :mod:`_winreg` module now has a function, … … 3262 3263 an :exc:`ImportError`. 3263 3264 3264 * C API: the :c func:`PyImport_Import` and :cfunc:`PyImport_ImportModule`3265 * C API: the :c:func:`PyImport_Import` and :c:func:`PyImport_ImportModule` 3265 3266 functions now default to absolute imports, not relative imports. 3266 3267 This will affect C extensions that import other modules. … … 3268 3269 * C API: extension data types that shouldn't be hashable 3269 3270 should define their ``tp_hash`` slot to 3270 :c func:`PyObject_HashNotImplemented`.3271 :c:func:`PyObject_HashNotImplemented`. 3271 3272 3272 3273 * The :mod:`socket` module exception :exc:`socket.error` now inherits -
python/vendor/current/Doc/whatsnew/index.rst
r2 r388 12 12 :maxdepth: 2 13 13 14 2.7.rst 14 15 2.6.rst 15 16 2.5.rst
Note:
See TracChangeset
for help on using the changeset viewer.
