Mailman 3 January 2004 - Python-checkins

python/dist/src/Misc ACKS, 1.257, 1.258 NEWS, 1.924, 1.925
by loewis＠projects.sourceforge.net 31 Jan '04

31 Jan '04

Update of /cvsroot/python/python/dist/src/Misc In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4650/Misc Modified Files: ACKS NEWS Log Message: Patch #874083: Bluetooth support for socket module. Index: ACKS =================================================================== RCS file: /cvsroot/python/python/dist/src/Misc/ACKS,v retrieving revision 1.257 retrieving revision 1.258 diff -C2 -d -r1.257 -r1.258 *** ACKS 5 Jan 2004 10:13:34 -0000 1.257 --- ACKS 31 Jan 2004 12:34:16 -0000 1.258 *************** *** 178,181 **** --- 178,182 ---- Russell Finn Nils Fischbeck + Frederik Fix Hernán Martínez Foffani Doug Fort Index: NEWS =================================================================== RCS file: /cvsroot/python/python/dist/src/Misc/NEWS,v retrieving revision 1.924 retrieving revision 1.925 diff -C2 -d -r1.924 -r1.925 *** NEWS 29 Jan 2004 06:37:50 -0000 1.924 --- NEWS 31 Jan 2004 12:34:16 -0000 1.925 *************** *** 122,125 **** --- 122,128 ---- ----------------- + - The socket module now supports Bluetooth sockets, if the + system has <bluetooth/bluetooth.h> + - Added a collections module containing a new datatype, deque(), offering high-performance, thread-safe, memory friendly appends

1 0

python/dist/src configure, 1.436, 1.437 configure.in, 1.447, 1.448 pyconfig.h.in, 1.90, 1.91
by loewis＠projects.sourceforge.net 31 Jan '04

31 Jan '04

Update of /cvsroot/python/python/dist/src In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4650 Modified Files: configure configure.in pyconfig.h.in Log Message: Patch #874083: Bluetooth support for socket module. Index: configure =================================================================== RCS file: /cvsroot/python/python/dist/src/configure,v retrieving revision 1.436 retrieving revision 1.437 diff -C2 -d -r1.436 -r1.437 *** configure 17 Jan 2004 04:04:09 -0000 1.436 --- configure 31 Jan 2004 12:34:15 -0000 1.437 *************** *** 1,4 **** #! /bin/sh ! # From configure.in Revision: 1.445 . # Guess values for system-dependent variables and create Makefiles. # Generated by GNU Autoconf 2.57 for python 2.4. --- 1,4 ---- #! /bin/sh ! # From configure.in Revision: 1.447 . # Guess values for system-dependent variables and create Makefiles. # Generated by GNU Autoconf 2.57 for python 2.4. *************** *** 3009,3013 **** # Check for unsupported systems case $ac_sys_system/$ac_sys_release in ! SunOS/4*|Linux*/1*) echo This system $$ac_sys_system/$ac_sys_release$ is no longer supported. echo See README for details. --- 3009,3013 ---- # Check for unsupported systems case $ac_sys_system/$ac_sys_release in ! Linux*/1*) echo This system $$ac_sys_system/$ac_sys_release$ is no longer supported. echo See README for details. *************** *** 4350,4353 **** --- 4350,4354 ---- + for ac_header in dlfcn.h fcntl.h grp.h limits.h langinfo.h \ libintl.h locale.h ncurses.h poll.h pthread.h \ *************** *** 4357,4361 **** sys/param.h sys/poll.h sys/select.h sys/socket.h sys/time.h sys/times.h \ sys/un.h sys/utsname.h sys/wait.h pty.h term.h libutil.h \ ! sys/resource.h netpacket/packet.h sysexits.h do as_ac_Header=`echo "ac_cv_header_$ac_header" | $as_tr_sh` --- 4358,4362 ---- sys/param.h sys/poll.h sys/select.h sys/socket.h sys/time.h sys/times.h \ sys/un.h sys/utsname.h sys/wait.h pty.h term.h libutil.h \ ! sys/resource.h netpacket/packet.h sysexits.h bluetooth/bluetooth.h do as_ac_Header=`echo "ac_cv_header_$ac_header" | $as_tr_sh` *************** *** 9363,9367 **** echo "${ECHO_T}$SO" >&6 # LDSHARED is the ld *command* used to create shared library ! # -- "ld" on SunOS 4.x.x, "cc -G" on SunOS 5.x, "ld -shared" on IRIX 5 # (Shared libraries in this instance are shared modules to be loaded into # Python, as opposed to building Python itself as a shared library.) --- 9364,9368 ---- echo "${ECHO_T}$SO" >&6 # LDSHARED is the ld *command* used to create shared library ! # -- "cc -G" on SunOS 5.x, "ld -shared" on IRIX 5 # (Shared libraries in this instance are shared modules to be loaded into # Python, as opposed to building Python itself as a shared library.) *************** *** 9381,9385 **** IRIX/5*) LDSHARED="ld -shared";; IRIX*/6*) LDSHARED="ld ${SGI_ABI} -shared -all";; - SunOS/4*) LDSHARED="ld";; SunOS/5*) if test "$GCC" = "yes" --- 9382,9385 ---- *************** *** 15519,15572 **** echo "${ECHO_T}$works" >&6 - if test "$have_prototypes" = yes; then - bad_prototypes=no - echo "$as_me:$LINENO: checking for bad exec* prototypes" >&5 - echo $ECHO_N "checking for bad exec* prototypes... $ECHO_C" >&6 - cat >conftest.$ac_ext <<_ACEOF - #line $LINENO "configure" - /* confdefs.h. */ - _ACEOF - cat confdefs.h >>conftest.$ac_ext - cat >>conftest.$ac_ext <<_ACEOF - /* end confdefs.h. */ - #include <unistd.h> - int - main () - { - char **t;execve("@",t,t); - ; - return 0; - } - _ACEOF - rm -f conftest.$ac_objext - if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5 - (eval $ac_compile) 2>&5 - ac_status=$? - echo "$as_me:$LINENO: \$? = $ac_status" >&5 - (exit $ac_status); } && - { ac_try='test -s conftest.$ac_objext' - { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 - (eval $ac_try) 2>&5 - ac_status=$? - echo "$as_me:$LINENO: \$? = $ac_status" >&5 - (exit $ac_status); }; }; then - : - else - echo "$as_me: failed program was:" >&5 - sed 's/^/| /' conftest.$ac_ext >&5 - - - cat >>confdefs.h <<\_ACEOF - #define BAD_EXEC_PROTOTYPES 1 - _ACEOF - - bad_prototypes=yes - - fi - rm -f conftest.$ac_objext conftest.$ac_ext - echo "$as_me:$LINENO: result: $bad_prototypes" >&5 - echo "${ECHO_T}$bad_prototypes" >&6 - fi - # check if sockaddr has sa_len member echo "$as_me:$LINENO: checking if sockaddr has sa_len member" >&5 --- 15519,15522 ---- Index: configure.in =================================================================== RCS file: /cvsroot/python/python/dist/src/configure.in,v retrieving revision 1.447 retrieving revision 1.448 diff -C2 -d -r1.447 -r1.448 *** configure.in 17 Jan 2004 14:19:43 -0000 1.447 --- configure.in 31 Jan 2004 12:34:16 -0000 1.448 *************** *** 919,923 **** sys/param.h sys/poll.h sys/select.h sys/socket.h sys/time.h sys/times.h \ sys/un.h sys/utsname.h sys/wait.h pty.h term.h libutil.h \ ! sys/resource.h netpacket/packet.h sysexits.h) AC_HEADER_DIRENT AC_HEADER_MAJOR --- 919,923 ---- sys/param.h sys/poll.h sys/select.h sys/socket.h sys/time.h sys/times.h \ sys/un.h sys/utsname.h sys/wait.h pty.h term.h libutil.h \ ! sys/resource.h netpacket/packet.h sysexits.h bluetooth/bluetooth.h) AC_HEADER_DIRENT AC_HEADER_MAJOR Index: pyconfig.h.in =================================================================== RCS file: /cvsroot/python/python/dist/src/pyconfig.h.in,v retrieving revision 1.90 retrieving revision 1.91 diff -C2 -d -r1.90 -r1.91 *** pyconfig.h.in 17 Jan 2004 14:19:43 -0000 1.90 --- pyconfig.h.in 31 Jan 2004 12:34:16 -0000 1.91 *************** *** 38,41 **** --- 38,44 ---- #undef HAVE_ALTZONE + /* Define to 1 if you have the <bluetooth/bluetooth.h> header file. */ + #undef HAVE_BLUETOOTH_BLUETOOTH_H + /* Define if nice() returns success/failure instead of the new priority. */ #undef HAVE_BROKEN_NICE *************** *** 819,832 **** #undef _OSF_SOURCE - /* Define to 2 if the system does not provide POSIX.1 features except with - this defined. */ - #undef _POSIX_1_SOURCE - /* Define to activate features from IEEE Stds 1003.1-2001 */ #undef _POSIX_C_SOURCE - /* Define to 1 if you need to in order for `stat' and other things to work. */ - #undef _POSIX_SOURCE - /* Define if you have POSIX threads, and your system does not define that. */ #undef _POSIX_THREADS --- 822,828 ----

1 0

python/dist/src/Modules socketmodule.c, 1.281, 1.282 socketmodule.h, 1.9, 1.10
by loewis＠projects.sourceforge.net 31 Jan '04

31 Jan '04

Update of /cvsroot/python/python/dist/src/Modules In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4650/Modules Modified Files: socketmodule.c socketmodule.h Log Message: Patch #874083: Bluetooth support for socket module. Index: socketmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v retrieving revision 1.281 retrieving revision 1.282 diff -C2 -d -r1.281 -r1.282 *** socketmodule.c 30 Dec 2003 11:14:01 -0000 1.281 --- socketmodule.c 31 Jan 2004 12:34:16 -0000 1.282 *************** *** 1013,1016 **** --- 1013,1078 ---- #endif + #ifdef HAVE_BLUETOOTH_BLUETOOTH_H + case AF_BLUETOOTH: + { + switch( s->sock_proto ) + { + case BTPROTO_L2CAP: + { + struct sockaddr_l2* addr = (struct sockaddr_l2*) &(s->sock_addr).bt_l2; + bdaddr_t* bdaddr = &(addr->l2_bdaddr); + + addr->l2_family = AF_BLUETOOTH; + if( !PyArg_ParseTuple(args, "(iiiiii)i", &bdaddr->b[0], &bdaddr->b[1], &bdaddr->b[2], &bdaddr->b[3], &bdaddr->b[4], &bdaddr->b[5], &addr->l2_psm) ) + { + PyErr_SetString(socket_error, "getsockaddrarg: wrong format"); + return 0; + } + + *addr_ret = (struct sockaddr *) addr; + *len_ret = sizeof *addr; + return 1; + } + case BTPROTO_RFCOMM: + { + struct sockaddr_rc* addr = (struct sockaddr_rc*) &(s->sock_addr).bt_rc; + bdaddr_t* bdaddr = &(addr->rc_bdaddr); + + addr->rc_family = AF_BLUETOOTH; + if( !PyArg_ParseTuple(args, "(iiiiii)i", &bdaddr->b[0], &bdaddr->b[1], &bdaddr->b[2], &bdaddr->b[3], &bdaddr->b[4], &bdaddr->b[5], &addr->rc_channel) ) + { + PyErr_SetString(socket_error, "getsockaddrarg: wrong format"); + return 0; + } + + *addr_ret = (struct sockaddr *) addr; + *len_ret = sizeof *addr; + return 1; + } + case BTPROTO_SCO: + { + struct sockaddr_sco* addr = (struct sockaddr_sco*) &(s->sock_addr).bt_sco; + bdaddr_t* bdaddr = &(addr->sco_bdaddr); + + addr->sco_family = AF_BLUETOOTH; + if( !PyArg_ParseTuple(args, "iiiiii", &bdaddr->b[0], &bdaddr->b[1], &bdaddr->b[2], &bdaddr->b[3], &bdaddr->b[4], &bdaddr->b[5]) ) + { + PyErr_SetString(socket_error, "getsockaddrarg: wrong format"); + return 0; + } + + *addr_ret = (struct sockaddr *) addr; + *len_ret = sizeof *addr; + return 1; + } + default: + { + PyErr_SetString(socket_error, "getsockaddrarg: unknown Bluetooth protocol"); + return 0; + } + } + } + #endif + #ifdef HAVE_NETPACKET_PACKET_H case AF_PACKET: *************** *** 1086,1089 **** --- 1148,1180 ---- #endif + #ifdef HAVE_BLUETOOTH_BLUETOOTH_H + case AF_BLUETOOTH: + { + switch(s->sock_proto) + { + case BTPROTO_L2CAP: + { + *len_ret = sizeof (struct sockaddr_l2); + return 1; + } + case BTPROTO_RFCOMM: + { + *len_ret = sizeof (struct sockaddr_rc); + return 1; + } + case BTPROTO_SCO: + { + *len_ret = sizeof (struct sockaddr_sco); + return 1; + } + default: + { + PyErr_SetString(socket_error, "getsockaddrlen: unknown BT protocol"); + return 0; + } + } + } + #endif + #ifdef HAVE_NETPACKET_PACKET_H case AF_PACKET: *************** *** 3574,3577 **** --- 3665,3678 ---- PyModule_AddIntConstant(m, "AF_ROSE", AF_ROSE); #endif + + #ifdef HAVE_BLUETOOTH_BLUETOOTH_H + PyModule_AddIntConstant(m, "AF_BLUETOOTH", AF_BLUETOOTH); + PyModule_AddIntConstant(m, "BTPROTO_L2CAP", BTPROTO_L2CAP); + PyModule_AddIntConstant(m, "BTPROTO_SCO", BTPROTO_SCO); + PyModule_AddIntConstant(m, "BTPROTO_RFCOMM", BTPROTO_RFCOMM); + PyModule_AddObject(m, "BDADDR_ANY", Py_BuildValue( "iiiiii", 0,0,0,0,0,0 ) ); + PyModule_AddObject(m, "BDADDR_LOCAL", Py_BuildValue( "iiiiii", 0,0,0,0xff,0xff,0xff ) ); + #endif + #ifdef HAVE_NETPACKET_PACKET_H PyModule_AddIntConstant(m, "AF_PACKET", AF_PACKET); Index: socketmodule.h =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.h,v retrieving revision 1.9 retrieving revision 1.10 diff -C2 -d -r1.9 -r1.10 *** socketmodule.h 3 May 2003 09:14:53 -0000 1.9 --- socketmodule.h 31 Jan 2004 12:34:17 -0000 1.10 *************** *** 33,36 **** --- 33,43 ---- #endif + #ifdef HAVE_BLUETOOTH_BLUETOOTH_H + #include <bluetooth/bluetooth.h> + #include <bluetooth/rfcomm.h> + #include <bluetooth/l2cap.h> + #include <bluetooth/sco.h> + #endif + #ifdef HAVE_NETPACKET_PACKET_H # include <sys/ioctl.h> *************** *** 81,84 **** --- 88,96 ---- struct sockaddr_storage storage; #endif + #ifdef HAVE_BLUETOOTH_BLUETOOTH_H + struct sockaddr_l2 bt_l2; + struct sockaddr_rc bt_rc; + struct sockaddr_sco bt_sco; + #endif #ifdef HAVE_NETPACKET_PACKET_H struct sockaddr_ll ll;

1 0

python/nondist/peps pep-0328.txt,1.1,1.2
by goodger＠projects.sourceforge.net 31 Jan '04

31 Jan '04

Update of /cvsroot/python/python/nondist/peps In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22399 Modified Files: pep-0328.txt Log Message: title capitalization Index: pep-0328.txt =================================================================== RCS file: /cvsroot/python/python/nondist/peps/pep-0328.txt,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 *** pep-0328.txt 31 Jan 2004 05:14:16 -0000 1.1 --- pep-0328.txt 31 Jan 2004 05:19:25 -0000 1.2 *************** *** 1,4 **** PEP: 328 ! Title: Imports: multi-line and absolute/relative Version: $Revision$ Last-Modified: $Date$ --- 1,4 ---- PEP: 328 ! Title: Imports: Multi-Line and Absolute/Relative Version: $Revision$ Last-Modified: $Date$

1 0

python/nondist/peps pep-0328.txt, NONE, 1.1 pep-0000.txt, 1.264, 1.265
by goodger＠projects.sourceforge.net 31 Jan '04

31 Jan '04

Update of /cvsroot/python/python/nondist/peps In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv17705 Modified Files: pep-0000.txt Added Files: pep-0328.txt Log Message: Added PEP 328, Imports: Multi-Line and Absolute/Relative, by Aahz --- NEW FILE: pep-0328.txt --- PEP: 328 Title: Imports: multi-line and absolute/relative Version: $Revision: 1.1 $ Last-Modified: $Date: 2004/01/31 05:14:16 $ Author: Aahz <aahz(a)pythoncraft.com Status: Draft Type: Standards Track Python-Version: 2.4 Content-Type: text/x-rst Created: 21-Dec-2003 Post-History: Abstract ======== The ``import`` statement has two problems: * Long ``import`` statements can be difficult to write, requiring various contortions to fit Pythonic style guidelines. * Imports can be ambiguous in the face of packages; within a package, it's not clear whether ``import foo`` refers to a module within the package or some module outside the package. For the first problem, it is proposed that parentheses be permitted to enclose multiple names, thus allowing Python's standard mechanisms for multi-line values to apply. For the second problem, it is proposed that all ``import`` statements be absolute by default (more precisely, relative to ``sys.path``) with special syntax for accessing package-relative imports. Rationale for Parentheses ========================= Currently, if you want to import a lot of names from a module or package, you have to choose one of several unpalatable options: * Write a long line with backslash continuations:: from Tkinter import Tk, Frame, Button, Entry, Canvas, Text \ LEFT, DISABLED, NORMAL, RIDGE, END * Write multiple ``import`` statements:: from Tkinter import Tk, Frame, Button, Entry, Canvas, Text from Tkinter import LEFT, DISABLED, NORMAL, RIDGE, END (``import *`` is *not* an option ;-) Instead, it should be possible to use Python's standard grouping mechanism (parentheses) to write the ``import`` statement:: from Tkinter import (Tk, Frame, Button, Entry, Canvas, Text LEFT, DISABLED, NORMAL, RIDGE, END) This part of the proposal already has BDFL approval. Rationale for Absolute Imports ============================== In current Python, if you're reading a module located inside a package, it is not clear whether :: import foo refers to a top-level module or to another module inside the package. To resolve the ambiguity, it is proposed that ``foo`` will always be a module or package reachable from ``sys.path``. Because this represents a change in semantics, absolute imports will be optional in Python 2.4 through the use of :: from __future__ import absolute_import This PEP will be updated when it is decided to make absolute imports the default, probably Python 2.5 or 2.6. This part of the proposal already has BDFL approval. Rationale for Relative Imports ============================== With the shift to absolute imports, the question arose whether relative imports should be allowed at all. Several use cases were presented, the most important of which is being able to rearrange the structure of large packages without having to edit sub-packages. In addition, a module inside a package can't easily import itself without relative imports. Guido approved of the idea of relative imports, but there has been a lot of disagreement on the spelling (syntax). There does seem to be agreement that relative imports will require listing specific names to import (that is, ``import foo`` as a bare term will always be an absolute import). Here are the contenders: * One from Guido:: from .foo import and :: from ...foo import These two forms have a couple of different suggested semantics. One semantic is to make each dot represent one level. There have been many complaints about the difficulty of counting dots. Another option is to only allow one level of relative import. That misses a lot of functionality, and people still complained about missing the dot in the one-dot form. The final option is to define an algorithm for finding relative modules and packages; the objection here is "Explicit is better than implicit". (The algorithm proposed is "search up from current package directory until the ultimate package parent gets hit".) * The next set of options is conflated from several posters:: from __pkg__.__pkg__ import and :: from .__parent__.__parent__ import Many people (Guido included) think these look ugly, but they *are* clear and explicit. Overall, more people prefer ``__pkg__`` as the shorter option. * Finally, some people dislike the way you have to change ``import`` to ``from ... import`` when you want to dig inside a package. They suggest completely rewriting the ``import`` syntax:: from MODULE import NAMES as RENAME searching HOW or :: import NAMES as RENAME from MODULE searching HOW [from NAMES] [in WHERE] import ... However, this most likely could not be implemented for Python 2.4 (too big a change), and allowing relative imports is sufficiently critical that we need something now (given that the standard ``import`` will change to absolute import). More than that, this proposed syntax has several open questions: - What is the precise proposed syntax? (Which clauses are optional under which circumstances?) - How strongly does the ``searching`` clause bind? In other words, do you write:: import foo as bar searching XXX, spam as ham searching XXX or:: import foo as bar, spam as ham searching XXX Open Issues =========== The BDFL needs to decide which of the various options for relative imports works best. Additional proposals are still welcome. As usual, Guido prefers reasons to histrionics. References ========== For more background, see the following python-dev threads: - `Re: Christmas Wishlist <http://mail.python.org/pipermail/python-dev/2003-December/040973.html>`__ - `Re: Python-Dev Digest, Vol 5, Issue 57 <http://mail.python.org/pipermail/python-dev/2003-December/041078.html>`__ - `Relative import <http://mail.python.org/pipermail/python-dev/2003-December/041065.html>`__ - `Another Strategy for Relative Import <http://mail.python.org/pipermail/python-dev/2003-December/041418.html>`__ Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 End: Index: pep-0000.txt =================================================================== RCS file: /cvsroot/python/python/nondist/peps/pep-0000.txt,v retrieving revision 1.264 retrieving revision 1.265 diff -C2 -d -r1.264 -r1.265 *** pep-0000.txt 29 Jan 2004 20:17:06 -0000 1.264 --- pep-0000.txt 31 Jan 2004 05:14:15 -0000 1.265 *************** *** 124,127 **** --- 124,128 ---- S 326 A Case for Top and Bottom Values Carlson, Reedy S 327 Decimal Data Type Batista + S 328 Imports: Multi-Line and Absolute/Relative Aahz S 754 IEEE 754 Floating Point Special Values Warnes *************** *** 348,351 **** --- 349,353 ---- S 326 A Case for Top and Bottom Values Carlson, Reedy S 327 Decimal Data Type Batista + S 328 Imports: Multi-Line and Absolute/Relative Aahz SR 666 Reject Foolish Indentation Creighton S 754 IEEE 754 Floating Point Special Values Warnes

1 0

python/nondist/peps pep-0000.txt,1.263,1.264
by goodger＠projects.sourceforge.net 29 Jan '04

29 Jan '04

Update of /cvsroot/python/python/nondist/peps In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv26930 Modified Files: pep-0000.txt Log Message: updated Index: pep-0000.txt =================================================================== RCS file: /cvsroot/python/python/nondist/peps/pep-0000.txt,v retrieving revision 1.263 retrieving revision 1.264 diff -C2 -d -r1.263 -r1.264 *** pep-0000.txt 29 Jan 2004 20:00:32 -0000 1.263 --- pep-0000.txt 29 Jan 2004 20:17:06 -0000 1.264 *************** *** 123,126 **** --- 123,127 ---- S 325 Resource-Release Support for Generators Pedroni S 326 A Case for Top and Bottom Values Carlson, Reedy + S 327 Decimal Data Type Batista S 754 IEEE 754 Floating Point Special Values Warnes

1 0

python/nondist/peps pep-0000.txt,1.262,1.263
by goodger＠projects.sourceforge.net 29 Jan '04

29 Jan '04

Update of /cvsroot/python/python/nondist/peps In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16396 Modified Files: pep-0000.txt Log Message: added PEP 327 Index: pep-0000.txt =================================================================== RCS file: /cvsroot/python/python/nondist/peps/pep-0000.txt,v retrieving revision 1.262 retrieving revision 1.263 diff -C2 -d -r1.262 -r1.263 *** pep-0000.txt 6 Jan 2004 15:34:49 -0000 1.262 --- pep-0000.txt 29 Jan 2004 20:00:32 -0000 1.263 *************** *** 122,126 **** S 324 popen5 - New POSIX process module Astrand S 325 Resource-Release Support for Generators Pedroni ! S 326 A Case for Top and Bottom Values Carlson S 754 IEEE 754 Floating Point Special Values Warnes --- 122,126 ---- S 324 popen5 - New POSIX process module Astrand S 325 Resource-Release Support for Generators Pedroni ! S 326 A Case for Top and Bottom Values Carlson, Reedy S 754 IEEE 754 Floating Point Special Values Warnes *************** *** 345,349 **** S 324 popen5 - New POSIX process module Astrand S 325 Resource-Release Support for Generators Pedroni ! S 326 A Case for Top and Bottom Values Carlson SR 666 Reject Foolish Indentation Creighton S 754 IEEE 754 Floating Point Special Values Warnes --- 345,350 ---- S 324 popen5 - New POSIX process module Astrand S 325 Resource-Release Support for Generators Pedroni ! S 326 A Case for Top and Bottom Values Carlson, Reedy ! S 327 Decimal Data Type Batista SR 666 Reject Foolish Indentation Creighton S 754 IEEE 754 Floating Point Special Values Warnes *************** *** 371,374 **** --- 372,376 ---- Astrand, Peter astrand(a)lysator.liu.se Barrett, Paul barrett(a)stsci.edu + Batista, Facundo facundo(a)taniquetil.com.ar Baxter, Anthony anthony(a)interlink.com.au Bellman, Thomas bellman+pep-divmod(a)lysator.liu.se *************** *** 419,422 **** --- 421,425 ---- Petrone, Jason jp(a)demonseed.net Prescod, Paul paul(a)prescod.net + Reedy, Terry tjreedy(a)udel.edu Reifschneider, Sean jafo-pep(a)tummy.com Riehl, Jonathan jriehl(a)spaceship.com

1 0

python/nondist/peps pep-0327.txt,NONE,1.1
by goodger＠projects.sourceforge.net 29 Jan '04

29 Jan '04

Update of /cvsroot/python/python/nondist/peps In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16029 Added Files: pep-0327.txt Log Message: Added PEP 327, Decimal Data Type, by Facundo Batista. Could use more editing. --- NEW FILE: pep-0327.txt --- PEP: 327 Title: Decimal Data Type Version: $Revision: 1.1 $ Last-Modified: $Date: 2004/01/29 19:59:56 $ Author: Facundo Batista <facundo(a)taniquetil.com.ar> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 17-Oct-2003 Python-Version: 2.4 Post-History: 30-Nov-2003, 02-Jan-2004 Abstract ======== The idea is to have a Decimal data type, for every use where decimals are needed but binary floating point is too inexact. The Decimal data type will support the Python standard functions and operations, and must comply the decimal arithmetic ANSI standard X3.274-1996 [1]_. Decimal will be floating point (as opposed to fixed point) and will have bounded precision (the precision is the upper limit on the quantity of significant digits in a result). This work is based on code and test functions written by Eric Price, Aahz and Tim Peters. Actually I'll work on the Decimal.py code in the sandbox (at python/nondist/sandbox/decimal in the SourceForge CVS repository). Much of the explanation in this PEP is taken from Cowlishaw's work [2]_ and comp.lang.python. Motivation ========== Here I'll expose the reasons of why I think a Decimal data type is needed and why others numeric data types are not enough. I wanted a Money data type, and after proposing a pre-PEP in comp.lang.python, the community agreed to have a numeric data type with the needed arithmetic behaviour, and then build Money over it: all the considerations about quantity of digits after the decimal point, rounding, etc., will be handled through Money. It is not the purpose of this PEP to have a data type that can be used as Money without further effort. One of the biggest advantages of implementing a standard is that someone already thought all the creepy cases for you. And to a standard GvR redirected me: Mike Cowlishaw's General Decimal Arithmetic specification [2]_. This document defines a general purpose decimal arithmetic. A correct implementation of this specification will conform to the decimal arithmetic defined in ANSI/IEEE standard 854-1987, except for some minor restrictions, and will also provide unrounded decimal arithmetic and integer arithmetic as proper subsets. The problem with binary float ----------------------------- In decimal math, there are many numbers that can't be represented with a fixed number of decimal digits, e.g. 1/3 = 0.3333333333....... In base 2 (the way that standard floating point is calculated), 1/2 = 0.1, 1/4 = 0.01, 1/8 = 0.001, etc. Decimal 0.2 equals 2/10 equals 1/5, resulting in the binary fractional number 0.001100110011001... As you can see, the problem is that some decimal numbers can't be represented exactly in binary, resulting in small roundoff errors. So we need a decimal data type that represents exactly decimal numbers. Instead of a binary data type, we need a decimal one. Why floating point? ------------------- So we go to decimal, but why *floating point*? Floating point numbers use a fixed quantity of digits (precision) to represent a number, working with an exponent when the number gets too big or too small. For example, with a precision of 5:: 1234 ==> 1234e0 12345 ==> 12345e0 123456 ==> 12345e1 In contrast, we have the example of a ``long`` integer with infinite precision, meaning that you can have the number as big as you want, and you'll never lose any information. In a fixed point number, the position of the decimal point is fixed. For a fixed point data type, check Tim Peter's FixedPoint at SourceForge [4]_. I'll go for floating point because it's easier to implement the arithmetic behaviour of the standard, and then you can implement a fixed point data type over Decimal. But why can't we have a floating point number with infinite precision? It's not so easy, because of inexact divisions. E.g.: 1/3 = 0.3333333333333... ad infinitum. In this case you should store a infinite amount of 3s, which takes too much memory, ;). John Roth proposed to eliminate the division operator and force the user to use an explicit method, just to avoid this kind of trouble. This generated adverse reactions in comp.lang.python, as everybody wants to have support for the ``/`` operator in a numeric data type. With this exposed maybe you're thinking "Hey! Can we just store the 1 and the 3 as numerator and denominator?", which take us to the next point. Why not rational ---------------- Rational numbers are stored using two integer numbers, the numerator and the denominator. This implies that the arithmetic operations can't be executed directly (e.g. to add two rational numbers you first need to calculate the common denominator). Quoting Alex Martelli: The performance implications of the fact that summing two rationals (which take O(M) and O(N) space respectively) gives a rational which takes O(M+N) memory space is just too troublesome. There are excellent Rational implementations in both pure Python and as extensions (e.g., gmpy), but they'll always be a "niche market" IMHO. Probably worth PEPping, not worth doing without Decimal -- which is the right way to represent sums of money, a truly major use case in the real world. Anyway, if you're interested in this data type, you maybe will want to take a look at PEP 239: Adding a Rational Type to Python. So, what do we have? -------------------- The result is a Decimal data type, with bounded precision and floating point. Will it be useful? I can't say it better than Alex Martelli: Python (out of the box) doesn't let you have binary floating point numbers *with whatever precision you specify*: you're limited to what your hardware supplies. Decimal, be it used as a fixed or floating point number, should suffer from no such limitation: whatever bounded precision you may specify on number creation (your memory permitting) should work just as well. Most of the expense of programming simplicity can be hidden from application programs and placed in a suitable decimal arithmetic type. As per http://www2.hursley.ibm.com/decimal/, *a single data type can be used for integer, fixed-point, and floating-point decimal arithmetic* -- and for money arithmetic which doesn't drive the application programmer crazy. There are several uses for such a data type. As I said before, I will use it as base for Money. In this case the bounded precision is not an issue; quoting Tim Peters: A precision of 20 would be way more than enough to account for total world economic output, down to the penny, since the beginning of time. General Decimal Arithmetic Specification ======================================== Here I'll include information and descriptions that are part of the specification [2]_ (the structure of the number, the context, etc.). All the requirements included in this section are not for discussion (barring typos or other mistakes), as they are in the standard, and the PEP is just for implementing the standard. Because of copyright restrictions, I can not copy here explanations taken from the specification, so I'll try to explain it in my own words. I firmly encourage you to read the original specification document [2]_ for details or if you have any doubt. The Arithmetic Model -------------------- The specification is based on a decimal arithmetic model, as defined by the relevant standards: IEEE 854 [3]_, ANSI X3-274 [1]_, and the proposed revision [5]_ of IEEE 754 [6]_. The model has three components: - Numbers: just the values that the operation uses as input or output. - Operations: addition, multiplication, etc. - Context: a set of parameters and rules that the user can select and which govern the results of operations (for example, the precision to be used). Numbers ------- Numbers may be finite or special values. The former can be represented exactly. The latter are infinites and undefined (such as 0/0). Finite numbers are defined by three parameters: - Sign: 0 (positive) or 1 (negative). - Coefficient: a non-negative integer. - Exponent: a signed integer, the power of ten of the coefficient multiplier. The numerical value of a finite number is given by:: (-1)**sign * coefficient * 10**exponent Special values are named as following: - Infinity: a value which is infinitely large. Could be positive or negative. - Quiet NaN ("qNaN"): represent undefined results (*Not a Number*). Does not cause an Invalid operation condition. The sign in a NaN has no meaning. - Signaling NaN ("sNaN"): also *Not a Number*, but will cause an Invalid operation condition if used in any operation. Context ------- The context is a set of parameters and rules that the user can select and which govern the results of operations (for example, the precision to be used). The context gets that name because surrounds the Decimal numbers. It's up to the implementation to work with one or several contexts, but definitely the idea is not to get a context per Decimal number. These definitions don't affect the internal storage of the Decimal numbers, just the way that the arithmetic operations are performed. The context is defined by the following parameters: - Precision: The maximum number of significant digits that can result from an arithmetic operation (integer > 0). - Rounding: The name of the algorithm to be used when rounding is necessary, one of "round-down", "round-half-up", "round-half-even", "round-ceiling", "round-floor", "round-half-down", and "round-up". See `Rounding Algorithms`_ below. - Flags and trap-enablers: `Exceptional conditions`_ are grouped into signals, controllable individually, each consisting of a flag (boolean, set when the signal occurs) and a trap-enabler (a boolean that controls behavior). The signals are: "clamped", "division-by-zero", "inexact", "invalid-operation", "overflow", "rounded", "subnormal" and "underflow". Default Contexts ---------------- The specification defines two default contexts, which should be easily selectable by the user. Basic Default Context: - flags: all set to 0 - trap-enablers: inexact, rounded, and subnormal are set to 0; all others are set to 1 - precision: is set to 9 - rounding: is set to round-half-up Extended Default Context: - flags: all set to 0 - trap-enablers: all set to 0 - precision: is set to the designated single precision - rounding: is set to round-half-even Exceptional Conditions ---------------------- The table below lists the exceptional conditions that may arise during the arithmetic operations, the corresponding signal, and the defined result. For details, see the specification [2]_. ==================== ================= =================================== Condition Signal Result ==================== ================= =================================== Clamped clamped see spec [2]_ Conversion syntax invalid-operation [0,qNaN] Division by zero division-by-zero [sign,inf] Division impossible invalid-operation [0,qNaN] Division undefined invalid-operation [0,qNaN] Inexact inexact unchanged Insufficient storage [0,qNaN] Invalid context invalid-operation [0,qNaN] Invalid operation invalid-operation [0,qNaN] (or [s,qNaN] or [s,qNaN,d] when the cause is a signaling NaN) Overflow overflow depends on the rounding mode Rounded rounded unchanged Subnormal subnormal unchanged Underflow underflow see spec [2]_ ==================== ================= =================================== Rounding Algorithms ------------------- ``round-down``: The discarded digits are ignored; the result is unchanged (round toward 0, truncate):: 1.123 --> 1.12 1.128 --> 1.12 1.125 --> 1.12 1.135 --> 1.13 ``round-half-up``: If the discarded digits represent greater than or equal to half (0.5) then the result should be incremented by 1; otherwise the discarded digits are ignored:: 1.123 --> 1.12 1.128 --> 1.13 1.125 --> 1.13 1.135 --> 1.14 ``round-half-even``: If the discarded digits represent greater than half (0.5) then the result coefficient is incremented by 1; if they represent less than half, then the result is not adjusted; otherwise the result is unaltered if its rightmost digit is even, or incremented by 1 if its rightmost digit is odd (to make an even digit):: 1.123 --> 1.12 1.128 --> 1.13 1.125 --> 1.12 1.135 --> 1.14 ``round-ceiling``: If all of the discarded digits are zero or if the sign is negative the result is unchanged; otherwise, the result is incremented by 1:: 1.123 --> 1.13 1.128 --> 1.13 -1.123 --> -1.12 -1.128 --> -1.12 ``round-floor``: If all of the discarded digits are zero or if the sign is positive the result is unchanged; otherwise, the absolute value of the result is incremented by 1:: 1.123 --> 1.12 1.128 --> 1.12 -1.123 --> -1.13 -1.128 --> -1.13 ``round-half-down``: If the discarded digits represent greater than half (0.5) then the result is incremented by 1; otherwise the discarded digits are ignored:: 1.123 --> 1.12 1.128 --> 1.13 1.125 --> 1.12 1.135 --> 1.13 ``round-up``: If all of the discarded digits are zero the result is unchanged, otherwise the result is incremented by 1 (round away from 0):: 1.123 --> 1.13 1.128 --> 1.13 1.125 --> 1.13 1.135 --> 1.14 Rationale ========= I must separate the requirements in two sections. The first is to comply with the ANSI standard. All the requirements for this are specified in the Mike Cowlishaw's work [2]_. He also provided a **comprehensive** suite of test cases. The second section of requirements (standard Python functions support, usability, etc.) is detailed from here, where I'll include all the decisions made and why, and all the subjects still being discussed. Explicit construction --------------------- The explicit construction does not get affected by the context (there is no rounding, no limits by the precision, etc.), because the context affects just operations' results. **From int or long**: There's no loss and no need to specify any other information:: Decimal(35) Decimal(-124) **From string**: Strings with floats in normal and engineering notation will be supported. In this transformation there is no loss of information, as the string is directly converted to Decimal (there is not an intermediate conversion through float):: Decimal("-12") Decimal("23.2e-7") **From float**: The initial discussion on this item was what should happen when passing floating point to the constructor: 1. ``Decimal(1.1) == Decimal('1.1')`` 2. ``Decimal(1.1) == Decimal('110000000000000008881784197001252...e-51')`` 3. an exception is raised Several people alleged that (1) is the better option here, because it's what you expect when writing ``Decimal(1.1)``. And quoting John Roth, it's easy to implement: It's not at all difficult to find where the actual number ends and where the fuzz begins. You can do it visually, and the algorithms to do it are quite well known. But If I *really* want my number to be ``Decimal('110000000000000008881784197001252...e-51')``, why can not write ``Decimal(1.1)``? Why should I expect Decimal to be "rounding" it? Remember that ``1.1`` *is* binary floating point, so I can predict the result. It's not intuitive to a beginner, but that's the way it is. Anyway, Paul Moore shown that (1) can't be, because:: (1) says D(1.1) == D('1.1') but 1.1 == 1.1000000000000001 so D(1.1) == D(1.1000000000000001) together: D(1.1000000000000001) == D('1.1') which is wrong, because if I write ``Decimal('1.1')`` it is exact, not ``D(1.1000000000000001)``. He also proposed to have an explicit conversion to float. bokr says you need to put the precision in the constructor and mwilson has the idea to:: d = Decimal (1.1, 1) # take float value to 1 decimal place d = Decimal (1.1) # gets `places` from pre-set context But Alex Martelli says that: Constructing with some specified precision would be fine. Thus, I think "construction from float with some default precision" runs a substantial risk of tricking naive users. So, I think that the best solution is to have a parameter that says in which position after the decimal point you apply a round-half-up rounding. If you do not specify this parameter, you get an exact conversion. In this way:: Decimal(1.1, 2) == Decimal('1.1') Decimal(1.1, 16) == Decimal('1.1000000000000001') Decimal(1.1) == Decimal('110000000000000008881784197001252...e-51') **From tuples**: Aahz suggested to construct from tuples: it's easier to implement ``eval()``'s round trip and "someone who has numeric values representing a Decimal does not need to convert them to a string." The structure will be a tuple of three elements: sign, number and exponent. The sign is 1 or 0, the number is a tuple of decimal digits and the exponent is a signed int or long:: Decimal((1, (3, 2, 2, 5), -2)) # for -32.25 **From Decimal**: No mystery here, just a copy. **Syntax to all the cases**:: Decimal(value, [decimal_digits]) where ``value`` can be any of the data types just mentioned and ``decimal_digits`` is allowed only when value is float. Implicit construction --------------------- As the implicit construction is the consequence of an operation, it will be affected by the context as is detailed in each point. John Roth suggested that "The other type should be handled in the same way the decimal() constructor would handle it". But Alex Martelli thinks that this total breach with Python tradition would be a terrible mistake. 23+"43" is NOT handled in the same way as 23+int("45"), and a VERY good thing that is too. It's a completely different thing for a user to EXPLICITLY indicate they want construction (conversion) and to just happen to sum two objects one of which by mistake could be a string. So, here I define the behaviour again for each data type. **From int or long**: Aahz suggested the need of an explicit conversion from int, but also thinks it's OK if the precision in the current Context is not exceeded; in that case you raise ValueError. Votes in comp.lang.python agreed with this. **From string**: Everybody agrees to raise an exception here. **From float**: Aahz is strongly opposed to interact with float, suggesting an explicit conversion: The problem is that Decimal is capable of greater precision, accuracy, and range than float. But in Python it's OK to do ``35 + 1.1``, so why can't I do ``Decimal(35) + 1.1``? We agree that when a naive user writes ``1.1`` doesn't know that he's being inexact, but that happens in the both examples I just mentioned. So, what should we do? I propose to allow the interaction with float, making an exact conversion and raising ValueError if exceeds the precision in the current context (this is maybe too tricky, because for example with a precision of 9, ``Decimal(35) + 1.2`` is OK but ``Decimal(35) + 1.1`` raises an error). **From Decimal**: There isn't any issue here. Use of Context -------------- In the last pre-PEP I said that "The Context must be omnipresent, meaning that changes to it affects all the current and future Decimal instances". I was wrong. In response, John Roth said: The context should be selectable for the particular usage. That is, it should be possible to have several different contexts in play at one time in an application. In comp.lang.python, Aahz explained that the idea is to have a "context per thread". So, all the instances of a thread belongs to a context, and you can change a context in thread A (and the behaviour of the instances of that thread) without changing nothing in thread B. Also, and again correcting me, he said: (the) Context applies only to operations, not to Decimal instances; changing the Context does not affect existing instances if there are no operations on them. Arguing about special cases when there's need to perform operations with other rules that those of the current context, Tim Peters said that the context will have the operations as methods. This way, the user "can create whatever private context object(s) it needs, and spell arithmetic as explicit method calls on its private context object(s), so that the default thread context object is neither consulted nor modified". Python Usability ---------------- - Decimal should support the basic arithmetic (``+, -, *, /, //, **, %, divmod``) and comparison (``==, !=, <, >, <=, >=, cmp``) operators in the following cases (check `Implicit Construction`_ to see what types could OtherType be, and what happens in each case): - Decimal op Decimal - Decimal op otherType - otherType op Decimal - Decimal op= Decimal - Decimal op= otherType - Decimal should support unary operators (``-, +, abs``). - Decimal should support the built-in methods: - min, max - float, int, long - str, repr - hash - copy, deepcopy - bool (0 is false, otherwise true) - Calling repr() should do round trip, meaning that:: m = Decimal(...) m == eval(repr(m)) - Decimal should be immutable. Reference Implementation ======================== To be included later: - code - test code - documentation References ========== .. [1] ANSI standard X3.274-1996 (Programming Language REXX): http://www.rexxla.org/Standards/ansi.html .. [2] General Decimal Arithmetic specification (Cowlishaw): http://www2.hursley.ibm.com/decimal/decarith.html (related documents and links at http://www2.hursley.ibm.com/decimal/) .. [3] ANSI/IEEE standard 854-1987 (Radix-Independent Floating-Point Arithmetic): http://www.cs.berkeley.edu/~ejr/projects/754/private/drafts/854-1987/dir.ht… (unofficial text; official copies can be ordered from http://standards.ieee.org/catalog/ordering.html) .. [4] Tim Peter's FixedPoint at SourceForge: http://fixedpoint.sourceforge.net/ .. [5] IEEE 754 revision: http://grouper.ieee.org/groups/754/revision.html .. [6] IEEE 754 references: http://babbage.cs.qc.edu/courses/cs341/IEEE-754references.html Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 End:

1 0

python/dist/src/Doc Makefile.deps,1.115,1.116
by fdrake＠projects.sourceforge.net 29 Jan '04

29 Jan '04

Update of /cvsroot/python/python/dist/src/Doc In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30594 Modified Files: Makefile.deps Log Message: update dependency information Index: Makefile.deps =================================================================== RCS file: /cvsroot/python/python/dist/src/Doc/Makefile.deps,v retrieving revision 1.115 retrieving revision 1.116 diff -C2 -d -r1.115 -r1.116 *** Makefile.deps 21 Oct 2003 17:25:05 -0000 1.115 --- Makefile.deps 29 Jan 2004 15:13:08 -0000 1.116 *************** *** 285,288 **** --- 285,289 ---- lib/libpopen2.tex \ lib/libbisect.tex \ + lib/libcollections.tex \ lib/libheapq.tex \ lib/libmimetypes.tex \

1 0

python/dist/src/Doc/lib lib.tex,1.224,1.225
by rhettinger＠projects.sourceforge.net 29 Jan '04

29 Jan '04

Update of /cvsroot/python/python/dist/src/Doc/lib In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv10447 Modified Files: lib.tex Log Message: Add documentation for collections.deque(). Index: lib.tex =================================================================== RCS file: /cvsroot/python/python/dist/src/Doc/lib/lib.tex,v retrieving revision 1.224 retrieving revision 1.225 diff -C2 -d -r1.224 -r1.225 *** lib.tex 14 Oct 2003 21:45:59 -0000 1.224 --- lib.tex 29 Jan 2004 07:35:45 -0000 1.225 *************** *** 126,129 **** --- 126,130 ---- \input{libwhrandom} \input{libbisect} + \input{libcollections} \input{libheapq} \input{libarray}

1 0