From noreply at sourceforge.net Wed Sep 1 00:08:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 00:08:31 2004 Subject: [Patches] [ python-Patches-1020042 ] Bad test for HAVE_UINTPTR_T in PC/pyconfig.h Message-ID: Patches item #1020042, was opened at 2004-08-31 22:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020042&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Scott David Daniels (scott_daniels) Assigned to: Nobody/Anonymous (nobody) Summary: Bad test for HAVE_UINTPTR_T in PC/pyconfig.h Initial Comment: In python 2.4.a2 on Win2K, There is a test (encased in an "#if MS_WIN32" block) that goes awry. The original code (around line 270 of PC/pyconfig.h) is: /* VC 7.1 has them and VC 6.0 does not. VC 6.0 has a version number of 1200. If some compiler does not provide them, modify the #if appropriately. */ #if _MSC_VER != 1200 #define HAVE_UINTPTR_T 1 #define HAVE_INTPTR_T 1 #endif MinGW has trouble compiling with this code. Unless you have VC 6.0, this presumes you have uintptr_t and intptr_t available. From what I can find out (including a message from MvL), I believe the code should really be: #if HAVE_STDINT_H #define HAVE_UINTPTR_T 1 #define HAVE_INTPTR_T 1 #endif However, I don't have VC 7.1 to test this theory out. A more conservative change would be to: #if _MSC_VER > 1200 #define HAVE_UINTPTR_T 1 #define HAVE_INTPTR_T 1 #elif HAVE_STDINT_H #define HAVE_UINTPTR_T 1 #define HAVE_INTPTR_T 1 #endif Essentially, the problem is whether a type name has been defined or not. The C99 standard dictates that the types uintptr_t and intptr_t be available through #include . Some systems have stdint.h, others don't. Old MinGW systems do not (e.g. 2.95); new ones do (e.g. 3.2.3). Martin von Loewis tells me the library libc6 is responsible for having this file or not, so it is not really a compiler thing at all. HAVE_STDINT_H should cover all cases. If you can install python 2.4 and compile (with distlib) _any_ C extension, that compiler (the one used by distlib) works correctly. When the problem occurs, the C compiler fails inside declarations included by Python.h. I've tried this with the MinGW 2.95 and 3.2.3. Even changing the #if _MSC_VER != 1200 to #if _MSC_VER > 1200 is good enough (C preprocessing rules make undefined _MSC_VER != 1200 behave unfortunately) to work, but _if_ the STDINT_H version works for VC 6.0 and 7.1, I favor that (it is testing the correct thing). If _any_ C extension can be successfully compiled on a windows box using the distributed pyconfig.h and a particular compiler, the problem has been solved for that compiler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020042&group_id=5470 From noreply at sourceforge.net Wed Sep 1 07:33:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 07:33:05 2004 Subject: [Patches] [ python-Patches-1020185 ] Py_CLEAR to implicitly cast its argument to PyObject * Message-ID: Patches item #1020185, was opened at 2004-09-01 05:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020185&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: Py_CLEAR to implicitly cast its argument to PyObject * Initial Comment: Py_CLEAR assigns its argument to a PyObject pointer without a cast. This causes a warning if the argument is PyObject- compatible but not actually a PyObject. The other reference counting macros accept non-PyObjects without a cast by the user, so Py_CLEAR should too. The patch is hard to read since it realigns the backslashes on the macro. diff -b (ignore whitespace) is good in these cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020185&group_id=5470 From noreply at sourceforge.net Wed Sep 1 07:35:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 07:35:40 2004 Subject: [Patches] [ python-Patches-1020188 ] Use Py_CLEAR where necessary to avoid crashes Message-ID: Patches item #1020188, was opened at 2004-09-01 05:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020188&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: Use Py_CLEAR where necessary to avoid crashes Initial Comment: The Py_CLEAR macro was introduced to make it less tempting to write incorrect code in the form Py_DECREF(self->field); self->field = NULL; because that can expose a half-destroyed object if deallocation can cause self->field to be read. This patch fixes mistakes like this that still exist in the core. Only cases that are potentially dangerous are fixed in this patch. If self->field can only reference a special kind of [builtin] object, then it's just a style bug because we know that the builtin object isn't evil. Likewise if the code is operating on an automatic variable. It might be nice to fix those style bugs anyway, to discourage the broken idiom. Just for kicks, here's a way to use this bug in reversed to crash the interpreter: import array, gc, weakref a = array.array('c') wr = weakref.ref(a, lambda _: gc.get_referents(rev)) rev = reversed(a) del a list(rev) For me, this crashes immediately with a debug build and after a couple tries otherwise. Also attached is clearcand.py to help find these cases. It's not comprehensive, but it's a start. Usage: $ find src -name '*.c' | python clearcand.py | fgrep -- '->' The patch requires SF #1020185 to be applied for genobject.c to compile without warnings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020188&group_id=5470 From noreply at sourceforge.net Wed Sep 1 09:06:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 09:06:06 2004 Subject: [Patches] [ python-Patches-1020188 ] Use Py_CLEAR where necessary to avoid crashes Message-ID: Patches item #1020188, was opened at 2004-09-01 00:35 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020188&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: Use Py_CLEAR where necessary to avoid crashes Initial Comment: The Py_CLEAR macro was introduced to make it less tempting to write incorrect code in the form Py_DECREF(self->field); self->field = NULL; because that can expose a half-destroyed object if deallocation can cause self->field to be read. This patch fixes mistakes like this that still exist in the core. Only cases that are potentially dangerous are fixed in this patch. If self->field can only reference a special kind of [builtin] object, then it's just a style bug because we know that the builtin object isn't evil. Likewise if the code is operating on an automatic variable. It might be nice to fix those style bugs anyway, to discourage the broken idiom. Just for kicks, here's a way to use this bug in reversed to crash the interpreter: import array, gc, weakref a = array.array('c') wr = weakref.ref(a, lambda _: gc.get_referents(rev)) rev = reversed(a) del a list(rev) For me, this crashes immediately with a debug build and after a couple tries otherwise. Also attached is clearcand.py to help find these cases. It's not comprehensive, but it's a start. Usage: $ find src -name '*.c' | python clearcand.py | fgrep -- '->' The patch requires SF #1020185 to be applied for genobject.c to compile without warnings. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-01 02:06 Message: Logged In: YES user_id=80475 Accepted and applied. See: Include/object.h 2.129 Modules/itertoolsmodule.c 1.35 Objects/enumobject.c 1.18 Objects/genobject.c 1.4 Objects/iterobject.c 1.19 Thanks for the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020188&group_id=5470 From noreply at sourceforge.net Wed Sep 1 09:16:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 09:16:36 2004 Subject: [Patches] [ python-Patches-1020185 ] Py_CLEAR to implicitly cast its argument to PyObject * Message-ID: Patches item #1020185, was opened at 2004-09-01 00:33 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020185&group_id=5470 Category: Core (C code) >Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: Py_CLEAR to implicitly cast its argument to PyObject * Initial Comment: Py_CLEAR assigns its argument to a PyObject pointer without a cast. This causes a warning if the argument is PyObject- compatible but not actually a PyObject. The other reference counting macros accept non-PyObjects without a cast by the user, so Py_CLEAR should too. The patch is hard to read since it realigns the backslashes on the macro. diff -b (ignore whitespace) is good in these cases. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-01 02:16 Message: Logged In: YES user_id=80475 Accepted and applied (without re-aligning the backslashes). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020185&group_id=5470 From noreply at sourceforge.net Wed Sep 1 11:32:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 11:32:45 2004 Subject: [Patches] [ python-Patches-1013835 ] Implementation for PEP 318 using syntax J2 Message-ID: Patches item #1013835, was opened at 2004-08-22 16:39 Message generated for change (Comment added) made by ms_ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1013835&group_id=5470 Category: Parser/Compiler Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Michael (ms_) Assigned to: Nobody/Anonymous (nobody) Summary: Implementation for PEP 318 using syntax J2 Initial Comment: This patch implements decorator syntax J2 from http://www.python.org/moin/PythonDecorators Example: class Foo: decorate: staticmethod deprecated memoize author("Joe Bloggs") def foo(bar): pass Key changes: * Grammar/Grammar updated * Python/compile.c updated. * Test suite, docs and Lib updated. (test suite passes on my linux box) Specific changes: * Grammar/Grammar changed to recognise J2 syntax * Python/compile.c changed to support J2 * Removed "@" from Lib/tokenize.py as Special * Removed "AT" from joe Include/token.h as a token * Removed "AT" from Parser/tokenizer.c * Doc/lib/libfuncs.tex - Changed examples from @ format to decorate: format * Doc/ref/ref7.tex - changed Function Definitions production rules to match the change in syntax. - Changed example to use the change in syntax. * Lib/compiler/transformer.py - Modified to handle the new syntax * Lib/test/test_parser.py - Changed tests for old syntax to check new form * Lib/test/tokenize_tests.txt - changed @staticmethod to J2 format * Lib/test/output/test_tokenize - Changed to match the changed test file * Modules/parsermodule.c - Changed to support new Grammar * Lib/test/pyclbr_input.py - Changed from @ syntax to decorate: syntax * Lib/test/test_decorators.py - changed all "decorate" functions to decorate_ and all @ usages to "decorate:" syntax. Files checked, but not changed: * Doc/lib/asttable.tex - Can't see any necessary changes * Lib/compiler/pycodegen.py - Can't see any necessary changes * Lib/compiler/symbols.py - Can't see any necessary changes * Tools/compiler/ast.txt - Can't see any necessary changes * Tools/compiler/astgen.py - Can't see any necessary changes * Tools/compiler/regrtest.py - No changes NB: * I can't see whether ast.py should/should not be changed and if it should, *how* it should be changed, as a result I've left well alone. Issues: * Keyword clash with test suite is bad - suggest change to "using" to limit clash with existing user code as far as possible. I intend to follow this up with a replacement with a changed keyword and if possible shortened/simplified version. * Patch is against the vanilla 2.4a2 download from python.org, does this need changing to being a patch against the current CVS head? (I suspect the answer to this is "yes") * The following tests are skipped on my machine: test_aepack test_al test_applesingle test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_gdbm test_gl test_imgfile test_largefile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_tcl test_timeout test_urllibnet test_winreg test_winsound As a result I don't know for certain these aren't affected by the change. I'm checking them by hand at present. ---------------------------------------------------------------------- >Comment By: Michael (ms_) Date: 2004-09-01 10:32 Message: Logged In: YES user_id=994316 From: http://mail.python.org/pipermail/python-dev/2004-September/048518.html Guido wrote: "I've read the J2 proposal up and down several times, pondered all the issues, and slept on it for a night, and I still don't like it enough to accept it." I'm closing this patch as a result, I hope that's the right thing to do. ---------------------------------------------------------------------- Comment By: Michael (ms_) Date: 2004-08-26 17:19 Message: Logged In: YES user_id=994316 The updated patch is against anon CVS as of 26 Aug 2004, 17:00. This patch leaves the keyword unchanged as "using". All tests pass on my machine (with "make testall"). The key change is that the keyword - and hence decorators must now be actively switched on using a "from __future__ import decorators" statement. The code using this is heavily based on the same approach that "from __future__ import generators" took -- indeed reusing as much as possible. I suspect that it might be wise to have more tests regarding decorators, and the docs might need a small amount of work, any feedback welcome on this point. ---------------------------------------------------------------------- Comment By: Michael (ms_) Date: 2004-08-26 17:13 Message: Logged In: YES user_id=994316 ---------------------------------------------------------------------- Comment By: Michael (ms_) Date: 2004-08-25 21:17 Message: Logged In: YES user_id=994316 Updated patch against anonymous CVS. Covers the same files as before, with the addition of changes to test_inspect.py, and inspect.py. inspect.py was updated to handle the paired decorate/def blocks. Specifically this required changes to getblock such that if getblock is called on a decorated function that both blocks are returned rather than just the function or just the decorator suite. This is to preserve the same behaviour as the current inspect behaviour. Also: * changed keyword to "using" * Eliminated the single clash in the library that uses "using" as a variable. (webbrowser.py has a function "get" that has "using" as a single named parameter. AFAICT no google findable source file uses this parameter) * implemented the short form: using: trace def someFunction(someThing): doStuff(someThing) * Decorators are single decorator per line - as per current CVS, which means the short form only takes 1 decorator. All tests except test_distutils pass. Since this appear to fail in Anon CVS without this patch that failure looks unrelated. Remaining issues(?): * It's been suggested that this should be activated by a __future__ declaration. I'm currently looking at how to do this. * Extra docs on short form would probably be a good idea. (Docs are already updated otherwise) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1013835&group_id=5470 From noreply at sourceforge.net Wed Sep 1 14:32:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 14:32:55 2004 Subject: [Patches] [ python-Patches-1020188 ] Use Py_CLEAR where necessary to avoid crashes Message-ID: Patches item #1020188, was opened at 2004-09-01 06:35 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020188&group_id=5470 Category: Core (C code) Group: None >Status: Open Resolution: Accepted Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: Use Py_CLEAR where necessary to avoid crashes Initial Comment: The Py_CLEAR macro was introduced to make it less tempting to write incorrect code in the form Py_DECREF(self->field); self->field = NULL; because that can expose a half-destroyed object if deallocation can cause self->field to be read. This patch fixes mistakes like this that still exist in the core. Only cases that are potentially dangerous are fixed in this patch. If self->field can only reference a special kind of [builtin] object, then it's just a style bug because we know that the builtin object isn't evil. Likewise if the code is operating on an automatic variable. It might be nice to fix those style bugs anyway, to discourage the broken idiom. Just for kicks, here's a way to use this bug in reversed to crash the interpreter: import array, gc, weakref a = array.array('c') wr = weakref.ref(a, lambda _: gc.get_referents(rev)) rev = reversed(a) del a list(rev) For me, this crashes immediately with a debug build and after a couple tries otherwise. Also attached is clearcand.py to help find these cases. It's not comprehensive, but it's a start. Usage: $ find src -name '*.c' | python clearcand.py | fgrep -- '->' The patch requires SF #1020185 to be applied for genobject.c to compile without warnings. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-09-01 13:32 Message: Logged In: YES user_id=6656 Test cases would be nice. If it's easy for someone whose thought about it, that would be great, if not assign to me and I'll get to it... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-01 08:06 Message: Logged In: YES user_id=80475 Accepted and applied. See: Include/object.h 2.129 Modules/itertoolsmodule.c 1.35 Objects/enumobject.c 1.18 Objects/genobject.c 1.4 Objects/iterobject.c 1.19 Thanks for the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020188&group_id=5470 From noreply at sourceforge.net Wed Sep 1 17:10:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 17:10:59 2004 Subject: [Patches] [ python-Patches-1010677 ] thread Module Breaks PyGILState_Ensure() Message-ID: Patches item #1010677, was opened at 2004-08-17 04:08 Message generated for change (Comment added) made by zilche You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1010677&group_id=5470 Category: Modules Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 7 Submitted By: Phil Thompson (philthompson10) Assigned to: Mark Hammond (mhammond) Summary: thread Module Breaks PyGILState_Ensure() Initial Comment: The thread module creates thread states that PyGILState_Ensure() doesn't know about. This means that the latter can try to acquire the GIL when it already has it - resulting in a deadlock. ---------------------------------------------------------------------- Comment By: Johan Dahlin (zilche) Date: 2004-09-01 07:10 Message: Logged In: YES user_id=132216 Can this be backported release23-maint as well? PyGTK suffers quite badly from this. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-08-24 14:24 Message: Logged In: YES user_id=14198 Fixed - thanks! Checking in Modules/threadmodule.c; new revision: 2.59; previous revision: 2.58 Checking in Lib/test/test_capi.py; new revision: 1.7; previous revision: 1.6 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-24 05:14 Message: Logged In: YES user_id=29957 Boosting to pri 7 for pre-2.4 inclusion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1010677&group_id=5470 From noreply at sourceforge.net Wed Sep 1 19:27:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 19:27:57 2004 Subject: [Patches] [ python-Patches-1020188 ] Use Py_CLEAR where necessary to avoid crashes Message-ID: Patches item #1020188, was opened at 2004-09-01 00:35 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020188&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Dima Dorfman (ddorfman) >Assigned to: Michael Hudson (mwh) Summary: Use Py_CLEAR where necessary to avoid crashes Initial Comment: The Py_CLEAR macro was introduced to make it less tempting to write incorrect code in the form Py_DECREF(self->field); self->field = NULL; because that can expose a half-destroyed object if deallocation can cause self->field to be read. This patch fixes mistakes like this that still exist in the core. Only cases that are potentially dangerous are fixed in this patch. If self->field can only reference a special kind of [builtin] object, then it's just a style bug because we know that the builtin object isn't evil. Likewise if the code is operating on an automatic variable. It might be nice to fix those style bugs anyway, to discourage the broken idiom. Just for kicks, here's a way to use this bug in reversed to crash the interpreter: import array, gc, weakref a = array.array('c') wr = weakref.ref(a, lambda _: gc.get_referents(rev)) rev = reversed(a) del a list(rev) For me, this crashes immediately with a debug build and after a couple tries otherwise. Also attached is clearcand.py to help find these cases. It's not comprehensive, but it's a start. Usage: $ find src -name '*.c' | python clearcand.py | fgrep -- '->' The patch requires SF #1020185 to be applied for genobject.c to compile without warnings. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-01 07:32 Message: Logged In: YES user_id=6656 Test cases would be nice. If it's easy for someone whose thought about it, that would be great, if not assign to me and I'll get to it... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-01 02:06 Message: Logged In: YES user_id=80475 Accepted and applied. See: Include/object.h 2.129 Modules/itertoolsmodule.c 1.35 Objects/enumobject.c 1.18 Objects/genobject.c 1.4 Objects/iterobject.c 1.19 Thanks for the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020188&group_id=5470 From noreply at sourceforge.net Thu Sep 2 00:32:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 2 00:32:30 2004 Subject: [Patches] [ python-Patches-1010677 ] thread Module Breaks PyGILState_Ensure() Message-ID: Patches item #1010677, was opened at 2004-08-17 22:08 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1010677&group_id=5470 Category: Modules Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 7 Submitted By: Phil Thompson (philthompson10) Assigned to: Mark Hammond (mhammond) Summary: thread Module Breaks PyGILState_Ensure() Initial Comment: The thread module creates thread states that PyGILState_Ensure() doesn't know about. This means that the latter can try to acquire the GIL when it already has it - resulting in a deadlock. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-09-02 08:32 Message: Logged In: YES user_id=14198 Checked into 2.3 maint branch: Checking in Lib/test/test_capi.py; new revision: 1.6.10.1; previous revision: 1.6 Checking in Modules/threadmodule.c; new revision: 2.56.8.1; previous revision: 2.56 ---------------------------------------------------------------------- Comment By: Johan Dahlin (zilche) Date: 2004-09-02 01:10 Message: Logged In: YES user_id=132216 Can this be backported release23-maint as well? PyGTK suffers quite badly from this. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-08-25 08:24 Message: Logged In: YES user_id=14198 Fixed - thanks! Checking in Modules/threadmodule.c; new revision: 2.59; previous revision: 2.58 Checking in Lib/test/test_capi.py; new revision: 1.7; previous revision: 1.6 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-24 23:14 Message: Logged In: YES user_id=29957 Boosting to pri 7 for pre-2.4 inclusion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1010677&group_id=5470 From noreply at sourceforge.net Thu Sep 2 02:08:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 2 02:08:10 2004 Subject: [Patches] [ python-Patches-1020845 ] Decimal performance enhancements Message-ID: Patches item #1020845, was opened at 2004-09-02 10:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Decimal performance enhancements Initial Comment: The attached patch implements a collection of performance enhancements for decimal.py. They are currently focused on the performance of the telco benchmark in the sandbox (i.e. they aim to speed up instantiation, addition, multiplication and quantization). The main strategy used (a subclass for NaN and infinite values) can be extended to encompass more methods in order to improve performance in other situations. There is one non-performance related change included - the '_sign' attribute is renamed to '_isneg' to better reflect the boolean nature of the property. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 From noreply at sourceforge.net Thu Sep 2 02:11:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 2 02:11:29 2004 Subject: [Patches] [ python-Patches-1020845 ] Decimal performance enhancements Message-ID: Patches item #1020845, was opened at 2004-09-02 10:08 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Decimal performance enhancements Initial Comment: The attached patch implements a collection of performance enhancements for decimal.py. They are currently focused on the performance of the telco benchmark in the sandbox (i.e. they aim to speed up instantiation, addition, multiplication and quantization). The main strategy used (a subclass for NaN and infinite values) can be extended to encompass more methods in order to improve performance in other situations. There is one non-performance related change included - the '_sign' attribute is renamed to '_isneg' to better reflect the boolean nature of the property. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-02 10:11 Message: Logged In: YES user_id=1038590 I forgot to add that this is NOT yet a production quality patch. The doc strings, in particular, need work. I'm mainly posting it so Raymond can have a look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 From noreply at sourceforge.net Thu Sep 2 02:11:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 2 02:12:03 2004 Subject: [Patches] [ python-Patches-1020845 ] Decimal performance enhancements Message-ID: Patches item #1020845, was opened at 2004-09-02 10:08 Message generated for change (Settings changed) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) >Assigned to: Raymond Hettinger (rhettinger) Summary: Decimal performance enhancements Initial Comment: The attached patch implements a collection of performance enhancements for decimal.py. They are currently focused on the performance of the telco benchmark in the sandbox (i.e. they aim to speed up instantiation, addition, multiplication and quantization). The main strategy used (a subclass for NaN and infinite values) can be extended to encompass more methods in order to improve performance in other situations. There is one non-performance related change included - the '_sign' attribute is renamed to '_isneg' to better reflect the boolean nature of the property. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-02 10:11 Message: Logged In: YES user_id=1038590 I forgot to add that this is NOT yet a production quality patch. The doc strings, in particular, need work. I'm mainly posting it so Raymond can have a look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 From noreply at sourceforge.net Thu Sep 2 07:18:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 2 07:18:33 2004 Subject: [Patches] [ python-Patches-1020845 ] Decimal performance enhancements Message-ID: Patches item #1020845, was opened at 2004-09-01 19:08 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Raymond Hettinger (rhettinger) Summary: Decimal performance enhancements Initial Comment: The attached patch implements a collection of performance enhancements for decimal.py. They are currently focused on the performance of the telco benchmark in the sandbox (i.e. they aim to speed up instantiation, addition, multiplication and quantization). The main strategy used (a subclass for NaN and infinite values) can be extended to encompass more methods in order to improve performance in other situations. There is one non-performance related change included - the '_sign' attribute is renamed to '_isneg' to better reflect the boolean nature of the property. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-02 00:18 Message: Logged In: YES user_id=80475 Nice job. The timings do improve and the approach is reasonable. Please go ahead to the next step and polish it up. Also, please change _isneg back to _sign. That matches the terminology in the spec, the machine centric sign bit viewpoint of 754R, and the components of the user visible as_tuple() method. The goal is to make the patch as minimal as possible, to keep the API unchanged, and improve performance. Using the __new__ method was smart. That more closely corresponds to a potential C implementation of an immutable type. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-01 19:11 Message: Logged In: YES user_id=1038590 I forgot to add that this is NOT yet a production quality patch. The doc strings, in particular, need work. I'm mainly posting it so Raymond can have a look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 From noreply at sourceforge.net Thu Sep 2 15:14:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 2 15:14:52 2004 Subject: [Patches] [ python-Patches-1015989 ] compiler.transformer: correct lineno attribute when possible Message-ID: Patches item #1015989, was opened at 2004-08-25 14:00 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1015989&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thenault Sylvain (syt) >Assigned to: Jeremy Hylton (jhylton) Summary: compiler.transformer: correct lineno attribute when possible Initial Comment: this patch try to fix the lineno attribute of some ast nodes whenever possible. I'm not sure this patch fix all relevant cases, but at least it fixes the most obvious ones. I would like to have at the end a correct line number on every nodes but Module (some program such as Pylint are using this package and need to have this information correctly). A test module is also joined. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1015989&group_id=5470 From noreply at sourceforge.net Thu Sep 2 15:15:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 2 15:15:50 2004 Subject: [Patches] [ python-Patches-988642 ] Update HTTPRespnse.length Message-ID: Patches item #988642, was opened at 2004-07-10 21:16 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988642&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Jeremy Hylton (jhylton) Summary: Update HTTPRespnse.length Initial Comment: Update length attribute correctly when read() returns less than the expected number of bytes. Addresses bug # 988120 ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2004-09-02 13:15 Message: Logged In: YES user_id=31392 I will take a look. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 20:59 Message: Logged In: YES user_id=11375 Jeremy, you know about HTTP stuff, right? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2004-07-10 22:36 Message: Logged In: YES user_id=261020 Patch basically looks good, but I'm worrying about the bit of code in the current httplib.py, in the block commented with '# unbounded read'. Why the switch on .will_close? Shouldn't the switch be on (self.length is None), instead? I could well be missing something, but this looks like another bug of the same kind as in the original report. Also, how about the various .readline() calls? Might they also return less than a full line? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988642&group_id=5470 From noreply at sourceforge.net Thu Sep 2 15:19:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 2 15:19:53 2004 Subject: [Patches] [ python-Patches-932935 ] doctest: allow custom matchers for testing if got==want Message-ID: Patches item #932935, was opened at 2004-04-10 19:57 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=932935&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Edward Loper (edloper) >Assigned to: Edward Loper (edloper) Summary: doctest: allow custom matchers for testing if got==want Initial Comment: To determine the success of a doctest example, doctest compares the actual output to the expected output. The test succeeds if the two match exactly. This patch gives the user the ability to supply a custom "matcher" function, which will be used instead of string equality to test whether the test succeeds. This function should take two string parameters, "got" and "want", which will contain the actual and expected output, respectively; and it should return True if they should be considered to match (i.e., test succeeds), and False if they should not (i.e., test fails). Two sample matcher functions are provided, as well: - match_ignoring_whitespace returns true if the actual output and expected output are equal, ignoring differences in amount of whitespace (eg 2 spaces vs 1). - match_ignoring_trailing_blanklines returns true if the actual output and expected output are equal, once any trailing blank lines are discarded. This can be useful with the END_WITH_DEDENT option, suggested in patch #932933 [1] The patch was made avainst revision 1.33 of doctest.py. [1] http://sourceforge.net/tracker/index.php? func=detail&aid=932933&group_id=5470&atid=3054 70 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-05-31 19:04 Message: Logged In: YES user_id=21627 Please resubmit the patch using unified diffs. You might just as well include test cases and documentation right away. ---------------------------------------------------------------------- Comment By: Edward Loper (edloper) Date: 2004-04-10 20:00 Message: Logged In: YES user_id=195958 If this patch looks good, I'd be happy to write a patch for the docs & test cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=932935&group_id=5470 From noreply at sourceforge.net Thu Sep 2 15:20:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 2 15:20:37 2004 Subject: [Patches] [ python-Patches-972322 ] urllib2 handler naming convention collision Message-ID: Patches item #972322, was opened at 2004-06-13 23:16 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972322&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) >Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 handler naming convention collision Initial Comment: The method naming conventions of *_open and *_request in urllib2 are accidentally met by the following methods: AbstractHTTPHandler.do_open() ProxyHandler.proxy_open() AbstractHTTPHandler.redirect_request() So URLs like do://example.com/ are regarded as having a handler, and urllib2.urlopen("do://python.org/") causes a TypeError. I think *something* should be done about this, but I'm willing to provide a different patch if this one is frowned upon. The alternative would be to rename do_open and proxy_open, and leave the redirect_request case unchanged (see below for why). The first two methods are undocumented, so could in theory be renamed. However, people will likely be overriding them anyway, so perhaps it's better to apply this ugly patch than rename them. redirect_request is documented, so can't be renamed, but it will never be accidentally called unless somebody actually adds a handler with a method named "redirect_open". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=972322&group_id=5470 From noreply at sourceforge.net Thu Sep 2 15:20:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 2 15:20:53 2004 Subject: [Patches] [ python-Patches-932932 ] doctest: Add Tester params to DocTestSuite Message-ID: Patches item #932932, was opened at 2004-04-10 19:56 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=932932&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Edward Loper (edloper) >Assigned to: Edward Loper (edloper) Summary: doctest: Add Tester params to DocTestSuite Initial Comment: This diff adds the following parameters to DocTestSuite: globs, verbose, isprivate, optionflags. The new parameters are simply passed on to the Tester object that the DocTestSuite wraps. This match was made against revision 1.33 of doctest.py ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-05-31 19:05 Message: Logged In: YES user_id=21627 The patch looks good in principle. Please submit test cases and documentation. ---------------------------------------------------------------------- Comment By: Edward Loper (edloper) Date: 2004-04-10 19:59 Message: Logged In: YES user_id=195958 If this patch looks good, I'd be happy to write a patch for the docs & test cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=932932&group_id=5470 From paulagrassi203 at hotmail.com Thu Sep 2 20:11:53 2004 From: paulagrassi203 at hotmail.com (Paula Bernardes) Date: Thu Sep 2 20:11:45 2004 Subject: [Patches] =?iso-8859-1?q?Divulga=E7=E3o_em_sites_de_busca_-_Mark?= =?iso-8859-1?q?eting_por_e-mail_-_Cadastramento_de_homepages_em_bu?= =?iso-8859-1?q?scadores?= Message-ID: <20040902181144.09CF51E4002@bag.python.org> Visite agora: http://www.divulgamail.mx.gs Divulga??o da Home Page em Sites de Busca, Divulga??o Sites Como divulgar home pages como divulgar sites como divulgar meu site, dicas de divulga??o de sites. Otimiza??o e posicionamento no Google. Mala direta e-mail, email regi?es, e-mails regi?o, mala direta por email, marketing e-mail, regi?es, cadastro e-mails, publicidade por email, emails regi?o, divulgar, enviar emails, campanha emails, propaganda emails, email cidade, envio an?nimo emails, email estados, divulgar e-mail, programas emails, e-mails por estados, e-mails cidade, cadastro e-mail, mala direta por e-mail, listas emails, e-mail regi?es, propaganda email, enviar email an?nimo, envio mala direta, estados, campanha, cidade, envio, publicidade e-mails, Visite agora: http://www.divulgamail.mx.gs Divulga??o da Home Page em Sites de Busca, Divulga??o Sites Como divulgar home pages como divulgar sites como divulgar meu site, dicas de divulga??o de sites. Otimiza??o e posicionamento no Google. campanhas e-mail, lista e-mail, programas e-mails, e-mails estado, publicidade emails, marketing digital, cidade, divulgar, lista email, emails estados, propaganda digital e-mails, e-mail por regi?es, e-mails por cidades, email cidades, campanha e-mail, e-mail estado, listas email, lista emails, propaganda por e-mails, mala direta email, publicidade, cidades, marketing emails, cidade, email por regi?es, envio propaganda, listas e-mails, e-mails regi?es, divulgar e-mails, envio mala-direta, e-mail cidades, email estado, e-mails por Visite agora: http://www.divulgamail.mx.gs Divulga??o da Home Page em Sites de Busca, Divulga??o Sites Como divulgar home pages como divulgar sites como divulgar meu site, dicas de divulga??o de sites. Otimiza??o e posicionamento no Google. Regi?o, marketing por emails, propaganda, software email em massa, propaganda digital e-mail, programas email, email, mala direta, propaganda e-mail, marketing e-mails, e-mail, mala-direta email, propaganda digital, emails por regi?o, email segmentado, estado, campanhas e-mails, e-mails cidades, e-mails segmentados, email por estado, marketing por email, emails segmentado, divulga??o, e-mails estados, cidade, campanha e-mails, software, email segmentados, regi?o, enviar e-mails an?nimo, enviar emails an?nimo, mala direta emails, marketing email, emails segmentados, programas e-mail, e-mails por cidade, lista e-mails, propaganda, mala direta por e-mails, campanha email, software spam internet, Visite agora: http://www.divulgamail.mx.gs Divulga??o da Home Page em Sites de Busca, buscadores, Divulga??o Sites Como divulgar home pages como divulgar sites como divulgar meu site, dicas de divulga??o de sites. Otimiza??o e posicionamento no Google., e-mail regi?o, listas, listas segmentadas, marketing, marketing digital por emails, email regi?o, divulga??o e-mail, emails por cidade, mala-direta por email, marketing digital por e-mails, listas email, lista segmentada, cidades, cadastro email, divulgue seu produto, mala-direta por e-mails, e-mail por estado, segmentos, email por cidades, propaganda por e-mail, emails cidades, publicidade por emails, envio e-mail, e-mails por estado, mala direta, mala-direta, mala-direta por emails, e-mail segmentado, marketing digital emails, cidades, divulga??o e-mails, marketing, e-mail estados, cidades, marketing por e-mail, envio emails, marketing digital email, propaganda Visite agora: http://www.divulgamail.mx.gs por email, envio an?nimo email, divulgue sua propaganda, propaganda digital emails, cidade, emails por cidades, e-mails segmentado, propaganda por emails, divulgar email, e-mail cidade, enviar e-mails, e-mails, cadastro emails, e-mail por cidade, envio email, cadastro, lista, envio e-mails, propaganda digital email, publicidade por e-mails, marketing digital, e-mail por regi?o, email por estados, divulga??o, emails por estados, segmentados, mala-direta emails, envio publicidade, campanhas, mala direta por emails, e-mail por estados, marketing por e-mails, emails por estado, mala-direta e-mails, marketing digital e-mail, divulgar emails, emails regi?es, publicidade, email por regi?o, e-mails por regi?es, listas e-mail, divulga??o emails, mala-direta por e-mail, enviar e-mail, enviar email, Visite agora: http://www.divulgamail.mx.gs divulga??o email, cidades, publicidade por e-mail, enviar, emails por regi?es, marketing digital por e-mail, email por cidade, campanhas email, marketing digital por email, marketing digital e-mails, propaganda e-mails, e-mail segmentados, envio an?nimo e-mail, software publicidade internet, segmentados, envio an?nimo e-mails, lista mala direta, programa email an?nimo, mala direta internet, publicidade email, mala direta segmentada, emails segmentados, marketing digital, mala direta email, publicidade, spam, mala direta e-mail, email regi?es, e-mails regi?o, mala direta por email, marketing e-mail, regi?es, cadastro e-mails, publicidade por email, emails regi?o, divulgar, enviar emails, campanha emails, propaganda emails, email cidade, envio an?nimo emails, email estados, divulgar e-mail, programas emails, e-mails por estados, e-mails cidade, cadastro e-mail, mala direta por e-mail, listas emails, e-mail regi?es, propaganda email, enviar email an?nimo, envio Visite agora: http://www.divulgamail.mx.gs mala direta, estados, campanha, cidade, envio, publicidade e-mails, campanhas e-mail, lista e-mail, programas e-mails, e-mails estado, publicidade emails, marketing digital, cidade, divulgar, lista email, emails estados, propaganda digital e-mails, e-mail por regi?es, e-mails por cidades, email cidades, campanha e-mail, e-mail estado, listas email, lista emails, propaganda por e-mails, mala direta email, publicidade, cidades, marketing emails, cidade, email por regi?es, envio propaganda, listas e-mails, e-mails regi?es, divulgar e-mails, envio mala-direta, e-mail cidades, email estado, e-mails por regi?o, marketing por emails, propaganda, software email em massa, propaganda digital e-mail, programas email, email, mala direta, propaganda e-mail, marketing e-mails, e-mail, mala-direta email, propaganda Visite agora: http://www.divulgamail.mx.gs digital, emails por regi?o, email segmentado, estado, campanhas e-mails, e-mails cidades, e-mails segmentados, email por estado, marketing por email, emails segmentado, divulga??o, e-mails estados, cidade, campanha e-mails, software, email segmentados, regi?o, enviar e-mails an?nimo, enviar emails an?nimo, mala direta emails, marketing email, emails segmentados, programas e-mail, e-mails por cidade, lista e-mails, propaganda, mala direta por e-mails, campanha email, software spam internet, emails Visite agora: http://www.divulgamail.mx.gs estado, publicidade e-mail, e-mail por cidades, enviar e-mail an?nimo, software propaganda internet, emails cidade, emails, campanhas emails, mala-direta e-mail, publicidade email, mala direta e-mails, e-mail regi?o, listas, listas segmentadas, marketing, marketing digital por emails, email regi?o, divulga??o e-mail, emails por cidade, mala-direta por email, marketing digital por e-mails, listas email, lista segmentada, cidades, cadastro email, divulgue seu produto, mala-direta por e-mails, e-mail por estado, segmentos, email por cidades, propaganda por e-mail, emails cidades, publicidade por emails, envio e-mail, e- Visite agora: http://www.divulgamail.mx.gs mails por estado, mala direta, mala-direta, mala-direta por emails, e-mail segmentado, marketing digital emails, cidades, divulga??o e-mails, marketing, e-mail estados, cidades, marketing por e-mail, envio emails, marketing digital email, propaganda por email, envio an?nimo email, divulgue sua propaganda, propaganda digital emails, cidade, emails por cidades, e-mails segmentado, propaganda por emails, divulgar email, e-mail cidade, enviar e-mails, e-mails, cadastro emails, e-mail por cidade, envio email, cadastro, lista, envio e-mails, propaganda digital email, publicidade por e-mails, marketing digital, e-mail por regi?o, email por estados, divulga??o, emails por estados, segmentados, mala-direta emails, envio publicidade, campanhas, mala direta por emails, e-mail por estados, marketing por e- Visite agora: http://www.divulgamail.mx.gs mails, emails por estado, mala-direta e-mails, marketing digital e-mail, divulgar emails, emails regi?es, publicidade, email por regi?o, e-mails por regi?es, listas e-mail, divulga??o emails, mala-direta por e-mail, enviar e-mail, enviar email, divulga??o email, cidades, publicidade por e-mail, enviar, emails por regi?es, marketing digital por e-mail, email por cidade, campanhas email, marketing digital por email, marketing digital e-mails, propaganda e-mails, e-mail segmentados, envio an?nimo e-mail, software publicidade internet, segmentados, envio an?nimo e-mails, lista mala direta, programa email an?nimo, mala direta internet, publicidade email, mala direta segmentada, emails segmentados, marketing digital, mala direta email, publicidade, spam From noreply at sourceforge.net Thu Sep 2 23:51:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 2 23:51:43 2004 Subject: [Patches] [ python-Patches-1018386 ] fix for several sre escaping bugs (fixes #776311) Message-ID: Patches item #1018386, was opened at 2004-08-29 00:19 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1018386&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Gustavo Niemeyer (niemeyer) Summary: fix for several sre escaping bugs (fixes #776311) Initial Comment: This patch fixes a number of escaping bugs in sre (the re module). The most serious is an infinite loop in the parser, which is what the submitter of bug #776311 was seeing. Another allows octal escapes to have an arbitrary number of digits--the doc didn't quite exclude this, but it's clearly the wrong thing (cf. string literals). There are others--see the test cases. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-09-02 21:51 Message: Logged In: YES user_id=7887 Of course! I'll be reviewing it offline and get back shortly. Thanks for assigning it to me! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-29 16:01 Message: Logged In: YES user_id=21627 Gustavo, can you take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1018386&group_id=5470 From noreply at sourceforge.net Fri Sep 3 19:18:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 19:18:39 2004 Subject: [Patches] [ python-Patches-1018386 ] fix for several sre escaping bugs (fixes #776311) Message-ID: Patches item #1018386, was opened at 2004-08-29 00:19 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1018386&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Gustavo Niemeyer (niemeyer) Summary: fix for several sre escaping bugs (fixes #776311) Initial Comment: This patch fixes a number of escaping bugs in sre (the re module). The most serious is an infinite loop in the parser, which is what the submitter of bug #776311 was seeing. Another allows octal escapes to have an arbitrary number of digits--the doc didn't quite exclude this, but it's clearly the wrong thing (cf. string literals). There are others--see the test cases. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-09-03 17:18 Message: Logged In: YES user_id=7887 Applied as: Lib/sre_parse.py: 1.62 Lib/test/test_re.py: 1.51 Doc/lib/libre.tex: 1.109 It was a little bit modified to adapt to the current CVS version. I've also reimplemented the logic of numeric escaping with a logic similar to what is used in _escape() function, making it a little bit faster and removing the need for the external function. I'm attaching the applied patch for reference. Please, let me know if you have any comments. Thanks a lot for the patch! ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-09-02 21:51 Message: Logged In: YES user_id=7887 Of course! I'll be reviewing it offline and get back shortly. Thanks for assigning it to me! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-29 16:01 Message: Logged In: YES user_id=21627 Gustavo, can you take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1018386&group_id=5470 From noreply at sourceforge.net Fri Sep 3 20:32:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 20:32:11 2004 Subject: [Patches] [ python-Patches-1022003 ] topdir calculated incorrectly in bdist_rpm Message-ID: Patches item #1022003, was opened at 2004-09-03 12:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022003&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: topdir calculated incorrectly in bdist_rpm Initial Comment: The _topdir directive to the bdist_rpm command is calculated incorrectly when the --bdist-base or --dist-dir options to the command use absolute path names. It should use os.path.abspath() instead, I believe. It would be nice if this patch was backported to earlier versions of Python as well but it is not critical for me. If you have further questions, let me know. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022003&group_id=5470 From noreply at sourceforge.net Fri Sep 3 20:49:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 20:49:40 2004 Subject: [Patches] [ python-Patches-1022011 ] add support for the AutoReq flag in bdist_rpm Message-ID: Patches item #1022011, was opened at 2004-09-03 12:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022011&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: add support for the AutoReq flag in bdist_rpm Initial Comment: This patch supplies a new option to bdist_rpm to allow the setting of the AutoReq flag in RPM to false. This ensures that no dependencies are calculated automatically. If you have further questions or want the name of the option changed, please feel free to ask. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022011&group_id=5470 From noreply at sourceforge.net Fri Sep 3 22:00:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 22:01:05 2004 Subject: [Patches] [ python-Patches-1018386 ] fix for several sre escaping bugs (fixes #776311) Message-ID: Patches item #1018386, was opened at 2004-08-28 19:19 Message generated for change (Comment added) made by mkc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1018386&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Gustavo Niemeyer (niemeyer) Summary: fix for several sre escaping bugs (fixes #776311) Initial Comment: This patch fixes a number of escaping bugs in sre (the re module). The most serious is an infinite loop in the parser, which is what the submitter of bug #776311 was seeing. Another allows octal escapes to have an arbitrary number of digits--the doc didn't quite exclude this, but it's clearly the wrong thing (cf. string literals). There are others--see the test cases. ---------------------------------------------------------------------- >Comment By: Mike Coleman (mkc) Date: 2004-09-03 15:00 Message: Logged In: YES user_id=555 Gustavo, it looks better than my patch. Two very minor comments: - The s/wildcare/wildcard/ fix to _sre.c got dropped? - In this expression, you're checking the first digit, then the third, then the second. I'd check them in order, for readability. c in OCTDIGITS and s.next in OCTDIGITS and this[2] in OCTDIGITS As I said, very minor. Thanks for the quick review/apply! ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-09-03 12:18 Message: Logged In: YES user_id=7887 Applied as: Lib/sre_parse.py: 1.62 Lib/test/test_re.py: 1.51 Doc/lib/libre.tex: 1.109 It was a little bit modified to adapt to the current CVS version. I've also reimplemented the logic of numeric escaping with a logic similar to what is used in _escape() function, making it a little bit faster and removing the need for the external function. I'm attaching the applied patch for reference. Please, let me know if you have any comments. Thanks a lot for the patch! ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-09-02 16:51 Message: Logged In: YES user_id=7887 Of course! I'll be reviewing it offline and get back shortly. Thanks for assigning it to me! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-29 11:01 Message: Logged In: YES user_id=21627 Gustavo, can you take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1018386&group_id=5470 From noreply at sourceforge.net Fri Sep 3 22:15:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 22:15:07 2004 Subject: [Patches] [ python-Patches-988761 ] re.split emptyok flag (fix for #852532) Message-ID: Patches item #988761, was opened at 2004-07-10 22:25 Message generated for change (Comment added) made by mkc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988761&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: re.split emptyok flag (fix for #852532) Initial Comment: This patch addresses bug #852532. The underlying problem is that re.split ignores any match it makes that has length zero, which blocks a number of useful possibilities. The attached patch implements a flag 'emptyok', which if set to True, causes re.split to allow zero length matches. My preference would be to just change the behavior of re.split, rather than adding this flag. The old behavior isn't documented (though a couple of cases in test_re.py do depend on it). As a practical matter, though, I realize that there may be some code out there relying on this undocumented behavior. And I'm hoping that this useful feature can be added quickly. Perhaps this new behavior could be made the default in a future version of Python. (Linux 2.6.3 i686) ---------------------------------------------------------------------- >Comment By: Mike Coleman (mkc) Date: 2004-09-03 15:15 Message: Logged In: YES user_id=555 Apparently this patch is stalled, but I'd like to get it in, in some form, for 2.4. The only question, as far as I know, is whether empty matches following non-empty matches "count" or not (they do in the original patch). If I make a patch with the "doesn't count" behavior, could we apply that right away? I'd rather get either behavior in for 2.4 than wait for 2.5... ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2004-07-28 11:23 Message: Logged In: YES user_id=555 I picked through CVS, python-dev and google and came up with this. The current behavior was present way back in the earliest regsub.py in CVS (dated Sep 1992); subsequent implementation seem to be mirroring this behavior. The CVS comment back in 1992 described split as modeled on nawk. A check of nawk(1) confirms that nawk only splits on non-null matches. Perl (circa 5.6) on the other hand, appears to split the way this patch does (though I wasn't aware of that when I wrote the patch) so that might argue in the other direction. I would note, too, that re.findall and re.finditer tend in this direction ("Empty matches are included in the result unless they touch the beginning of another match."). The python-dev archive doesn't seem to go back far enough to be relevant and I'm not sure how to search it. General googling (python "re.split" empty match) found a few hits. Probably the most relevant is Tim Peters saying "Python won't change here (IMO)" and giving the example that he also gives in a comment to bug #852532 (which this patch addresses). He also wonders in his comment about the possibility of a "design constraint", but I think this patch addresses that concern. As far as I can tell, the current behavior was a design decision made over 10 years ago, between two alternatives that probably didn't matter much at the time. Skipping empty matches probably seemed harmless before lookahead/lookbehind assertions. Now, though, the current behavior seems like a significant hindrance. Furthermore, it ought to be pretty trivial to modify any existing patterns to get the old behavior, should that be desired (e.g., use 'x+' instead of 'x*'). (I didn't notice that re.findall doc when I originally wrote this patch. Perhaps the doc in the patch should be slightly modified to help emphasize the similarity between how re.findall and re.split handle empty matches.) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-07-27 09:08 Message: Logged In: YES user_id=11375 Overall I like the patch and wouldn't mind seeing the change become the default behaviour. However, I'm nervous about possibly not understanding the reason the prohibition on zero-length matches was added in the first place. Can you please do some research in the CVS logs and python-dev archives to figure out why the limitation was implemented in the first place? ---------------------------------------------------------------------- Comment By: Chris King (colander_man) Date: 2004-07-21 07:46 Message: Logged In: YES user_id=573252 Practical example where the current behaviour produces undesirable results (splitting on character transitions): >>> import re >>> re.split(r'(?<=[A-Z])(?=[^a-z])','SOMEstring') ['SOMEstring'] # desired is ['SOME','string'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988761&group_id=5470 From noreply at sourceforge.net Fri Sep 3 22:19:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 22:19:11 2004 Subject: [Patches] [ python-Patches-1018386 ] fix for several sre escaping bugs (fixes #776311) Message-ID: Patches item #1018386, was opened at 2004-08-29 00:19 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1018386&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Gustavo Niemeyer (niemeyer) Summary: fix for several sre escaping bugs (fixes #776311) Initial Comment: This patch fixes a number of escaping bugs in sre (the re module). The most serious is an infinite loop in the parser, which is what the submitter of bug #776311 was seeing. Another allows octal escapes to have an arbitrary number of digits--the doc didn't quite exclude this, but it's clearly the wrong thing (cf. string literals). There are others--see the test cases. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-09-03 20:19 Message: Logged In: YES user_id=7887 I included the comment typo fix on _sre.c into another patch I had to apply. Sorry for not mentioning it. I just reordered these entries as you suggested. Thanks again! ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2004-09-03 20:00 Message: Logged In: YES user_id=555 Gustavo, it looks better than my patch. Two very minor comments: - The s/wildcare/wildcard/ fix to _sre.c got dropped? - In this expression, you're checking the first digit, then the third, then the second. I'd check them in order, for readability. c in OCTDIGITS and s.next in OCTDIGITS and this[2] in OCTDIGITS As I said, very minor. Thanks for the quick review/apply! ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-09-03 17:18 Message: Logged In: YES user_id=7887 Applied as: Lib/sre_parse.py: 1.62 Lib/test/test_re.py: 1.51 Doc/lib/libre.tex: 1.109 It was a little bit modified to adapt to the current CVS version. I've also reimplemented the logic of numeric escaping with a logic similar to what is used in _escape() function, making it a little bit faster and removing the need for the external function. I'm attaching the applied patch for reference. Please, let me know if you have any comments. Thanks a lot for the patch! ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-09-02 21:51 Message: Logged In: YES user_id=7887 Of course! I'll be reviewing it offline and get back shortly. Thanks for assigning it to me! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-29 16:01 Message: Logged In: YES user_id=21627 Gustavo, can you take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1018386&group_id=5470 From noreply at sourceforge.net Sat Sep 4 02:54:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 4 02:54:56 2004 Subject: [Patches] [ python-Patches-1022173 ] Improve Template error detection and reporting Message-ID: Patches item #1022173, was opened at 2004-09-03 19:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Improve Template error detection and reporting Initial Comment: Report line number and token rather than just character position. Detect and report situations where non-ASCII alphabet characters are used in a placeholder number. Currently, this situation results in a silent error for SafeTemplates and either a KeyError or mis-substitution for Templates. Does not change the API or existing tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 From noreply at sourceforge.net Sat Sep 4 03:12:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 4 03:12:10 2004 Subject: [Patches] [ python-Patches-1022176 ] test_random depends on os.urandom Message-ID: Patches item #1022176, was opened at 2004-09-03 20:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022176&group_id=5470 Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Anthony Baxter (anthonybaxter) Summary: test_random depends on os.urandom Initial Comment: Anthony, Here is the patch to test_random.py. Currently, it will fail on systems that do not support os.urandom(). This patch is not as critical as the one that went in earlier today. If you re-issue the alpha, consider including this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022176&group_id=5470 From noreply at sourceforge.net Sat Sep 4 03:41:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 4 03:41:57 2004 Subject: [Patches] [ python-Patches-1017405 ] bsddb's DB.keys() method ignores transaction argument Message-ID: Patches item #1017405, was opened at 2004-08-26 23:01 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1017405&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Jp Calderone (kuran) >Assigned to: Gregory P. Smith (greg) Summary: bsddb's DB.keys() method ignores transaction argument Initial Comment: _DB_make_list in _bsddb.c's accepts a transaction argument but ignores it. This makes db.keys(), db.values(), and db.items() somewhat broken. Patch and quick demo attached. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2004-09-03 18:41 Message: Logged In: YES user_id=413 thanks. i've committed the fix to HEAD and to release23_maint. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2004-08-30 07:50 Message: Logged In: YES user_id=366566 You're right. Not sure what I was thinking. The test script doesn't even run successfully w/ the patch as attached. Passing txn instead of &txn lets it complete correctly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-29 09:00 Message: Logged In: YES user_id=21627 The patch looks wrong to me. Why are you passing &txn, not txn? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1017405&group_id=5470 From noreply at sourceforge.net Sat Sep 4 14:51:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 4 14:51:42 2004 Subject: [Patches] [ python-Patches-1022003 ] topdir calculated incorrectly in bdist_rpm Message-ID: Patches item #1022003, was opened at 2004-09-03 19:32 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022003&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) >Assigned to: Sean Reifschneider (jafo) Summary: topdir calculated incorrectly in bdist_rpm Initial Comment: The _topdir directive to the bdist_rpm command is calculated incorrectly when the --bdist-base or --dist-dir options to the command use absolute path names. It should use os.path.abspath() instead, I believe. It would be nice if this patch was backported to earlier versions of Python as well but it is not critical for me. If you have further questions, let me know. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022003&group_id=5470 From noreply at sourceforge.net Sat Sep 4 15:06:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 4 15:06:39 2004 Subject: [Patches] [ python-Patches-1022011 ] add support for the AutoReq flag in bdist_rpm Message-ID: Patches item #1022011, was opened at 2004-09-03 19:49 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022011&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) >Assigned to: Sean Reifschneider (jafo) Summary: add support for the AutoReq flag in bdist_rpm Initial Comment: This patch supplies a new option to bdist_rpm to allow the setting of the AutoReq flag in RPM to false. This ensures that no dependencies are calculated automatically. If you have further questions or want the name of the option changed, please feel free to ask. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022011&group_id=5470 From noreply at sourceforge.net Sat Sep 4 19:15:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 4 19:15:34 2004 Subject: [Patches] [ python-Patches-1022173 ] Improve Template error detection and reporting Message-ID: Patches item #1022173, was opened at 2004-09-03 20:54 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Improve Template error detection and reporting Initial Comment: Report line number and token rather than just character position. Detect and report situations where non-ASCII alphabet characters are used in a placeholder number. Currently, this situation results in a silent error for SafeTemplates and either a KeyError or mis-substitution for Templates. Does not change the API or existing tests. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-04 13:15 Message: Logged In: YES user_id=12800 I wonder about this patch. PEP 292 clearly says that the first non-identifier character terminates the placeholder. So why would you expect that the e?e would cause an exception to be raised instead of a valid substitution for $ma? Will discuss on python-dev, but in any event, if we accept this patch we would need a unittest update, as well as documentation and PEP 292 updates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 From noreply at sourceforge.net Sat Sep 4 21:43:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 4 21:43:57 2004 Subject: [Patches] [ python-Patches-1022173 ] Improve Template error detection and reporting Message-ID: Patches item #1022173, was opened at 2004-09-03 19:54 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Improve Template error detection and reporting Initial Comment: Report line number and token rather than just character position. Detect and report situations where non-ASCII alphabet characters are used in a placeholder number. Currently, this situation results in a silent error for SafeTemplates and either a KeyError or mis-substitution for Templates. Does not change the API or existing tests. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-04 14:43 Message: Logged In: YES user_id=80475 When a user has their locale set so that a different alphabet is enabled, then they see $ma?ana as a single token. To them, the third character is not out of place with the rest -- anymore than we think of the letter "d" as not being special. In such case, SafeTemplate will pass the error silently. Bug Report: """SafeTemplate broke. I see placeholder in dictionary but it no substitute. Please fix. >>> SafeTemplate("vamanos $ma?ana o est? dia") % {'ma?ana':'ahora'} u'vamanos $ma?ana o est? dia' """ The templates are likely to be exposed to end users (non- programmers). The above is not an unlikely scenario. We should give the users as much help as possible. Yes, tests and docs will be updated if accepted. It's a waste of time to do so now if you think that $ma was the intended placeholder and want the silent error to pass. Also, the line number / token is an important part of the error message. In a long template, it is useless to say that there is an error at position 23019 for example. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-04 12:15 Message: Logged In: YES user_id=12800 I wonder about this patch. PEP 292 clearly says that the first non-identifier character terminates the placeholder. So why would you expect that the e?e would cause an exception to be raised instead of a valid substitution for $ma? Will discuss on python-dev, but in any event, if we accept this patch we would need a unittest update, as well as documentation and PEP 292 updates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 From noreply at sourceforge.net Sat Sep 4 21:44:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 4 21:44:12 2004 Subject: [Patches] [ python-Patches-1022173 ] Improve Template error detection and reporting Message-ID: Patches item #1022173, was opened at 2004-09-03 19:54 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Improve Template error detection and reporting Initial Comment: Report line number and token rather than just character position. Detect and report situations where non-ASCII alphabet characters are used in a placeholder number. Currently, this situation results in a silent error for SafeTemplates and either a KeyError or mis-substitution for Templates. Does not change the API or existing tests. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-04 14:44 Message: Logged In: YES user_id=80475 When a user has their locale set so that a different alphabet is enabled, then they see $ma?ana as a single token. To them, the third character is not out of place with the rest -- anymore than we think of the letter "d" as not being special. In such case, SafeTemplate will pass the error silently. Bug Report: """SafeTemplate broke. I see placeholder in dictionary but it no substitute. Please fix. >>> SafeTemplate("vamanos $ma?ana o est? dia") % {'ma?ana':'ahora'} u'vamanos $ma?ana o est? dia' """ The templates are likely to be exposed to end users (non- programmers). The above is not an unlikely scenario. We should give the users as much help as possible. Yes, tests and docs will be updated if accepted. It's a waste of time to do so now if you think that $ma was the intended placeholder and want the silent error to pass. Also, the line number / token is an important part of the error message. In a long template, it is useless to say that there is an error at position 23019 for example. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-04 14:43 Message: Logged In: YES user_id=80475 When a user has their locale set so that a different alphabet is enabled, then they see $ma?ana as a single token. To them, the third character is not out of place with the rest -- anymore than we think of the letter "d" as not being special. In such case, SafeTemplate will pass the error silently. Bug Report: """SafeTemplate broke. I see placeholder in dictionary but it no substitute. Please fix. >>> SafeTemplate("vamanos $ma?ana o est? dia") % {'ma?ana':'ahora'} u'vamanos $ma?ana o est? dia' """ The templates are likely to be exposed to end users (non- programmers). The above is not an unlikely scenario. We should give the users as much help as possible. Yes, tests and docs will be updated if accepted. It's a waste of time to do so now if you think that $ma was the intended placeholder and want the silent error to pass. Also, the line number / token is an important part of the error message. In a long template, it is useless to say that there is an error at position 23019 for example. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-04 12:15 Message: Logged In: YES user_id=12800 I wonder about this patch. PEP 292 clearly says that the first non-identifier character terminates the placeholder. So why would you expect that the e?e would cause an exception to be raised instead of a valid substitution for $ma? Will discuss on python-dev, but in any event, if we accept this patch we would need a unittest update, as well as documentation and PEP 292 updates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 From noreply at sourceforge.net Sat Sep 4 22:21:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 4 22:22:01 2004 Subject: [Patches] [ python-Patches-1022176 ] test_random depends on os.urandom Message-ID: Patches item #1022176, was opened at 2004-09-03 20:12 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022176&group_id=5470 Category: None Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Anthony Baxter (anthonybaxter) Summary: test_random depends on os.urandom Initial Comment: Anthony, Here is the patch to test_random.py. Currently, it will fail on systems that do not support os.urandom(). This patch is not as critical as the one that went in earlier today. If you re-issue the alpha, consider including this patch. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-04 15:21 Message: Logged In: YES user_id=80475 It looks like the head is open again. Applying the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022176&group_id=5470 From noreply at sourceforge.net Sun Sep 5 17:34:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 5 17:34:36 2004 Subject: [Patches] [ python-Patches-1022173 ] Improve Template error detection and reporting Message-ID: Patches item #1022173, was opened at 2004-09-03 20:54 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Improve Template error detection and reporting Initial Comment: Report line number and token rather than just character position. Detect and report situations where non-ASCII alphabet characters are used in a placeholder number. Currently, this situation results in a silent error for SafeTemplates and either a KeyError or mis-substitution for Templates. Does not change the API or existing tests. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-05 11:34 Message: Logged In: YES user_id=12800 Why would the locale have any effect on what Python defines an identifier as? The PEP and documentation clearly state that the substitution variables are Python identifiers and that's a well-defined, locale-neutral concept. The resolution of your hypothetical bug report is: Won't Fix -- "ma?ana" is not a Python identifier. You can't use it as a variable in regular Python code, and you can't use it as a placeholder in a Template string. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-04 15:44 Message: Logged In: YES user_id=80475 When a user has their locale set so that a different alphabet is enabled, then they see $ma?ana as a single token. To them, the third character is not out of place with the rest -- anymore than we think of the letter "d" as not being special. In such case, SafeTemplate will pass the error silently. Bug Report: """SafeTemplate broke. I see placeholder in dictionary but it no substitute. Please fix. >>> SafeTemplate("vamanos $ma?ana o est? dia") % {'ma?ana':'ahora'} u'vamanos $ma?ana o est? dia' """ The templates are likely to be exposed to end users (non- programmers). The above is not an unlikely scenario. We should give the users as much help as possible. Yes, tests and docs will be updated if accepted. It's a waste of time to do so now if you think that $ma was the intended placeholder and want the silent error to pass. Also, the line number / token is an important part of the error message. In a long template, it is useless to say that there is an error at position 23019 for example. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-04 15:43 Message: Logged In: YES user_id=80475 When a user has their locale set so that a different alphabet is enabled, then they see $ma?ana as a single token. To them, the third character is not out of place with the rest -- anymore than we think of the letter "d" as not being special. In such case, SafeTemplate will pass the error silently. Bug Report: """SafeTemplate broke. I see placeholder in dictionary but it no substitute. Please fix. >>> SafeTemplate("vamanos $ma?ana o est? dia") % {'ma?ana':'ahora'} u'vamanos $ma?ana o est? dia' """ The templates are likely to be exposed to end users (non- programmers). The above is not an unlikely scenario. We should give the users as much help as possible. Yes, tests and docs will be updated if accepted. It's a waste of time to do so now if you think that $ma was the intended placeholder and want the silent error to pass. Also, the line number / token is an important part of the error message. In a long template, it is useless to say that there is an error at position 23019 for example. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-04 13:15 Message: Logged In: YES user_id=12800 I wonder about this patch. PEP 292 clearly says that the first non-identifier character terminates the placeholder. So why would you expect that the e?e would cause an exception to be raised instead of a valid substitution for $ma? Will discuss on python-dev, but in any event, if we accept this patch we would need a unittest update, as well as documentation and PEP 292 updates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 From noreply at sourceforge.net Sun Sep 5 21:19:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 5 21:19:28 2004 Subject: [Patches] [ python-Patches-1022173 ] Improve Template error detection and reporting Message-ID: Patches item #1022173, was opened at 2004-09-03 19:54 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Improve Template error detection and reporting Initial Comment: Report line number and token rather than just character position. Detect and report situations where non-ASCII alphabet characters are used in a placeholder number. Currently, this situation results in a silent error for SafeTemplates and either a KeyError or mis-substitution for Templates. Does not change the API or existing tests. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 14:19 Message: Logged In: YES user_id=80475 Sure, it is documented that way. That doesn't mean that we can't give a useful error message when a potentially common end-user mistake is made. The locale has no affect on valid python identifiers; however, it is a strong indicator of what the user expects to be valid alphabetical characters. The idea is to avoid a silent failure for non-programmer end users who may understandably not know that some of their everyday characters will be viewed as delimiters by the template logic. As it stands, it is a usability bug (documented, but a problem never-the-less). MvL concurred when I discussed with him two weeks ago. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-05 10:34 Message: Logged In: YES user_id=12800 Why would the locale have any effect on what Python defines an identifier as? The PEP and documentation clearly state that the substitution variables are Python identifiers and that's a well-defined, locale-neutral concept. The resolution of your hypothetical bug report is: Won't Fix -- "ma?ana" is not a Python identifier. You can't use it as a variable in regular Python code, and you can't use it as a placeholder in a Template string. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-04 14:44 Message: Logged In: YES user_id=80475 When a user has their locale set so that a different alphabet is enabled, then they see $ma?ana as a single token. To them, the third character is not out of place with the rest -- anymore than we think of the letter "d" as not being special. In such case, SafeTemplate will pass the error silently. Bug Report: """SafeTemplate broke. I see placeholder in dictionary but it no substitute. Please fix. >>> SafeTemplate("vamanos $ma?ana o est? dia") % {'ma?ana':'ahora'} u'vamanos $ma?ana o est? dia' """ The templates are likely to be exposed to end users (non- programmers). The above is not an unlikely scenario. We should give the users as much help as possible. Yes, tests and docs will be updated if accepted. It's a waste of time to do so now if you think that $ma was the intended placeholder and want the silent error to pass. Also, the line number / token is an important part of the error message. In a long template, it is useless to say that there is an error at position 23019 for example. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-04 14:43 Message: Logged In: YES user_id=80475 When a user has their locale set so that a different alphabet is enabled, then they see $ma?ana as a single token. To them, the third character is not out of place with the rest -- anymore than we think of the letter "d" as not being special. In such case, SafeTemplate will pass the error silently. Bug Report: """SafeTemplate broke. I see placeholder in dictionary but it no substitute. Please fix. >>> SafeTemplate("vamanos $ma?ana o est? dia") % {'ma?ana':'ahora'} u'vamanos $ma?ana o est? dia' """ The templates are likely to be exposed to end users (non- programmers). The above is not an unlikely scenario. We should give the users as much help as possible. Yes, tests and docs will be updated if accepted. It's a waste of time to do so now if you think that $ma was the intended placeholder and want the silent error to pass. Also, the line number / token is an important part of the error message. In a long template, it is useless to say that there is an error at position 23019 for example. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-04 12:15 Message: Logged In: YES user_id=12800 I wonder about this patch. PEP 292 clearly says that the first non-identifier character terminates the placeholder. So why would you expect that the e?e would cause an exception to be raised instead of a valid substitution for $ma? Will discuss on python-dev, but in any event, if we accept this patch we would need a unittest update, as well as documentation and PEP 292 updates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 From noreply at sourceforge.net Sun Sep 5 21:30:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 5 21:30:39 2004 Subject: [Patches] [ python-Patches-1022173 ] Improve Template error detection and reporting Message-ID: Patches item #1022173, was opened at 2004-09-03 19:54 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Martin v. L?wis (loewis) Summary: Improve Template error detection and reporting Initial Comment: Report line number and token rather than just character position. Detect and report situations where non-ASCII alphabet characters are used in a placeholder number. Currently, this situation results in a silent error for SafeTemplates and either a KeyError or mis-substitution for Templates. Does not change the API or existing tests. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 14:30 Message: Logged In: YES user_id=80475 Martin, I'm failing to articulate something that seems obvious to me. Can you add your thoughts on the most user friendly way to treat a placeholder like $ma?ana in a latin locale. Currently, it captures $ma and proceeds. My thought is to raise a ValueError noting that $ma?ana contains characters other than _A-Za-z0-9. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 14:19 Message: Logged In: YES user_id=80475 Sure, it is documented that way. That doesn't mean that we can't give a useful error message when a potentially common end-user mistake is made. The locale has no affect on valid python identifiers; however, it is a strong indicator of what the user expects to be valid alphabetical characters. The idea is to avoid a silent failure for non-programmer end users who may understandably not know that some of their everyday characters will be viewed as delimiters by the template logic. As it stands, it is a usability bug (documented, but a problem never-the-less). MvL concurred when I discussed with him two weeks ago. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-05 10:34 Message: Logged In: YES user_id=12800 Why would the locale have any effect on what Python defines an identifier as? The PEP and documentation clearly state that the substitution variables are Python identifiers and that's a well-defined, locale-neutral concept. The resolution of your hypothetical bug report is: Won't Fix -- "ma?ana" is not a Python identifier. You can't use it as a variable in regular Python code, and you can't use it as a placeholder in a Template string. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-04 14:44 Message: Logged In: YES user_id=80475 When a user has their locale set so that a different alphabet is enabled, then they see $ma?ana as a single token. To them, the third character is not out of place with the rest -- anymore than we think of the letter "d" as not being special. In such case, SafeTemplate will pass the error silently. Bug Report: """SafeTemplate broke. I see placeholder in dictionary but it no substitute. Please fix. >>> SafeTemplate("vamanos $ma?ana o est? dia") % {'ma?ana':'ahora'} u'vamanos $ma?ana o est? dia' """ The templates are likely to be exposed to end users (non- programmers). The above is not an unlikely scenario. We should give the users as much help as possible. Yes, tests and docs will be updated if accepted. It's a waste of time to do so now if you think that $ma was the intended placeholder and want the silent error to pass. Also, the line number / token is an important part of the error message. In a long template, it is useless to say that there is an error at position 23019 for example. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-04 14:43 Message: Logged In: YES user_id=80475 When a user has their locale set so that a different alphabet is enabled, then they see $ma?ana as a single token. To them, the third character is not out of place with the rest -- anymore than we think of the letter "d" as not being special. In such case, SafeTemplate will pass the error silently. Bug Report: """SafeTemplate broke. I see placeholder in dictionary but it no substitute. Please fix. >>> SafeTemplate("vamanos $ma?ana o est? dia") % {'ma?ana':'ahora'} u'vamanos $ma?ana o est? dia' """ The templates are likely to be exposed to end users (non- programmers). The above is not an unlikely scenario. We should give the users as much help as possible. Yes, tests and docs will be updated if accepted. It's a waste of time to do so now if you think that $ma was the intended placeholder and want the silent error to pass. Also, the line number / token is an important part of the error message. In a long template, it is useless to say that there is an error at position 23019 for example. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-04 12:15 Message: Logged In: YES user_id=12800 I wonder about this patch. PEP 292 clearly says that the first non-identifier character terminates the placeholder. So why would you expect that the e?e would cause an exception to be raised instead of a valid substitution for $ma? Will discuss on python-dev, but in any event, if we accept this patch we would need a unittest update, as well as documentation and PEP 292 updates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 From noreply at sourceforge.net Sun Sep 5 23:37:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 5 23:37:36 2004 Subject: [Patches] [ python-Patches-1022173 ] Improve Template error detection and reporting Message-ID: Patches item #1022173, was opened at 2004-09-04 02:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Martin v. L?wis (loewis) Summary: Improve Template error detection and reporting Initial Comment: Report line number and token rather than just character position. Detect and report situations where non-ASCII alphabet characters are used in a placeholder number. Currently, this situation results in a silent error for SafeTemplates and either a KeyError or mis-substitution for Templates. Does not change the API or existing tests. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-05 23:37 Message: Logged In: YES user_id=21627 I think the locale should have no effect whatsoever on templates. The template most likely uses the encoding of the source code, which may or may not be encoding of the locale at run-time. In many cases, it won't, as the run-time locale will be "C", as locale.setlocale has not been called. Of course, it might be possible to state an explicit set of termination characters (e.g. all ASCII punctuation and whitespace) and mandate that the template either terminates with one of these, or uses explicit parentheses. That would mean that the only requirement is that the source encoding is an ASCII superset, which is a requirement, anyway. Whether such a change to the PEP is still possible at this point in time, I don't know. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 21:30 Message: Logged In: YES user_id=80475 Martin, I'm failing to articulate something that seems obvious to me. Can you add your thoughts on the most user friendly way to treat a placeholder like $ma?ana in a latin locale. Currently, it captures $ma and proceeds. My thought is to raise a ValueError noting that $ma?ana contains characters other than _A-Za-z0-9. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 21:19 Message: Logged In: YES user_id=80475 Sure, it is documented that way. That doesn't mean that we can't give a useful error message when a potentially common end-user mistake is made. The locale has no affect on valid python identifiers; however, it is a strong indicator of what the user expects to be valid alphabetical characters. The idea is to avoid a silent failure for non-programmer end users who may understandably not know that some of their everyday characters will be viewed as delimiters by the template logic. As it stands, it is a usability bug (documented, but a problem never-the-less). MvL concurred when I discussed with him two weeks ago. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-05 17:34 Message: Logged In: YES user_id=12800 Why would the locale have any effect on what Python defines an identifier as? The PEP and documentation clearly state that the substitution variables are Python identifiers and that's a well-defined, locale-neutral concept. The resolution of your hypothetical bug report is: Won't Fix -- "ma?ana" is not a Python identifier. You can't use it as a variable in regular Python code, and you can't use it as a placeholder in a Template string. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-04 21:44 Message: Logged In: YES user_id=80475 When a user has their locale set so that a different alphabet is enabled, then they see $ma?ana as a single token. To them, the third character is not out of place with the rest -- anymore than we think of the letter "d" as not being special. In such case, SafeTemplate will pass the error silently. Bug Report: """SafeTemplate broke. I see placeholder in dictionary but it no substitute. Please fix. >>> SafeTemplate("vamanos $ma?ana o est? dia") % {'ma?ana':'ahora'} u'vamanos $ma?ana o est? dia' """ The templates are likely to be exposed to end users (non- programmers). The above is not an unlikely scenario. We should give the users as much help as possible. Yes, tests and docs will be updated if accepted. It's a waste of time to do so now if you think that $ma was the intended placeholder and want the silent error to pass. Also, the line number / token is an important part of the error message. In a long template, it is useless to say that there is an error at position 23019 for example. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-04 21:43 Message: Logged In: YES user_id=80475 When a user has their locale set so that a different alphabet is enabled, then they see $ma?ana as a single token. To them, the third character is not out of place with the rest -- anymore than we think of the letter "d" as not being special. In such case, SafeTemplate will pass the error silently. Bug Report: """SafeTemplate broke. I see placeholder in dictionary but it no substitute. Please fix. >>> SafeTemplate("vamanos $ma?ana o est? dia") % {'ma?ana':'ahora'} u'vamanos $ma?ana o est? dia' """ The templates are likely to be exposed to end users (non- programmers). The above is not an unlikely scenario. We should give the users as much help as possible. Yes, tests and docs will be updated if accepted. It's a waste of time to do so now if you think that $ma was the intended placeholder and want the silent error to pass. Also, the line number / token is an important part of the error message. In a long template, it is useless to say that there is an error at position 23019 for example. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-04 19:15 Message: Logged In: YES user_id=12800 I wonder about this patch. PEP 292 clearly says that the first non-identifier character terminates the placeholder. So why would you expect that the e?e would cause an exception to be raised instead of a valid substitution for $ma? Will discuss on python-dev, but in any event, if we accept this patch we would need a unittest update, as well as documentation and PEP 292 updates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 From noreply at sourceforge.net Mon Sep 6 00:41:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 00:41:37 2004 Subject: [Patches] [ python-Patches-1022173 ] Improve Template error detection and reporting Message-ID: Patches item #1022173, was opened at 2004-09-03 19:54 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Martin v. L?wis (loewis) Summary: Improve Template error detection and reporting Initial Comment: Report line number and token rather than just character position. Detect and report situations where non-ASCII alphabet characters are used in a placeholder number. Currently, this situation results in a silent error for SafeTemplates and either a KeyError or mis-substitution for Templates. Does not change the API or existing tests. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 17:41 Message: Logged In: YES user_id=80475 Can you recommend a non-locale sensitive approach to detecting alphabetic characters outside of A-Za-z? For SafeTemplates especially, capturing only $ma is a small disaster. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-05 16:37 Message: Logged In: YES user_id=21627 I think the locale should have no effect whatsoever on templates. The template most likely uses the encoding of the source code, which may or may not be encoding of the locale at run-time. In many cases, it won't, as the run-time locale will be "C", as locale.setlocale has not been called. Of course, it might be possible to state an explicit set of termination characters (e.g. all ASCII punctuation and whitespace) and mandate that the template either terminates with one of these, or uses explicit parentheses. That would mean that the only requirement is that the source encoding is an ASCII superset, which is a requirement, anyway. Whether such a change to the PEP is still possible at this point in time, I don't know. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 14:30 Message: Logged In: YES user_id=80475 Martin, I'm failing to articulate something that seems obvious to me. Can you add your thoughts on the most user friendly way to treat a placeholder like $ma?ana in a latin locale. Currently, it captures $ma and proceeds. My thought is to raise a ValueError noting that $ma?ana contains characters other than _A-Za-z0-9. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 14:19 Message: Logged In: YES user_id=80475 Sure, it is documented that way. That doesn't mean that we can't give a useful error message when a potentially common end-user mistake is made. The locale has no affect on valid python identifiers; however, it is a strong indicator of what the user expects to be valid alphabetical characters. The idea is to avoid a silent failure for non-programmer end users who may understandably not know that some of their everyday characters will be viewed as delimiters by the template logic. As it stands, it is a usability bug (documented, but a problem never-the-less). MvL concurred when I discussed with him two weeks ago. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-05 10:34 Message: Logged In: YES user_id=12800 Why would the locale have any effect on what Python defines an identifier as? The PEP and documentation clearly state that the substitution variables are Python identifiers and that's a well-defined, locale-neutral concept. The resolution of your hypothetical bug report is: Won't Fix -- "ma?ana" is not a Python identifier. You can't use it as a variable in regular Python code, and you can't use it as a placeholder in a Template string. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-04 14:44 Message: Logged In: YES user_id=80475 When a user has their locale set so that a different alphabet is enabled, then they see $ma?ana as a single token. To them, the third character is not out of place with the rest -- anymore than we think of the letter "d" as not being special. In such case, SafeTemplate will pass the error silently. Bug Report: """SafeTemplate broke. I see placeholder in dictionary but it no substitute. Please fix. >>> SafeTemplate("vamanos $ma?ana o est? dia") % {'ma?ana':'ahora'} u'vamanos $ma?ana o est? dia' """ The templates are likely to be exposed to end users (non- programmers). The above is not an unlikely scenario. We should give the users as much help as possible. Yes, tests and docs will be updated if accepted. It's a waste of time to do so now if you think that $ma was the intended placeholder and want the silent error to pass. Also, the line number / token is an important part of the error message. In a long template, it is useless to say that there is an error at position 23019 for example. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-04 14:43 Message: Logged In: YES user_id=80475 When a user has their locale set so that a different alphabet is enabled, then they see $ma?ana as a single token. To them, the third character is not out of place with the rest -- anymore than we think of the letter "d" as not being special. In such case, SafeTemplate will pass the error silently. Bug Report: """SafeTemplate broke. I see placeholder in dictionary but it no substitute. Please fix. >>> SafeTemplate("vamanos $ma?ana o est? dia") % {'ma?ana':'ahora'} u'vamanos $ma?ana o est? dia' """ The templates are likely to be exposed to end users (non- programmers). The above is not an unlikely scenario. We should give the users as much help as possible. Yes, tests and docs will be updated if accepted. It's a waste of time to do so now if you think that $ma was the intended placeholder and want the silent error to pass. Also, the line number / token is an important part of the error message. In a long template, it is useless to say that there is an error at position 23019 for example. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-04 12:15 Message: Logged In: YES user_id=12800 I wonder about this patch. PEP 292 clearly says that the first non-identifier character terminates the placeholder. So why would you expect that the e?e would cause an exception to be raised instead of a valid substitution for $ma? Will discuss on python-dev, but in any event, if we accept this patch we would need a unittest update, as well as documentation and PEP 292 updates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 From noreply at sourceforge.net Mon Sep 6 00:53:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 00:53:48 2004 Subject: [Patches] [ python-Patches-988761 ] re.split emptyok flag (fix for #852532) Message-ID: Patches item #988761, was opened at 2004-07-10 22:25 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988761&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Coleman (mkc) >Assigned to: Fredrik Lundh (effbot) Summary: re.split emptyok flag (fix for #852532) Initial Comment: This patch addresses bug #852532. The underlying problem is that re.split ignores any match it makes that has length zero, which blocks a number of useful possibilities. The attached patch implements a flag 'emptyok', which if set to True, causes re.split to allow zero length matches. My preference would be to just change the behavior of re.split, rather than adding this flag. The old behavior isn't documented (though a couple of cases in test_re.py do depend on it). As a practical matter, though, I realize that there may be some code out there relying on this undocumented behavior. And I'm hoping that this useful feature can be added quickly. Perhaps this new behavior could be made the default in a future version of Python. (Linux 2.6.3 i686) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 17:53 Message: Logged In: YES user_id=80475 Fred, what do you think of the proposal. Are the backwards compatability issues worth it? ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2004-09-03 15:15 Message: Logged In: YES user_id=555 Apparently this patch is stalled, but I'd like to get it in, in some form, for 2.4. The only question, as far as I know, is whether empty matches following non-empty matches "count" or not (they do in the original patch). If I make a patch with the "doesn't count" behavior, could we apply that right away? I'd rather get either behavior in for 2.4 than wait for 2.5... ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2004-07-28 11:23 Message: Logged In: YES user_id=555 I picked through CVS, python-dev and google and came up with this. The current behavior was present way back in the earliest regsub.py in CVS (dated Sep 1992); subsequent implementation seem to be mirroring this behavior. The CVS comment back in 1992 described split as modeled on nawk. A check of nawk(1) confirms that nawk only splits on non-null matches. Perl (circa 5.6) on the other hand, appears to split the way this patch does (though I wasn't aware of that when I wrote the patch) so that might argue in the other direction. I would note, too, that re.findall and re.finditer tend in this direction ("Empty matches are included in the result unless they touch the beginning of another match."). The python-dev archive doesn't seem to go back far enough to be relevant and I'm not sure how to search it. General googling (python "re.split" empty match) found a few hits. Probably the most relevant is Tim Peters saying "Python won't change here (IMO)" and giving the example that he also gives in a comment to bug #852532 (which this patch addresses). He also wonders in his comment about the possibility of a "design constraint", but I think this patch addresses that concern. As far as I can tell, the current behavior was a design decision made over 10 years ago, between two alternatives that probably didn't matter much at the time. Skipping empty matches probably seemed harmless before lookahead/lookbehind assertions. Now, though, the current behavior seems like a significant hindrance. Furthermore, it ought to be pretty trivial to modify any existing patterns to get the old behavior, should that be desired (e.g., use 'x+' instead of 'x*'). (I didn't notice that re.findall doc when I originally wrote this patch. Perhaps the doc in the patch should be slightly modified to help emphasize the similarity between how re.findall and re.split handle empty matches.) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-07-27 09:08 Message: Logged In: YES user_id=11375 Overall I like the patch and wouldn't mind seeing the change become the default behaviour. However, I'm nervous about possibly not understanding the reason the prohibition on zero-length matches was added in the first place. Can you please do some research in the CVS logs and python-dev archives to figure out why the limitation was implemented in the first place? ---------------------------------------------------------------------- Comment By: Chris King (colander_man) Date: 2004-07-21 07:46 Message: Logged In: YES user_id=573252 Practical example where the current behaviour produces undesirable results (splitting on character transitions): >>> import re >>> re.split(r'(?<=[A-Z])(?=[^a-z])','SOMEstring') ['SOMEstring'] # desired is ['SOME','string'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=988761&group_id=5470 From noreply at sourceforge.net Mon Sep 6 01:22:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 01:22:23 2004 Subject: [Patches] [ python-Patches-1022173 ] Improve Template error detection and reporting Message-ID: Patches item #1022173, was opened at 2004-09-04 02:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Martin v. L?wis (loewis) Summary: Improve Template error detection and reporting Initial Comment: Report line number and token rather than just character position. Detect and report situations where non-ASCII alphabet characters are used in a placeholder number. Currently, this situation results in a silent error for SafeTemplates and either a KeyError or mis-substitution for Templates. Does not change the API or existing tests. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-06 01:22 Message: Logged In: YES user_id=21627 If the string is a Unicode string, you can use .isletter. If it is a byte string, then it is impossible to determine letters (strictly speaking, it is even impossible to determin ASCII letters then). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 00:41 Message: Logged In: YES user_id=80475 Can you recommend a non-locale sensitive approach to detecting alphabetic characters outside of A-Za-z? For SafeTemplates especially, capturing only $ma is a small disaster. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-05 23:37 Message: Logged In: YES user_id=21627 I think the locale should have no effect whatsoever on templates. The template most likely uses the encoding of the source code, which may or may not be encoding of the locale at run-time. In many cases, it won't, as the run-time locale will be "C", as locale.setlocale has not been called. Of course, it might be possible to state an explicit set of termination characters (e.g. all ASCII punctuation and whitespace) and mandate that the template either terminates with one of these, or uses explicit parentheses. That would mean that the only requirement is that the source encoding is an ASCII superset, which is a requirement, anyway. Whether such a change to the PEP is still possible at this point in time, I don't know. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 21:30 Message: Logged In: YES user_id=80475 Martin, I'm failing to articulate something that seems obvious to me. Can you add your thoughts on the most user friendly way to treat a placeholder like $ma?ana in a latin locale. Currently, it captures $ma and proceeds. My thought is to raise a ValueError noting that $ma?ana contains characters other than _A-Za-z0-9. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 21:19 Message: Logged In: YES user_id=80475 Sure, it is documented that way. That doesn't mean that we can't give a useful error message when a potentially common end-user mistake is made. The locale has no affect on valid python identifiers; however, it is a strong indicator of what the user expects to be valid alphabetical characters. The idea is to avoid a silent failure for non-programmer end users who may understandably not know that some of their everyday characters will be viewed as delimiters by the template logic. As it stands, it is a usability bug (documented, but a problem never-the-less). MvL concurred when I discussed with him two weeks ago. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-05 17:34 Message: Logged In: YES user_id=12800 Why would the locale have any effect on what Python defines an identifier as? The PEP and documentation clearly state that the substitution variables are Python identifiers and that's a well-defined, locale-neutral concept. The resolution of your hypothetical bug report is: Won't Fix -- "ma?ana" is not a Python identifier. You can't use it as a variable in regular Python code, and you can't use it as a placeholder in a Template string. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-04 21:44 Message: Logged In: YES user_id=80475 When a user has their locale set so that a different alphabet is enabled, then they see $ma?ana as a single token. To them, the third character is not out of place with the rest -- anymore than we think of the letter "d" as not being special. In such case, SafeTemplate will pass the error silently. Bug Report: """SafeTemplate broke. I see placeholder in dictionary but it no substitute. Please fix. >>> SafeTemplate("vamanos $ma?ana o est? dia") % {'ma?ana':'ahora'} u'vamanos $ma?ana o est? dia' """ The templates are likely to be exposed to end users (non- programmers). The above is not an unlikely scenario. We should give the users as much help as possible. Yes, tests and docs will be updated if accepted. It's a waste of time to do so now if you think that $ma was the intended placeholder and want the silent error to pass. Also, the line number / token is an important part of the error message. In a long template, it is useless to say that there is an error at position 23019 for example. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-04 21:43 Message: Logged In: YES user_id=80475 When a user has their locale set so that a different alphabet is enabled, then they see $ma?ana as a single token. To them, the third character is not out of place with the rest -- anymore than we think of the letter "d" as not being special. In such case, SafeTemplate will pass the error silently. Bug Report: """SafeTemplate broke. I see placeholder in dictionary but it no substitute. Please fix. >>> SafeTemplate("vamanos $ma?ana o est? dia") % {'ma?ana':'ahora'} u'vamanos $ma?ana o est? dia' """ The templates are likely to be exposed to end users (non- programmers). The above is not an unlikely scenario. We should give the users as much help as possible. Yes, tests and docs will be updated if accepted. It's a waste of time to do so now if you think that $ma was the intended placeholder and want the silent error to pass. Also, the line number / token is an important part of the error message. In a long template, it is useless to say that there is an error at position 23019 for example. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-04 19:15 Message: Logged In: YES user_id=12800 I wonder about this patch. PEP 292 clearly says that the first non-identifier character terminates the placeholder. So why would you expect that the e?e would cause an exception to be raised instead of a valid substitution for $ma? Will discuss on python-dev, but in any event, if we accept this patch we would need a unittest update, as well as documentation and PEP 292 updates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 From noreply at sourceforge.net Mon Sep 6 09:16:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 6 09:16:49 2004 Subject: [Patches] [ python-Patches-1022910 ] Conserve memory with list.pop() Message-ID: Patches item #1022910, was opened at 2004-09-06 02:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022910&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Tim Peters (tim_one) Summary: Conserve memory with list.pop() Initial Comment: The current list resizing scheme only downsizes when more than 16 elements are removed in a single step: del a[100:120]. When popping elements off of a list one at a time, the current resizing approach never shrinks. This patch makes it shrink whenever more than half of the space is unused. There may be a better approach. This one is simple and avoids thrashing in stack applications that hover up and down around a nearly steady state. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022910&group_id=5470 From noreply at sourceforge.net Tue Sep 7 04:32:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 04:32:55 2004 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 03:45 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) >Assigned to: Walter D?rwald (doerwalter) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-09-06 19:32 Message: Logged In: YES user_id=357491 OK, test__locale has been checked in. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-30 04:00 Message: Logged In: YES user_id=469548 Brett: that's just one of the drawbacks of doing data-driven testing with unittest. I don't think it's terribly important, so the test is OK to me. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-26 20:44 Message: Logged In: YES user_id=357491 Just attached a new version of test__locale. Since it is so small of a file and the change so drastic I just uploaded the whole file. Only drawback is before the test kept testing all locales when there was a failure while my implementation stops at the first failure discovered. Don't know if it is important to test all locales. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-24 09:59 Message: Logged In: YES user_id=80475 Walter, I'm afraid I don't have time for these right now. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-08-20 09:39 Message: Logged In: YES user_id=89016 Raymond, can you take a look at the patches? ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-20 08:06 Message: Logged In: YES user_id=469548 Another one: ported test_inspect to unittest and moved out the inspect fodder out into two modules instead of using the ugly imp.load_source and TESTFN. I also did a bit of rearrangement so that the TestCase classes mostly match the sections in the library docs. I used a separate module (inspect_fodder2) and class for the decorators tests. Those are kind of small now, but I'll check in http://python.org/sf/1011890 after this port and let it grow without having to update test_getfunctions(). ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-19 08:14 Message: Logged In: YES user_id=469548 Hum yes, that was me trying out how doctest fails. The expected outcome should have been True. Can you try the corrected version? Test_zipfile has been checked in as rev 1.11. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-08-18 12:29 Message: Logged In: YES user_id=89016 doctest tests should be OK. The error tests in test_unpack can be done with PyUnit too, you either use self.assertRaises(ValueError, eval, "a,b = Seq()") or try: a,b = Seq() except ValueError: pass else: self.fail("failed") test_zipfile_unittest.py looks OK, but should of course be named test_zipfile.py when you check it in. test_unpack_doctest.py gives me: ********************************************** ************************ Failure in example: a == 4 and b == 5 and c == 6 from line #14 of test.test_unpack_doctest.doctests in /home/walter/Achtung/Python- test/dist/src/Lib/test/test_unpack_doctest.pyc Expected: False Got: True ********************************************** ************************ 1 items had failures: 1 of 28 in test.test_unpack_doctest.doctests ***Test Failed*** 1 failures. Traceback (most recent call last): File "Lib/test/test_unpack_doctest.py", line 133, in ? test_main(verbose=True) File "Lib/test/test_unpack_doctest.py", line 130, in test_main test_support.run_doctest(test_unpack_doctest, verbose) File "/home/walter/Achtung/Python- test/dist/src/Lib/test/test_support.py", line 318, in run_doctest raise TestFailed("%d of %d doctests failed" % (f, t)) test.test_support.TestFailed: 1 of 28 doctests failed ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-18 06:23 Message: Logged In: YES user_id=469548 Is there any problem with porting test scripts to doctest instead of unittest? doctest is just perfect for test_unpack (doctest version attached). I've also ported test_zipfile to unittest (attached as well). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-31 09:31 Message: Logged In: YES user_id=89016 OK, checked in as: Lib/test/mapping_tests.py 1.1 Lib/test/test_os.py 1.22 Lib/test/test_shelve.py 1.7 Lib/test/test_types.py 1.60 Lib/test/test_userdict.py 1.19 Lib/test/test_weakref.py 1.39 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-28 16:02 Message: Logged In: YES user_id=80475 Looks good. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-28 13:59 Message: Logged In: YES user_id=89016 OK, I've updated the docstring for dict.update() (Object/dictobject.c 2.160) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-27 12:04 Message: Logged In: YES user_id=89016 dict_diff.txt is a patch that tries to share tests between test_dict, test_userdict, test_os, test_shelve and test_weakref. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-25 13:29 Message: Logged In: YES user_id=31435 Don't really care myself. Would be nice if the docstring for dict.update() matched the new realities, though . BTW, there is a reliable and conventional way to detect whether the 'dict' argument was passed to UserDict.update: use a unique marker object instead of the universally visible None. Like _marker = object() at module level, and ...(self, dict=_marker, ...) in the method defn. That can't be fooled without deliberate intent to deceive. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-25 13:21 Message: Logged In: YES user_id=80475 IMO, it is fine as is. I would be suprised if some code were relying on UserDict.update(None) raising an exception. This sort of thing also comes up also in places like the string and random modules whereever a function or method with an optional argument gets wrapped by another function. The only way around this is to use *args and then you break code that used the unfortunately named "dict" argument as a keyword. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-25 12:32 Message: Logged In: YES user_id=89016 Merging test_dict and test_userdict revealed a difference between dict and UserDict.UserDict: >>> import UserDict >>> d = UserDict.UserDict() >>> d.update(None) >>> d {} >>> d = {} >>> d.update(None) Traceback (most recent call last): File "", line 1, in ? TypeError: iteration over non-sequence Should we do anything about this? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-20 09:03 Message: Logged In: YES user_id=80475 test_dict is fine. Consider beefing up the tests for update(). As of Py2.4, it now takes all the same argument possibilites as dict(): d.update(a=1, b=2) d.update([('a', 1), ('b', 2)]) Also, try to link in: from test_userdict import TestMappingProtocol This was supposed to provide tests common to all mappings. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-04-03 03:06 Message: Logged In: YES user_id=89016 The attached test_dict.py moves the dict tests from test_types.py to a new PyUnit test script. Code coverage for dictobject.c is at 90.76% (up from 89.51%) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-03-15 04:17 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_binascii delete Lib/test/test_binascii.py 1.17 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-03-13 12:26 Message: Logged In: YES user_id=80475 Okay, this one is fine. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-18 15:49 Message: Logged In: YES user_id=89016 Here's the next one: test_binascii.py. Code coverage in binascii.c is at 92% (could be improved by enhancing test_binhex.py). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-13 14:46 Message: Logged In: YES user_id=33168 Looked good to me, test_future_pyunit.diff checked in as: * Lib/test/badsyntax_future3.py 1.2 * Lib/test/badsyntax_future4.py 1.2 * Lib/test/badsyntax_future5.py 1.2 * Lib/test/badsyntax_future6.py 1.2 * Lib/test/badsyntax_future7.py 1.2 * Lib/test/badsyntax_future8.py 1.1 * Lib/test/badsyntax_future9.py 1.1 * Lib/test/test_future.py 1.7 * Lib/test/test_future1.py 1.3 * Lib/test/test_future2.py 1.2 * Lib/test/output/test_future 1.4 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-13 13:47 Message: Logged In: YES user_id=33168 Walter, I didn't get a mail from SF either. After you do a cvs add, you need to use -N to cvs diff. For example, cvs diff -N new_file_added_to_cvs_but_not_committed. If you look carefully, you can see this in the patch on the diff line for each file. I'll take a look at the patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-13 12:18 Message: Logged In: YES user_id=89016 Here is a version of test_future ported to PyUnit (test_future_pyunit.diff). If this makes sense to you Neal, please check it in. (BTW, how did you convince CVS to include badsyntax_future8.py and badsyntax_future9.py in the diff? Doing a "cvs add" only results in " Lib/test/badsyntax_future8.py is a new entry, no comparison available") ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-11 04:36 Message: Logged In: YES user_id=89016 md5/weakref patch checked in as: Lib/test/test_weakref.py 1.33 Lib/test/test_md5.py 1.5 Lib/test/output/test_md5 remove ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-10 22:05 Message: Logged In: YES user_id=33168 Improve coverage for test_future too. I'm not sure if test future can be ported to PyUnit. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-10 21:52 Message: Logged In: YES user_id=33168 Attached are two tests (in one file, I'm being lazy, sorry) to improve test coverage for md5c.c and _weakref.c. test_md5 was ported to unittest, weakref, just adds two little tests to get coverage up to 100%. If you like, just go ahead and check in. You will need to remove Lib/test/output/test_md5 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-08 03:42 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/list_tests.py 1.1 Lib/test/seq_tests.py 1.1 Lib/test/test_list.py 1.1 Lib/test/test_tuple.py 1.1 Lib/test/test_types.py 1.56 Lib/test/test_userlist.py 1.11 Lib/test/output/test_types 1.3 Next will be test_binascii.py before I continue with test_types.py. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-07 15:49 Message: Logged In: YES user_id=80475 Looks good. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-11-27 11:48 Message: Logged In: YES user_id=89016 Here the first part of the test_types port: list and tuple tests have been moved to their own scripts: test_tuple.py and test_list.py. Common tests for tuple, list and UserList are shared (in seq_test.py and list_test.py) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 18:53 Message: Logged In: YES user_id=80475 Applied as: Lib/test/test_slice.py 1.5. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 16:52 Message: Logged In: YES user_id=80475 Looks good. I added a couple of minor tests. Revised patch attached. Okay to apply. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-31 12:49 Message: Logged In: YES user_id=89016 Thanks! Here's another one: test_slice.py ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 16:04 Message: Logged In: YES user_id=80475 Done. See: Lib/test/test_longexp.py 1.9; previous revision: 1.8 Lib/test/test_pep263.py 1.3; previous revision: 1.2 Lib/test/test_sets.py 1.27; previous revision: 1.26 Lib/test/test_structseq.py 1.5; previous revision: 1.4 Lib/test/output/test_longexp delete; previous revision: 1.3 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 10:10 Message: Logged In: YES user_id=80475 Will do! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-30 10:06 Message: Logged In: YES user_id=89016 Here's test_structse.py converted with a few additional tests. If all three scripts are OK, could you check them in Raymond, as I'll be on vacation for three weeks? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-09 08:47 Message: Logged In: YES user_id=89016 Here are two simple ones: test_pep263 and test_longexp. I can't think of any additional tests to add. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-23 06:38 Message: Logged In: YES user_id=80475 Fixed Walter's review comments and committed as Lib/test/test_compile.py 1.19 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-23 04:49 Message: Logged In: YES user_id=89016 Are you sure, that the code path is the same in the new test_argument_handling() as in the old test? I.e. is "eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"? The print statement in test_float_literals should be changed to a comment. Should the imports in test_unary_minus() be moved to the start of the script? Otherwise the test looks (and runs) OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 12:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-19 02:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 12:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-18 07:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-17 16:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 14:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 05:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 14:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 12:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 12:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 12:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 12:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 11:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 11:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 09:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 08:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 08:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 05:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 10:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 09:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 08:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 06:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 16:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 19:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 18:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 18:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 18:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 17:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 16:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply at sourceforge.net Tue Sep 7 04:34:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 04:34:29 2004 Subject: [Patches] [ python-Patches-922115 ] PEP 292 reference implementation Message-ID: Patches item #922115, was opened at 2004-03-23 15:41 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=922115&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Brett Cannon (bcannon) Summary: PEP 292 reference implementation Initial Comment: Here's a reference implementation for PEP 292, along with a few other things we talked about at PyCON II - creation of a top-level stringlib package - addition of stringlib/safedict.py which is a handy adjunct to PEP 292 I will also be checking in an updated PEP 292. Still to do: add test cases and documentation. I will do this in time for Python 2.4, if the PEP is accepted. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-09-06 19:34 Message: Logged In: YES user_id=357491 Well, PEP 292 was moved out of the sandbox so I am closing this down. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-03-26 07:24 Message: Logged In: YES user_id=357491 OK, the files (including a copy of string.py from Lib/) have been put in the sandbox in the 'string' directory. I will leave this patch open until something gets moved out os nondist/ into dist/ . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=922115&group_id=5470 From noreply at sourceforge.net Tue Sep 7 06:49:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 06:49:18 2004 Subject: [Patches] [ python-Patches-1022173 ] Improve Template error detection and reporting Message-ID: Patches item #1022173, was opened at 2004-09-03 19:54 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Martin v. L?wis (loewis) Summary: Improve Template error detection and reporting Initial Comment: Report line number and token rather than just character position. Detect and report situations where non-ASCII alphabet characters are used in a placeholder number. Currently, this situation results in a silent error for SafeTemplates and either a KeyError or mis-substitution for Templates. Does not change the API or existing tests. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 23:49 Message: Logged In: YES user_id=80475 Put new alternate versions in nondist\sandbox\string. Has improved line number logic that recognized various types of line endings. Removes the locale specific alphabet tests. Now uses the unicode definitions of alphanumeric characters to detect and report a broad class of usability errors that will likely affect non-programmer end users. By using the unicode definitions, the code is no longer locale sensitive and will provide identical cross-platform results. The sandbox code also includes doctests. Currently, it is in a form for class based __call__ invocation or for funtion invocation. Easily adapted to the __mod__ form is that is the final decision. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-05 18:22 Message: Logged In: YES user_id=21627 If the string is a Unicode string, you can use .isletter. If it is a byte string, then it is impossible to determine letters (strictly speaking, it is even impossible to determin ASCII letters then). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 17:41 Message: Logged In: YES user_id=80475 Can you recommend a non-locale sensitive approach to detecting alphabetic characters outside of A-Za-z? For SafeTemplates especially, capturing only $ma is a small disaster. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-05 16:37 Message: Logged In: YES user_id=21627 I think the locale should have no effect whatsoever on templates. The template most likely uses the encoding of the source code, which may or may not be encoding of the locale at run-time. In many cases, it won't, as the run-time locale will be "C", as locale.setlocale has not been called. Of course, it might be possible to state an explicit set of termination characters (e.g. all ASCII punctuation and whitespace) and mandate that the template either terminates with one of these, or uses explicit parentheses. That would mean that the only requirement is that the source encoding is an ASCII superset, which is a requirement, anyway. Whether such a change to the PEP is still possible at this point in time, I don't know. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 14:30 Message: Logged In: YES user_id=80475 Martin, I'm failing to articulate something that seems obvious to me. Can you add your thoughts on the most user friendly way to treat a placeholder like $ma?ana in a latin locale. Currently, it captures $ma and proceeds. My thought is to raise a ValueError noting that $ma?ana contains characters other than _A-Za-z0-9. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 14:19 Message: Logged In: YES user_id=80475 Sure, it is documented that way. That doesn't mean that we can't give a useful error message when a potentially common end-user mistake is made. The locale has no affect on valid python identifiers; however, it is a strong indicator of what the user expects to be valid alphabetical characters. The idea is to avoid a silent failure for non-programmer end users who may understandably not know that some of their everyday characters will be viewed as delimiters by the template logic. As it stands, it is a usability bug (documented, but a problem never-the-less). MvL concurred when I discussed with him two weeks ago. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-05 10:34 Message: Logged In: YES user_id=12800 Why would the locale have any effect on what Python defines an identifier as? The PEP and documentation clearly state that the substitution variables are Python identifiers and that's a well-defined, locale-neutral concept. The resolution of your hypothetical bug report is: Won't Fix -- "ma?ana" is not a Python identifier. You can't use it as a variable in regular Python code, and you can't use it as a placeholder in a Template string. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-04 14:44 Message: Logged In: YES user_id=80475 When a user has their locale set so that a different alphabet is enabled, then they see $ma?ana as a single token. To them, the third character is not out of place with the rest -- anymore than we think of the letter "d" as not being special. In such case, SafeTemplate will pass the error silently. Bug Report: """SafeTemplate broke. I see placeholder in dictionary but it no substitute. Please fix. >>> SafeTemplate("vamanos $ma?ana o est? dia") % {'ma?ana':'ahora'} u'vamanos $ma?ana o est? dia' """ The templates are likely to be exposed to end users (non- programmers). The above is not an unlikely scenario. We should give the users as much help as possible. Yes, tests and docs will be updated if accepted. It's a waste of time to do so now if you think that $ma was the intended placeholder and want the silent error to pass. Also, the line number / token is an important part of the error message. In a long template, it is useless to say that there is an error at position 23019 for example. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-04 14:43 Message: Logged In: YES user_id=80475 When a user has their locale set so that a different alphabet is enabled, then they see $ma?ana as a single token. To them, the third character is not out of place with the rest -- anymore than we think of the letter "d" as not being special. In such case, SafeTemplate will pass the error silently. Bug Report: """SafeTemplate broke. I see placeholder in dictionary but it no substitute. Please fix. >>> SafeTemplate("vamanos $ma?ana o est? dia") % {'ma?ana':'ahora'} u'vamanos $ma?ana o est? dia' """ The templates are likely to be exposed to end users (non- programmers). The above is not an unlikely scenario. We should give the users as much help as possible. Yes, tests and docs will be updated if accepted. It's a waste of time to do so now if you think that $ma was the intended placeholder and want the silent error to pass. Also, the line number / token is an important part of the error message. In a long template, it is useless to say that there is an error at position 23019 for example. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-04 12:15 Message: Logged In: YES user_id=12800 I wonder about this patch. PEP 292 clearly says that the first non-identifier character terminates the placeholder. So why would you expect that the e?e would cause an exception to be raised instead of a valid substitution for $ma? Will discuss on python-dev, but in any event, if we accept this patch we would need a unittest update, as well as documentation and PEP 292 updates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 From noreply at sourceforge.net Tue Sep 7 07:05:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 07:05:25 2004 Subject: [Patches] [ python-Patches-1020845 ] Decimal performance enhancements Message-ID: Patches item #1020845, was opened at 2004-09-01 19:08 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) >Assigned to: Facundo Batista (facundobatista) Summary: Decimal performance enhancements Initial Comment: The attached patch implements a collection of performance enhancements for decimal.py. They are currently focused on the performance of the telco benchmark in the sandbox (i.e. they aim to speed up instantiation, addition, multiplication and quantization). The main strategy used (a subclass for NaN and infinite values) can be extended to encompass more methods in order to improve performance in other situations. There is one non-performance related change included - the '_sign' attribute is renamed to '_isneg' to better reflect the boolean nature of the property. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 00:05 Message: Logged In: YES user_id=80475 Facundo, do you have time to look at this one? We need to: * revert the _isneg variable name change * find out why it gives a 2:1 gain on telco but only 10% on test_decimal.py * make sure the API has not changed in a way that will make it more difficult someday to convert this into C and make it a built-in. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-02 00:18 Message: Logged In: YES user_id=80475 Nice job. The timings do improve and the approach is reasonable. Please go ahead to the next step and polish it up. Also, please change _isneg back to _sign. That matches the terminology in the spec, the machine centric sign bit viewpoint of 754R, and the components of the user visible as_tuple() method. The goal is to make the patch as minimal as possible, to keep the API unchanged, and improve performance. Using the __new__ method was smart. That more closely corresponds to a potential C implementation of an immutable type. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-01 19:11 Message: Logged In: YES user_id=1038590 I forgot to add that this is NOT yet a production quality patch. The doc strings, in particular, need work. I'm mainly posting it so Raymond can have a look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 From noreply at sourceforge.net Tue Sep 7 07:08:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 07:08:21 2004 Subject: [Patches] [ python-Patches-1019220 ] Multi-line strings and unittest Message-ID: Patches item #1019220, was opened at 2004-08-30 12:00 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1019220&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Felix Wiemann (felixwiemann) >Assigned to: Steve Purcell (purcell) Summary: Multi-line strings and unittest Initial Comment: Currently, the output of unittest.py looks like this: F ====================================================================== FAIL: test_newline (__main__.NewlineTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "unittestnewline.py", line 7, in test_newline self.assertEqual('foo\nbar\nbaz', 'foo\nbaz\nbaz') AssertionError: 'foo\nbar\nbaz' != 'foo\nbaz\nbaz' ---------------------------------------------------------------------- Ran 1 test in 0.001s FAILED (failures=1) For long strings to be compared, an output like 'foo\nbar\nbaz' != 'foo\nbaz\nbaz' isn't particularly useful. The attached patch makes it look like this for multi-line strings: F ====================================================================== FAIL: test_newline (__main__.NewlineTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "unittestnewline.py", line 7, in test_newline self.assertEqual('foo\nbar\nbaz', 'foo\nbaz\nbaz') AssertionError: '''foo bar baz''' != '''foo baz baz''' ---------------------------------------------------------------------- Ran 1 test in 0.001s FAILED (failures=1) The behavior is only changed for strings which contain newline characters. I admittedly do not know if there is a problem when using the patched unittest.py on Windows (due to the different newline convention). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 00:08 Message: Logged In: YES user_id=80475 Steve, would you rule on this one? I personally do not find it to be an improvement. Walter D?rwald is also a heavy unittester and may have a helpful viewpoint. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1019220&group_id=5470 From noreply at sourceforge.net Tue Sep 7 07:24:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 07:24:48 2004 Subject: [Patches] [ python-Patches-1022173 ] Improve Template error detection and reporting Message-ID: Patches item #1022173, was opened at 2004-09-03 19:54 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Martin v. L?wis (loewis) Summary: Improve Template error detection and reporting Initial Comment: Report line number and token rather than just character position. Detect and report situations where non-ASCII alphabet characters are used in a placeholder number. Currently, this situation results in a silent error for SafeTemplates and either a KeyError or mis-substitution for Templates. Does not change the API or existing tests. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 00:24 Message: Logged In: YES user_id=80475 There are now three alternatives in the sandbox. In order of preference: alt292.py Function invocation curry292.py Guido's __call__ invocation mod292.py Version using the % operator ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-06 23:49 Message: Logged In: YES user_id=80475 Put new alternate versions in nondist\sandbox\string. Has improved line number logic that recognized various types of line endings. Removes the locale specific alphabet tests. Now uses the unicode definitions of alphanumeric characters to detect and report a broad class of usability errors that will likely affect non-programmer end users. By using the unicode definitions, the code is no longer locale sensitive and will provide identical cross-platform results. The sandbox code also includes doctests. Currently, it is in a form for class based __call__ invocation or for funtion invocation. Easily adapted to the __mod__ form is that is the final decision. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-05 18:22 Message: Logged In: YES user_id=21627 If the string is a Unicode string, you can use .isletter. If it is a byte string, then it is impossible to determine letters (strictly speaking, it is even impossible to determin ASCII letters then). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 17:41 Message: Logged In: YES user_id=80475 Can you recommend a non-locale sensitive approach to detecting alphabetic characters outside of A-Za-z? For SafeTemplates especially, capturing only $ma is a small disaster. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-05 16:37 Message: Logged In: YES user_id=21627 I think the locale should have no effect whatsoever on templates. The template most likely uses the encoding of the source code, which may or may not be encoding of the locale at run-time. In many cases, it won't, as the run-time locale will be "C", as locale.setlocale has not been called. Of course, it might be possible to state an explicit set of termination characters (e.g. all ASCII punctuation and whitespace) and mandate that the template either terminates with one of these, or uses explicit parentheses. That would mean that the only requirement is that the source encoding is an ASCII superset, which is a requirement, anyway. Whether such a change to the PEP is still possible at this point in time, I don't know. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 14:30 Message: Logged In: YES user_id=80475 Martin, I'm failing to articulate something that seems obvious to me. Can you add your thoughts on the most user friendly way to treat a placeholder like $ma?ana in a latin locale. Currently, it captures $ma and proceeds. My thought is to raise a ValueError noting that $ma?ana contains characters other than _A-Za-z0-9. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-05 14:19 Message: Logged In: YES user_id=80475 Sure, it is documented that way. That doesn't mean that we can't give a useful error message when a potentially common end-user mistake is made. The locale has no affect on valid python identifiers; however, it is a strong indicator of what the user expects to be valid alphabetical characters. The idea is to avoid a silent failure for non-programmer end users who may understandably not know that some of their everyday characters will be viewed as delimiters by the template logic. As it stands, it is a usability bug (documented, but a problem never-the-less). MvL concurred when I discussed with him two weeks ago. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-05 10:34 Message: Logged In: YES user_id=12800 Why would the locale have any effect on what Python defines an identifier as? The PEP and documentation clearly state that the substitution variables are Python identifiers and that's a well-defined, locale-neutral concept. The resolution of your hypothetical bug report is: Won't Fix -- "ma?ana" is not a Python identifier. You can't use it as a variable in regular Python code, and you can't use it as a placeholder in a Template string. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-04 14:44 Message: Logged In: YES user_id=80475 When a user has their locale set so that a different alphabet is enabled, then they see $ma?ana as a single token. To them, the third character is not out of place with the rest -- anymore than we think of the letter "d" as not being special. In such case, SafeTemplate will pass the error silently. Bug Report: """SafeTemplate broke. I see placeholder in dictionary but it no substitute. Please fix. >>> SafeTemplate("vamanos $ma?ana o est? dia") % {'ma?ana':'ahora'} u'vamanos $ma?ana o est? dia' """ The templates are likely to be exposed to end users (non- programmers). The above is not an unlikely scenario. We should give the users as much help as possible. Yes, tests and docs will be updated if accepted. It's a waste of time to do so now if you think that $ma was the intended placeholder and want the silent error to pass. Also, the line number / token is an important part of the error message. In a long template, it is useless to say that there is an error at position 23019 for example. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-04 14:43 Message: Logged In: YES user_id=80475 When a user has their locale set so that a different alphabet is enabled, then they see $ma?ana as a single token. To them, the third character is not out of place with the rest -- anymore than we think of the letter "d" as not being special. In such case, SafeTemplate will pass the error silently. Bug Report: """SafeTemplate broke. I see placeholder in dictionary but it no substitute. Please fix. >>> SafeTemplate("vamanos $ma?ana o est? dia") % {'ma?ana':'ahora'} u'vamanos $ma?ana o est? dia' """ The templates are likely to be exposed to end users (non- programmers). The above is not an unlikely scenario. We should give the users as much help as possible. Yes, tests and docs will be updated if accepted. It's a waste of time to do so now if you think that $ma was the intended placeholder and want the silent error to pass. Also, the line number / token is an important part of the error message. In a long template, it is useless to say that there is an error at position 23019 for example. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-04 12:15 Message: Logged In: YES user_id=12800 I wonder about this patch. PEP 292 clearly says that the first non-identifier character terminates the placeholder. So why would you expect that the e?e would cause an exception to be raised instead of a valid substitution for $ma? Will discuss on python-dev, but in any event, if we accept this patch we would need a unittest update, as well as documentation and PEP 292 updates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022173&group_id=5470 From noreply at sourceforge.net Tue Sep 7 07:30:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 07:30:28 2004 Subject: [Patches] [ python-Patches-963906 ] Unicode email address helper Message-ID: Patches item #963906, was opened at 2004-06-01 09:36 Message generated for change (Comment added) made by zenzen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=963906&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode email address helper Initial Comment: Converting email addresses between Unicode and ASCII is non trivial, as three different encodings are used (RFC2047, IDNA and ASCII). Here is an EmailAddress I use and a test suite, which I feel should be integrated into the email package. I'm quite happy to implement a different interface if the 'unicode subclass' design is unsuitable, although I got no feedback from the Email-SIG so they are either happy with it or asleep ;) ---------------------------------------------------------------------- >Comment By: Stuart Bishop (zenzen) Date: 2004-09-07 15:30 Message: Logged In: YES user_id=46639 I think that adding options to the existing APIs simply makes the Unicode support feel tacked on (as it would be). It is also error prone, where if you are following best practice and using Unicode everywhere, you have to remember to explicitly pass the 'do_unicode=True' parameter to this one particular function. I think the alternative approach would be to use a codec, similar to how Unicode DNS domains are handled ('foo@example.com'.decode('emailaddress')). I still prefer the OO approach though, as it allows the programmer to treat email addresses as a standard Unicode string with a few extra features, such as the __cmp__ method I've since added to EmailAddress.py and the test suite: >>> e = EmailAddress(u'renee@ol\u00e9.de', u'Rene\u00e9 Acut\u00e9') >>> e == str(e) True >>> e == unicode(e) True >>> e == str(EmailAddress(e.upper())) True >>> e == unicode(EmailAddress(e.upper())) True ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 23:19 Message: Logged In: YES user_id=21627 Oops, test cases are there - only documentation is lacking. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 23:18 Message: Logged In: YES user_id=21627 I think it is inappropriate to create new API for this. Instead, one of the many functions that already deal with address parsing need to be enhanced. For example, email.Util.formataddr should learn to format unicode strings, too. Likewise, parseaddr could grow a parameter do_unicode, or a second function parseaddr_unicode could be added. There is IMO no need for a new class. In addition, this patch lacks documentation and test cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=963906&group_id=5470 From noreply at sourceforge.net Tue Sep 7 17:54:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 17:54:45 2004 Subject: [Patches] [ python-Patches-1019220 ] Multi-line strings and unittest Message-ID: Patches item #1019220, was opened at 2004-08-30 19:00 Message generated for change (Comment added) made by purcell You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1019220&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Steve Purcell (purcell) Summary: Multi-line strings and unittest Initial Comment: Currently, the output of unittest.py looks like this: F ====================================================================== FAIL: test_newline (__main__.NewlineTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "unittestnewline.py", line 7, in test_newline self.assertEqual('foo\nbar\nbaz', 'foo\nbaz\nbaz') AssertionError: 'foo\nbar\nbaz' != 'foo\nbaz\nbaz' ---------------------------------------------------------------------- Ran 1 test in 0.001s FAILED (failures=1) For long strings to be compared, an output like 'foo\nbar\nbaz' != 'foo\nbaz\nbaz' isn't particularly useful. The attached patch makes it look like this for multi-line strings: F ====================================================================== FAIL: test_newline (__main__.NewlineTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "unittestnewline.py", line 7, in test_newline self.assertEqual('foo\nbar\nbaz', 'foo\nbaz\nbaz') AssertionError: '''foo bar baz''' != '''foo baz baz''' ---------------------------------------------------------------------- Ran 1 test in 0.001s FAILED (failures=1) The behavior is only changed for strings which contain newline characters. I admittedly do not know if there is a problem when using the patched unittest.py on Windows (due to the different newline convention). ---------------------------------------------------------------------- >Comment By: Steve Purcell (purcell) Date: 2004-09-07 17:54 Message: Logged In: YES user_id=21477 Hi Raymond and Felix, I also don't find this an improvement. I personally like to see the repr() version of the strings, since it shows embedded tabs etc; the output proposed here makes such differences much less obvious. More interesting was a patch submitted some time ago that used difflib to show the exact differing areas between the unequal strings. I was wary of that patch due to the amount of extra code it introduced, and an incompatibility with Jython at the time, IIRC. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 07:08 Message: Logged In: YES user_id=80475 Steve, would you rule on this one? I personally do not find it to be an improvement. Walter D?rwald is also a heavy unittester and may have a helpful viewpoint. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1019220&group_id=5470 From noreply at sourceforge.net Tue Sep 7 19:21:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 19:21:16 2004 Subject: [Patches] [ python-Patches-1019220 ] Multi-line strings and unittest Message-ID: Patches item #1019220, was opened at 2004-08-30 19:00 Message generated for change (Comment added) made by felixwiemann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1019220&group_id=5470 Category: Library (Lib) Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Steve Purcell (purcell) Summary: Multi-line strings and unittest Initial Comment: Currently, the output of unittest.py looks like this: F ====================================================================== FAIL: test_newline (__main__.NewlineTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "unittestnewline.py", line 7, in test_newline self.assertEqual('foo\nbar\nbaz', 'foo\nbaz\nbaz') AssertionError: 'foo\nbar\nbaz' != 'foo\nbaz\nbaz' ---------------------------------------------------------------------- Ran 1 test in 0.001s FAILED (failures=1) For long strings to be compared, an output like 'foo\nbar\nbaz' != 'foo\nbaz\nbaz' isn't particularly useful. The attached patch makes it look like this for multi-line strings: F ====================================================================== FAIL: test_newline (__main__.NewlineTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "unittestnewline.py", line 7, in test_newline self.assertEqual('foo\nbar\nbaz', 'foo\nbaz\nbaz') AssertionError: '''foo bar baz''' != '''foo baz baz''' ---------------------------------------------------------------------- Ran 1 test in 0.001s FAILED (failures=1) The behavior is only changed for strings which contain newline characters. I admittedly do not know if there is a problem when using the patched unittest.py on Windows (due to the different newline convention). ---------------------------------------------------------------------- >Comment By: Felix Wiemann (felixwiemann) Date: 2004-09-07 19:21 Message: Logged In: YES user_id=1014490 > I personally like to see the repr() > version of the strings, since it shows embedded tabs etc; The patch doesn't change that. It just replaces \n by real newlines. The reason why I wrote this patch is that the Docutils unit tests often contain very many lines of text, and if something has changed, it is very handy to be able to copy some lines of test output into the test files. But this only works if the lines contain real newlines -- the long character sequences with some intermittent '\n's unittest.py currently produces are almost unusable. If I've been able convince you, feel free to re-open the bug. :-) ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2004-09-07 17:54 Message: Logged In: YES user_id=21477 Hi Raymond and Felix, I also don't find this an improvement. I personally like to see the repr() version of the strings, since it shows embedded tabs etc; the output proposed here makes such differences much less obvious. More interesting was a patch submitted some time ago that used difflib to show the exact differing areas between the unequal strings. I was wary of that patch due to the amount of extra code it introduced, and an incompatibility with Jython at the time, IIRC. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 07:08 Message: Logged In: YES user_id=80475 Steve, would you rule on this one? I personally do not find it to be an improvement. Walter D?rwald is also a heavy unittester and may have a helpful viewpoint. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1019220&group_id=5470 From noreply at sourceforge.net Tue Sep 7 22:30:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 22:30:41 2004 Subject: [Patches] [ python-Patches-998993 ] Decoding incomplete unicode Message-ID: Patches item #998993, was opened at 2004-07-27 22:35 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=998993&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Decoding incomplete unicode Initial Comment: Pythons unicode machinery currently has problems when decoding incomplete input. When codecs.StreamReader.read() encounters a decoding error it reads more bytes from the input stream and retries decoding. This is broken for two reasons: 1) The error might be due to a malformed byte sequence in the input, a problem that can't be fixed by reading more bytes. 2) There may be no more bytes available at this time. Once more data is available decoding can't continue because bytes from the input stream have already been read and thrown away. (sio.DecodingInputFilter has the same problems) To fix this, three changes are required: a) We need stateful versions of the decoding functions that don't raise "truncated data" exceptions, but decode as much as possible and return the position where decoding stopped. b) The StreamReader classes need to use those stateful versions of the decoding functions. c) codecs.StreamReader needs to keep an internal buffer with the bytes read from the input stream that haven't been decoded into unicode yet. For a) the Python API already exists: All decoding functions in the codecs module return a tuple containing the decoded unicode object and the number of bytes consumed. But this functionality isn't implemented in the decoders: codec.utf_8_decode(u"a?".encode("utf-8")[:-1]) raises an exception instead of returning (u"a", 1). This can be fixed by extending the UTF-8 and UTF-16 decoding functions like this: PyObject *PyUnicode_DecodeUTF8Stateful( const char *s, int size, const char *errors, int *consumed) If consumed == NULL PyUnicode_DecodeUTF8Stateful() behaves like PyUnicode_DecodeUTF8() (i.e. it raises a "truncated data" exception). If consumed != NULL it decodes as much as possible (raising exceptions for invalid byte sequences) and puts the number of bytes consumed into *consumed. Additionally for UTF-7 we need to pass the decoder state around. An implementation of c) looks like this: def read(self, size=-1): if size < 0: data = self.bytebuffer+self.stream.read() else: data = self.bytebuffer+self.stream.read(size) (object, decodedbytes) = self.decode(data, self.errors) self.bytebuffer = data[decodedbytes:] return object Unfortunately this changes the semantics. read() might return an empty string even if there would be more data available. But this can be fixed if we continue reading until at least one character is available. The patch implements a few additional features: read() has an additional argument chars that can be used to specify the number of characters that should be returned. readline() is supported on all readers derived from codecs.StreamReader(). readline() and readlines() have an additional option for dropping the u"\n". The patch is still missing changes to the escape codecs ("unicode_escape" and "raw_unicode_escape"), but it has test cases that check the new functionality for all affected codecs (UTF-7, UTF-8, UTF-16, UTF-16-LE, UTF-16-BE). ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-09-07 22:30 Message: Logged In: YES user_id=89016 Checked in as: Doc/api/concrete.tex 1.56 Doc/lib/libcodecs.tex 1.33 Include/unicodeobject.h 2.46 Lib/codecs.py 1.34 Lib/encodings/utf_16.py 1.5 Lib/encodings/utf_16_be.py 1.4 Lib/encodings/utf_16_le.py 1.4 Lib/encodings/utf_8.py 1.3 Lib/test/test_codecs.py 1.13 Misc/NEWS 1.1129 Modules/_codecsmodule.c 2.20 Objects/unicodeobject.c 2.224 I've added documentation for the chars and keepends argument. I've removed the #defines for the UTF7 codec, although I think they should be added back in: The C functions *do* exist, it's just the UCS2/UCS4 name mangling that's missing. > diff4.txt looks OK (even though I don't like the final > argument in the _codecs module decode APIs). I think the other alternatives are worse: 1) Implement two version of the decoding function that use a common PyUnicode_Decode???() (like the first patch does). 2) Implement two versions of the decoding functions, each one using a separate version of PyUnicode_Decode???(). I'll open the new report once 2.4 is out the door and we can start discussing the final argument and the feed API. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-31 16:19 Message: Logged In: YES user_id=38388 diff4.txt looks OK (even though I don't like the final argument in the _codecs module decode APIs). Please remove the UTF-7 #defines and then check it in. Thanks, Walter. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-08-27 21:00 Message: Logged In: YES user_id=89016 diff4.txt includes patches to the documentation ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-08-24 22:02 Message: Logged In: YES user_id=89016 Here is a third version of the patch with the requested changes. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-24 12:15 Message: Logged In: YES user_id=38388 Walter, please update the first version of the patch as outlined in my python-dev posting: * move the UTF-7 change to a separate patch (this won't get checked in for Python 2.4) * remove the extra APIs from the _codecs patches (these are not needed; instead the existing APIs should be updated to use the ...Stateful() C APIs and pass along the possibly changed consumed setting) Thanks. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-08-10 21:22 Message: Logged In: YES user_id=89016 Here is a second version of the patch: It implements a final argument for read/write/decode/encode, with specifies whether this is the last call to the method, it adds a chunk reader/writer API to StreamReader/Writer and it unifies the stateless/stateful decoding functions in the codecs module again. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-27 23:11 Message: Logged In: YES user_id=21627 Marc-Andre, can you please specifically point to the places in the patch where it violates the principles you have stated? E.g. where does it maintain state outside the StreamReader/Writer? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-27 22:56 Message: Logged In: YES user_id=38388 Walter, I think you should split this into multiple feature requests. First of all, I agree that the current situation with StreamReader on malformed input is not really ideal. However, I don't think we need to fix anything in terms of adding new interfaces. Also, introducing state at the encode/decode breaks the design of the codecs functions -- only StreamReader/Writer may maintain state. Now, the situation is not that bad though: the case of a codec continuing as far as possible and then returning the decoded data as well as the number of bytes consumed is basically just another error handling scheme. Let's call it "break". If errors is set to "break", the codec will stop decoding/encoding and return the coded data as well as the number of input characters consumed. You could then use this scheme in the StreamWriter/Reader to implement the "read as far as possible" scheme. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=998993&group_id=5470 From noreply at sourceforge.net Tue Sep 7 22:34:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 22:34:49 2004 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) >Assigned to: Brett Cannon (bcannon) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-09-07 22:34 Message: Logged In: YES user_id=89016 I'm getting the following error from the new test__locale: test test__locale failed -- Traceback (most recent call last): File "/home/walter/Achtung/Python-codec- small/dist/src/Lib/test/test__locale.py", line 37, in test_lc_numeric "%r != %r (%s); " File "/home/walter/Achtung/Python-codec- small/dist/src/Lib/locale.py", line 363, in getlocale return _parse_localename(localename) File "/home/walter/Achtung/Python-codec- small/dist/src/Lib/locale.py", line 278, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: lv_LV BTW, could someone have a look at Johannes' test_doctest and test_inspect patches? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-09-07 04:32 Message: Logged In: YES user_id=357491 OK, test__locale has been checked in. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-30 13:00 Message: Logged In: YES user_id=469548 Brett: that's just one of the drawbacks of doing data-driven testing with unittest. I don't think it's terribly important, so the test is OK to me. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-27 05:44 Message: Logged In: YES user_id=357491 Just attached a new version of test__locale. Since it is so small of a file and the change so drastic I just uploaded the whole file. Only drawback is before the test kept testing all locales when there was a failure while my implementation stops at the first failure discovered. Don't know if it is important to test all locales. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-24 18:59 Message: Logged In: YES user_id=80475 Walter, I'm afraid I don't have time for these right now. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-08-20 18:39 Message: Logged In: YES user_id=89016 Raymond, can you take a look at the patches? ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-20 17:06 Message: Logged In: YES user_id=469548 Another one: ported test_inspect to unittest and moved out the inspect fodder out into two modules instead of using the ugly imp.load_source and TESTFN. I also did a bit of rearrangement so that the TestCase classes mostly match the sections in the library docs. I used a separate module (inspect_fodder2) and class for the decorators tests. Those are kind of small now, but I'll check in http://python.org/sf/1011890 after this port and let it grow without having to update test_getfunctions(). ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-19 17:14 Message: Logged In: YES user_id=469548 Hum yes, that was me trying out how doctest fails. The expected outcome should have been True. Can you try the corrected version? Test_zipfile has been checked in as rev 1.11. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-08-18 21:29 Message: Logged In: YES user_id=89016 doctest tests should be OK. The error tests in test_unpack can be done with PyUnit too, you either use self.assertRaises(ValueError, eval, "a,b = Seq()") or try: a,b = Seq() except ValueError: pass else: self.fail("failed") test_zipfile_unittest.py looks OK, but should of course be named test_zipfile.py when you check it in. test_unpack_doctest.py gives me: ********************************************** ************************ Failure in example: a == 4 and b == 5 and c == 6 from line #14 of test.test_unpack_doctest.doctests in /home/walter/Achtung/Python- test/dist/src/Lib/test/test_unpack_doctest.pyc Expected: False Got: True ********************************************** ************************ 1 items had failures: 1 of 28 in test.test_unpack_doctest.doctests ***Test Failed*** 1 failures. Traceback (most recent call last): File "Lib/test/test_unpack_doctest.py", line 133, in ? test_main(verbose=True) File "Lib/test/test_unpack_doctest.py", line 130, in test_main test_support.run_doctest(test_unpack_doctest, verbose) File "/home/walter/Achtung/Python- test/dist/src/Lib/test/test_support.py", line 318, in run_doctest raise TestFailed("%d of %d doctests failed" % (f, t)) test.test_support.TestFailed: 1 of 28 doctests failed ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-18 15:23 Message: Logged In: YES user_id=469548 Is there any problem with porting test scripts to doctest instead of unittest? doctest is just perfect for test_unpack (doctest version attached). I've also ported test_zipfile to unittest (attached as well). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-31 18:31 Message: Logged In: YES user_id=89016 OK, checked in as: Lib/test/mapping_tests.py 1.1 Lib/test/test_os.py 1.22 Lib/test/test_shelve.py 1.7 Lib/test/test_types.py 1.60 Lib/test/test_userdict.py 1.19 Lib/test/test_weakref.py 1.39 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-29 01:02 Message: Logged In: YES user_id=80475 Looks good. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-28 22:59 Message: Logged In: YES user_id=89016 OK, I've updated the docstring for dict.update() (Object/dictobject.c 2.160) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-27 21:04 Message: Logged In: YES user_id=89016 dict_diff.txt is a patch that tries to share tests between test_dict, test_userdict, test_os, test_shelve and test_weakref. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-25 22:29 Message: Logged In: YES user_id=31435 Don't really care myself. Would be nice if the docstring for dict.update() matched the new realities, though . BTW, there is a reliable and conventional way to detect whether the 'dict' argument was passed to UserDict.update: use a unique marker object instead of the universally visible None. Like _marker = object() at module level, and ...(self, dict=_marker, ...) in the method defn. That can't be fooled without deliberate intent to deceive. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-25 22:21 Message: Logged In: YES user_id=80475 IMO, it is fine as is. I would be suprised if some code were relying on UserDict.update(None) raising an exception. This sort of thing also comes up also in places like the string and random modules whereever a function or method with an optional argument gets wrapped by another function. The only way around this is to use *args and then you break code that used the unfortunately named "dict" argument as a keyword. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-25 21:32 Message: Logged In: YES user_id=89016 Merging test_dict and test_userdict revealed a difference between dict and UserDict.UserDict: >>> import UserDict >>> d = UserDict.UserDict() >>> d.update(None) >>> d {} >>> d = {} >>> d.update(None) Traceback (most recent call last): File "", line 1, in ? TypeError: iteration over non-sequence Should we do anything about this? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-20 18:03 Message: Logged In: YES user_id=80475 test_dict is fine. Consider beefing up the tests for update(). As of Py2.4, it now takes all the same argument possibilites as dict(): d.update(a=1, b=2) d.update([('a', 1), ('b', 2)]) Also, try to link in: from test_userdict import TestMappingProtocol This was supposed to provide tests common to all mappings. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-04-03 13:06 Message: Logged In: YES user_id=89016 The attached test_dict.py moves the dict tests from test_types.py to a new PyUnit test script. Code coverage for dictobject.c is at 90.76% (up from 89.51%) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-03-15 13:17 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_binascii delete Lib/test/test_binascii.py 1.17 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-03-13 21:26 Message: Logged In: YES user_id=80475 Okay, this one is fine. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-19 00:49 Message: Logged In: YES user_id=89016 Here's the next one: test_binascii.py. Code coverage in binascii.c is at 92% (could be improved by enhancing test_binhex.py). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-13 23:46 Message: Logged In: YES user_id=33168 Looked good to me, test_future_pyunit.diff checked in as: * Lib/test/badsyntax_future3.py 1.2 * Lib/test/badsyntax_future4.py 1.2 * Lib/test/badsyntax_future5.py 1.2 * Lib/test/badsyntax_future6.py 1.2 * Lib/test/badsyntax_future7.py 1.2 * Lib/test/badsyntax_future8.py 1.1 * Lib/test/badsyntax_future9.py 1.1 * Lib/test/test_future.py 1.7 * Lib/test/test_future1.py 1.3 * Lib/test/test_future2.py 1.2 * Lib/test/output/test_future 1.4 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-13 22:47 Message: Logged In: YES user_id=33168 Walter, I didn't get a mail from SF either. After you do a cvs add, you need to use -N to cvs diff. For example, cvs diff -N new_file_added_to_cvs_but_not_committed. If you look carefully, you can see this in the patch on the diff line for each file. I'll take a look at the patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-13 21:18 Message: Logged In: YES user_id=89016 Here is a version of test_future ported to PyUnit (test_future_pyunit.diff). If this makes sense to you Neal, please check it in. (BTW, how did you convince CVS to include badsyntax_future8.py and badsyntax_future9.py in the diff? Doing a "cvs add" only results in " Lib/test/badsyntax_future8.py is a new entry, no comparison available") ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-11 13:36 Message: Logged In: YES user_id=89016 md5/weakref patch checked in as: Lib/test/test_weakref.py 1.33 Lib/test/test_md5.py 1.5 Lib/test/output/test_md5 remove ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 07:05 Message: Logged In: YES user_id=33168 Improve coverage for test_future too. I'm not sure if test future can be ported to PyUnit. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 06:52 Message: Logged In: YES user_id=33168 Attached are two tests (in one file, I'm being lazy, sorry) to improve test coverage for md5c.c and _weakref.c. test_md5 was ported to unittest, weakref, just adds two little tests to get coverage up to 100%. If you like, just go ahead and check in. You will need to remove Lib/test/output/test_md5 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-08 12:42 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/list_tests.py 1.1 Lib/test/seq_tests.py 1.1 Lib/test/test_list.py 1.1 Lib/test/test_tuple.py 1.1 Lib/test/test_types.py 1.56 Lib/test/test_userlist.py 1.11 Lib/test/output/test_types 1.3 Next will be test_binascii.py before I continue with test_types.py. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-08 00:49 Message: Logged In: YES user_id=80475 Looks good. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-11-27 20:48 Message: Logged In: YES user_id=89016 Here the first part of the test_types port: list and tuple tests have been moved to their own scripts: test_tuple.py and test_list.py. Common tests for tuple, list and UserList are shared (in seq_test.py and list_test.py) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-02 03:53 Message: Logged In: YES user_id=80475 Applied as: Lib/test/test_slice.py 1.5. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 01:52 Message: Logged In: YES user_id=80475 Looks good. I added a couple of minor tests. Revised patch attached. Okay to apply. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-31 21:49 Message: Logged In: YES user_id=89016 Thanks! Here's another one: test_slice.py ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 01:04 Message: Logged In: YES user_id=80475 Done. See: Lib/test/test_longexp.py 1.9; previous revision: 1.8 Lib/test/test_pep263.py 1.3; previous revision: 1.2 Lib/test/test_sets.py 1.27; previous revision: 1.26 Lib/test/test_structseq.py 1.5; previous revision: 1.4 Lib/test/output/test_longexp delete; previous revision: 1.3 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 19:10 Message: Logged In: YES user_id=80475 Will do! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-30 19:06 Message: Logged In: YES user_id=89016 Here's test_structse.py converted with a few additional tests. If all three scripts are OK, could you check them in Raymond, as I'll be on vacation for three weeks? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-09 17:47 Message: Logged In: YES user_id=89016 Here are two simple ones: test_pep263 and test_longexp. I can't think of any additional tests to add. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-23 15:38 Message: Logged In: YES user_id=80475 Fixed Walter's review comments and committed as Lib/test/test_compile.py 1.19 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-23 13:49 Message: Logged In: YES user_id=89016 Are you sure, that the code path is the same in the new test_argument_handling() as in the old test? I.e. is "eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"? The print statement in test_float_literals should be changed to a comment. Should the imports in test_unary_minus() be moved to the start of the script? Otherwise the test looks (and runs) OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 21:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-19 11:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 21:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-18 16:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 01:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 23:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 14:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 23:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 21:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 21:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 20:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 20:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 18:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 14:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 17:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 15:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-19 01:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 05:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 04:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 03:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 02:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 01:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply at sourceforge.net Tue Sep 7 23:06:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 23:07:17 2004 Subject: [Patches] [ python-Patches-1020845 ] Decimal performance enhancements Message-ID: Patches item #1020845, was opened at 2004-09-02 10:08 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Facundo Batista (facundobatista) Summary: Decimal performance enhancements Initial Comment: The attached patch implements a collection of performance enhancements for decimal.py. They are currently focused on the performance of the telco benchmark in the sandbox (i.e. they aim to speed up instantiation, addition, multiplication and quantization). The main strategy used (a subclass for NaN and infinite values) can be extended to encompass more methods in order to improve performance in other situations. There is one non-performance related change included - the '_sign' attribute is renamed to '_isneg' to better reflect the boolean nature of the property. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-08 07:06 Message: Logged In: YES user_id=1038590 With the _sign/_isneg thing, I figured out the reason it was hurting my brain - I was failing to think of the value as representing a two's complement sign bit. Once I thought of it that way, it made sense with the original terminology. I suspect the lesser speedup on test_decimal.py may be due to the fact that the current version of the patch only optimises the operations used by the telco benchmark (instantiation, addition, multiplication, quantisation). As we speed up other operations, the performance on the unit tests should improve. As far as the API itself goes, the major differences I am aware of are the existence of the new subclass, and the use of __new__ instead of __init__. That will presumably be a bit more work to implement in C since another class is needed. Do we need to document somewhere that Decimal(x) may return an instance of a subclass of Decimal() rather than an instance of Decimal itself? My current plan is to produce a second version of this patch that: 1. Starts again from current CVS 2. Leaves '_sign' alone 3. Leaves existing doc strings alone (I broke a couple of them in this version of patch - I hadn't really thought about how to handle them properly) 4. For overridden methods in the _Special_Value class, duplicate the docstring from the baseclass with "f.__doc__ = Decimal.f.__doc__". This should avoid giving different answers for "help(Decimal(1).__add__)" and "help(Decimal('NaN').__add__)". 5. Optimises all operations, not just the four used by the telco benchmark (with the new strategy in place, this is mostly legwork - cutting and pasting the special-value related stuff to the new subclass, and rearranging appropriately. Unfortunately, it's legwork that I can't see a sensible way to automate, so it's a matter of taking the time to do it, and then checking that the tests all still pass). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 15:05 Message: Logged In: YES user_id=80475 Facundo, do you have time to look at this one? We need to: * revert the _isneg variable name change * find out why it gives a 2:1 gain on telco but only 10% on test_decimal.py * make sure the API has not changed in a way that will make it more difficult someday to convert this into C and make it a built-in. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-02 15:18 Message: Logged In: YES user_id=80475 Nice job. The timings do improve and the approach is reasonable. Please go ahead to the next step and polish it up. Also, please change _isneg back to _sign. That matches the terminology in the spec, the machine centric sign bit viewpoint of 754R, and the components of the user visible as_tuple() method. The goal is to make the patch as minimal as possible, to keep the API unchanged, and improve performance. Using the __new__ method was smart. That more closely corresponds to a potential C implementation of an immutable type. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-02 10:11 Message: Logged In: YES user_id=1038590 I forgot to add that this is NOT yet a production quality patch. The doc strings, in particular, need work. I'm mainly posting it so Raymond can have a look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 From noreply at sourceforge.net Tue Sep 7 23:59:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 00:01:08 2004 Subject: [Patches] [ python-Patches-1020845 ] Decimal performance enhancements Message-ID: Patches item #1020845, was opened at 2004-09-01 19:08 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Facundo Batista (facundobatista) Summary: Decimal performance enhancements Initial Comment: The attached patch implements a collection of performance enhancements for decimal.py. They are currently focused on the performance of the telco benchmark in the sandbox (i.e. they aim to speed up instantiation, addition, multiplication and quantization). The main strategy used (a subclass for NaN and infinite values) can be extended to encompass more methods in order to improve performance in other situations. There is one non-performance related change included - the '_sign' attribute is renamed to '_isneg' to better reflect the boolean nature of the property. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 16:59 Message: Logged In: YES user_id=80475 Glad to hear you've wrapped your head around the sign bit. FWIW, it bugged me too. But it is so closely tied to the spec that it is better to adjust our mental model than change the code. Do extend your optimizations to the other functions. Don't just optimize the benchmark -- that defeats the purpose. Can you work together with Facundo on this one? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-07 16:06 Message: Logged In: YES user_id=1038590 With the _sign/_isneg thing, I figured out the reason it was hurting my brain - I was failing to think of the value as representing a two's complement sign bit. Once I thought of it that way, it made sense with the original terminology. I suspect the lesser speedup on test_decimal.py may be due to the fact that the current version of the patch only optimises the operations used by the telco benchmark (instantiation, addition, multiplication, quantisation). As we speed up other operations, the performance on the unit tests should improve. As far as the API itself goes, the major differences I am aware of are the existence of the new subclass, and the use of __new__ instead of __init__. That will presumably be a bit more work to implement in C since another class is needed. Do we need to document somewhere that Decimal(x) may return an instance of a subclass of Decimal() rather than an instance of Decimal itself? My current plan is to produce a second version of this patch that: 1. Starts again from current CVS 2. Leaves '_sign' alone 3. Leaves existing doc strings alone (I broke a couple of them in this version of patch - I hadn't really thought about how to handle them properly) 4. For overridden methods in the _Special_Value class, duplicate the docstring from the baseclass with "f.__doc__ = Decimal.f.__doc__". This should avoid giving different answers for "help(Decimal(1).__add__)" and "help(Decimal('NaN').__add__)". 5. Optimises all operations, not just the four used by the telco benchmark (with the new strategy in place, this is mostly legwork - cutting and pasting the special-value related stuff to the new subclass, and rearranging appropriately. Unfortunately, it's legwork that I can't see a sensible way to automate, so it's a matter of taking the time to do it, and then checking that the tests all still pass). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 00:05 Message: Logged In: YES user_id=80475 Facundo, do you have time to look at this one? We need to: * revert the _isneg variable name change * find out why it gives a 2:1 gain on telco but only 10% on test_decimal.py * make sure the API has not changed in a way that will make it more difficult someday to convert this into C and make it a built-in. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-02 00:18 Message: Logged In: YES user_id=80475 Nice job. The timings do improve and the approach is reasonable. Please go ahead to the next step and polish it up. Also, please change _isneg back to _sign. That matches the terminology in the spec, the machine centric sign bit viewpoint of 754R, and the components of the user visible as_tuple() method. The goal is to make the patch as minimal as possible, to keep the API unchanged, and improve performance. Using the __new__ method was smart. That more closely corresponds to a potential C implementation of an immutable type. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-01 19:11 Message: Logged In: YES user_id=1038590 I forgot to add that this is NOT yet a production quality patch. The doc strings, in particular, need work. I'm mainly posting it so Raymond can have a look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 From noreply at sourceforge.net Wed Sep 8 00:42:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 00:42:06 2004 Subject: [Patches] [ python-Patches-936169 ] CodeContext - an extension to show you where you are Message-ID: Patches item #936169, was opened at 2004-04-16 11:40 Message generated for change (Comment added) made by noamr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936169&group_id=5470 Category: IDLE Group: None >Status: Open Resolution: Accepted Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: CodeContext - an extension to show you where you are Initial Comment: Have you ever edited a code, and did not know exactly which block you were closing? Or didn't know exactly even in which block you were? This extension solves this problem, by adding a few lines (3 by default) above the IDLE edit box, which show you exactly where you are in your code. For example, you may be editing a code with three indentation levels (has three tabs on its left), but to find the reason for this - to find what is the meaning of your block - you have to scroll upwards a long distance. CodeContext will add three lines of text above your edit box, so your editing window will look like this: ---------------------------------- Class MyClass: def myMethod(self, arg1, arg2): <- auto-updated if something_happens: ---------------------------------- i += 1 print "hello" <- You edit here ... ---------------------------------- So you can know that i is incremented by 1, in the method myMethod of class MyClass, and only if something_happens. To make this extension work, you have to put the attached file, CodeContext.py, in your IDLE directory, and add these lines to config-extensions.def: ---------------------------------- [CodeContext] enable=1 numlines=3 bgcolor=LightGray fgcolor=Black ---------------------------------- A note to KBK: I think this extension can go into the Python distribution. If you don't like it, or if you want a testing period, you can put "enable=0" instead of "enable=1". In this way, most users will not even know CodeContext exists, but "power users" will be able to put "enable=1" and have CodeContext if they like it (- I like it). Best wishes, Noam Raphael ---------------------------------------------------------------------- >Comment By: Noam Raphael (noamr) Date: 2004-09-08 01:42 Message: Logged In: YES user_id=679426 I improved the algorithm for finding the context lines, so it now scans the minimum number of lines it needs in order to update the panel - it uses the information it already has in a better way. This makes the scrolling of long modules more "streaming", on my not-that-new computer. I tried it, and it seems to work just as good as the old algorithm - it produces the same results. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-06-06 04:33 Message: Logged In: YES user_id=149084 Checked in Noam Raphael's improvements. CodeContext.py 1.4 et. al. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2004-04-28 00:24 Message: Logged In: YES user_id=679426 Hello, I think that showing / not showing the Code Context panel should be a persistent setting - if the user wants it, it will appear, and if he doesn't, it won't. The concept of "it has an initial state, and you can change it afterwards if you like" is confusing. Using a persistent setting makes a keyboard shortcut unnecessary - I think that usually the user will be happy with what he likes, and won't hide/show the panel many times. So I made the <> event save the new setting in the user's configuration file. The new setting will be applied also to new windows opened in the same session. This required me to add a SetOption method to configHandler.IdleConf. Also, the initialization of the CodeContext instance required the menu item to be already installed, but EditorWindow.load_extension installs the menu items after it initializes the extension's instance. It turns out that the menu items can be installed before the instance initialization, so I changed it. Another problem was that the Code Context menu item was installed on shell windows, but wasn't functioning, which was quite confusing. So I added new optional configurations for extensions: enable_shell and enable_editor, which allow you to write extensions only for the editor/shell window, without using the "isinstance(editwin, PyShell)" trick. About using a Text widget instead of a Label - it may work, I don't know, but making the Label behave as I wanted was hard enough, and it looks fine to me as it is, so I leave it for now. Bye Bye, Noam ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-04-27 01:28 Message: Logged In: YES user_id=149084 Yeah, I noticed that problem and wasn't sure if I had caused it. Thanks, fixed. CodeContext.py 1.3. Sorry I took so long getting back, for some reason I'm not getting mail from SF when a Tracker item changes (though I don't have a problem sending mail to myself via users.sourceforge.net). I added an entry for Code Context on the Options menu, it toggles the context pane. Any suggestion for a keybinding? A remaining problem is the text in the Label doesn't quite line up with the text in the main pane. Adding a pad of one space makes it almost perfect. But maybe using a Text widget instead of a Label would fix it 100%? ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2004-04-22 23:11 Message: Logged In: YES user_id=679426 I'm glad you like it! Thanks for the changes - your English is certainly better than mine. A buglet you made - in line 91 you added "elif" as a block opener which should show the previous block opener of the same indentation, which is a good idea, but you wrote: if opener == "else" or "elif": which is an expression which always yields True. It caused all block openers to be displayed, not only the relevant ones. Change it to if opener in ("else", "elif"): and it will work fine. Happy Israel Independence Day! (I know you probably don't celebrate it, but it is on 27 April this year) Noam ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-04-21 23:09 Message: Logged In: YES user_id=149084 Cool Extension! Thanks! CodeContext.py 1.1 config-extensions.def 1.13 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936169&group_id=5470 From noreply at sourceforge.net Wed Sep 8 01:03:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 01:03:52 2004 Subject: [Patches] [ python-Patches-1024041 ] Add arguments to RE functions Message-ID: Patches item #1024041, was opened at 2004-09-08 02:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1024041&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: Add arguments to RE functions Initial Comment: Attached are diffs for the sre.py module and to its documentation. Testing should also be added. ========================= My message to python-dev: Hello, I've now finished teaching Python to a group of people, and regular expressions was a part of the course. I have encountered a few missing features (that is, optional arguments) in RE functions. I've checked, and it seems to me that they can be added very easily. The first missing feature is the "flags" argument in the findall and finditer functions. Searching for all occurances of an RE is, of course, a legitimate action, and I had to use (?s) in my RE, instead of adding re.DOTALL, which, to my opinion, is a lot clearer. The solution is simple: the functions sub, subn, split, findall and finditer all first compile the given RE, with the flags argument set to 0, and then run the appropriate method. As far as I can see, they could all get an additional optional argument, flags=0, and compile the RE with it. The second missing feature is the ability to specify start and end indices when doing matches and searches. This feature is available when using a compiled RE, but isn't mentioned at all in any of the straightforward functions (That's why I didn't even know it was possible, until I now checked - I naturally assumed that all the functionality is availabe when using the functions). I think these should be added to the functions match, search, findall and finditer. This feature isn't documented for the findall and finditer methods, but I checked, and it seems to work fine. (In case you are interested in the use case: the exercise was to parse an XML file. It was done by first matching the beginning of a tag, then trying to match attributes, and so on - each match starts from where the previous successfull match ended. Since I didn't know of this feature, it was done by replacing the original string with a substring after every match, which is terribly unefficient.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1024041&group_id=5470 From noreply at sourceforge.net Wed Sep 8 01:47:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 01:47:34 2004 Subject: [Patches] [ python-Patches-1020845 ] Decimal performance enhancements Message-ID: Patches item #1020845, was opened at 2004-09-01 21:08 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Facundo Batista (facundobatista) Summary: Decimal performance enhancements Initial Comment: The attached patch implements a collection of performance enhancements for decimal.py. They are currently focused on the performance of the telco benchmark in the sandbox (i.e. they aim to speed up instantiation, addition, multiplication and quantization). The main strategy used (a subclass for NaN and infinite values) can be extended to encompass more methods in order to improve performance in other situations. There is one non-performance related change included - the '_sign' attribute is renamed to '_isneg' to better reflect the boolean nature of the property. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2004-09-07 20:47 Message: Logged In: YES user_id=752496 Nick: Submit the second version of the patch and I'll review it. Also feel free to contact me by mail anytime. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 18:59 Message: Logged In: YES user_id=80475 Glad to hear you've wrapped your head around the sign bit. FWIW, it bugged me too. But it is so closely tied to the spec that it is better to adjust our mental model than change the code. Do extend your optimizations to the other functions. Don't just optimize the benchmark -- that defeats the purpose. Can you work together with Facundo on this one? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-07 18:06 Message: Logged In: YES user_id=1038590 With the _sign/_isneg thing, I figured out the reason it was hurting my brain - I was failing to think of the value as representing a two's complement sign bit. Once I thought of it that way, it made sense with the original terminology. I suspect the lesser speedup on test_decimal.py may be due to the fact that the current version of the patch only optimises the operations used by the telco benchmark (instantiation, addition, multiplication, quantisation). As we speed up other operations, the performance on the unit tests should improve. As far as the API itself goes, the major differences I am aware of are the existence of the new subclass, and the use of __new__ instead of __init__. That will presumably be a bit more work to implement in C since another class is needed. Do we need to document somewhere that Decimal(x) may return an instance of a subclass of Decimal() rather than an instance of Decimal itself? My current plan is to produce a second version of this patch that: 1. Starts again from current CVS 2. Leaves '_sign' alone 3. Leaves existing doc strings alone (I broke a couple of them in this version of patch - I hadn't really thought about how to handle them properly) 4. For overridden methods in the _Special_Value class, duplicate the docstring from the baseclass with "f.__doc__ = Decimal.f.__doc__". This should avoid giving different answers for "help(Decimal(1).__add__)" and "help(Decimal('NaN').__add__)". 5. Optimises all operations, not just the four used by the telco benchmark (with the new strategy in place, this is mostly legwork - cutting and pasting the special-value related stuff to the new subclass, and rearranging appropriately. Unfortunately, it's legwork that I can't see a sensible way to automate, so it's a matter of taking the time to do it, and then checking that the tests all still pass). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 02:05 Message: Logged In: YES user_id=80475 Facundo, do you have time to look at this one? We need to: * revert the _isneg variable name change * find out why it gives a 2:1 gain on telco but only 10% on test_decimal.py * make sure the API has not changed in a way that will make it more difficult someday to convert this into C and make it a built-in. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-02 02:18 Message: Logged In: YES user_id=80475 Nice job. The timings do improve and the approach is reasonable. Please go ahead to the next step and polish it up. Also, please change _isneg back to _sign. That matches the terminology in the spec, the machine centric sign bit viewpoint of 754R, and the components of the user visible as_tuple() method. The goal is to make the patch as minimal as possible, to keep the API unchanged, and improve performance. Using the __new__ method was smart. That more closely corresponds to a potential C implementation of an immutable type. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-01 21:11 Message: Logged In: YES user_id=1038590 I forgot to add that this is NOT yet a production quality patch. The doc strings, in particular, need work. I'm mainly posting it so Raymond can have a look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 From noreply at sourceforge.net Wed Sep 8 01:49:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 01:49:04 2004 Subject: [Patches] [ python-Patches-1024041 ] Add arguments to RE functions Message-ID: Patches item #1024041, was opened at 2004-09-07 18:03 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1024041&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) >Assigned to: Raymond Hettinger (rhettinger) Summary: Add arguments to RE functions Initial Comment: Attached are diffs for the sre.py module and to its documentation. Testing should also be added. ========================= My message to python-dev: Hello, I've now finished teaching Python to a group of people, and regular expressions was a part of the course. I have encountered a few missing features (that is, optional arguments) in RE functions. I've checked, and it seems to me that they can be added very easily. The first missing feature is the "flags" argument in the findall and finditer functions. Searching for all occurances of an RE is, of course, a legitimate action, and I had to use (?s) in my RE, instead of adding re.DOTALL, which, to my opinion, is a lot clearer. The solution is simple: the functions sub, subn, split, findall and finditer all first compile the given RE, with the flags argument set to 0, and then run the appropriate method. As far as I can see, they could all get an additional optional argument, flags=0, and compile the RE with it. The second missing feature is the ability to specify start and end indices when doing matches and searches. This feature is available when using a compiled RE, but isn't mentioned at all in any of the straightforward functions (That's why I didn't even know it was possible, until I now checked - I naturally assumed that all the functionality is availabe when using the functions). I think these should be added to the functions match, search, findall and finditer. This feature isn't documented for the findall and finditer methods, but I checked, and it seems to work fine. (In case you are interested in the use case: the exercise was to parse an XML file. It was done by first matching the beginning of a tag, then trying to match attributes, and so on - each match starts from where the previous successfull match ended. Since I didn't know of this feature, it was done by replacing the original string with a substring after every match, which is terribly unefficient.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1024041&group_id=5470 From noreply at sourceforge.net Wed Sep 8 11:17:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 11:17:17 2004 Subject: [Patches] [ python-Patches-1024238 ] Fix for 1022152 Message-ID: Patches item #1024238, was opened at 2004-09-08 19:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1024238&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Durdin (adurdin) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for 1022152 Initial Comment: This is a fix for bug 1022152 "Bad examples of gettext.translation" It adds in the required domain parameter to gettext.translation() calls. File changed: /cvsroot/python/python/dist/src/Doc/lib/libgettext.tex ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1024238&group_id=5470 From noreply at sourceforge.net Wed Sep 8 17:37:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 17:37:51 2004 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Brett Cannon (bcannon) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-08 17:37 Message: Logged In: YES user_id=469548 Yeah, bug #1023798 reported that and Brett fixed it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-09-07 22:34 Message: Logged In: YES user_id=89016 I'm getting the following error from the new test__locale: test test__locale failed -- Traceback (most recent call last): File "/home/walter/Achtung/Python-codec- small/dist/src/Lib/test/test__locale.py", line 37, in test_lc_numeric "%r != %r (%s); " File "/home/walter/Achtung/Python-codec- small/dist/src/Lib/locale.py", line 363, in getlocale return _parse_localename(localename) File "/home/walter/Achtung/Python-codec- small/dist/src/Lib/locale.py", line 278, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: lv_LV BTW, could someone have a look at Johannes' test_doctest and test_inspect patches? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-09-07 04:32 Message: Logged In: YES user_id=357491 OK, test__locale has been checked in. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-30 13:00 Message: Logged In: YES user_id=469548 Brett: that's just one of the drawbacks of doing data-driven testing with unittest. I don't think it's terribly important, so the test is OK to me. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-27 05:44 Message: Logged In: YES user_id=357491 Just attached a new version of test__locale. Since it is so small of a file and the change so drastic I just uploaded the whole file. Only drawback is before the test kept testing all locales when there was a failure while my implementation stops at the first failure discovered. Don't know if it is important to test all locales. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-24 18:59 Message: Logged In: YES user_id=80475 Walter, I'm afraid I don't have time for these right now. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-08-20 18:39 Message: Logged In: YES user_id=89016 Raymond, can you take a look at the patches? ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-20 17:06 Message: Logged In: YES user_id=469548 Another one: ported test_inspect to unittest and moved out the inspect fodder out into two modules instead of using the ugly imp.load_source and TESTFN. I also did a bit of rearrangement so that the TestCase classes mostly match the sections in the library docs. I used a separate module (inspect_fodder2) and class for the decorators tests. Those are kind of small now, but I'll check in http://python.org/sf/1011890 after this port and let it grow without having to update test_getfunctions(). ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-19 17:14 Message: Logged In: YES user_id=469548 Hum yes, that was me trying out how doctest fails. The expected outcome should have been True. Can you try the corrected version? Test_zipfile has been checked in as rev 1.11. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-08-18 21:29 Message: Logged In: YES user_id=89016 doctest tests should be OK. The error tests in test_unpack can be done with PyUnit too, you either use self.assertRaises(ValueError, eval, "a,b = Seq()") or try: a,b = Seq() except ValueError: pass else: self.fail("failed") test_zipfile_unittest.py looks OK, but should of course be named test_zipfile.py when you check it in. test_unpack_doctest.py gives me: ********************************************** ************************ Failure in example: a == 4 and b == 5 and c == 6 from line #14 of test.test_unpack_doctest.doctests in /home/walter/Achtung/Python- test/dist/src/Lib/test/test_unpack_doctest.pyc Expected: False Got: True ********************************************** ************************ 1 items had failures: 1 of 28 in test.test_unpack_doctest.doctests ***Test Failed*** 1 failures. Traceback (most recent call last): File "Lib/test/test_unpack_doctest.py", line 133, in ? test_main(verbose=True) File "Lib/test/test_unpack_doctest.py", line 130, in test_main test_support.run_doctest(test_unpack_doctest, verbose) File "/home/walter/Achtung/Python- test/dist/src/Lib/test/test_support.py", line 318, in run_doctest raise TestFailed("%d of %d doctests failed" % (f, t)) test.test_support.TestFailed: 1 of 28 doctests failed ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-18 15:23 Message: Logged In: YES user_id=469548 Is there any problem with porting test scripts to doctest instead of unittest? doctest is just perfect for test_unpack (doctest version attached). I've also ported test_zipfile to unittest (attached as well). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-31 18:31 Message: Logged In: YES user_id=89016 OK, checked in as: Lib/test/mapping_tests.py 1.1 Lib/test/test_os.py 1.22 Lib/test/test_shelve.py 1.7 Lib/test/test_types.py 1.60 Lib/test/test_userdict.py 1.19 Lib/test/test_weakref.py 1.39 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-29 01:02 Message: Logged In: YES user_id=80475 Looks good. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-28 22:59 Message: Logged In: YES user_id=89016 OK, I've updated the docstring for dict.update() (Object/dictobject.c 2.160) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-27 21:04 Message: Logged In: YES user_id=89016 dict_diff.txt is a patch that tries to share tests between test_dict, test_userdict, test_os, test_shelve and test_weakref. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-25 22:29 Message: Logged In: YES user_id=31435 Don't really care myself. Would be nice if the docstring for dict.update() matched the new realities, though . BTW, there is a reliable and conventional way to detect whether the 'dict' argument was passed to UserDict.update: use a unique marker object instead of the universally visible None. Like _marker = object() at module level, and ...(self, dict=_marker, ...) in the method defn. That can't be fooled without deliberate intent to deceive. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-25 22:21 Message: Logged In: YES user_id=80475 IMO, it is fine as is. I would be suprised if some code were relying on UserDict.update(None) raising an exception. This sort of thing also comes up also in places like the string and random modules whereever a function or method with an optional argument gets wrapped by another function. The only way around this is to use *args and then you break code that used the unfortunately named "dict" argument as a keyword. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-25 21:32 Message: Logged In: YES user_id=89016 Merging test_dict and test_userdict revealed a difference between dict and UserDict.UserDict: >>> import UserDict >>> d = UserDict.UserDict() >>> d.update(None) >>> d {} >>> d = {} >>> d.update(None) Traceback (most recent call last): File "", line 1, in ? TypeError: iteration over non-sequence Should we do anything about this? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-20 18:03 Message: Logged In: YES user_id=80475 test_dict is fine. Consider beefing up the tests for update(). As of Py2.4, it now takes all the same argument possibilites as dict(): d.update(a=1, b=2) d.update([('a', 1), ('b', 2)]) Also, try to link in: from test_userdict import TestMappingProtocol This was supposed to provide tests common to all mappings. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-04-03 13:06 Message: Logged In: YES user_id=89016 The attached test_dict.py moves the dict tests from test_types.py to a new PyUnit test script. Code coverage for dictobject.c is at 90.76% (up from 89.51%) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-03-15 13:17 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_binascii delete Lib/test/test_binascii.py 1.17 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-03-13 21:26 Message: Logged In: YES user_id=80475 Okay, this one is fine. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-19 00:49 Message: Logged In: YES user_id=89016 Here's the next one: test_binascii.py. Code coverage in binascii.c is at 92% (could be improved by enhancing test_binhex.py). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-13 23:46 Message: Logged In: YES user_id=33168 Looked good to me, test_future_pyunit.diff checked in as: * Lib/test/badsyntax_future3.py 1.2 * Lib/test/badsyntax_future4.py 1.2 * Lib/test/badsyntax_future5.py 1.2 * Lib/test/badsyntax_future6.py 1.2 * Lib/test/badsyntax_future7.py 1.2 * Lib/test/badsyntax_future8.py 1.1 * Lib/test/badsyntax_future9.py 1.1 * Lib/test/test_future.py 1.7 * Lib/test/test_future1.py 1.3 * Lib/test/test_future2.py 1.2 * Lib/test/output/test_future 1.4 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-13 22:47 Message: Logged In: YES user_id=33168 Walter, I didn't get a mail from SF either. After you do a cvs add, you need to use -N to cvs diff. For example, cvs diff -N new_file_added_to_cvs_but_not_committed. If you look carefully, you can see this in the patch on the diff line for each file. I'll take a look at the patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-13 21:18 Message: Logged In: YES user_id=89016 Here is a version of test_future ported to PyUnit (test_future_pyunit.diff). If this makes sense to you Neal, please check it in. (BTW, how did you convince CVS to include badsyntax_future8.py and badsyntax_future9.py in the diff? Doing a "cvs add" only results in " Lib/test/badsyntax_future8.py is a new entry, no comparison available") ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-11 13:36 Message: Logged In: YES user_id=89016 md5/weakref patch checked in as: Lib/test/test_weakref.py 1.33 Lib/test/test_md5.py 1.5 Lib/test/output/test_md5 remove ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 07:05 Message: Logged In: YES user_id=33168 Improve coverage for test_future too. I'm not sure if test future can be ported to PyUnit. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 06:52 Message: Logged In: YES user_id=33168 Attached are two tests (in one file, I'm being lazy, sorry) to improve test coverage for md5c.c and _weakref.c. test_md5 was ported to unittest, weakref, just adds two little tests to get coverage up to 100%. If you like, just go ahead and check in. You will need to remove Lib/test/output/test_md5 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-08 12:42 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/list_tests.py 1.1 Lib/test/seq_tests.py 1.1 Lib/test/test_list.py 1.1 Lib/test/test_tuple.py 1.1 Lib/test/test_types.py 1.56 Lib/test/test_userlist.py 1.11 Lib/test/output/test_types 1.3 Next will be test_binascii.py before I continue with test_types.py. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-08 00:49 Message: Logged In: YES user_id=80475 Looks good. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-11-27 20:48 Message: Logged In: YES user_id=89016 Here the first part of the test_types port: list and tuple tests have been moved to their own scripts: test_tuple.py and test_list.py. Common tests for tuple, list and UserList are shared (in seq_test.py and list_test.py) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-02 03:53 Message: Logged In: YES user_id=80475 Applied as: Lib/test/test_slice.py 1.5. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 01:52 Message: Logged In: YES user_id=80475 Looks good. I added a couple of minor tests. Revised patch attached. Okay to apply. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-31 21:49 Message: Logged In: YES user_id=89016 Thanks! Here's another one: test_slice.py ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 01:04 Message: Logged In: YES user_id=80475 Done. See: Lib/test/test_longexp.py 1.9; previous revision: 1.8 Lib/test/test_pep263.py 1.3; previous revision: 1.2 Lib/test/test_sets.py 1.27; previous revision: 1.26 Lib/test/test_structseq.py 1.5; previous revision: 1.4 Lib/test/output/test_longexp delete; previous revision: 1.3 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 19:10 Message: Logged In: YES user_id=80475 Will do! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-30 19:06 Message: Logged In: YES user_id=89016 Here's test_structse.py converted with a few additional tests. If all three scripts are OK, could you check them in Raymond, as I'll be on vacation for three weeks? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-09 17:47 Message: Logged In: YES user_id=89016 Here are two simple ones: test_pep263 and test_longexp. I can't think of any additional tests to add. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-23 15:38 Message: Logged In: YES user_id=80475 Fixed Walter's review comments and committed as Lib/test/test_compile.py 1.19 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-23 13:49 Message: Logged In: YES user_id=89016 Are you sure, that the code path is the same in the new test_argument_handling() as in the old test? I.e. is "eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"? The print statement in test_float_literals should be changed to a comment. Should the imports in test_unary_minus() be moved to the start of the script? Otherwise the test looks (and runs) OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 21:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-19 11:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 21:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-18 16:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 01:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 23:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 14:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 23:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 21:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 21:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 20:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 20:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 18:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 14:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 17:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 15:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-19 01:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 05:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 04:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 03:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 02:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 01:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply at sourceforge.net Wed Sep 8 19:33:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 19:33:57 2004 Subject: [Patches] [ python-Patches-1020188 ] Use Py_CLEAR where necessary to avoid crashes Message-ID: Patches item #1020188, was opened at 2004-09-01 00:35 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020188&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Michael Hudson (mwh) Summary: Use Py_CLEAR where necessary to avoid crashes Initial Comment: The Py_CLEAR macro was introduced to make it less tempting to write incorrect code in the form Py_DECREF(self->field); self->field = NULL; because that can expose a half-destroyed object if deallocation can cause self->field to be read. This patch fixes mistakes like this that still exist in the core. Only cases that are potentially dangerous are fixed in this patch. If self->field can only reference a special kind of [builtin] object, then it's just a style bug because we know that the builtin object isn't evil. Likewise if the code is operating on an automatic variable. It might be nice to fix those style bugs anyway, to discourage the broken idiom. Just for kicks, here's a way to use this bug in reversed to crash the interpreter: import array, gc, weakref a = array.array('c') wr = weakref.ref(a, lambda _: gc.get_referents(rev)) rev = reversed(a) del a list(rev) For me, this crashes immediately with a debug build and after a couple tries otherwise. Also attached is clearcand.py to help find these cases. It's not comprehensive, but it's a start. Usage: $ find src -name '*.c' | python clearcand.py | fgrep -- '->' The patch requires SF #1020185 to be applied for genobject.c to compile without warnings. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 12:33 Message: Logged In: YES user_id=80475 FWIW, rather than add specific testcases (closing the barndoor after the horse has escaped), it might be a good idea to fixup the OP's search code and add it to the toolbox. Future errors of this type are better caught through code scans than by testing stuff that already works fine. Of course, if highly motivated, you can do both :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-01 07:32 Message: Logged In: YES user_id=6656 Test cases would be nice. If it's easy for someone whose thought about it, that would be great, if not assign to me and I'll get to it... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-01 02:06 Message: Logged In: YES user_id=80475 Accepted and applied. See: Include/object.h 2.129 Modules/itertoolsmodule.c 1.35 Objects/enumobject.c 1.18 Objects/genobject.c 1.4 Objects/iterobject.c 1.19 Thanks for the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020188&group_id=5470 From noreply at sourceforge.net Wed Sep 8 23:03:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 23:03:15 2004 Subject: [Patches] [ python-Patches-1024670 ] Error when int sent to PyLong_AsUnsignedLong Message-ID: Patches item #1024670, was opened at 2004-09-08 14:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1024670&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Clinton R. Nixon (crnixon) Assigned to: Nobody/Anonymous (nobody) Summary: Error when int sent to PyLong_AsUnsignedLong Initial Comment: When sending a Python integer as an argument to PyLong_AsUnsignedLong, the following error occurs SystemError: Objects/longobject.c:240: bad argument to internal function This error comes from the fact that PyLong_AsUnsignedLong, unlike PyLong_AsLong, does not check to see if the number is a long or integer, but only a long. This patch checks to see if the number is an integer, and if so, calls PyInt_AsUnsignedLongMask. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1024670&group_id=5470 From noreply at sourceforge.net Thu Sep 9 01:45:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 9 01:45:48 2004 Subject: [Patches] [ python-Patches-1020845 ] Decimal performance enhancements Message-ID: Patches item #1020845, was opened at 2004-09-02 10:08 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Facundo Batista (facundobatista) Summary: Decimal performance enhancements Initial Comment: The attached patch implements a collection of performance enhancements for decimal.py. They are currently focused on the performance of the telco benchmark in the sandbox (i.e. they aim to speed up instantiation, addition, multiplication and quantization). The main strategy used (a subclass for NaN and infinite values) can be extended to encompass more methods in order to improve performance in other situations. There is one non-performance related change included - the '_sign' attribute is renamed to '_isneg' to better reflect the boolean nature of the property. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-09 09:45 Message: Logged In: YES user_id=1038590 2nd version of patch attached. It does NOT use a subclassing strategy for optimisation due to the following charming little problem I found with that approach: >>> import decimal >>> class foo(decimal.Decimal): pass >>> x = foo("NaN") >>> isinstance(x, foo) False I couldn't find any sane way to get around this, and it seemed to be a showstopper given the amount of work that has gone into making all the builtin types easily subclassable. The new patch instead relies mainly on the following techniques: - defer invocation of getcontext() as late as possible, so that we only call it if the context is going to be referenced - use issubclass(x, basestring) to identify if there are special cases that need handling, then use _is_nan and _is_infinity to determine exactly which special case applies (this slows the special cases down slightly, but speeds up the normal cases a lot) - make _convert_other a helper function instead of a method There are also some other minor changes that were present in the original patch (use sum() in __nonzero__, reduce the number of calls to list.reversed() in __add__, extract digits directly from integer inputs with divmod, rearrange _fixexponents to minimise context method calls, cache results of method calls in various operations) Facundo, two particular changes I'd like you to OK are: - _fix now indents the second call to _fixexponents to be inside the if block (in CVS, _fix_exponents could get called again directly on the result of the previous call to _fix_exponents, which didn't seem to make any sense) - _fixexponents returns immediately for NaN as well as infinite values This version of patch appears to give around a 40% speedup on direct execution of test_decimal.py, and all the tests still pass for me. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-09-08 09:47 Message: Logged In: YES user_id=752496 Nick: Submit the second version of the patch and I'll review it. Also feel free to contact me by mail anytime. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 07:59 Message: Logged In: YES user_id=80475 Glad to hear you've wrapped your head around the sign bit. FWIW, it bugged me too. But it is so closely tied to the spec that it is better to adjust our mental model than change the code. Do extend your optimizations to the other functions. Don't just optimize the benchmark -- that defeats the purpose. Can you work together with Facundo on this one? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-08 07:06 Message: Logged In: YES user_id=1038590 With the _sign/_isneg thing, I figured out the reason it was hurting my brain - I was failing to think of the value as representing a two's complement sign bit. Once I thought of it that way, it made sense with the original terminology. I suspect the lesser speedup on test_decimal.py may be due to the fact that the current version of the patch only optimises the operations used by the telco benchmark (instantiation, addition, multiplication, quantisation). As we speed up other operations, the performance on the unit tests should improve. As far as the API itself goes, the major differences I am aware of are the existence of the new subclass, and the use of __new__ instead of __init__. That will presumably be a bit more work to implement in C since another class is needed. Do we need to document somewhere that Decimal(x) may return an instance of a subclass of Decimal() rather than an instance of Decimal itself? My current plan is to produce a second version of this patch that: 1. Starts again from current CVS 2. Leaves '_sign' alone 3. Leaves existing doc strings alone (I broke a couple of them in this version of patch - I hadn't really thought about how to handle them properly) 4. For overridden methods in the _Special_Value class, duplicate the docstring from the baseclass with "f.__doc__ = Decimal.f.__doc__". This should avoid giving different answers for "help(Decimal(1).__add__)" and "help(Decimal('NaN').__add__)". 5. Optimises all operations, not just the four used by the telco benchmark (with the new strategy in place, this is mostly legwork - cutting and pasting the special-value related stuff to the new subclass, and rearranging appropriately. Unfortunately, it's legwork that I can't see a sensible way to automate, so it's a matter of taking the time to do it, and then checking that the tests all still pass). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 15:05 Message: Logged In: YES user_id=80475 Facundo, do you have time to look at this one? We need to: * revert the _isneg variable name change * find out why it gives a 2:1 gain on telco but only 10% on test_decimal.py * make sure the API has not changed in a way that will make it more difficult someday to convert this into C and make it a built-in. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-02 15:18 Message: Logged In: YES user_id=80475 Nice job. The timings do improve and the approach is reasonable. Please go ahead to the next step and polish it up. Also, please change _isneg back to _sign. That matches the terminology in the spec, the machine centric sign bit viewpoint of 754R, and the components of the user visible as_tuple() method. The goal is to make the patch as minimal as possible, to keep the API unchanged, and improve performance. Using the __new__ method was smart. That more closely corresponds to a potential C implementation of an immutable type. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-02 10:11 Message: Logged In: YES user_id=1038590 I forgot to add that this is NOT yet a production quality patch. The doc strings, in particular, need work. I'm mainly posting it so Raymond can have a look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 From noreply at sourceforge.net Thu Sep 9 04:24:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 9 04:24:57 2004 Subject: [Patches] [ python-Patches-1024041 ] Add arguments to RE functions Message-ID: Patches item #1024041, was opened at 2004-09-07 18:03 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1024041&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Raymond Hettinger (rhettinger) Summary: Add arguments to RE functions Initial Comment: Attached are diffs for the sre.py module and to its documentation. Testing should also be added. ========================= My message to python-dev: Hello, I've now finished teaching Python to a group of people, and regular expressions was a part of the course. I have encountered a few missing features (that is, optional arguments) in RE functions. I've checked, and it seems to me that they can be added very easily. The first missing feature is the "flags" argument in the findall and finditer functions. Searching for all occurances of an RE is, of course, a legitimate action, and I had to use (?s) in my RE, instead of adding re.DOTALL, which, to my opinion, is a lot clearer. The solution is simple: the functions sub, subn, split, findall and finditer all first compile the given RE, with the flags argument set to 0, and then run the appropriate method. As far as I can see, they could all get an additional optional argument, flags=0, and compile the RE with it. The second missing feature is the ability to specify start and end indices when doing matches and searches. This feature is available when using a compiled RE, but isn't mentioned at all in any of the straightforward functions (That's why I didn't even know it was possible, until I now checked - I naturally assumed that all the functionality is availabe when using the functions). I think these should be added to the functions match, search, findall and finditer. This feature isn't documented for the findall and finditer methods, but I checked, and it seems to work fine. (In case you are interested in the use case: the exercise was to parse an XML file. It was done by first matching the beginning of a tag, then trying to match attributes, and so on - each match starts from where the previous successfull match ended. Since I didn't know of this feature, it was done by replacing the original string with a substring after every match, which is terribly unefficient.) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 21:24 Message: Logged In: YES user_id=80475 Nice patch, but Guido and Fred like the API as is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1024041&group_id=5470 From noreply at sourceforge.net Thu Sep 9 05:54:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 9 05:54:33 2004 Subject: [Patches] [ python-Patches-901369 ] markupbase misses comments (bug 736659) Message-ID: Patches item #901369, was opened at 2004-02-20 15:58 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=901369&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: markupbase misses comments (bug 736659) Initial Comment: markupbase.ParserBase().parse_declaration calls parse_comment if the text starts with " [11, 13, 17] * If x is large, switch to a modern primality testing algorithm so that arbitrarily large primes can be found (perhaps for RSA purposes or some such). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870286&group_id=5470 From noreply at sourceforge.net Sat Sep 11 18:50:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 11 18:50:28 2004 Subject: [Patches] [ python-Patches-1026384 ] typo repair Message-ID: Patches item #1026384, was opened at 2004-09-11 18:24 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1026384&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: typo repair Initial Comment: The title says it all. two kinds of typos: - accomodate -> accommodate - occured -> occurred Cheers. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-11 18:50 Message: Logged In: YES user_id=469548 Indeed it does. Checked in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1026384&group_id=5470 From noreply at sourceforge.net Sat Sep 11 18:58:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 11 18:58:37 2004 Subject: [Patches] [ python-Patches-842567 ] reflect the removal of mpz Message-ID: Patches item #842567, was opened at 2003-11-15 04:00 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=842567&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: reflect the removal of mpz Initial Comment: mpz's doc says "This module will be removed in Python 2.3" but Python 2.3 has been released, so it should read: "This module has been removed in Python 2.3" Python 2.3.2 (#1, Oct 9 2003, 12:03:29) Type "help", "copyright", "credits" or "license" for more information. >>> import mpz Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named mpz ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-11 18:58 Message: Logged In: YES user_id=469548 Closing: mpz and libmpz are gone now. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-19 04:23 Message: Logged In: YES user_id=671362 Following your advice, I revised the previous patch. * remove the obscure part (This module will be removed in Python 2.3.) * add the version infomation to the availability of the module (use \versionchanged tag) I guess this is clearer what has changed since 2.3. The change is as follows: Deprecated since release 2.2. See the references at the end of this section for information about packages which provide similar functionality. This module will be removed in Python 2.3. This is an optional module. It is only available when Python is configured to include it, which requires that the GNU MP software is installed. --> patch applied Deprecated since release 2.2. See the references at the end of this section for information about packages which provide similar functionality. Changed in version 2.3: This is an optional module. It is only available when Python is configured to include it, which requires that the GNU MP software is installed. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-18 20:51 Message: Logged In: YES user_id=21627 I believe the patch is incorrect; the module is still available. The fact that you don't have it probably originates from the fact that you don't have gmp build environment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=842567&group_id=5470 From noreply at sourceforge.net Sat Sep 11 19:34:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 11 19:34:07 2004 Subject: [Patches] [ python-Patches-1024238 ] Fix for 1022152 Message-ID: Patches item #1024238, was opened at 2004-09-08 11:17 Message generated for change (Settings changed) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1024238&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Andrew Durdin (adurdin) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for 1022152 Initial Comment: This is a fix for bug 1022152 "Bad examples of gettext.translation" It adds in the required domain parameter to gettext.translation() calls. File changed: /cvsroot/python/python/dist/src/Doc/lib/libgettext.tex ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-11 19:34 Message: Logged In: YES user_id=469548 Checked in as rev 1.26 of libgettext.tex. Thanks for the patch! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1024238&group_id=5470 From noreply at sourceforge.net Sat Sep 11 19:50:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 11 19:50:11 2004 Subject: [Patches] [ python-Patches-1025795 ] Clarify language in Data Structures chapter of tutorial Message-ID: Patches item #1025795, was opened at 2004-09-10 13:54 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1025795&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: Clarify language in Data Structures chapter of tutorial Initial Comment: - Dictionary keys are in arbitrary order, but not random (which implies, well, intentional randomness) - Move a footnote closer to what it's talking about so that it doesn't look like we're saying that "0 == 0.0" can't be relied on - Minor language tweaks in the vicinity (I tried to change only what's actually confusing instead of anything that "can be better") ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-11 19:50 Message: Logged In: YES user_id=469548 Checked in as rev 1.248 of tut.tex with one minor tweak: I didn't change 'These have lower priorities' to 'These have lower priority' because I think the former makes clearer that there are multiple priorities between boolean operators. Thanks for the patch! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1025795&group_id=5470 From noreply at sourceforge.net Sun Sep 12 06:28:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 12 06:28:34 2004 Subject: [Patches] [ python-Patches-1022910 ] Conserve memory with list.pop() Message-ID: Patches item #1022910, was opened at 2004-09-06 03:16 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022910&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: Conserve memory with list.pop() Initial Comment: The current list resizing scheme only downsizes when more than 16 elements are removed in a single step: del a[100:120]. When popping elements off of a list one at a time, the current resizing approach never shrinks. This patch makes it shrink whenever more than half of the space is unused. There may be a better approach. This one is simple and avoids thrashing in stack applications that hover up and down around a nearly steady state. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-09-12 00:28 Message: Logged In: YES user_id=31435 +1 on the idea, and maybe on the code. Reading this routine always gave me a headache, and I finally figured out why: _new_size should be name new_allocated. It's the new value of self->allocated, after all, and has much less to do with newsize (which _new_size looks most like) or ob_size. If I rename the code like that, I find it much easier to follow. Then the tail end of the patched code looks like new_allocated = (newsize >> 3) + (self->ob_size < 8 ? 3 : 6) + newsize; if (newsize < (allocated >> 1)) new_allocated = newsize; Then I ask "why?" about the last "if" clause. That is, why change new_allocated away from the value it was given on the preceding line? IOW, if that was a good value for new_allocated when the list was growing, why not also when the list is shrinking? If we reset new_allocated to *exactly* the smaller requested new size, then if they add an element next time we have to endure a realloc right away again. I think it's good to leave some room for growth. If it turns out the list isn't yo-yo'ing, but going straight down to 0, that's fine, we'll just shrink it at a slightly slower pace then. For example, suppose the list has room for 500 slots, currently holds 250, and the last element is popped. Unconditionally accepting the first new_allocated computed would leave it with 249 + 3 + (249 >> 3) = 283 allocated slots instead of with 249. The relative difference is small, but the former is friendlier if the next operation is an append, and is faster to compute (skips the "if"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022910&group_id=5470 From noreply at sourceforge.net Sun Sep 12 19:15:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 12 19:15:49 2004 Subject: [Patches] [ python-Patches-1019220 ] Multi-line strings and unittest Message-ID: Patches item #1019220, was opened at 2004-08-30 19:00 Message generated for change (Comment added) made by felixwiemann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1019220&group_id=5470 Category: Library (Lib) Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Steve Purcell (purcell) Summary: Multi-line strings and unittest Initial Comment: Currently, the output of unittest.py looks like this: F ====================================================================== FAIL: test_newline (__main__.NewlineTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "unittestnewline.py", line 7, in test_newline self.assertEqual('foo\nbar\nbaz', 'foo\nbaz\nbaz') AssertionError: 'foo\nbar\nbaz' != 'foo\nbaz\nbaz' ---------------------------------------------------------------------- Ran 1 test in 0.001s FAILED (failures=1) For long strings to be compared, an output like 'foo\nbar\nbaz' != 'foo\nbaz\nbaz' isn't particularly useful. The attached patch makes it look like this for multi-line strings: F ====================================================================== FAIL: test_newline (__main__.NewlineTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "unittestnewline.py", line 7, in test_newline self.assertEqual('foo\nbar\nbaz', 'foo\nbaz\nbaz') AssertionError: '''foo bar baz''' != '''foo baz baz''' ---------------------------------------------------------------------- Ran 1 test in 0.001s FAILED (failures=1) The behavior is only changed for strings which contain newline characters. I admittedly do not know if there is a problem when using the patched unittest.py on Windows (due to the different newline convention). ---------------------------------------------------------------------- >Comment By: Felix Wiemann (felixwiemann) Date: 2004-09-12 19:15 Message: Logged In: YES user_id=1014490 Just in case anyone wants to use the patch: There is a bug in the patch, which pops up when using unicode strings. I uploaded a fixed version. The patch is against unittest.py rev. 1.63, as included in Python2.4a3. ---------------------------------------------------------------------- Comment By: Felix Wiemann (felixwiemann) Date: 2004-09-07 19:21 Message: Logged In: YES user_id=1014490 > I personally like to see the repr() > version of the strings, since it shows embedded tabs etc; The patch doesn't change that. It just replaces \n by real newlines. The reason why I wrote this patch is that the Docutils unit tests often contain very many lines of text, and if something has changed, it is very handy to be able to copy some lines of test output into the test files. But this only works if the lines contain real newlines -- the long character sequences with some intermittent '\n's unittest.py currently produces are almost unusable. If I've been able convince you, feel free to re-open the bug. :-) ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2004-09-07 17:54 Message: Logged In: YES user_id=21477 Hi Raymond and Felix, I also don't find this an improvement. I personally like to see the repr() version of the strings, since it shows embedded tabs etc; the output proposed here makes such differences much less obvious. More interesting was a patch submitted some time ago that used difflib to show the exact differing areas between the unequal strings. I was wary of that patch due to the amount of extra code it introduced, and an incompatibility with Jython at the time, IIRC. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 07:08 Message: Logged In: YES user_id=80475 Steve, would you rule on this one? I personally do not find it to be an improvement. Walter D?rwald is also a heavy unittester and may have a helpful viewpoint. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1019220&group_id=5470 From noreply at sourceforge.net Sun Sep 12 21:57:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 12 21:57:48 2004 Subject: [Patches] [ python-Patches-1022910 ] Conserve memory with list.pop() Message-ID: Patches item #1022910, was opened at 2004-09-06 02:16 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022910&group_id=5470 Category: Core (C code) Group: Python 2.4 >Status: Closed Resolution: None Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Conserve memory with list.pop() Initial Comment: The current list resizing scheme only downsizes when more than 16 elements are removed in a single step: del a[100:120]. When popping elements off of a list one at a time, the current resizing approach never shrinks. This patch makes it shrink whenever more than half of the space is unused. There may be a better approach. This one is simple and avoids thrashing in stack applications that hover up and down around a nearly steady state. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-12 14:57 Message: Logged In: YES user_id=80475 Revised and applies as Objects/listobject.c 2.223 * Changed the var name as requested. Great idea. * Changed the second "if" to only check for zero (so that lists can shrink all the way down). As requested, this change leaves non-zero length lists in an over-allocated state. * Restated the overallocation formula so that it depends only on the requested size instead of both requested and previous size. Doesn't change the growth schedule but does make the algorithm easier to analyze. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-09-11 23:28 Message: Logged In: YES user_id=31435 +1 on the idea, and maybe on the code. Reading this routine always gave me a headache, and I finally figured out why: _new_size should be name new_allocated. It's the new value of self->allocated, after all, and has much less to do with newsize (which _new_size looks most like) or ob_size. If I rename the code like that, I find it much easier to follow. Then the tail end of the patched code looks like new_allocated = (newsize >> 3) + (self->ob_size < 8 ? 3 : 6) + newsize; if (newsize < (allocated >> 1)) new_allocated = newsize; Then I ask "why?" about the last "if" clause. That is, why change new_allocated away from the value it was given on the preceding line? IOW, if that was a good value for new_allocated when the list was growing, why not also when the list is shrinking? If we reset new_allocated to *exactly* the smaller requested new size, then if they add an element next time we have to endure a realloc right away again. I think it's good to leave some room for growth. If it turns out the list isn't yo-yo'ing, but going straight down to 0, that's fine, we'll just shrink it at a slightly slower pace then. For example, suppose the list has room for 500 slots, currently holds 250, and the last element is popped. Unconditionally accepting the first new_allocated computed would leave it with 249 + 3 + (249 >> 3) = 283 allocated slots instead of with 249. The relative difference is small, but the former is friendlier if the next operation is an append, and is faster to compute (skips the "if"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022910&group_id=5470 From noreply at sourceforge.net Sun Sep 12 22:19:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 12 22:19:20 2004 Subject: [Patches] [ python-Patches-1026859 ] Add keyword arguments to Template substitutions Message-ID: Patches item #1026859, was opened at 2004-09-12 15:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1026859&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Add keyword arguments to Template substitutions Initial Comment: Allows beautiful, clean calls with keyword arguments when applicable: >>> Template('time is $obj').substitute(obj='money') 'time is money' If both a mapping and keywords are supplied, conflicts are resolved as they are for the dict constructor: >>> dict({'a':1}, a=2) {'a': 2} >>> Template('time is $obj').safe_substitute({'obj':'t'}, obj='money') 'time is money' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1026859&group_id=5470 From noreply at sourceforge.net Mon Sep 13 03:51:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 03:51:18 2004 Subject: [Patches] [ python-Patches-1025790 ] Add status code constants to httplib Message-ID: Patches item #1025790, was opened at 2004-09-10 21:48 Message generated for change (Comment added) made by adurdin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1025790&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Eland (andreweland) Assigned to: Nobody/Anonymous (nobody) Summary: Add status code constants to httplib Initial Comment: httplib doesn't define constants for the HTTP integer status codes, so most applications end up defining their own subset. This patch adds status code constants to httplib, using the same names as Twisted, and updates the documentation. ---------------------------------------------------------------------- Comment By: Andrew Durdin (adurdin) Date: 2004-09-13 11:51 Message: Logged In: YES user_id=625864 I think the best standard way of spelling the constants is to take them directly from the 10.x.x headings of RFC2616. This would require changing four of the names of the constants in the patch from: SWITCHING = 101 MULTIPLE_CHOICE = 300 NOT_ALLOWED = 405 PROXY_AUTH_REQUIRED = 407 to: SWITCHING_PROTOCOLS = 101 MULTIPLE_CHOICES = 300 METHOD_NOT_ALLOWED = 405 PROXY_AUTHENTICATION_REQUIRED = 407 Also, the following status codes are not part of the HTTP/1.1 standard as given in RFC2616: MULTI_STATUS = 207 INSUFFICIENT_STORAGE_SPACE = 507 NOT_EXTENDED = 510 Where do these come from? Being nonstandard, is it inappropriate to include them in httplib? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-11 06:54 Message: Logged In: YES user_id=21627 Unless the precise spelling of the constants is taken from some existing specification, I think the documentation needs to spell out the values, so that readers can easily confirm that a certain symbolic value has the meaning they expect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1025790&group_id=5470 From noreply at sourceforge.net Mon Sep 13 04:46:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 04:46:22 2004 Subject: [Patches] [ python-Patches-1026986 ] building on OpenBSD 3.5 Message-ID: Patches item #1026986, was opened at 2004-09-12 19:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1026986&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: building on OpenBSD 3.5 Initial Comment: Doing ./configure, make on OpenBSD 3.5 with Python 2.4a3 doesn't work. I looked in the OpenBSD 3.5 ports tree for Python 2.3, and saw a patch with a couple changes to Python's configure file. (plus a patch with a tiny tweak to one of the tests). With these changes, compile / make / regrtest.py seems to work: -bash-2.05b$ ../../python regrtest.py -q -unetwork No handlers could be found for logger "cookielib" -bash-2.05b$ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1026986&group_id=5470 From noreply at sourceforge.net Mon Sep 13 04:56:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 04:56:26 2004 Subject: [Patches] [ python-Patches-738389 ] fix for glob with directories which contain brackets Message-ID: Patches item #738389, was opened at 2003-05-15 13:11 Message generated for change (Settings changed) made by progoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=738389&group_id=5470 Category: Modules Group: Python 2.2.x >Status: Deleted Resolution: None Priority: 5 Submitted By: Steven Scott (progoth) Assigned to: Nobody/Anonymous (nobody) Summary: fix for glob with directories which contain brackets Initial Comment: see bug #738631, http://sourceforge.net/tracker/index.php?func=detail&aid=738361&group_id=5470&atid=105470 if you give glob a pattern with [...], it assumes it's a file pattern. this changes glob.py to add a \ in front of the [ if a directory actually exists with the bracket in it. it also changes translate in fnmatch.py to take the special case of \[ and add that straight to the regex instead of trying to handle the shell pattern. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=738389&group_id=5470 From noreply at sourceforge.net Mon Sep 13 07:54:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 07:54:56 2004 Subject: [Patches] [ python-Patches-1025790 ] Add status code constants to httplib Message-ID: Patches item #1025790, was opened at 2004-09-10 13:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1025790&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Eland (andreweland) Assigned to: Nobody/Anonymous (nobody) Summary: Add status code constants to httplib Initial Comment: httplib doesn't define constants for the HTTP integer status codes, so most applications end up defining their own subset. This patch adds status code constants to httplib, using the same names as Twisted, and updates the documentation. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-13 07:54 Message: Logged In: YES user_id=21627 207 comes from RFC 2518 (WebDAV), section 8.2.1 and 10.2. 507 likewise, section 10.6. It seems WebDAV codes that 102, 422, 423, 424 are missing. Likewise, 426 from RFC 2817 is missing, and 226 from RFC 3229. 510 comes from RFC 2774 (HTTP Extensions), section 7. Even though I agree with your procedure for creating "canonical" spellings, I think more documentation is needed. Following this procedure, it would be best to list RFC and section as the documentation; this might allow to leave out the numerical value IMO. OTOH, putting this all in a four-column table (constant name, value, RFC number, section) would make a very systematic presentation. ---------------------------------------------------------------------- Comment By: Andrew Durdin (adurdin) Date: 2004-09-13 03:51 Message: Logged In: YES user_id=625864 I think the best standard way of spelling the constants is to take them directly from the 10.x.x headings of RFC2616. This would require changing four of the names of the constants in the patch from: SWITCHING = 101 MULTIPLE_CHOICE = 300 NOT_ALLOWED = 405 PROXY_AUTH_REQUIRED = 407 to: SWITCHING_PROTOCOLS = 101 MULTIPLE_CHOICES = 300 METHOD_NOT_ALLOWED = 405 PROXY_AUTHENTICATION_REQUIRED = 407 Also, the following status codes are not part of the HTTP/1.1 standard as given in RFC2616: MULTI_STATUS = 207 INSUFFICIENT_STORAGE_SPACE = 507 NOT_EXTENDED = 510 Where do these come from? Being nonstandard, is it inappropriate to include them in httplib? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 22:54 Message: Logged In: YES user_id=21627 Unless the precise spelling of the constants is taken from some existing specification, I think the documentation needs to spell out the values, so that readers can easily confirm that a certain symbolic value has the meaning they expect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1025790&group_id=5470 From noreply at sourceforge.net Mon Sep 13 10:20:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 10:20:59 2004 Subject: [Patches] [ python-Patches-936813 ] fast modular exponentiation Message-ID: Patches item #936813, was opened at 2004-04-17 01:16 Message generated for change (Comment added) made by trevp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: fast modular exponentiation Initial Comment: For crypto-sized numbers, Python mod-exp is several times slower than GMP or OpenSSL (6x or more). Those libraries do crazy special-case stuff, + assembly, platform-specific tuning, and so on. However, there's some low-hanging fruit: this patch has a few basic optimizations giving a 2-3x speedup for numbers in the 1000-8000 bit range (that's what I've mostly tested; but the patch should improve, or at least not hurt, everything else): - x_mul() is special-cased for squaring, which is almost twice as fast as general multiplication. - x_mul() uses pointers instead of indices for iteration, giving ~10% speedup (under VC6). - the right-to-left square-and-multiply exponentiation algorithm is replaced with a left-to-right square-and-multiply, which takes advantage of small bases. - when the exponent is above a certain size, "k-ary" exponentiation is used to reduce the number of multiplications via precalculation. - when the modulus is odd, Montgomery reduction is used. - the Karatsuba cutoff seems too low. For multiplicands in the range of 500-5000 bits, Karatsuba slows multiplication by around ~25% (VC6sp4, Intel P4M 1.7 Ghz). For larger numbers, the benefits of Karatsuba are less than they could be. Currently, the cutoff is 35 digits (525 bits). I've tried 70, 140, 280, and 560. 70, 140, and 280 are roughly the same: they don't slow down small values, and they have good speedup on large ones. 560 is not quite as good for large values, but at least it doesn't hurt small ones. I know this is platform-dependent, but I think we should err on the side of making the cutoff too high and losing some optimization, instead of putting it too low and slowing things down. I suggest 70. A couple misc. things: - Negative exponents with a modulus no longer give an error, when the base is coprime with the modulus. Instead, it calculates the multiplicative inverse of the base with respect to the modulus, using the extended euclidean algorithm, and exponentiates that. Libraries like GMP and LibTomMath work the same way. Being able to take inverses mod a number is useful for cryptography (e.g. RSA, DSA, and Elgamal). - The diff includes patch 923643, which supports converting longs to byte-strings. Ignore the last few diff entries, if you don't want this. - I haven't looked into harmonizing with int_pow(). Something may have to be done. ---------------------------------------------------------------------- >Comment By: Trevor Perrin (trevp) Date: 2004-09-13 01:20 Message: Logged In: YES user_id=973611 Here's the 3rd part of the patch (long_mont.diff; Montgomery Reduction), diff'd against 2.4a3 and cleaned up a bit. Note that this doesn't include negative exponent handling. If this patch is accepted, I'll make a new tracker item for that, since it's not an optimization, just an "opportunistic feature" (it builds on one of the helper functions needed for Montgomery). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-29 19:47 Message: Logged In: YES user_id=31435 Same deal with the 2nd part of the patch (major format changes, minor code changes). Incidentally fixed an old leak bug in long_pow() during the review. Added code to raise a compile-time error (C) if SHIFT isn't divisible by 5, and removed long_pow's new hardcoded assumption that SHIFT is exactly 15. Include/longintrepr.h 2.16 Misc/NEWS 1.1120 Objects/longobject.c 1.163 This is cool stuff (& thank you!), but I'm sorry to say I can't foresee making time for the 3rd part of the patch for weeks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-29 15:21 Message: Logged In: YES user_id=31435 Checked in the first part of the patch, with major format changes (Python's C coding standard is hard 8-column tabs), and minor code changes: Include/longintrepr.h 2.15 Misc/ACKS 1.280 Misc/NEWS 1.1119 Objects/longobject.c 1.162 I don't know whether it's possible for me to get to part 2 of the patch before 2.4a3, but I would like to. It seems plainly impossible that I'll be able to get to part 3 before 2.4a3. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-22 01:39 Message: Logged In: YES user_id=973611 Pragmatics isn't my strong suit... but I get your drift :-). I split it into 3 diffs: 1) x_mul optimizations: (pointers instead of indices, special-case squaring, changing Karatsuba cutoff) 2) rewriting long_pow() for left-to-right 5-ary 3) Montgomery reduction. This also includes l_invmod(), since it's necessary for Montgomery. I've left out the code which exposes l_invmod() to the user (and associated docs, tests, and intobject changes). We could slap that on afterwards or not... Anyways, these are applied sequentially: longobject.c + longobject1.diff = longobject1.c longobject1.c + longobject2.diff = longobject2.c longobject2.c + longobject2.diff = longobject3.c Should I open new tracker items for them? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-21 12:29 Message: Logged In: YES user_id=31435 Pragmatics are a real problem here, Trevor. I don't foresee being able to make a solid block of sufficient hours to give to reviewing this before Python 2.4 is history (which is why I've left this patch unassigned, BTW -- I just can't promise to make enough time). So if nobody else can volunteer to review it, that alone is likely to leave the patch sitting here unapplied. But there are several independent changes in this patch, and it *could* be broken into several smaller patches. I tossed that bait out before, but you didn't bite. You should . ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-19 04:00 Message: Logged In: YES user_id=973611 Tim, thanks for the feedback. I'm uploading a new patch against CVS latest that fixes those issues, and adds docs and tests. Also, I cleaned up the code quite a bit, and got it properly handling (I hope) all the varied combinations of ints/longs, positives/negatives/zeros etc.. Unfortunately, Montgomery is the bulk of the speedup: http://trevp.net/long_pow/ But I could split out the negative exponent handling into a separate patch, if that would be easier. Anyways, I'd like to add more tests for the exponentiation stuff. Aside from that, I think the patch is complete. And more robust than previously, though I still wouldn't trust it until another person or two gives it a serious looking-over.... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-16 20:06 Message: Logged In: YES user_id=31435 Notes after a brief eyeball scan: Note that the expression a & 1 == 1 groups as a & (1 == 1) in C -- comparisons have higher precedence in C than bit- fiddling operators. Stuff like that is usually best resolved by explicitly parenthesizing any "impure" expression fiddling with bits. In this case, in a boolean expression plain a & 1 has the hoped-for effect. and is clearer anyway. Would be better to use "**" than "^" in comments when exponentiation is intended, since "^" means xor in both Python and C. Doc changes are needed, because you're changing visible semantics in some cases. Tests are needed, especially for new semantics. l_invmod can return NULL for more than one reason, but one of its callers ignores this, assuming that all NULL returns are due to lack of coprimality. It's unreasonable to, e.g., replace a MemoryError with a complaint about coprimality; this needs reworking. l_invmod should probably set an exception in the "not coprime" case. As is, it's a weird function, sometimes setting an exception when it returns NULL, but not setting one when coprimality doesn't obtain. That makes life difficult for callers (which isn't apparent in the patch, because its callers are currently ignoring this issue). The Montgomery reduction gimmicks grossly complicate this patch -- they're long-winded and hard to follow. That may come with the territory, but it's the only part of the patch that made me want to vomit . I'd be happier if it weren't there, for aesthetic, clarity, and maintainability reasons. How much of a speedup does it actually buy? You're right that int pow must deliver the same results as long pow, so code is needed for that too. "short int" versus "unbounded int" is increasingly meant to be an invisible internal implementation detail in Python. I'm also in favor of giving this meaning to modular negative exponents, btw, so no problem with that. An easy way would be to change int pow to delegate to long pow when this is needed. Pragmatics: there's a better chance of making 2.4 if the patch were done in bite-size stages. For example, no doc changes are needed to switch to 5-ary left-to-right exponentation, and that has no effect on the int implementation either, etc. A patch that did just that much probably would have gone in a long time ago. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-07-13 01:04 Message: Logged In: YES user_id=973611 Uploading 2nd version of longobject.diff - the only change is that patch 923643 is removed from this diff. That was a diff for converting longs to byte-strings, which I unnecessarily left in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=936813&group_id=5470 From noreply at sourceforge.net Mon Sep 13 11:03:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 11:03:38 2004 Subject: [Patches] [ python-Patches-1025790 ] Add status code constants to httplib Message-ID: Patches item #1025790, was opened at 2004-09-10 11:48 Message generated for change (Comment added) made by andreweland You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1025790&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Eland (andreweland) Assigned to: Nobody/Anonymous (nobody) Summary: Add status code constants to httplib Initial Comment: httplib doesn't define constants for the HTTP integer status codes, so most applications end up defining their own subset. This patch adds status code constants to httplib, using the same names as Twisted, and updates the documentation. ---------------------------------------------------------------------- >Comment By: Andrew Eland (andreweland) Date: 2004-09-13 09:03 Message: Logged In: YES user_id=646767 > I think the best standard way of spelling the constants is > to take them directly from the 10.x.x headings of RFC2616 The spellings in the initial patch come from Twisted, I kept the few non-canonical spellings to avoid confusing people who work with both httplib and Twisted. If the consensus is that canonical spellings should be used regardless, I'll update the patch. > It seems WebDAV codes that 102, 422, 423, 424 are missing Again, the subset chosen is from Twisted, I kept the additional codes compatibility. It does makes sense to include the others though, I'll add them. > OTOH, putting this all in a four-column table (constant name, value, > RFC number, section) would make a very systematic presentation. I avoided adding a comment for each code as the extra information provided by the comments was outweighed by the description of status codes swamping the httplib documentation. Using a table should keep the documentation compact, I'll try it out. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-13 05:54 Message: Logged In: YES user_id=21627 207 comes from RFC 2518 (WebDAV), section 8.2.1 and 10.2. 507 likewise, section 10.6. It seems WebDAV codes that 102, 422, 423, 424 are missing. Likewise, 426 from RFC 2817 is missing, and 226 from RFC 3229. 510 comes from RFC 2774 (HTTP Extensions), section 7. Even though I agree with your procedure for creating "canonical" spellings, I think more documentation is needed. Following this procedure, it would be best to list RFC and section as the documentation; this might allow to leave out the numerical value IMO. OTOH, putting this all in a four-column table (constant name, value, RFC number, section) would make a very systematic presentation. ---------------------------------------------------------------------- Comment By: Andrew Durdin (adurdin) Date: 2004-09-13 01:51 Message: Logged In: YES user_id=625864 I think the best standard way of spelling the constants is to take them directly from the 10.x.x headings of RFC2616. This would require changing four of the names of the constants in the patch from: SWITCHING = 101 MULTIPLE_CHOICE = 300 NOT_ALLOWED = 405 PROXY_AUTH_REQUIRED = 407 to: SWITCHING_PROTOCOLS = 101 MULTIPLE_CHOICES = 300 METHOD_NOT_ALLOWED = 405 PROXY_AUTHENTICATION_REQUIRED = 407 Also, the following status codes are not part of the HTTP/1.1 standard as given in RFC2616: MULTI_STATUS = 207 INSUFFICIENT_STORAGE_SPACE = 507 NOT_EXTENDED = 510 Where do these come from? Being nonstandard, is it inappropriate to include them in httplib? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 20:54 Message: Logged In: YES user_id=21627 Unless the precise spelling of the constants is taken from some existing specification, I think the documentation needs to spell out the values, so that readers can easily confirm that a certain symbolic value has the meaning they expect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1025790&group_id=5470 From noreply at sourceforge.net Mon Sep 13 16:33:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 16:33:48 2004 Subject: [Patches] [ python-Patches-1026859 ] Add keyword arguments to Template substitutions Message-ID: Patches item #1026859, was opened at 2004-09-12 16:19 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1026859&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Add keyword arguments to Template substitutions Initial Comment: Allows beautiful, clean calls with keyword arguments when applicable: >>> Template('time is $obj').substitute(obj='money') 'time is money' If both a mapping and keywords are supplied, conflicts are resolved as they are for the dict constructor: >>> dict({'a':1}, a=2) {'a': 2} >>> Template('time is $obj').safe_substitute({'obj':'t'}, obj='money') 'time is money' ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-13 10:33 Message: Logged In: YES user_id=12800 accepted, with slight modifications ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1026859&group_id=5470 From noreply at sourceforge.net Mon Sep 13 20:35:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 20:36:02 2004 Subject: [Patches] [ python-Patches-1019220 ] Multi-line strings and unittest Message-ID: Patches item #1019220, was opened at 2004-08-30 19:00 Message generated for change (Comment added) made by felixwiemann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1019220&group_id=5470 Category: Library (Lib) Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Steve Purcell (purcell) Summary: Multi-line strings and unittest Initial Comment: Currently, the output of unittest.py looks like this: F ====================================================================== FAIL: test_newline (__main__.NewlineTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "unittestnewline.py", line 7, in test_newline self.assertEqual('foo\nbar\nbaz', 'foo\nbaz\nbaz') AssertionError: 'foo\nbar\nbaz' != 'foo\nbaz\nbaz' ---------------------------------------------------------------------- Ran 1 test in 0.001s FAILED (failures=1) For long strings to be compared, an output like 'foo\nbar\nbaz' != 'foo\nbaz\nbaz' isn't particularly useful. The attached patch makes it look like this for multi-line strings: F ====================================================================== FAIL: test_newline (__main__.NewlineTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "unittestnewline.py", line 7, in test_newline self.assertEqual('foo\nbar\nbaz', 'foo\nbaz\nbaz') AssertionError: '''foo bar baz''' != '''foo baz baz''' ---------------------------------------------------------------------- Ran 1 test in 0.001s FAILED (failures=1) The behavior is only changed for strings which contain newline characters. I admittedly do not know if there is a problem when using the patched unittest.py on Windows (due to the different newline convention). ---------------------------------------------------------------------- >Comment By: Felix Wiemann (felixwiemann) Date: 2004-09-13 20:35 Message: Logged In: YES user_id=1014490 If anyone finds this tracker item later and wants to use the patch, please refer to CustomTestCase and _format_str in DocutilsTestSupport.py instead: http://cvs.sourceforge.net/viewcvs.py/docutils/docutils/test/DocutilsTestSupport.py The patch in this tracker item still has bugs which are fixed in the above mentioned file. (Sorry for causing lots of mail traffic.) ---------------------------------------------------------------------- Comment By: Felix Wiemann (felixwiemann) Date: 2004-09-12 19:15 Message: Logged In: YES user_id=1014490 Just in case anyone wants to use the patch: There is a bug in the patch, which pops up when using unicode strings. I uploaded a fixed version. The patch is against unittest.py rev. 1.63, as included in Python2.4a3. ---------------------------------------------------------------------- Comment By: Felix Wiemann (felixwiemann) Date: 2004-09-07 19:21 Message: Logged In: YES user_id=1014490 > I personally like to see the repr() > version of the strings, since it shows embedded tabs etc; The patch doesn't change that. It just replaces \n by real newlines. The reason why I wrote this patch is that the Docutils unit tests often contain very many lines of text, and if something has changed, it is very handy to be able to copy some lines of test output into the test files. But this only works if the lines contain real newlines -- the long character sequences with some intermittent '\n's unittest.py currently produces are almost unusable. If I've been able convince you, feel free to re-open the bug. :-) ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2004-09-07 17:54 Message: Logged In: YES user_id=21477 Hi Raymond and Felix, I also don't find this an improvement. I personally like to see the repr() version of the strings, since it shows embedded tabs etc; the output proposed here makes such differences much less obvious. More interesting was a patch submitted some time ago that used difflib to show the exact differing areas between the unequal strings. I was wary of that patch due to the amount of extra code it introduced, and an incompatibility with Jython at the time, IIRC. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 07:08 Message: Logged In: YES user_id=80475 Steve, would you rule on this one? I personally do not find it to be an improvement. Walter D?rwald is also a heavy unittester and may have a helpful viewpoint. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1019220&group_id=5470 From noreply at sourceforge.net Mon Sep 13 21:29:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 21:29:47 2004 Subject: [Patches] [ python-Patches-1020042 ] Bad test for HAVE_UINTPTR_T in PC/pyconfig.h Message-ID: Patches item #1020042, was opened at 2004-08-31 22:08 Message generated for change (Comment added) made by scott_daniels You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020042&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Scott David Daniels (scott_daniels) Assigned to: Nobody/Anonymous (nobody) Summary: Bad test for HAVE_UINTPTR_T in PC/pyconfig.h Initial Comment: In python 2.4.a2 on Win2K, There is a test (encased in an "#if MS_WIN32" block) that goes awry. The original code (around line 270 of PC/pyconfig.h) is: /* VC 7.1 has them and VC 6.0 does not. VC 6.0 has a version number of 1200. If some compiler does not provide them, modify the #if appropriately. */ #if _MSC_VER != 1200 #define HAVE_UINTPTR_T 1 #define HAVE_INTPTR_T 1 #endif MinGW has trouble compiling with this code. Unless you have VC 6.0, this presumes you have uintptr_t and intptr_t available. From what I can find out (including a message from MvL), I believe the code should really be: #if HAVE_STDINT_H #define HAVE_UINTPTR_T 1 #define HAVE_INTPTR_T 1 #endif However, I don't have VC 7.1 to test this theory out. A more conservative change would be to: #if _MSC_VER > 1200 #define HAVE_UINTPTR_T 1 #define HAVE_INTPTR_T 1 #elif HAVE_STDINT_H #define HAVE_UINTPTR_T 1 #define HAVE_INTPTR_T 1 #endif Essentially, the problem is whether a type name has been defined or not. The C99 standard dictates that the types uintptr_t and intptr_t be available through #include . Some systems have stdint.h, others don't. Old MinGW systems do not (e.g. 2.95); new ones do (e.g. 3.2.3). Martin von Loewis tells me the library libc6 is responsible for having this file or not, so it is not really a compiler thing at all. HAVE_STDINT_H should cover all cases. If you can install python 2.4 and compile (with distlib) _any_ C extension, that compiler (the one used by distlib) works correctly. When the problem occurs, the C compiler fails inside declarations included by Python.h. I've tried this with the MinGW 2.95 and 3.2.3. Even changing the #if _MSC_VER != 1200 to #if _MSC_VER > 1200 is good enough (C preprocessing rules make undefined _MSC_VER != 1200 behave unfortunately) to work, but _if_ the STDINT_H version works for VC 6.0 and 7.1, I favor that (it is testing the correct thing). If _any_ C extension can be successfully compiled on a windows box using the distributed pyconfig.h and a particular compiler, the problem has been solved for that compiler. ---------------------------------------------------------------------- >Comment By: Scott David Daniels (scott_daniels) Date: 2004-09-13 19:29 Message: Logged In: YES user_id=493818 To expand a bit on C preprocessing rules make undefined _MSC_VER != 1200 behave unfortunately, if _MSC_VER is undefined: #if _MSC_VER != 1200 becomes: #if 0 != 1200 And so takes the branch for all C compilers except VC 6.0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020042&group_id=5470 From noreply at sourceforge.net Mon Sep 13 23:27:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 23:28:05 2004 Subject: [Patches] [ python-Patches-1025790 ] Add status code constants to httplib Message-ID: Patches item #1025790, was opened at 2004-09-10 13:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1025790&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Eland (andreweland) Assigned to: Nobody/Anonymous (nobody) Summary: Add status code constants to httplib Initial Comment: httplib doesn't define constants for the HTTP integer status codes, so most applications end up defining their own subset. This patch adds status code constants to httplib, using the same names as Twisted, and updates the documentation. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-13 23:27 Message: Logged In: YES user_id=21627 Compatibility with twisted is a non-goal; twisted will adopt soon enough to the precedent that Python sets, especially if there is a clear objective rationale. Completeness is one such objective rationale, and consistency with the RFC is another one. Twisted can then easily achieve Python compatibility by adding the missing constants. ---------------------------------------------------------------------- Comment By: Andrew Eland (andreweland) Date: 2004-09-13 11:03 Message: Logged In: YES user_id=646767 > I think the best standard way of spelling the constants is > to take them directly from the 10.x.x headings of RFC2616 The spellings in the initial patch come from Twisted, I kept the few non-canonical spellings to avoid confusing people who work with both httplib and Twisted. If the consensus is that canonical spellings should be used regardless, I'll update the patch. > It seems WebDAV codes that 102, 422, 423, 424 are missing Again, the subset chosen is from Twisted, I kept the additional codes compatibility. It does makes sense to include the others though, I'll add them. > OTOH, putting this all in a four-column table (constant name, value, > RFC number, section) would make a very systematic presentation. I avoided adding a comment for each code as the extra information provided by the comments was outweighed by the description of status codes swamping the httplib documentation. Using a table should keep the documentation compact, I'll try it out. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-13 07:54 Message: Logged In: YES user_id=21627 207 comes from RFC 2518 (WebDAV), section 8.2.1 and 10.2. 507 likewise, section 10.6. It seems WebDAV codes that 102, 422, 423, 424 are missing. Likewise, 426 from RFC 2817 is missing, and 226 from RFC 3229. 510 comes from RFC 2774 (HTTP Extensions), section 7. Even though I agree with your procedure for creating "canonical" spellings, I think more documentation is needed. Following this procedure, it would be best to list RFC and section as the documentation; this might allow to leave out the numerical value IMO. OTOH, putting this all in a four-column table (constant name, value, RFC number, section) would make a very systematic presentation. ---------------------------------------------------------------------- Comment By: Andrew Durdin (adurdin) Date: 2004-09-13 03:51 Message: Logged In: YES user_id=625864 I think the best standard way of spelling the constants is to take them directly from the 10.x.x headings of RFC2616. This would require changing four of the names of the constants in the patch from: SWITCHING = 101 MULTIPLE_CHOICE = 300 NOT_ALLOWED = 405 PROXY_AUTH_REQUIRED = 407 to: SWITCHING_PROTOCOLS = 101 MULTIPLE_CHOICES = 300 METHOD_NOT_ALLOWED = 405 PROXY_AUTHENTICATION_REQUIRED = 407 Also, the following status codes are not part of the HTTP/1.1 standard as given in RFC2616: MULTI_STATUS = 207 INSUFFICIENT_STORAGE_SPACE = 507 NOT_EXTENDED = 510 Where do these come from? Being nonstandard, is it inappropriate to include them in httplib? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 22:54 Message: Logged In: YES user_id=21627 Unless the precise spelling of the constants is taken from some existing specification, I think the documentation needs to spell out the values, so that readers can easily confirm that a certain symbolic value has the meaning they expect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1025790&group_id=5470 From noreply at sourceforge.net Tue Sep 14 09:22:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 14 09:22:52 2004 Subject: [Patches] [ python-Patches-1026986 ] building on OpenBSD 3.5 Message-ID: Patches item #1026986, was opened at 2004-09-13 04:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1026986&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: building on OpenBSD 3.5 Initial Comment: Doing ./configure, make on OpenBSD 3.5 with Python 2.4a3 doesn't work. I looked in the OpenBSD 3.5 ports tree for Python 2.3, and saw a patch with a couple changes to Python's configure file. (plus a patch with a tiny tweak to one of the tests). With these changes, compile / make / regrtest.py seems to work: -bash-2.05b$ ../../python regrtest.py -q -unetwork No handlers could be found for logger "cookielib" -bash-2.05b$ ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-14 09:22 Message: Logged In: YES user_id=21627 Why the change to LDSHARED? Didn't OpenBSD use a.out at some point in time? Does the C preprocessor not define __ELF__ anymore? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1026986&group_id=5470 From noreply at sourceforge.net Tue Sep 14 19:25:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 14 19:26:02 2004 Subject: [Patches] [ python-Patches-975056 ] Signal fixes for BSD systems Message-ID: Patches item #975056, was opened at 2004-06-18 01:05 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=975056&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Luke Mewburn (lukem) Assigned to: Nobody/Anonymous (nobody) Summary: Signal fixes for BSD systems Initial Comment: As documented in bug 969574, restartable signals are not correctly disabled on BSD systems (e.g, NetBSD 2.0, FreeBSD 4.8). The attached patch is a more complete version of the one I provided in that bug report, and it more closely follows the patch submission guidelines (context instead of unified diff, against python CVS instead of python 2.3.4, ...). It also fixes: * A few sections of the tree that weren't converted from signal() to PyOS_setsig(). * There's no need to call siginterrupt() before PyOS_setsig() in Module/signalmodule.c because PyOS_setsig() handles that, and calling siginterrupt() before changing a signal's handler (via signal/sigaction) doesn't work correctly anyway; it should have been called after. I have compiled the source with and without "--without-signal-module" and successfully run "make test" on both cases. Suggested NEWS entry: === Bug #969574: Restartable signals were not correctly disabled on BSD systems. Consistently use PyOS_setsig() instead of signal(). === Cheers, Luke. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-09-14 18:25 Message: Logged In: YES user_id=6656 The patch has bitrotted slightly. I'm attaching an updated version. It looks reasonable to me, though I'm officially leery of checking in patches that affect platforms I can't test... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=975056&group_id=5470 From noreply at sourceforge.net Wed Sep 15 07:20:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 15 07:20:37 2004 Subject: [Patches] [ python-Patches-1026986 ] building on OpenBSD 3.5 Message-ID: Patches item #1026986, was opened at 2004-09-12 19:46 Message generated for change (Comment added) made by trevp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1026986&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: building on OpenBSD 3.5 Initial Comment: Doing ./configure, make on OpenBSD 3.5 with Python 2.4a3 doesn't work. I looked in the OpenBSD 3.5 ports tree for Python 2.3, and saw a patch with a couple changes to Python's configure file. (plus a patch with a tiny tweak to one of the tests). With these changes, compile / make / regrtest.py seems to work: -bash-2.05b$ ../../python regrtest.py -q -unetwork No handlers could be found for logger "cookielib" -bash-2.05b$ ---------------------------------------------------------------------- >Comment By: Trevor Perrin (trevp) Date: 2004-09-14 22:20 Message: Logged In: YES user_id=973611 I don't know. I copied that blindly from a patch in OpenBSD's python port. It doesn't appear to be necessary (I can configure & make without it), so I'm resubmitting the patch without it. Also, OpenBSD 3.6 is in beta, and will be released November 1. Looking at the source, it will require this change as well. From the below thread, the OpenBSD people don't seem to be on the verge of fixing this. So I made the patch apply to 3.6. http://www.netsys.com/openbsd-tech/2003/05/msg00172.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-14 00:22 Message: Logged In: YES user_id=21627 Why the change to LDSHARED? Didn't OpenBSD use a.out at some point in time? Does the C preprocessor not define __ELF__ anymore? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1026986&group_id=5470 From noreply at sourceforge.net Wed Sep 15 08:03:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 15 08:03:53 2004 Subject: [Patches] [ python-Patches-1026986 ] building on OpenBSD 3.5 Message-ID: Patches item #1026986, was opened at 2004-09-13 04:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1026986&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: building on OpenBSD 3.5 Initial Comment: Doing ./configure, make on OpenBSD 3.5 with Python 2.4a3 doesn't work. I looked in the OpenBSD 3.5 ports tree for Python 2.3, and saw a patch with a couple changes to Python's configure file. (plus a patch with a tiny tweak to one of the tests). With these changes, compile / make / regrtest.py seems to work: -bash-2.05b$ ../../python regrtest.py -q -unetwork No handlers could be found for logger "cookielib" -bash-2.05b$ ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-15 08:03 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as configure 1.456 configure.in 1.469 test_tempfile.py 1.18 ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-09-15 07:20 Message: Logged In: YES user_id=973611 I don't know. I copied that blindly from a patch in OpenBSD's python port. It doesn't appear to be necessary (I can configure & make without it), so I'm resubmitting the patch without it. Also, OpenBSD 3.6 is in beta, and will be released November 1. Looking at the source, it will require this change as well. From the below thread, the OpenBSD people don't seem to be on the verge of fixing this. So I made the patch apply to 3.6. http://www.netsys.com/openbsd-tech/2003/05/msg00172.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-14 09:22 Message: Logged In: YES user_id=21627 Why the change to LDSHARED? Didn't OpenBSD use a.out at some point in time? Does the C preprocessor not define __ELF__ anymore? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1026986&group_id=5470 From noreply at sourceforge.net Wed Sep 15 09:59:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 15 09:59:52 2004 Subject: [Patches] [ python-Patches-1028432 ] Specify a source baseurl for bdist_rpm. Message-ID: Patches item #1028432, was opened at 2004-09-15 07:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028432&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Chris Ottrey (ottrey) Assigned to: Nobody/Anonymous (nobody) Summary: Specify a source baseurl for bdist_rpm. Initial Comment: I've written some python code and now wish to make an RPM for it. This is the first time I've actually looked at making RPMs, so please excuse any dumb questions. So now for a dumb question.... Is it preferable to specify a URL for the "Source" field in a .spec file (rather than just a filename)? eg. from distutils/command/bdist_rpm.py code. --- snip --- spec_file.append('Source0: %{name}-%{version}.tar.gz') --- snip --- If so, might I suggest you add something like a "--source-baseurl=BASE_URL" option. That is set to '' by default. (see my attached patch against revision 1.43 of bdist_rpm.py) Which is then used something like: python setup.py bdist_rpm --source-urlbase="http://download.here.com/from/this/path" Which will create a line in the .spec file something like: Source0: http://download.here.com/from/this/path/%{name}-%{version}.tar.gz Cheers. Chris. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028432&group_id=5470 From noreply at sourceforge.net Wed Sep 15 11:27:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 15 11:28:05 2004 Subject: [Patches] [ python-Patches-923643 ] long < -> byte-string conversion Message-ID: Patches item #923643, was opened at 2004-03-25 19:17 Message generated for change (Comment added) made by trevp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=923643&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: long <-> byte-string conversion Initial Comment: Sometimes you want to turn a long into a byte-string, or vice-versa. This is useful in cryptographic protocols, and probably other network protocols where you need to exchange large integers. In 2.4, you can handle unsigned longs with this: def stringToLong(s): return long(binascii.hexlify(s), 16) def longToString(n): return binascii.unhexlify("%x" % n) However, these functions are slower than they need to be, they're kinda kludgey, and they don't handle negative values. So here's a proposal: def stringToLong(s): return long(s, 256) def longToString(n): return n.tostring() These functions operate on big-endian, 2's-complement byte-strings. If the value is positive but has its most- significant-bit set, an extra zero-byte will be prepended. This is the same way OpenSSL and (I think) GMP handle signed numbers. These functions are ~5x faster than the earlier ones, they're cleaner, and they work with negative numbers. If you only want to deal with unsigned positive numbers, you'll have to do some adjustments: def stringToLong(s): return long('\0'+s, 256) def longToString(n): s = n.tostring() if s[0] == '\0' and s != '\0': s = s[1:] return s That's not ideal, but it seems better than any interface change I could think of. Anyways, the patch adds this to longs. It should be added to ints too, and I guess it needs tests etc.. I can help with that, if the basic idea is acceptable. Trevor ---------------------------------------------------------------------- >Comment By: Trevor Perrin (trevp) Date: 2004-09-15 02:27 Message: Logged In: YES user_id=973611 Uploading a new patch (base256.diff). This implements only the string-> long (or int) conversion. It adds support for radix 256 (unsigned) or -256 (2's-complement signed) to the int() and long() built-ins: int("\xFF\xFF\xFF", 256) -> 0xFFFFFF int("\xFF\xFF\xFF", -256) -> -1 long(os.urandom(128), 256) -> 1024-bit integer I left out the long -> string conversion. If python adds a bytes() type, then that conversion could be done as bytes(long). This patch has docs and tests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-03-29 23:10 Message: Logged In: YES user_id=341410 I'm curious to know if anyone would object to optional minimum or maximum or both arguments, or even some additional methods that would result in a potentially constrained string output from long.tostring()? If I were to split the functionality into three methods, they would be as follows... def atleast(long, atl): if atl < 0: raise TypeError("atleast requires a positive integer for a minimum length") a = long.tostring() la = len(a) return (atl-la)*'\o' + a def atmost(long, atm): if atm < 0: raise TypeError("atleast requires a positive integer for a minimum length") a = long.tostring() la = len(a) return a[:atm] def constrained(long, atl, atm): if atm < atl: raise TypeError("constrained requires that the maximum length be larger than the minimum length") if atl < 0 or atm < 0: raise TypeError("constrained requires that both arguments are positive") a = long.tostring() la = len(a) return ((atl-la)*'\o' + a)[:atm] I personally would find use for the above, would anyone else have use for it? ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-28 16:55 Message: Logged In: YES user_id=973611 My last comment was wrong: GMP's raw input/output format uses big-endian positive values, with the sign bit stored separately. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-28 16:54 Message: Logged In: YES user_id=973611 My last comment was wrong: GMP's raw input/output format uses big-endian positive values, with the sign bit stored separately. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-26 23:51 Message: Logged In: YES user_id=973611 I think 2's complement makes good sense for arbitrary precision longs. This is how OpenSSL and GMP handle them. It's also how the ASN.1 BER/DER encodings handle integers: these encodings just prepend tag and length fields to the big- endian 2's complement value. I.e.: If you want to extract RSA public values from an X.509 certificate, they'll be in 2's complement (well, they'll always be positive... but they'll have an extra zero byte if necessary). Since the functionality for 2's complement is already in the C code it's easy to expose through a patch. So I'm still in favor of presenting it. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2004-03-26 22:57 Message: Logged In: YES user_id=72053 How about just punting signed conversion. I don't think two's complement makes much sense for arbitrary precision longs. Have some separate representation for negative longs if needed. If you call hex() on a large negative number, you get a hex string with a leading minus sign. For base 256, you can't reserve a char like that, so I guess you have to just throw an error if someone tries to convert a negative long to a string. If you want a representation for signed longs, ASN1 DER is probably an ok choice. I agree with Guido that the binascii module is a good place to put such a function. Twos complement can work if you specify a fixed precision, but that sure complicates what this started out as. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-26 22:45 Message: Logged In: YES user_id=973611 You're right, we should support unsigned strings somehow. Adding another argument to the int() and long() constructors would be messy, though. How about: n = long(s, 256) #unsigned n = long(s, -256) #signed n.tounsignedstring() n.tosignedstring() The "-256" thing is a hack, I admit.. but it kinda grows on you, if you stare it at awhile :-)... ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-26 22:45 Message: Logged In: YES user_id=973611 You're right, we should support unsigned strings somehow. Adding another argument to the int() and long() constructors would be messy, though. How about: n = long(s, 256) #unsigned n = long(s, -256) #signed n.tounsignedstring() n.tosignedstring() The "-256" thing is a hack, I admit.. but it kinda grows on you, if you stare it at awhile :-)... ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2004-03-25 19:53 Message: Logged In: YES user_id=72053 I think those funcs should take an optional extra arg to say you want unsigned. That's cleaner than prepending '0'. In cryptography you usually do want unsigned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=923643&group_id=5470 From noreply at sourceforge.net Wed Sep 15 13:14:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 15 13:14:23 2004 Subject: [Patches] [ python-Patches-1028502 ] Adding IPv6 host handling to httplib Message-ID: Patches item #1028502, was opened at 2004-09-15 11:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028502&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Mills (dgm6net) Assigned to: Nobody/Anonymous (nobody) Summary: Adding IPv6 host handling to httplib Initial Comment: getaddrinfo() doesn't like the square brackets round an IPv6 hostname, so they are now stripped off. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028502&group_id=5470 From noreply at sourceforge.net Wed Sep 15 18:49:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 15 18:49:57 2004 Subject: [Patches] [ python-Patches-923643 ] long < -> byte-string conversion Message-ID: Patches item #923643, was opened at 2004-03-25 19:17 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=923643&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: long <-> byte-string conversion Initial Comment: Sometimes you want to turn a long into a byte-string, or vice-versa. This is useful in cryptographic protocols, and probably other network protocols where you need to exchange large integers. In 2.4, you can handle unsigned longs with this: def stringToLong(s): return long(binascii.hexlify(s), 16) def longToString(n): return binascii.unhexlify("%x" % n) However, these functions are slower than they need to be, they're kinda kludgey, and they don't handle negative values. So here's a proposal: def stringToLong(s): return long(s, 256) def longToString(n): return n.tostring() These functions operate on big-endian, 2's-complement byte-strings. If the value is positive but has its most- significant-bit set, an extra zero-byte will be prepended. This is the same way OpenSSL and (I think) GMP handle signed numbers. These functions are ~5x faster than the earlier ones, they're cleaner, and they work with negative numbers. If you only want to deal with unsigned positive numbers, you'll have to do some adjustments: def stringToLong(s): return long('\0'+s, 256) def longToString(n): s = n.tostring() if s[0] == '\0' and s != '\0': s = s[1:] return s That's not ideal, but it seems better than any interface change I could think of. Anyways, the patch adds this to longs. It should be added to ints too, and I guess it needs tests etc.. I can help with that, if the basic idea is acceptable. Trevor ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-15 09:49 Message: Logged In: YES user_id=341410 As an aside, I've requested similar functionality be added to the struct module, which handles signed, unsigned, big-endian, little-endian, and integers of arbitrary length. The request is available here: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Would you prefer two functions that live as methods of ints and longs, or would you prefer the functionality be placed inside of the struct module (which already does numeric packing and upacking), and had its own type code? ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-09-15 02:27 Message: Logged In: YES user_id=973611 Uploading a new patch (base256.diff). This implements only the string-> long (or int) conversion. It adds support for radix 256 (unsigned) or -256 (2's-complement signed) to the int() and long() built-ins: int("\xFF\xFF\xFF", 256) -> 0xFFFFFF int("\xFF\xFF\xFF", -256) -> -1 long(os.urandom(128), 256) -> 1024-bit integer I left out the long -> string conversion. If python adds a bytes() type, then that conversion could be done as bytes(long). This patch has docs and tests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-03-29 23:10 Message: Logged In: YES user_id=341410 I'm curious to know if anyone would object to optional minimum or maximum or both arguments, or even some additional methods that would result in a potentially constrained string output from long.tostring()? If I were to split the functionality into three methods, they would be as follows... def atleast(long, atl): if atl < 0: raise TypeError("atleast requires a positive integer for a minimum length") a = long.tostring() la = len(a) return (atl-la)*'\o' + a def atmost(long, atm): if atm < 0: raise TypeError("atleast requires a positive integer for a minimum length") a = long.tostring() la = len(a) return a[:atm] def constrained(long, atl, atm): if atm < atl: raise TypeError("constrained requires that the maximum length be larger than the minimum length") if atl < 0 or atm < 0: raise TypeError("constrained requires that both arguments are positive") a = long.tostring() la = len(a) return ((atl-la)*'\o' + a)[:atm] I personally would find use for the above, would anyone else have use for it? ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-28 16:55 Message: Logged In: YES user_id=973611 My last comment was wrong: GMP's raw input/output format uses big-endian positive values, with the sign bit stored separately. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-28 16:54 Message: Logged In: YES user_id=973611 My last comment was wrong: GMP's raw input/output format uses big-endian positive values, with the sign bit stored separately. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-26 23:51 Message: Logged In: YES user_id=973611 I think 2's complement makes good sense for arbitrary precision longs. This is how OpenSSL and GMP handle them. It's also how the ASN.1 BER/DER encodings handle integers: these encodings just prepend tag and length fields to the big- endian 2's complement value. I.e.: If you want to extract RSA public values from an X.509 certificate, they'll be in 2's complement (well, they'll always be positive... but they'll have an extra zero byte if necessary). Since the functionality for 2's complement is already in the C code it's easy to expose through a patch. So I'm still in favor of presenting it. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2004-03-26 22:57 Message: Logged In: YES user_id=72053 How about just punting signed conversion. I don't think two's complement makes much sense for arbitrary precision longs. Have some separate representation for negative longs if needed. If you call hex() on a large negative number, you get a hex string with a leading minus sign. For base 256, you can't reserve a char like that, so I guess you have to just throw an error if someone tries to convert a negative long to a string. If you want a representation for signed longs, ASN1 DER is probably an ok choice. I agree with Guido that the binascii module is a good place to put such a function. Twos complement can work if you specify a fixed precision, but that sure complicates what this started out as. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-26 22:45 Message: Logged In: YES user_id=973611 You're right, we should support unsigned strings somehow. Adding another argument to the int() and long() constructors would be messy, though. How about: n = long(s, 256) #unsigned n = long(s, -256) #signed n.tounsignedstring() n.tosignedstring() The "-256" thing is a hack, I admit.. but it kinda grows on you, if you stare it at awhile :-)... ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-26 22:45 Message: Logged In: YES user_id=973611 You're right, we should support unsigned strings somehow. Adding another argument to the int() and long() constructors would be messy, though. How about: n = long(s, 256) #unsigned n = long(s, -256) #signed n.tounsignedstring() n.tosignedstring() The "-256" thing is a hack, I admit.. but it kinda grows on you, if you stare it at awhile :-)... ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2004-03-25 19:53 Message: Logged In: YES user_id=72053 I think those funcs should take an optional extra arg to say you want unsigned. That's cleaner than prepending '0'. In cryptography you usually do want unsigned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=923643&group_id=5470 From noreply at sourceforge.net Thu Sep 16 02:19:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 02:19:08 2004 Subject: [Patches] [ python-Patches-1028908 ] Changes to cookielib.py & friends for 2.4b1 Message-ID: Patches item #1028908, was opened at 2004-09-16 01:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028908&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Changes to cookielib.py & friends for 2.4b1 Initial Comment: The patch contains uncontroversial changes to cookielib and associated modules, documentation and tests. Would be unfortunate not to have these in 2.4.0. 1. Changes to keep cookielib in sync with ClientCookie 1.0 release. This will make life simpler for people migrating from ClientCookie (the package from whence cookielib, and some recent urllib2 changes, came). a. Moved country-code pseudo-top-level domain (eg. .co.uk) code into a separate method of DefaultCookiePolicy to make life easier for subclassers (.set_ok_countrycode_domain()). b. Added Cookie.nonstandard_attr_keys() method. 2. Added a new test. 3. Documentation corrections and clarifications (including adding a prominent warning about current lack of thread-safety, and a new example). 4. Small-scale refactoring in cookielib.py (including moving magic_re to its rightful place in _LWPCookieJar.py). 5. Tiny code clarification in urllib2.py. 6. Removed coding declaration from test_cookielib.py, in favour of escape sequences, since I discovered that I don't understand coding declarations :-/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028908&group_id=5470 From noreply at sourceforge.net Thu Sep 16 08:56:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 08:56:17 2004 Subject: [Patches] [ python-Patches-923643 ] long < -> byte-string conversion Message-ID: Patches item #923643, was opened at 2004-03-25 19:17 Message generated for change (Comment added) made by trevp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=923643&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: long <-> byte-string conversion Initial Comment: Sometimes you want to turn a long into a byte-string, or vice-versa. This is useful in cryptographic protocols, and probably other network protocols where you need to exchange large integers. In 2.4, you can handle unsigned longs with this: def stringToLong(s): return long(binascii.hexlify(s), 16) def longToString(n): return binascii.unhexlify("%x" % n) However, these functions are slower than they need to be, they're kinda kludgey, and they don't handle negative values. So here's a proposal: def stringToLong(s): return long(s, 256) def longToString(n): return n.tostring() These functions operate on big-endian, 2's-complement byte-strings. If the value is positive but has its most- significant-bit set, an extra zero-byte will be prepended. This is the same way OpenSSL and (I think) GMP handle signed numbers. These functions are ~5x faster than the earlier ones, they're cleaner, and they work with negative numbers. If you only want to deal with unsigned positive numbers, you'll have to do some adjustments: def stringToLong(s): return long('\0'+s, 256) def longToString(n): s = n.tostring() if s[0] == '\0' and s != '\0': s = s[1:] return s That's not ideal, but it seems better than any interface change I could think of. Anyways, the patch adds this to longs. It should be added to ints too, and I guess it needs tests etc.. I can help with that, if the basic idea is acceptable. Trevor ---------------------------------------------------------------------- >Comment By: Trevor Perrin (trevp) Date: 2004-09-15 23:56 Message: Logged In: YES user_id=973611 Thanks for the pointer. I'm actually not smitten with any of the approaches for long<->byte-string conversion (mine included). Now that I think about it, the best interface might be if Python had a 'bytes' type, then both conversions could be done by constructors: long(bytes) bytes(long) If Python is going to grow such a type in the future, maybe we can defer this question, and live with the hexlifying and whatnot, till then. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-15 09:49 Message: Logged In: YES user_id=341410 As an aside, I've requested similar functionality be added to the struct module, which handles signed, unsigned, big-endian, little-endian, and integers of arbitrary length. The request is available here: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Would you prefer two functions that live as methods of ints and longs, or would you prefer the functionality be placed inside of the struct module (which already does numeric packing and upacking), and had its own type code? ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-09-15 02:27 Message: Logged In: YES user_id=973611 Uploading a new patch (base256.diff). This implements only the string-> long (or int) conversion. It adds support for radix 256 (unsigned) or -256 (2's-complement signed) to the int() and long() built-ins: int("\xFF\xFF\xFF", 256) -> 0xFFFFFF int("\xFF\xFF\xFF", -256) -> -1 long(os.urandom(128), 256) -> 1024-bit integer I left out the long -> string conversion. If python adds a bytes() type, then that conversion could be done as bytes(long). This patch has docs and tests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-03-29 23:10 Message: Logged In: YES user_id=341410 I'm curious to know if anyone would object to optional minimum or maximum or both arguments, or even some additional methods that would result in a potentially constrained string output from long.tostring()? If I were to split the functionality into three methods, they would be as follows... def atleast(long, atl): if atl < 0: raise TypeError("atleast requires a positive integer for a minimum length") a = long.tostring() la = len(a) return (atl-la)*'\o' + a def atmost(long, atm): if atm < 0: raise TypeError("atleast requires a positive integer for a minimum length") a = long.tostring() la = len(a) return a[:atm] def constrained(long, atl, atm): if atm < atl: raise TypeError("constrained requires that the maximum length be larger than the minimum length") if atl < 0 or atm < 0: raise TypeError("constrained requires that both arguments are positive") a = long.tostring() la = len(a) return ((atl-la)*'\o' + a)[:atm] I personally would find use for the above, would anyone else have use for it? ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-28 16:55 Message: Logged In: YES user_id=973611 My last comment was wrong: GMP's raw input/output format uses big-endian positive values, with the sign bit stored separately. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-28 16:54 Message: Logged In: YES user_id=973611 My last comment was wrong: GMP's raw input/output format uses big-endian positive values, with the sign bit stored separately. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-26 23:51 Message: Logged In: YES user_id=973611 I think 2's complement makes good sense for arbitrary precision longs. This is how OpenSSL and GMP handle them. It's also how the ASN.1 BER/DER encodings handle integers: these encodings just prepend tag and length fields to the big- endian 2's complement value. I.e.: If you want to extract RSA public values from an X.509 certificate, they'll be in 2's complement (well, they'll always be positive... but they'll have an extra zero byte if necessary). Since the functionality for 2's complement is already in the C code it's easy to expose through a patch. So I'm still in favor of presenting it. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2004-03-26 22:57 Message: Logged In: YES user_id=72053 How about just punting signed conversion. I don't think two's complement makes much sense for arbitrary precision longs. Have some separate representation for negative longs if needed. If you call hex() on a large negative number, you get a hex string with a leading minus sign. For base 256, you can't reserve a char like that, so I guess you have to just throw an error if someone tries to convert a negative long to a string. If you want a representation for signed longs, ASN1 DER is probably an ok choice. I agree with Guido that the binascii module is a good place to put such a function. Twos complement can work if you specify a fixed precision, but that sure complicates what this started out as. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-26 22:45 Message: Logged In: YES user_id=973611 You're right, we should support unsigned strings somehow. Adding another argument to the int() and long() constructors would be messy, though. How about: n = long(s, 256) #unsigned n = long(s, -256) #signed n.tounsignedstring() n.tosignedstring() The "-256" thing is a hack, I admit.. but it kinda grows on you, if you stare it at awhile :-)... ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-26 22:45 Message: Logged In: YES user_id=973611 You're right, we should support unsigned strings somehow. Adding another argument to the int() and long() constructors would be messy, though. How about: n = long(s, 256) #unsigned n = long(s, -256) #signed n.tounsignedstring() n.tosignedstring() The "-256" thing is a hack, I admit.. but it kinda grows on you, if you stare it at awhile :-)... ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2004-03-25 19:53 Message: Logged In: YES user_id=72053 I think those funcs should take an optional extra arg to say you want unsigned. That's cleaner than prepending '0'. In cryptography you usually do want unsigned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=923643&group_id=5470 From noreply at sourceforge.net Thu Sep 16 09:53:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 09:53:16 2004 Subject: [Patches] [ python-Patches-923643 ] long < -> byte-string conversion Message-ID: Patches item #923643, was opened at 2004-03-26 03:17 Message generated for change (Comment added) made by phr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=923643&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: long <-> byte-string conversion Initial Comment: Sometimes you want to turn a long into a byte-string, or vice-versa. This is useful in cryptographic protocols, and probably other network protocols where you need to exchange large integers. In 2.4, you can handle unsigned longs with this: def stringToLong(s): return long(binascii.hexlify(s), 16) def longToString(n): return binascii.unhexlify("%x" % n) However, these functions are slower than they need to be, they're kinda kludgey, and they don't handle negative values. So here's a proposal: def stringToLong(s): return long(s, 256) def longToString(n): return n.tostring() These functions operate on big-endian, 2's-complement byte-strings. If the value is positive but has its most- significant-bit set, an extra zero-byte will be prepended. This is the same way OpenSSL and (I think) GMP handle signed numbers. These functions are ~5x faster than the earlier ones, they're cleaner, and they work with negative numbers. If you only want to deal with unsigned positive numbers, you'll have to do some adjustments: def stringToLong(s): return long('\0'+s, 256) def longToString(n): s = n.tostring() if s[0] == '\0' and s != '\0': s = s[1:] return s That's not ideal, but it seems better than any interface change I could think of. Anyways, the patch adds this to longs. It should be added to ints too, and I guess it needs tests etc.. I can help with that, if the basic idea is acceptable. Trevor ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2004-09-16 07:53 Message: Logged In: YES user_id=72053 There shouldn't be a bytes type. Those are just strings. Instead I think it's better to add a conversion function to the strings module or the binascii module. The hex thing is a crock and should be exterminated. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-09-16 06:56 Message: Logged In: YES user_id=973611 Thanks for the pointer. I'm actually not smitten with any of the approaches for long<->byte-string conversion (mine included). Now that I think about it, the best interface might be if Python had a 'bytes' type, then both conversions could be done by constructors: long(bytes) bytes(long) If Python is going to grow such a type in the future, maybe we can defer this question, and live with the hexlifying and whatnot, till then. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-15 16:49 Message: Logged In: YES user_id=341410 As an aside, I've requested similar functionality be added to the struct module, which handles signed, unsigned, big-endian, little-endian, and integers of arbitrary length. The request is available here: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Would you prefer two functions that live as methods of ints and longs, or would you prefer the functionality be placed inside of the struct module (which already does numeric packing and upacking), and had its own type code? ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-09-15 09:27 Message: Logged In: YES user_id=973611 Uploading a new patch (base256.diff). This implements only the string-> long (or int) conversion. It adds support for radix 256 (unsigned) or -256 (2's-complement signed) to the int() and long() built-ins: int("\xFF\xFF\xFF", 256) -> 0xFFFFFF int("\xFF\xFF\xFF", -256) -> -1 long(os.urandom(128), 256) -> 1024-bit integer I left out the long -> string conversion. If python adds a bytes() type, then that conversion could be done as bytes(long). This patch has docs and tests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-03-30 07:10 Message: Logged In: YES user_id=341410 I'm curious to know if anyone would object to optional minimum or maximum or both arguments, or even some additional methods that would result in a potentially constrained string output from long.tostring()? If I were to split the functionality into three methods, they would be as follows... def atleast(long, atl): if atl < 0: raise TypeError("atleast requires a positive integer for a minimum length") a = long.tostring() la = len(a) return (atl-la)*'\o' + a def atmost(long, atm): if atm < 0: raise TypeError("atleast requires a positive integer for a minimum length") a = long.tostring() la = len(a) return a[:atm] def constrained(long, atl, atm): if atm < atl: raise TypeError("constrained requires that the maximum length be larger than the minimum length") if atl < 0 or atm < 0: raise TypeError("constrained requires that both arguments are positive") a = long.tostring() la = len(a) return ((atl-la)*'\o' + a)[:atm] I personally would find use for the above, would anyone else have use for it? ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-29 00:55 Message: Logged In: YES user_id=973611 My last comment was wrong: GMP's raw input/output format uses big-endian positive values, with the sign bit stored separately. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-29 00:54 Message: Logged In: YES user_id=973611 My last comment was wrong: GMP's raw input/output format uses big-endian positive values, with the sign bit stored separately. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-27 07:51 Message: Logged In: YES user_id=973611 I think 2's complement makes good sense for arbitrary precision longs. This is how OpenSSL and GMP handle them. It's also how the ASN.1 BER/DER encodings handle integers: these encodings just prepend tag and length fields to the big- endian 2's complement value. I.e.: If you want to extract RSA public values from an X.509 certificate, they'll be in 2's complement (well, they'll always be positive... but they'll have an extra zero byte if necessary). Since the functionality for 2's complement is already in the C code it's easy to expose through a patch. So I'm still in favor of presenting it. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2004-03-27 06:57 Message: Logged In: YES user_id=72053 How about just punting signed conversion. I don't think two's complement makes much sense for arbitrary precision longs. Have some separate representation for negative longs if needed. If you call hex() on a large negative number, you get a hex string with a leading minus sign. For base 256, you can't reserve a char like that, so I guess you have to just throw an error if someone tries to convert a negative long to a string. If you want a representation for signed longs, ASN1 DER is probably an ok choice. I agree with Guido that the binascii module is a good place to put such a function. Twos complement can work if you specify a fixed precision, but that sure complicates what this started out as. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-27 06:45 Message: Logged In: YES user_id=973611 You're right, we should support unsigned strings somehow. Adding another argument to the int() and long() constructors would be messy, though. How about: n = long(s, 256) #unsigned n = long(s, -256) #signed n.tounsignedstring() n.tosignedstring() The "-256" thing is a hack, I admit.. but it kinda grows on you, if you stare it at awhile :-)... ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-27 06:45 Message: Logged In: YES user_id=973611 You're right, we should support unsigned strings somehow. Adding another argument to the int() and long() constructors would be messy, though. How about: n = long(s, 256) #unsigned n = long(s, -256) #signed n.tounsignedstring() n.tosignedstring() The "-256" thing is a hack, I admit.. but it kinda grows on you, if you stare it at awhile :-)... ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2004-03-26 03:53 Message: Logged In: YES user_id=72053 I think those funcs should take an optional extra arg to say you want unsigned. That's cleaner than prepending '0'. In cryptography you usually do want unsigned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=923643&group_id=5470 From noreply at sourceforge.net Thu Sep 16 10:44:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 10:44:21 2004 Subject: [Patches] [ python-Patches-1029061 ] tarfile.py longnames are truncated in getnames() Message-ID: Patches item #1029061, was opened at 2004-09-16 10:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1029061&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py longnames are truncated in getnames() Initial Comment: When a TarFile object reads a tar archive, it scans through the headers, converts them into TarInfo objects and adds them to the internal data structures: self.members.append(tarinfo) self.membernames.append(tarinfo.name) When a GNU longname member is processed, it is added at a point in time when its name attribute has not yet been replaced with the longname, so longnames in self.membernames are truncated and therefore unusable. This problem could have been fixed with a quick/dirty hack. But I decided to remove self.membernames completely because it is redundant. getnames() which was the public interface to it now generates a list on-the-fly from the list of members, so it always reflects the actual state. I encountered another small bug on the way. The docs for TarFile.getmember() state: "If a member occurs more than once in the archive, its last occurence is assumed to be the most up-to-date version." It was never implemented like that, so I fixed it, too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1029061&group_id=5470 From noreply at sourceforge.net Thu Sep 16 14:17:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 14:17:47 2004 Subject: [Patches] [ python-Patches-1020845 ] Decimal performance enhancements Message-ID: Patches item #1020845, was opened at 2004-09-02 10:08 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Facundo Batista (facundobatista) Summary: Decimal performance enhancements Initial Comment: The attached patch implements a collection of performance enhancements for decimal.py. They are currently focused on the performance of the telco benchmark in the sandbox (i.e. they aim to speed up instantiation, addition, multiplication and quantization). The main strategy used (a subclass for NaN and infinite values) can be extended to encompass more methods in order to improve performance in other situations. There is one non-performance related change included - the '_sign' attribute is renamed to '_isneg' to better reflect the boolean nature of the property. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-16 22:17 Message: Logged In: YES user_id=1038590 I've separated the performance enhancements out into four different potential patches now: - "_odds_and_ends" - "_is_special" - "_both" (combination of the above two patches) - "_workint" (also incorporates "_both") A single tar.gz file is attached which contains all those in .diff and .py format, as well as a text file detailing the changes made in each patch. All diff's are directly against CVS. test_decimal.py passes cleanly with all four patches. They're listed above in order of increasing degree of change from current CVS. Hopefully I've gotten rid of any doc string changes, and non-performance related code changes (some comments have changed, usually because associated code has changed) The _workint version is the only version which regularly achieves < 20 s wall clock time on my machine for the unit tests and < 60 s for "telco_nofiles.py 10000" (that is, one hundred thousand decimal values). The _both version seems to run around 5 seconds slower on both tests (I am assuming this is due to the fact that _workint speeds up division significantly more than it speeds up addition and multiplication, thus having a much more pronounced effect on the unit tests than on the division-free telco benchmark) Here are the details on the different patches: decimal_odds_and_ends: - cache the result of repeated method calls in: __cmp__ _rescale _check_nans _fix_exponents - use sum() in __nonzero__ - call list.reverse() on preliminary result, not operands in __add__ - avoid redundant _fix_exponents call in _fix - rearrange _fix_exponents to minimise method calls on any given path - remove dead code from end of __int__ decimal_is_special: - convert to use __new__ instead of __init__ - new attribute _is_special is True if value is infinite or NaN - defer invocation of getcontext() as late as possible - make _convert_other a function instead of a method - modify all methods to take advantage of _is_special decimal_both: - combines decimal_is_special & decimal_odds_and_ends decimal_workint: - based on decimal_both - uses a numeric value for _WorkRep.int instead of a list - modifies __new__, __add__ and _divide accordingly - modifies __mul__ to use a _WorkRep (Sorry Raymond, I couldn't quite resist experimenting with borrowing int/long's C level arithmetic implementation!) I'll see about getting some wall-clock numbers for the *actual* million-value telco benchmark with all 5 versions (CVS + the four patches). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-09 09:45 Message: Logged In: YES user_id=1038590 2nd version of patch attached. It does NOT use a subclassing strategy for optimisation due to the following charming little problem I found with that approach: >>> import decimal >>> class foo(decimal.Decimal): pass >>> x = foo("NaN") >>> isinstance(x, foo) False I couldn't find any sane way to get around this, and it seemed to be a showstopper given the amount of work that has gone into making all the builtin types easily subclassable. The new patch instead relies mainly on the following techniques: - defer invocation of getcontext() as late as possible, so that we only call it if the context is going to be referenced - use issubclass(x, basestring) to identify if there are special cases that need handling, then use _is_nan and _is_infinity to determine exactly which special case applies (this slows the special cases down slightly, but speeds up the normal cases a lot) - make _convert_other a helper function instead of a method There are also some other minor changes that were present in the original patch (use sum() in __nonzero__, reduce the number of calls to list.reversed() in __add__, extract digits directly from integer inputs with divmod, rearrange _fixexponents to minimise context method calls, cache results of method calls in various operations) Facundo, two particular changes I'd like you to OK are: - _fix now indents the second call to _fixexponents to be inside the if block (in CVS, _fix_exponents could get called again directly on the result of the previous call to _fix_exponents, which didn't seem to make any sense) - _fixexponents returns immediately for NaN as well as infinite values This version of patch appears to give around a 40% speedup on direct execution of test_decimal.py, and all the tests still pass for me. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-09-08 09:47 Message: Logged In: YES user_id=752496 Nick: Submit the second version of the patch and I'll review it. Also feel free to contact me by mail anytime. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 07:59 Message: Logged In: YES user_id=80475 Glad to hear you've wrapped your head around the sign bit. FWIW, it bugged me too. But it is so closely tied to the spec that it is better to adjust our mental model than change the code. Do extend your optimizations to the other functions. Don't just optimize the benchmark -- that defeats the purpose. Can you work together with Facundo on this one? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-08 07:06 Message: Logged In: YES user_id=1038590 With the _sign/_isneg thing, I figured out the reason it was hurting my brain - I was failing to think of the value as representing a two's complement sign bit. Once I thought of it that way, it made sense with the original terminology. I suspect the lesser speedup on test_decimal.py may be due to the fact that the current version of the patch only optimises the operations used by the telco benchmark (instantiation, addition, multiplication, quantisation). As we speed up other operations, the performance on the unit tests should improve. As far as the API itself goes, the major differences I am aware of are the existence of the new subclass, and the use of __new__ instead of __init__. That will presumably be a bit more work to implement in C since another class is needed. Do we need to document somewhere that Decimal(x) may return an instance of a subclass of Decimal() rather than an instance of Decimal itself? My current plan is to produce a second version of this patch that: 1. Starts again from current CVS 2. Leaves '_sign' alone 3. Leaves existing doc strings alone (I broke a couple of them in this version of patch - I hadn't really thought about how to handle them properly) 4. For overridden methods in the _Special_Value class, duplicate the docstring from the baseclass with "f.__doc__ = Decimal.f.__doc__". This should avoid giving different answers for "help(Decimal(1).__add__)" and "help(Decimal('NaN').__add__)". 5. Optimises all operations, not just the four used by the telco benchmark (with the new strategy in place, this is mostly legwork - cutting and pasting the special-value related stuff to the new subclass, and rearranging appropriately. Unfortunately, it's legwork that I can't see a sensible way to automate, so it's a matter of taking the time to do it, and then checking that the tests all still pass). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 15:05 Message: Logged In: YES user_id=80475 Facundo, do you have time to look at this one? We need to: * revert the _isneg variable name change * find out why it gives a 2:1 gain on telco but only 10% on test_decimal.py * make sure the API has not changed in a way that will make it more difficult someday to convert this into C and make it a built-in. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-02 15:18 Message: Logged In: YES user_id=80475 Nice job. The timings do improve and the approach is reasonable. Please go ahead to the next step and polish it up. Also, please change _isneg back to _sign. That matches the terminology in the spec, the machine centric sign bit viewpoint of 754R, and the components of the user visible as_tuple() method. The goal is to make the patch as minimal as possible, to keep the API unchanged, and improve performance. Using the __new__ method was smart. That more closely corresponds to a potential C implementation of an immutable type. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-02 10:11 Message: Logged In: YES user_id=1038590 I forgot to add that this is NOT yet a production quality patch. The doc strings, in particular, need work. I'm mainly posting it so Raymond can have a look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 From noreply at sourceforge.net Thu Sep 16 15:12:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 15:12:54 2004 Subject: [Patches] [ python-Patches-1025790 ] Add status code constants to httplib Message-ID: Patches item #1025790, was opened at 2004-09-10 11:48 Message generated for change (Comment added) made by andreweland You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1025790&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Eland (andreweland) Assigned to: Nobody/Anonymous (nobody) Summary: Add status code constants to httplib Initial Comment: httplib doesn't define constants for the HTTP integer status codes, so most applications end up defining their own subset. This patch adds status code constants to httplib, using the same names as Twisted, and updates the documentation. ---------------------------------------------------------------------- >Comment By: Andrew Eland (andreweland) Date: 2004-09-16 13:12 Message: Logged In: YES user_id=646767 I've added a new patch that: - Uses the canonical spelling for constants - Adds missing status codes from RFCs 2817 and 3229 - Documents the constants in a table, referencing the section of the relevent RFC ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-13 21:27 Message: Logged In: YES user_id=21627 Compatibility with twisted is a non-goal; twisted will adopt soon enough to the precedent that Python sets, especially if there is a clear objective rationale. Completeness is one such objective rationale, and consistency with the RFC is another one. Twisted can then easily achieve Python compatibility by adding the missing constants. ---------------------------------------------------------------------- Comment By: Andrew Eland (andreweland) Date: 2004-09-13 09:03 Message: Logged In: YES user_id=646767 > I think the best standard way of spelling the constants is > to take them directly from the 10.x.x headings of RFC2616 The spellings in the initial patch come from Twisted, I kept the few non-canonical spellings to avoid confusing people who work with both httplib and Twisted. If the consensus is that canonical spellings should be used regardless, I'll update the patch. > It seems WebDAV codes that 102, 422, 423, 424 are missing Again, the subset chosen is from Twisted, I kept the additional codes compatibility. It does makes sense to include the others though, I'll add them. > OTOH, putting this all in a four-column table (constant name, value, > RFC number, section) would make a very systematic presentation. I avoided adding a comment for each code as the extra information provided by the comments was outweighed by the description of status codes swamping the httplib documentation. Using a table should keep the documentation compact, I'll try it out. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-13 05:54 Message: Logged In: YES user_id=21627 207 comes from RFC 2518 (WebDAV), section 8.2.1 and 10.2. 507 likewise, section 10.6. It seems WebDAV codes that 102, 422, 423, 424 are missing. Likewise, 426 from RFC 2817 is missing, and 226 from RFC 3229. 510 comes from RFC 2774 (HTTP Extensions), section 7. Even though I agree with your procedure for creating "canonical" spellings, I think more documentation is needed. Following this procedure, it would be best to list RFC and section as the documentation; this might allow to leave out the numerical value IMO. OTOH, putting this all in a four-column table (constant name, value, RFC number, section) would make a very systematic presentation. ---------------------------------------------------------------------- Comment By: Andrew Durdin (adurdin) Date: 2004-09-13 01:51 Message: Logged In: YES user_id=625864 I think the best standard way of spelling the constants is to take them directly from the 10.x.x headings of RFC2616. This would require changing four of the names of the constants in the patch from: SWITCHING = 101 MULTIPLE_CHOICE = 300 NOT_ALLOWED = 405 PROXY_AUTH_REQUIRED = 407 to: SWITCHING_PROTOCOLS = 101 MULTIPLE_CHOICES = 300 METHOD_NOT_ALLOWED = 405 PROXY_AUTHENTICATION_REQUIRED = 407 Also, the following status codes are not part of the HTTP/1.1 standard as given in RFC2616: MULTI_STATUS = 207 INSUFFICIENT_STORAGE_SPACE = 507 NOT_EXTENDED = 510 Where do these come from? Being nonstandard, is it inappropriate to include them in httplib? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 20:54 Message: Logged In: YES user_id=21627 Unless the precise spelling of the constants is taken from some existing specification, I think the documentation needs to spell out the values, so that readers can easily confirm that a certain symbolic value has the meaning they expect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1025790&group_id=5470 From noreply at sourceforge.net Thu Sep 16 15:47:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 15:47:17 2004 Subject: [Patches] [ python-Patches-975056 ] Signal fixes for BSD systems Message-ID: Patches item #975056, was opened at 2004-06-18 10:05 Message generated for change (Comment added) made by lukem You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=975056&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Luke Mewburn (lukem) Assigned to: Nobody/Anonymous (nobody) Summary: Signal fixes for BSD systems Initial Comment: As documented in bug 969574, restartable signals are not correctly disabled on BSD systems (e.g, NetBSD 2.0, FreeBSD 4.8). The attached patch is a more complete version of the one I provided in that bug report, and it more closely follows the patch submission guidelines (context instead of unified diff, against python CVS instead of python 2.3.4, ...). It also fixes: * A few sections of the tree that weren't converted from signal() to PyOS_setsig(). * There's no need to call siginterrupt() before PyOS_setsig() in Module/signalmodule.c because PyOS_setsig() handles that, and calling siginterrupt() before changing a signal's handler (via signal/sigaction) doesn't work correctly anyway; it should have been called after. I have compiled the source with and without "--without-signal-module" and successfully run "make test" on both cases. Suggested NEWS entry: === Bug #969574: Restartable signals were not correctly disabled on BSD systems. Consistently use PyOS_setsig() instead of signal(). === Cheers, Luke. ---------------------------------------------------------------------- >Comment By: Luke Mewburn (lukem) Date: 2004-09-16 23:47 Message: Logged In: YES user_id=135998 Whilst NetBSD isn't the world's most common UNIX operating system, FreeBSD 4.x is fairly widespread _and_ is affected by the bug as well... :) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-15 03:25 Message: Logged In: YES user_id=6656 The patch has bitrotted slightly. I'm attaching an updated version. It looks reasonable to me, though I'm officially leery of checking in patches that affect platforms I can't test... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=975056&group_id=5470 From noreply at sourceforge.net Thu Sep 16 21:23:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 21:24:04 2004 Subject: [Patches] [ python-Patches-923643 ] long < -> byte-string conversion Message-ID: Patches item #923643, was opened at 2004-03-25 19:17 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=923643&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: long <-> byte-string conversion Initial Comment: Sometimes you want to turn a long into a byte-string, or vice-versa. This is useful in cryptographic protocols, and probably other network protocols where you need to exchange large integers. In 2.4, you can handle unsigned longs with this: def stringToLong(s): return long(binascii.hexlify(s), 16) def longToString(n): return binascii.unhexlify("%x" % n) However, these functions are slower than they need to be, they're kinda kludgey, and they don't handle negative values. So here's a proposal: def stringToLong(s): return long(s, 256) def longToString(n): return n.tostring() These functions operate on big-endian, 2's-complement byte-strings. If the value is positive but has its most- significant-bit set, an extra zero-byte will be prepended. This is the same way OpenSSL and (I think) GMP handle signed numbers. These functions are ~5x faster than the earlier ones, they're cleaner, and they work with negative numbers. If you only want to deal with unsigned positive numbers, you'll have to do some adjustments: def stringToLong(s): return long('\0'+s, 256) def longToString(n): s = n.tostring() if s[0] == '\0' and s != '\0': s = s[1:] return s That's not ideal, but it seems better than any interface change I could think of. Anyways, the patch adds this to longs. It should be added to ints too, and I guess it needs tests etc.. I can help with that, if the basic idea is acceptable. Trevor ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-16 12:23 Message: Logged In: YES user_id=341410 Paul, it seems as though there exists a Python function in pickle that does conversions: encode_long() and decode_long(), though depending on the size of your longs, a custom version may be faster (I wrote one that doesn't use hex, and manages to be 20% faster on integers less than 32 bits). It also appears that Raymond is going to be placing such a pair of functions in binascii. I'm curious as to whether you prefer a variable-width return as provided by pickle.encode_long, or a fixed-width return as provided by the struct method I propose. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2004-09-16 00:53 Message: Logged In: YES user_id=72053 There shouldn't be a bytes type. Those are just strings. Instead I think it's better to add a conversion function to the strings module or the binascii module. The hex thing is a crock and should be exterminated. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-09-15 23:56 Message: Logged In: YES user_id=973611 Thanks for the pointer. I'm actually not smitten with any of the approaches for long<->byte-string conversion (mine included). Now that I think about it, the best interface might be if Python had a 'bytes' type, then both conversions could be done by constructors: long(bytes) bytes(long) If Python is going to grow such a type in the future, maybe we can defer this question, and live with the hexlifying and whatnot, till then. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-09-15 09:49 Message: Logged In: YES user_id=341410 As an aside, I've requested similar functionality be added to the struct module, which handles signed, unsigned, big-endian, little-endian, and integers of arbitrary length. The request is available here: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470 Would you prefer two functions that live as methods of ints and longs, or would you prefer the functionality be placed inside of the struct module (which already does numeric packing and upacking), and had its own type code? ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-09-15 02:27 Message: Logged In: YES user_id=973611 Uploading a new patch (base256.diff). This implements only the string-> long (or int) conversion. It adds support for radix 256 (unsigned) or -256 (2's-complement signed) to the int() and long() built-ins: int("\xFF\xFF\xFF", 256) -> 0xFFFFFF int("\xFF\xFF\xFF", -256) -> -1 long(os.urandom(128), 256) -> 1024-bit integer I left out the long -> string conversion. If python adds a bytes() type, then that conversion could be done as bytes(long). This patch has docs and tests. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-03-29 23:10 Message: Logged In: YES user_id=341410 I'm curious to know if anyone would object to optional minimum or maximum or both arguments, or even some additional methods that would result in a potentially constrained string output from long.tostring()? If I were to split the functionality into three methods, they would be as follows... def atleast(long, atl): if atl < 0: raise TypeError("atleast requires a positive integer for a minimum length") a = long.tostring() la = len(a) return (atl-la)*'\o' + a def atmost(long, atm): if atm < 0: raise TypeError("atleast requires a positive integer for a minimum length") a = long.tostring() la = len(a) return a[:atm] def constrained(long, atl, atm): if atm < atl: raise TypeError("constrained requires that the maximum length be larger than the minimum length") if atl < 0 or atm < 0: raise TypeError("constrained requires that both arguments are positive") a = long.tostring() la = len(a) return ((atl-la)*'\o' + a)[:atm] I personally would find use for the above, would anyone else have use for it? ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-28 16:55 Message: Logged In: YES user_id=973611 My last comment was wrong: GMP's raw input/output format uses big-endian positive values, with the sign bit stored separately. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-28 16:54 Message: Logged In: YES user_id=973611 My last comment was wrong: GMP's raw input/output format uses big-endian positive values, with the sign bit stored separately. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-26 23:51 Message: Logged In: YES user_id=973611 I think 2's complement makes good sense for arbitrary precision longs. This is how OpenSSL and GMP handle them. It's also how the ASN.1 BER/DER encodings handle integers: these encodings just prepend tag and length fields to the big- endian 2's complement value. I.e.: If you want to extract RSA public values from an X.509 certificate, they'll be in 2's complement (well, they'll always be positive... but they'll have an extra zero byte if necessary). Since the functionality for 2's complement is already in the C code it's easy to expose through a patch. So I'm still in favor of presenting it. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2004-03-26 22:57 Message: Logged In: YES user_id=72053 How about just punting signed conversion. I don't think two's complement makes much sense for arbitrary precision longs. Have some separate representation for negative longs if needed. If you call hex() on a large negative number, you get a hex string with a leading minus sign. For base 256, you can't reserve a char like that, so I guess you have to just throw an error if someone tries to convert a negative long to a string. If you want a representation for signed longs, ASN1 DER is probably an ok choice. I agree with Guido that the binascii module is a good place to put such a function. Twos complement can work if you specify a fixed precision, but that sure complicates what this started out as. ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-26 22:45 Message: Logged In: YES user_id=973611 You're right, we should support unsigned strings somehow. Adding another argument to the int() and long() constructors would be messy, though. How about: n = long(s, 256) #unsigned n = long(s, -256) #signed n.tounsignedstring() n.tosignedstring() The "-256" thing is a hack, I admit.. but it kinda grows on you, if you stare it at awhile :-)... ---------------------------------------------------------------------- Comment By: Trevor Perrin (trevp) Date: 2004-03-26 22:45 Message: Logged In: YES user_id=973611 You're right, we should support unsigned strings somehow. Adding another argument to the int() and long() constructors would be messy, though. How about: n = long(s, 256) #unsigned n = long(s, -256) #signed n.tounsignedstring() n.tosignedstring() The "-256" thing is a hack, I admit.. but it kinda grows on you, if you stare it at awhile :-)... ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2004-03-25 19:53 Message: Logged In: YES user_id=72053 I think those funcs should take an optional extra arg to say you want unsigned. That's cleaner than prepending '0'. In cryptography you usually do want unsigned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=923643&group_id=5470 From noreply at sourceforge.net Fri Sep 17 03:50:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 17 03:50:24 2004 Subject: [Patches] [ python-Patches-1020845 ] Decimal performance enhancements Message-ID: Patches item #1020845, was opened at 2004-09-01 21:08 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Facundo Batista (facundobatista) Summary: Decimal performance enhancements Initial Comment: The attached patch implements a collection of performance enhancements for decimal.py. They are currently focused on the performance of the telco benchmark in the sandbox (i.e. they aim to speed up instantiation, addition, multiplication and quantization). The main strategy used (a subclass for NaN and infinite values) can be extended to encompass more methods in order to improve performance in other situations. There is one non-performance related change included - the '_sign' attribute is renamed to '_isneg' to better reflect the boolean nature of the property. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2004-09-16 22:50 Message: Logged In: YES user_id=752496 Raymond, Nick: I only reviewed the "both" version. From the patch text, the changes were pretty logical, but they were a *lot*, so I didn't want to extend the change to "_workint" version. It'll always be time. The majority of changes are because of the added attribute "_is_special", which shortcuts in an obvious manner a lot of code, and also makes possibly some interesting conceptual changes (and some other changes were not simple and implied good knowledge of the code and decimal internals). There're also a lot of changes such as executing once a function, binding its result in a name and using that name several times later (which effectively reduced the quantity of function calls). And trimmed several "getcontext()" when the only thing that was done was passing context to other function (not used there). The changed decimal was OK in the tests, showing a 14% speed up. I'm +1 to commit the "both" version. Checking the code, I saw some other optimizations, but I don't want to introduce new changes without commiting these first. Nick, congratulations, you certainly made a good work! (btw, don't upload files with spaces in the name) Raymond, do you want to commit the code or should I do it? . Facundo ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-16 09:17 Message: Logged In: YES user_id=1038590 I've separated the performance enhancements out into four different potential patches now: - "_odds_and_ends" - "_is_special" - "_both" (combination of the above two patches) - "_workint" (also incorporates "_both") A single tar.gz file is attached which contains all those in .diff and .py format, as well as a text file detailing the changes made in each patch. All diff's are directly against CVS. test_decimal.py passes cleanly with all four patches. They're listed above in order of increasing degree of change from current CVS. Hopefully I've gotten rid of any doc string changes, and non-performance related code changes (some comments have changed, usually because associated code has changed) The _workint version is the only version which regularly achieves < 20 s wall clock time on my machine for the unit tests and < 60 s for "telco_nofiles.py 10000" (that is, one hundred thousand decimal values). The _both version seems to run around 5 seconds slower on both tests (I am assuming this is due to the fact that _workint speeds up division significantly more than it speeds up addition and multiplication, thus having a much more pronounced effect on the unit tests than on the division-free telco benchmark) Here are the details on the different patches: decimal_odds_and_ends: - cache the result of repeated method calls in: __cmp__ _rescale _check_nans _fix_exponents - use sum() in __nonzero__ - call list.reverse() on preliminary result, not operands in __add__ - avoid redundant _fix_exponents call in _fix - rearrange _fix_exponents to minimise method calls on any given path - remove dead code from end of __int__ decimal_is_special: - convert to use __new__ instead of __init__ - new attribute _is_special is True if value is infinite or NaN - defer invocation of getcontext() as late as possible - make _convert_other a function instead of a method - modify all methods to take advantage of _is_special decimal_both: - combines decimal_is_special & decimal_odds_and_ends decimal_workint: - based on decimal_both - uses a numeric value for _WorkRep.int instead of a list - modifies __new__, __add__ and _divide accordingly - modifies __mul__ to use a _WorkRep (Sorry Raymond, I couldn't quite resist experimenting with borrowing int/long's C level arithmetic implementation!) I'll see about getting some wall-clock numbers for the *actual* million-value telco benchmark with all 5 versions (CVS + the four patches). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-08 20:45 Message: Logged In: YES user_id=1038590 2nd version of patch attached. It does NOT use a subclassing strategy for optimisation due to the following charming little problem I found with that approach: >>> import decimal >>> class foo(decimal.Decimal): pass >>> x = foo("NaN") >>> isinstance(x, foo) False I couldn't find any sane way to get around this, and it seemed to be a showstopper given the amount of work that has gone into making all the builtin types easily subclassable. The new patch instead relies mainly on the following techniques: - defer invocation of getcontext() as late as possible, so that we only call it if the context is going to be referenced - use issubclass(x, basestring) to identify if there are special cases that need handling, then use _is_nan and _is_infinity to determine exactly which special case applies (this slows the special cases down slightly, but speeds up the normal cases a lot) - make _convert_other a helper function instead of a method There are also some other minor changes that were present in the original patch (use sum() in __nonzero__, reduce the number of calls to list.reversed() in __add__, extract digits directly from integer inputs with divmod, rearrange _fixexponents to minimise context method calls, cache results of method calls in various operations) Facundo, two particular changes I'd like you to OK are: - _fix now indents the second call to _fixexponents to be inside the if block (in CVS, _fix_exponents could get called again directly on the result of the previous call to _fix_exponents, which didn't seem to make any sense) - _fixexponents returns immediately for NaN as well as infinite values This version of patch appears to give around a 40% speedup on direct execution of test_decimal.py, and all the tests still pass for me. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-09-07 20:47 Message: Logged In: YES user_id=752496 Nick: Submit the second version of the patch and I'll review it. Also feel free to contact me by mail anytime. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 18:59 Message: Logged In: YES user_id=80475 Glad to hear you've wrapped your head around the sign bit. FWIW, it bugged me too. But it is so closely tied to the spec that it is better to adjust our mental model than change the code. Do extend your optimizations to the other functions. Don't just optimize the benchmark -- that defeats the purpose. Can you work together with Facundo on this one? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-07 18:06 Message: Logged In: YES user_id=1038590 With the _sign/_isneg thing, I figured out the reason it was hurting my brain - I was failing to think of the value as representing a two's complement sign bit. Once I thought of it that way, it made sense with the original terminology. I suspect the lesser speedup on test_decimal.py may be due to the fact that the current version of the patch only optimises the operations used by the telco benchmark (instantiation, addition, multiplication, quantisation). As we speed up other operations, the performance on the unit tests should improve. As far as the API itself goes, the major differences I am aware of are the existence of the new subclass, and the use of __new__ instead of __init__. That will presumably be a bit more work to implement in C since another class is needed. Do we need to document somewhere that Decimal(x) may return an instance of a subclass of Decimal() rather than an instance of Decimal itself? My current plan is to produce a second version of this patch that: 1. Starts again from current CVS 2. Leaves '_sign' alone 3. Leaves existing doc strings alone (I broke a couple of them in this version of patch - I hadn't really thought about how to handle them properly) 4. For overridden methods in the _Special_Value class, duplicate the docstring from the baseclass with "f.__doc__ = Decimal.f.__doc__". This should avoid giving different answers for "help(Decimal(1).__add__)" and "help(Decimal('NaN').__add__)". 5. Optimises all operations, not just the four used by the telco benchmark (with the new strategy in place, this is mostly legwork - cutting and pasting the special-value related stuff to the new subclass, and rearranging appropriately. Unfortunately, it's legwork that I can't see a sensible way to automate, so it's a matter of taking the time to do it, and then checking that the tests all still pass). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 02:05 Message: Logged In: YES user_id=80475 Facundo, do you have time to look at this one? We need to: * revert the _isneg variable name change * find out why it gives a 2:1 gain on telco but only 10% on test_decimal.py * make sure the API has not changed in a way that will make it more difficult someday to convert this into C and make it a built-in. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-02 02:18 Message: Logged In: YES user_id=80475 Nice job. The timings do improve and the approach is reasonable. Please go ahead to the next step and polish it up. Also, please change _isneg back to _sign. That matches the terminology in the spec, the machine centric sign bit viewpoint of 754R, and the components of the user visible as_tuple() method. The goal is to make the patch as minimal as possible, to keep the API unchanged, and improve performance. Using the __new__ method was smart. That more closely corresponds to a potential C implementation of an immutable type. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-01 21:11 Message: Logged In: YES user_id=1038590 I forgot to add that this is NOT yet a production quality patch. The doc strings, in particular, need work. I'm mainly posting it so Raymond can have a look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 From noreply at sourceforge.net Fri Sep 17 05:37:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 17 05:37:36 2004 Subject: [Patches] [ python-Patches-1020845 ] Decimal performance enhancements Message-ID: Patches item #1020845, was opened at 2004-09-01 19:08 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) >Assigned to: Raymond Hettinger (rhettinger) Summary: Decimal performance enhancements Initial Comment: The attached patch implements a collection of performance enhancements for decimal.py. They are currently focused on the performance of the telco benchmark in the sandbox (i.e. they aim to speed up instantiation, addition, multiplication and quantization). The main strategy used (a subclass for NaN and infinite values) can be extended to encompass more methods in order to improve performance in other situations. There is one non-performance related change included - the '_sign' attribute is renamed to '_isneg' to better reflect the boolean nature of the property. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-16 22:37 Message: Logged In: YES user_id=80475 I'll look at it in the next few day. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-09-16 20:50 Message: Logged In: YES user_id=752496 Raymond, Nick: I only reviewed the "both" version. From the patch text, the changes were pretty logical, but they were a *lot*, so I didn't want to extend the change to "_workint" version. It'll always be time. The majority of changes are because of the added attribute "_is_special", which shortcuts in an obvious manner a lot of code, and also makes possibly some interesting conceptual changes (and some other changes were not simple and implied good knowledge of the code and decimal internals). There're also a lot of changes such as executing once a function, binding its result in a name and using that name several times later (which effectively reduced the quantity of function calls). And trimmed several "getcontext()" when the only thing that was done was passing context to other function (not used there). The changed decimal was OK in the tests, showing a 14% speed up. I'm +1 to commit the "both" version. Checking the code, I saw some other optimizations, but I don't want to introduce new changes without commiting these first. Nick, congratulations, you certainly made a good work! (btw, don't upload files with spaces in the name) Raymond, do you want to commit the code or should I do it? . Facundo ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-16 07:17 Message: Logged In: YES user_id=1038590 I've separated the performance enhancements out into four different potential patches now: - "_odds_and_ends" - "_is_special" - "_both" (combination of the above two patches) - "_workint" (also incorporates "_both") A single tar.gz file is attached which contains all those in .diff and .py format, as well as a text file detailing the changes made in each patch. All diff's are directly against CVS. test_decimal.py passes cleanly with all four patches. They're listed above in order of increasing degree of change from current CVS. Hopefully I've gotten rid of any doc string changes, and non-performance related code changes (some comments have changed, usually because associated code has changed) The _workint version is the only version which regularly achieves < 20 s wall clock time on my machine for the unit tests and < 60 s for "telco_nofiles.py 10000" (that is, one hundred thousand decimal values). The _both version seems to run around 5 seconds slower on both tests (I am assuming this is due to the fact that _workint speeds up division significantly more than it speeds up addition and multiplication, thus having a much more pronounced effect on the unit tests than on the division-free telco benchmark) Here are the details on the different patches: decimal_odds_and_ends: - cache the result of repeated method calls in: __cmp__ _rescale _check_nans _fix_exponents - use sum() in __nonzero__ - call list.reverse() on preliminary result, not operands in __add__ - avoid redundant _fix_exponents call in _fix - rearrange _fix_exponents to minimise method calls on any given path - remove dead code from end of __int__ decimal_is_special: - convert to use __new__ instead of __init__ - new attribute _is_special is True if value is infinite or NaN - defer invocation of getcontext() as late as possible - make _convert_other a function instead of a method - modify all methods to take advantage of _is_special decimal_both: - combines decimal_is_special & decimal_odds_and_ends decimal_workint: - based on decimal_both - uses a numeric value for _WorkRep.int instead of a list - modifies __new__, __add__ and _divide accordingly - modifies __mul__ to use a _WorkRep (Sorry Raymond, I couldn't quite resist experimenting with borrowing int/long's C level arithmetic implementation!) I'll see about getting some wall-clock numbers for the *actual* million-value telco benchmark with all 5 versions (CVS + the four patches). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-08 18:45 Message: Logged In: YES user_id=1038590 2nd version of patch attached. It does NOT use a subclassing strategy for optimisation due to the following charming little problem I found with that approach: >>> import decimal >>> class foo(decimal.Decimal): pass >>> x = foo("NaN") >>> isinstance(x, foo) False I couldn't find any sane way to get around this, and it seemed to be a showstopper given the amount of work that has gone into making all the builtin types easily subclassable. The new patch instead relies mainly on the following techniques: - defer invocation of getcontext() as late as possible, so that we only call it if the context is going to be referenced - use issubclass(x, basestring) to identify if there are special cases that need handling, then use _is_nan and _is_infinity to determine exactly which special case applies (this slows the special cases down slightly, but speeds up the normal cases a lot) - make _convert_other a helper function instead of a method There are also some other minor changes that were present in the original patch (use sum() in __nonzero__, reduce the number of calls to list.reversed() in __add__, extract digits directly from integer inputs with divmod, rearrange _fixexponents to minimise context method calls, cache results of method calls in various operations) Facundo, two particular changes I'd like you to OK are: - _fix now indents the second call to _fixexponents to be inside the if block (in CVS, _fix_exponents could get called again directly on the result of the previous call to _fix_exponents, which didn't seem to make any sense) - _fixexponents returns immediately for NaN as well as infinite values This version of patch appears to give around a 40% speedup on direct execution of test_decimal.py, and all the tests still pass for me. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-09-07 18:47 Message: Logged In: YES user_id=752496 Nick: Submit the second version of the patch and I'll review it. Also feel free to contact me by mail anytime. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 16:59 Message: Logged In: YES user_id=80475 Glad to hear you've wrapped your head around the sign bit. FWIW, it bugged me too. But it is so closely tied to the spec that it is better to adjust our mental model than change the code. Do extend your optimizations to the other functions. Don't just optimize the benchmark -- that defeats the purpose. Can you work together with Facundo on this one? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-07 16:06 Message: Logged In: YES user_id=1038590 With the _sign/_isneg thing, I figured out the reason it was hurting my brain - I was failing to think of the value as representing a two's complement sign bit. Once I thought of it that way, it made sense with the original terminology. I suspect the lesser speedup on test_decimal.py may be due to the fact that the current version of the patch only optimises the operations used by the telco benchmark (instantiation, addition, multiplication, quantisation). As we speed up other operations, the performance on the unit tests should improve. As far as the API itself goes, the major differences I am aware of are the existence of the new subclass, and the use of __new__ instead of __init__. That will presumably be a bit more work to implement in C since another class is needed. Do we need to document somewhere that Decimal(x) may return an instance of a subclass of Decimal() rather than an instance of Decimal itself? My current plan is to produce a second version of this patch that: 1. Starts again from current CVS 2. Leaves '_sign' alone 3. Leaves existing doc strings alone (I broke a couple of them in this version of patch - I hadn't really thought about how to handle them properly) 4. For overridden methods in the _Special_Value class, duplicate the docstring from the baseclass with "f.__doc__ = Decimal.f.__doc__". This should avoid giving different answers for "help(Decimal(1).__add__)" and "help(Decimal('NaN').__add__)". 5. Optimises all operations, not just the four used by the telco benchmark (with the new strategy in place, this is mostly legwork - cutting and pasting the special-value related stuff to the new subclass, and rearranging appropriately. Unfortunately, it's legwork that I can't see a sensible way to automate, so it's a matter of taking the time to do it, and then checking that the tests all still pass). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 00:05 Message: Logged In: YES user_id=80475 Facundo, do you have time to look at this one? We need to: * revert the _isneg variable name change * find out why it gives a 2:1 gain on telco but only 10% on test_decimal.py * make sure the API has not changed in a way that will make it more difficult someday to convert this into C and make it a built-in. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-02 00:18 Message: Logged In: YES user_id=80475 Nice job. The timings do improve and the approach is reasonable. Please go ahead to the next step and polish it up. Also, please change _isneg back to _sign. That matches the terminology in the spec, the machine centric sign bit viewpoint of 754R, and the components of the user visible as_tuple() method. The goal is to make the patch as minimal as possible, to keep the API unchanged, and improve performance. Using the __new__ method was smart. That more closely corresponds to a potential C implementation of an immutable type. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-01 19:11 Message: Logged In: YES user_id=1038590 I forgot to add that this is NOT yet a production quality patch. The doc strings, in particular, need work. I'm mainly posting it so Raymond can have a look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 From noreply at sourceforge.net Fri Sep 17 10:25:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 17 10:25:36 2004 Subject: [Patches] [ python-Patches-1022003 ] topdir calculated incorrectly in bdist_rpm Message-ID: Patches item #1022003, was opened at 2004-09-03 18:32 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022003&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Sean Reifschneider (jafo) Summary: topdir calculated incorrectly in bdist_rpm Initial Comment: The _topdir directive to the bdist_rpm command is calculated incorrectly when the --bdist-base or --dist-dir options to the command use absolute path names. It should use os.path.abspath() instead, I believe. It would be nice if this patch was backported to earlier versions of Python as well but it is not critical for me. If you have further questions, let me know. ---------------------------------------------------------------------- >Comment By: Sean Reifschneider (jafo) Date: 2004-09-17 08:25 Message: Logged In: YES user_id=81797 I've committed this into the trunk, and asked on python-dev about it's inclusion for 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022003&group_id=5470 From noreply at sourceforge.net Fri Sep 17 10:37:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 17 10:37:49 2004 Subject: [Patches] [ python-Patches-1022011 ] add support for the AutoReq flag in bdist_rpm Message-ID: Patches item #1022011, was opened at 2004-09-03 18:49 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022011&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Sean Reifschneider (jafo) Summary: add support for the AutoReq flag in bdist_rpm Initial Comment: This patch supplies a new option to bdist_rpm to allow the setting of the AutoReq flag in RPM to false. This ensures that no dependencies are calculated automatically. If you have further questions or want the name of the option changed, please feel free to ask. ---------------------------------------------------------------------- >Comment By: Sean Reifschneider (jafo) Date: 2004-09-17 08:37 Message: Logged In: YES user_id=81797 I have committed this change into the trunk, and asked about their inclusion in 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1022011&group_id=5470 From noreply at sourceforge.net Fri Sep 17 18:32:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 17 18:32:39 2004 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 03:45 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) >Assigned to: Nobody/Anonymous (nobody) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-08 08:37 Message: Logged In: YES user_id=469548 Yeah, bug #1023798 reported that and Brett fixed it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-09-07 13:34 Message: Logged In: YES user_id=89016 I'm getting the following error from the new test__locale: test test__locale failed -- Traceback (most recent call last): File "/home/walter/Achtung/Python-codec- small/dist/src/Lib/test/test__locale.py", line 37, in test_lc_numeric "%r != %r (%s); " File "/home/walter/Achtung/Python-codec- small/dist/src/Lib/locale.py", line 363, in getlocale return _parse_localename(localename) File "/home/walter/Achtung/Python-codec- small/dist/src/Lib/locale.py", line 278, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: lv_LV BTW, could someone have a look at Johannes' test_doctest and test_inspect patches? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-09-06 19:32 Message: Logged In: YES user_id=357491 OK, test__locale has been checked in. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-30 04:00 Message: Logged In: YES user_id=469548 Brett: that's just one of the drawbacks of doing data-driven testing with unittest. I don't think it's terribly important, so the test is OK to me. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-26 20:44 Message: Logged In: YES user_id=357491 Just attached a new version of test__locale. Since it is so small of a file and the change so drastic I just uploaded the whole file. Only drawback is before the test kept testing all locales when there was a failure while my implementation stops at the first failure discovered. Don't know if it is important to test all locales. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-24 09:59 Message: Logged In: YES user_id=80475 Walter, I'm afraid I don't have time for these right now. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-08-20 09:39 Message: Logged In: YES user_id=89016 Raymond, can you take a look at the patches? ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-20 08:06 Message: Logged In: YES user_id=469548 Another one: ported test_inspect to unittest and moved out the inspect fodder out into two modules instead of using the ugly imp.load_source and TESTFN. I also did a bit of rearrangement so that the TestCase classes mostly match the sections in the library docs. I used a separate module (inspect_fodder2) and class for the decorators tests. Those are kind of small now, but I'll check in http://python.org/sf/1011890 after this port and let it grow without having to update test_getfunctions(). ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-19 08:14 Message: Logged In: YES user_id=469548 Hum yes, that was me trying out how doctest fails. The expected outcome should have been True. Can you try the corrected version? Test_zipfile has been checked in as rev 1.11. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-08-18 12:29 Message: Logged In: YES user_id=89016 doctest tests should be OK. The error tests in test_unpack can be done with PyUnit too, you either use self.assertRaises(ValueError, eval, "a,b = Seq()") or try: a,b = Seq() except ValueError: pass else: self.fail("failed") test_zipfile_unittest.py looks OK, but should of course be named test_zipfile.py when you check it in. test_unpack_doctest.py gives me: ********************************************** ************************ Failure in example: a == 4 and b == 5 and c == 6 from line #14 of test.test_unpack_doctest.doctests in /home/walter/Achtung/Python- test/dist/src/Lib/test/test_unpack_doctest.pyc Expected: False Got: True ********************************************** ************************ 1 items had failures: 1 of 28 in test.test_unpack_doctest.doctests ***Test Failed*** 1 failures. Traceback (most recent call last): File "Lib/test/test_unpack_doctest.py", line 133, in ? test_main(verbose=True) File "Lib/test/test_unpack_doctest.py", line 130, in test_main test_support.run_doctest(test_unpack_doctest, verbose) File "/home/walter/Achtung/Python- test/dist/src/Lib/test/test_support.py", line 318, in run_doctest raise TestFailed("%d of %d doctests failed" % (f, t)) test.test_support.TestFailed: 1 of 28 doctests failed ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-18 06:23 Message: Logged In: YES user_id=469548 Is there any problem with porting test scripts to doctest instead of unittest? doctest is just perfect for test_unpack (doctest version attached). I've also ported test_zipfile to unittest (attached as well). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-31 09:31 Message: Logged In: YES user_id=89016 OK, checked in as: Lib/test/mapping_tests.py 1.1 Lib/test/test_os.py 1.22 Lib/test/test_shelve.py 1.7 Lib/test/test_types.py 1.60 Lib/test/test_userdict.py 1.19 Lib/test/test_weakref.py 1.39 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-28 16:02 Message: Logged In: YES user_id=80475 Looks good. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-28 13:59 Message: Logged In: YES user_id=89016 OK, I've updated the docstring for dict.update() (Object/dictobject.c 2.160) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-27 12:04 Message: Logged In: YES user_id=89016 dict_diff.txt is a patch that tries to share tests between test_dict, test_userdict, test_os, test_shelve and test_weakref. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-25 13:29 Message: Logged In: YES user_id=31435 Don't really care myself. Would be nice if the docstring for dict.update() matched the new realities, though . BTW, there is a reliable and conventional way to detect whether the 'dict' argument was passed to UserDict.update: use a unique marker object instead of the universally visible None. Like _marker = object() at module level, and ...(self, dict=_marker, ...) in the method defn. That can't be fooled without deliberate intent to deceive. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-25 13:21 Message: Logged In: YES user_id=80475 IMO, it is fine as is. I would be suprised if some code were relying on UserDict.update(None) raising an exception. This sort of thing also comes up also in places like the string and random modules whereever a function or method with an optional argument gets wrapped by another function. The only way around this is to use *args and then you break code that used the unfortunately named "dict" argument as a keyword. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-25 12:32 Message: Logged In: YES user_id=89016 Merging test_dict and test_userdict revealed a difference between dict and UserDict.UserDict: >>> import UserDict >>> d = UserDict.UserDict() >>> d.update(None) >>> d {} >>> d = {} >>> d.update(None) Traceback (most recent call last): File "", line 1, in ? TypeError: iteration over non-sequence Should we do anything about this? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-20 09:03 Message: Logged In: YES user_id=80475 test_dict is fine. Consider beefing up the tests for update(). As of Py2.4, it now takes all the same argument possibilites as dict(): d.update(a=1, b=2) d.update([('a', 1), ('b', 2)]) Also, try to link in: from test_userdict import TestMappingProtocol This was supposed to provide tests common to all mappings. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-04-03 03:06 Message: Logged In: YES user_id=89016 The attached test_dict.py moves the dict tests from test_types.py to a new PyUnit test script. Code coverage for dictobject.c is at 90.76% (up from 89.51%) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-03-15 04:17 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_binascii delete Lib/test/test_binascii.py 1.17 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-03-13 12:26 Message: Logged In: YES user_id=80475 Okay, this one is fine. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-18 15:49 Message: Logged In: YES user_id=89016 Here's the next one: test_binascii.py. Code coverage in binascii.c is at 92% (could be improved by enhancing test_binhex.py). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-13 14:46 Message: Logged In: YES user_id=33168 Looked good to me, test_future_pyunit.diff checked in as: * Lib/test/badsyntax_future3.py 1.2 * Lib/test/badsyntax_future4.py 1.2 * Lib/test/badsyntax_future5.py 1.2 * Lib/test/badsyntax_future6.py 1.2 * Lib/test/badsyntax_future7.py 1.2 * Lib/test/badsyntax_future8.py 1.1 * Lib/test/badsyntax_future9.py 1.1 * Lib/test/test_future.py 1.7 * Lib/test/test_future1.py 1.3 * Lib/test/test_future2.py 1.2 * Lib/test/output/test_future 1.4 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-13 13:47 Message: Logged In: YES user_id=33168 Walter, I didn't get a mail from SF either. After you do a cvs add, you need to use -N to cvs diff. For example, cvs diff -N new_file_added_to_cvs_but_not_committed. If you look carefully, you can see this in the patch on the diff line for each file. I'll take a look at the patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-13 12:18 Message: Logged In: YES user_id=89016 Here is a version of test_future ported to PyUnit (test_future_pyunit.diff). If this makes sense to you Neal, please check it in. (BTW, how did you convince CVS to include badsyntax_future8.py and badsyntax_future9.py in the diff? Doing a "cvs add" only results in " Lib/test/badsyntax_future8.py is a new entry, no comparison available") ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-11 04:36 Message: Logged In: YES user_id=89016 md5/weakref patch checked in as: Lib/test/test_weakref.py 1.33 Lib/test/test_md5.py 1.5 Lib/test/output/test_md5 remove ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-10 22:05 Message: Logged In: YES user_id=33168 Improve coverage for test_future too. I'm not sure if test future can be ported to PyUnit. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-10 21:52 Message: Logged In: YES user_id=33168 Attached are two tests (in one file, I'm being lazy, sorry) to improve test coverage for md5c.c and _weakref.c. test_md5 was ported to unittest, weakref, just adds two little tests to get coverage up to 100%. If you like, just go ahead and check in. You will need to remove Lib/test/output/test_md5 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-08 03:42 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/list_tests.py 1.1 Lib/test/seq_tests.py 1.1 Lib/test/test_list.py 1.1 Lib/test/test_tuple.py 1.1 Lib/test/test_types.py 1.56 Lib/test/test_userlist.py 1.11 Lib/test/output/test_types 1.3 Next will be test_binascii.py before I continue with test_types.py. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-07 15:49 Message: Logged In: YES user_id=80475 Looks good. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-11-27 11:48 Message: Logged In: YES user_id=89016 Here the first part of the test_types port: list and tuple tests have been moved to their own scripts: test_tuple.py and test_list.py. Common tests for tuple, list and UserList are shared (in seq_test.py and list_test.py) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 18:53 Message: Logged In: YES user_id=80475 Applied as: Lib/test/test_slice.py 1.5. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 16:52 Message: Logged In: YES user_id=80475 Looks good. I added a couple of minor tests. Revised patch attached. Okay to apply. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-31 12:49 Message: Logged In: YES user_id=89016 Thanks! Here's another one: test_slice.py ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 16:04 Message: Logged In: YES user_id=80475 Done. See: Lib/test/test_longexp.py 1.9; previous revision: 1.8 Lib/test/test_pep263.py 1.3; previous revision: 1.2 Lib/test/test_sets.py 1.27; previous revision: 1.26 Lib/test/test_structseq.py 1.5; previous revision: 1.4 Lib/test/output/test_longexp delete; previous revision: 1.3 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 10:10 Message: Logged In: YES user_id=80475 Will do! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-30 10:06 Message: Logged In: YES user_id=89016 Here's test_structse.py converted with a few additional tests. If all three scripts are OK, could you check them in Raymond, as I'll be on vacation for three weeks? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-09 08:47 Message: Logged In: YES user_id=89016 Here are two simple ones: test_pep263 and test_longexp. I can't think of any additional tests to add. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-23 06:38 Message: Logged In: YES user_id=80475 Fixed Walter's review comments and committed as Lib/test/test_compile.py 1.19 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-23 04:49 Message: Logged In: YES user_id=89016 Are you sure, that the code path is the same in the new test_argument_handling() as in the old test? I.e. is "eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"? The print statement in test_float_literals should be changed to a comment. Should the imports in test_unary_minus() be moved to the start of the script? Otherwise the test looks (and runs) OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 12:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-19 02:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 12:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-18 07:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-17 16:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 14:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 05:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 14:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 12:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 12:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 12:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 12:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 11:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 11:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 09:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 08:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 08:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 05:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 10:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 09:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 08:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 06:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 16:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 19:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 18:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 18:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 18:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 17:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 16:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply at sourceforge.net Sat Sep 18 01:14:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 01:14:21 2004 Subject: [Patches] [ python-Patches-1028502 ] Adding IPv6 host handling to httplib Message-ID: Patches item #1028502, was opened at 2004-09-15 13:14 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028502&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: David Mills (dgm6net) Assigned to: Nobody/Anonymous (nobody) Summary: Adding IPv6 host handling to httplib Initial Comment: getaddrinfo() doesn't like the square brackets round an IPv6 hostname, so they are now stripped off. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-18 01:14 Message: Logged In: YES user_id=21627 The patch is out of date; rejecting it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1028502&group_id=5470 From noreply at sourceforge.net Sat Sep 18 11:04:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 11:04:38 2004 Subject: [Patches] [ python-Patches-1025790 ] Add status code constants to httplib Message-ID: Patches item #1025790, was opened at 2004-09-10 13:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1025790&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Andrew Eland (andreweland) Assigned to: Nobody/Anonymous (nobody) Summary: Add status code constants to httplib Initial Comment: httplib doesn't define constants for the HTTP integer status codes, so most applications end up defining their own subset. This patch adds status code constants to httplib, using the same names as Twisted, and updates the documentation. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-18 11:04 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as libhttplib.tex 1.38 httplib.py 1.92 ACKS 1.283 NEWS 1.1136 ---------------------------------------------------------------------- Comment By: Andrew Eland (andreweland) Date: 2004-09-16 15:12 Message: Logged In: YES user_id=646767 I've added a new patch that: - Uses the canonical spelling for constants - Adds missing status codes from RFCs 2817 and 3229 - Documents the constants in a table, referencing the section of the relevent RFC ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-13 23:27 Message: Logged In: YES user_id=21627 Compatibility with twisted is a non-goal; twisted will adopt soon enough to the precedent that Python sets, especially if there is a clear objective rationale. Completeness is one such objective rationale, and consistency with the RFC is another one. Twisted can then easily achieve Python compatibility by adding the missing constants. ---------------------------------------------------------------------- Comment By: Andrew Eland (andreweland) Date: 2004-09-13 11:03 Message: Logged In: YES user_id=646767 > I think the best standard way of spelling the constants is > to take them directly from the 10.x.x headings of RFC2616 The spellings in the initial patch come from Twisted, I kept the few non-canonical spellings to avoid confusing people who work with both httplib and Twisted. If the consensus is that canonical spellings should be used regardless, I'll update the patch. > It seems WebDAV codes that 102, 422, 423, 424 are missing Again, the subset chosen is from Twisted, I kept the additional codes compatibility. It does makes sense to include the others though, I'll add them. > OTOH, putting this all in a four-column table (constant name, value, > RFC number, section) would make a very systematic presentation. I avoided adding a comment for each code as the extra information provided by the comments was outweighed by the description of status codes swamping the httplib documentation. Using a table should keep the documentation compact, I'll try it out. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-13 07:54 Message: Logged In: YES user_id=21627 207 comes from RFC 2518 (WebDAV), section 8.2.1 and 10.2. 507 likewise, section 10.6. It seems WebDAV codes that 102, 422, 423, 424 are missing. Likewise, 426 from RFC 2817 is missing, and 226 from RFC 3229. 510 comes from RFC 2774 (HTTP Extensions), section 7. Even though I agree with your procedure for creating "canonical" spellings, I think more documentation is needed. Following this procedure, it would be best to list RFC and section as the documentation; this might allow to leave out the numerical value IMO. OTOH, putting this all in a four-column table (constant name, value, RFC number, section) would make a very systematic presentation. ---------------------------------------------------------------------- Comment By: Andrew Durdin (adurdin) Date: 2004-09-13 03:51 Message: Logged In: YES user_id=625864 I think the best standard way of spelling the constants is to take them directly from the 10.x.x headings of RFC2616. This would require changing four of the names of the constants in the patch from: SWITCHING = 101 MULTIPLE_CHOICE = 300 NOT_ALLOWED = 405 PROXY_AUTH_REQUIRED = 407 to: SWITCHING_PROTOCOLS = 101 MULTIPLE_CHOICES = 300 METHOD_NOT_ALLOWED = 405 PROXY_AUTHENTICATION_REQUIRED = 407 Also, the following status codes are not part of the HTTP/1.1 standard as given in RFC2616: MULTI_STATUS = 207 INSUFFICIENT_STORAGE_SPACE = 507 NOT_EXTENDED = 510 Where do these come from? Being nonstandard, is it inappropriate to include them in httplib? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-10 22:54 Message: Logged In: YES user_id=21627 Unless the precise spelling of the constants is taken from some existing specification, I think the documentation needs to spell out the values, so that readers can easily confirm that a certain symbolic value has the meaning they expect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1025790&group_id=5470 From noreply at sourceforge.net Sat Sep 18 11:09:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 11:09:37 2004 Subject: [Patches] [ python-Patches-1029061 ] tarfile.py longnames are truncated in getnames() Message-ID: Patches item #1029061, was opened at 2004-09-16 10:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1029061&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py longnames are truncated in getnames() Initial Comment: When a TarFile object reads a tar archive, it scans through the headers, converts them into TarInfo objects and adds them to the internal data structures: self.members.append(tarinfo) self.membernames.append(tarinfo.name) When a GNU longname member is processed, it is added at a point in time when its name attribute has not yet been replaced with the longname, so longnames in self.membernames are truncated and therefore unusable. This problem could have been fixed with a quick/dirty hack. But I decided to remove self.membernames completely because it is redundant. getnames() which was the public interface to it now generates a list on-the-fly from the list of members, so it always reflects the actual state. I encountered another small bug on the way. The docs for TarFile.getmember() state: "If a member occurs more than once in the archive, its last occurence is assumed to be the most up-to-date version." It was never implemented like that, so I fixed it, too. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-18 11:09 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as tarfile.py 1.20 NEWS 1.1137 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1029061&group_id=5470 From noreply at sourceforge.net Sat Sep 18 12:08:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 12:08:20 2004 Subject: [Patches] [ python-Patches-1012280 ] Patch for bug 933795. term.h and curses on Solaris Message-ID: Patches item #1012280, was opened at 2004-08-19 17:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1012280&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Ariel Arjona (beerfrick) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for bug 933795. term.h and curses on Solaris Initial Comment: The following patch solves issue 933795. Also see for more info: http://lists.gnu.org/archive/html/bug-autoconf/2003-05/msg00118.html This issue affects 2.3.3 and 2.3.4. The can be applied to both. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-18 12:08 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as configure 1.458 configure.in 1.471 pyconfig.h.in 1.104 configure 1.416.4.17 configure.in 1.427.4.16 pyconfig.h.in 1.83.4.6 NEWS 1.831.4.150 I made a few modifications to the patch: move curses.h test into the main header loop, and remove the double square brackets (which did not serve a purpose). ---------------------------------------------------------------------- Comment By: Ariel Arjona (beerfrick) Date: 2004-08-19 17:44 Message: Logged In: YES user_id=200741 Forgot: patch tested on Solaris 8 on SPARC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1012280&group_id=5470 From noreply at sourceforge.net Sat Sep 18 17:32:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 17:32:36 2004 Subject: [Patches] [ python-Patches-1012468 ] Rational.py various bugfixes Message-ID: Patches item #1012468, was opened at 2004-08-19 22:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1012468&group_id=5470 Category: Demos and tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Blau (russblau) Assigned to: Nobody/Anonymous (nobody) Summary: Rational.py various bugfixes Initial Comment: Rational.py in the sandbox (python/python/nondist/sandbox/rational/Rational.py) contains a variety of minor (and not-so-minor) bugs, and some doctest errors as a result of changes introduced in recent Python versions. A corrected version (that works for me) is attached. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-18 17:32 Message: Logged In: YES user_id=21627 Please submit patches as unified or context diffs. The file you have attached fails for me as well, I get ********************************************************************** File "/tmp/Rational.py", line 115, in Rational Failed example: float(p.trim(1L<<32)-p) Expected: -7.3974359428840768e-020 Got: -7.3974359428840768e-20 ********************************************************************** File "/tmp/Rational.py", line 126, in Rational Failed example: float(p.approximate(rational(1L)>>32)-p) Expected: 1.3733999215941832e-011 Got: 1.3733999215941832e-11 ********************************************************************** I have now untabified Rational.py, please use that as a starting point for further changes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1012468&group_id=5470 From noreply at sourceforge.net Sat Sep 18 18:05:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 18:05:49 2004 Subject: [Patches] [ python-Patches-1018509 ] fix bug 807871 : tkMessageBox.askyesno wrong result Message-ID: Patches item #1018509, was opened at 2004-08-29 13:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1018509&group_id=5470 Category: Tkinter Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jiba (jiba) Assigned to: Nobody/Anonymous (nobody) Summary: fix bug 807871 : tkMessageBox.askyesno wrong result Initial Comment: This patch is a quick fix for the bug 807871 : "tkMessageBox.askyesno wrong result". It should be applied in the file Lib/lib-tk/tkMessageBox.py. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-18 18:05 Message: Logged In: YES user_id=21627 Thanks for the patch. I have committed something similar as tkMessageBox.py 1.3, 1.2.10.1 NEWS 1.831.4.151 Essentially, I changed _show to convert booleans back to strings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1018509&group_id=5470 From noreply at sourceforge.net Sat Sep 18 18:11:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 18:11:15 2004 Subject: [Patches] [ python-Patches-1024670 ] Error when int sent to PyLong_AsUnsignedLong Message-ID: Patches item #1024670, was opened at 2004-09-08 23:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1024670&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Clinton R. Nixon (crnixon) Assigned to: Nobody/Anonymous (nobody) Summary: Error when int sent to PyLong_AsUnsignedLong Initial Comment: When sending a Python integer as an argument to PyLong_AsUnsignedLong, the following error occurs SystemError: Objects/longobject.c:240: bad argument to internal function This error comes from the fact that PyLong_AsUnsignedLong, unlike PyLong_AsLong, does not check to see if the number is a long or integer, but only a long. This patch checks to see if the number is an integer, and if so, calls PyInt_AsUnsignedLongMask. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-18 18:11 Message: Logged In: YES user_id=21627 Why is it desirable to accept ints in PyLong_AsUnsignedLong? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1024670&group_id=5470 From noreply at sourceforge.net Sat Sep 18 18:18:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 18:18:28 2004 Subject: [Patches] [ python-Patches-908631 ] WinSock 2 support on Win32 w/ MSVC++ 6 (fix #860134) Message-ID: Patches item #908631, was opened at 2004-03-03 00:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=908631&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 6 Submitted By: Jeff Connelly aka shellreef (jeffconnelly) Assigned to: Nobody/Anonymous (nobody) Summary: WinSock 2 support on Win32 w/ MSVC++ 6 (fix #860134) Initial Comment: WinSock 2 isn't supported on 2.3. The capability is there, but the Microsoft C++ version is incorrectly specified to the preprocessor, VC++ 6 (the version used to build the official Python Win32 executable) misses the #if's and links to wsock32.lib, instead. This results in the programmer only being able to use WinSock 1, instead of WinSock 2's useful functions. On modern Win32's, WinSock 2 is prevalent, so the switch shouldn't cause too much trouble, as well as providing additional functionality. The problem appears to be line 16 of socketmodule.h, which includes WinSock 2 #if _MSC_VER >= 1300 and WinSock 1 otherwise. (IP_HDRINCL is a part of WinSock 2.) Apply this patch to use WinSock 2 on MS VC++ 6 (1200), which is what the Python Win32 builds are compiled with. (1300 is .Net? maybe?) pyconfig.h also needs to be patched. Also, the _socket moduleneeds to link with ws2_32.lib instead of wsock32.lib. (Project -> Settings -> highlight _socket -> Win32 release -> Link tab -> in "Object/library modules" change wsock32.lib to ws2_32.lib). With these changes, IP_HDRINCL exists in socket: C:\>python Python 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import socket >>> socket.IP_HDRINCL 2 >>> And it works as it should, as do other obscure WinSock 2 functions. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-18 18:18 Message: Logged In: YES user_id=21627 I have changed _socket.vcproj 1.6 to link with ws2_32.lib (and I wonder whether any library needs to be specified in the project in the first place). I'm rejecting this patch as out-of-date - the build procedure for VC6 won't be changed, now that we have VC7. ---------------------------------------------------------------------- Comment By: Jeff Connelly aka shellreef (jeffconnelly) Date: 2004-08-25 06:51 Message: Logged In: YES user_id=31953 Python 2.4a2 fixes this issue somewhat, but not completely. Since the Win32 release is compiled using Visual Studio 7.1, the IP_HDRINCL and related symbols are defined. However, socketmodule still links to wsock32.lib instead of ws2_32.lib. This means that setsockopt(IP_HDRINCL) appears to work, and even returns None, but it doesn't really work. >From http://www2.2cah.com/ws2/log9706.txt : > You're not doing anything wrong. The problem is that, unfortunately, > Micorosoft's WinSock 2 doesn't support the IP_HDRINCL socket option. > > They don't support IPPROTO_RAW ("raw IP") either. They will gladly > give you a socket, but then they send your IP header as data, and > send a bogus IP datagram that has 255--the value of IPPROTO_RAW-- > as the protocol ID. If you look at the net traffic that results > from this (with a net analyzer), you'd see the receiver of this > bogus datagram respond with a "Protocol Unreachable" ICMP error > message. I haven't even succesfully sent raw sockets with wsock32.lib. This is fixed in ws2_32.lib. So all that Python has to do to pull in these fixes is to link to wsock32.lib instead of ws2_32.lib. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/wsacleanup_2.asp says: >Client: Requires Windows XP, Windows 2000 Professional, >Windows NT Workstation, Windows Me, Windows 98, or >Windows 95. >[...] >Library: Use Ws2_32.lib. Therefore it leads me to believe that having Python link with ws2_32.lib shouldn't cause any compatibility problems on older systems, provided they have the Winsock2 updates. If anyone is here, can we expect this patch to be merged soon? Thanks, -jc ---------------------------------------------------------------------- Comment By: Jeff Connelly aka shellreef (jeffconnelly) Date: 2004-07-17 12:17 Message: Logged In: YES user_id=31953 Can this change be merged into the current source tree? I need WinSock 2 for my application and distributing a patched version of Python isn't very elegant. ---------------------------------------------------------------------- Comment By: Jeff Connelly aka shellreef (jeffconnelly) Date: 2004-03-03 00:20 Message: Logged In: YES user_id=31953 P.S.: The original bug report is here: https://sourceforge.net/tracker/index.php? func=detail&aid=860134&group_id=5470&atid=105470 ---------------------------------------------------------------------- Comment By: Jeff Connelly aka shellreef (jeffconnelly) Date: 2004-03-03 00:18 Message: Logged In: YES user_id=31953 P.S.: The original bug report is here: https://sourceforge.net/tracker/index.php? func=detail&aid=860134&group_id=5470&atid=105470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=908631&group_id=5470 From noreply at sourceforge.net Sat Sep 18 21:02:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 21:02:47 2004 Subject: [Patches] [ python-Patches-1030422 ] Message-ID: Patches item #1030422, was opened at 2004-09-18 12:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1030422&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Connelly aka shellreef (jeffconnelly) Assigned to: Nobody/Anonymous (nobody) Summary: Initial Comment: Thanks loewis! This is the change I've been waiting for. Much appreciated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1030422&group_id=5470 From noreply at sourceforge.net Sat Sep 18 21:24:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 21:24:05 2004 Subject: [Patches] [ python-Patches-1030422 ] Message-ID: Patches item #1030422, was opened at 2004-09-19 04:02 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1030422&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Connelly aka shellreef (jeffconnelly) Assigned to: Nobody/Anonymous (nobody) Summary: Initial Comment: Thanks loewis! This is the change I've been waiting for. Much appreciated. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-19 04:24 Message: Logged In: YES user_id=671362 Is this a reply to patch #908631? - WinSock 2 support on Win32 w/ MSVC++ 6 http://www.python.org/sf/908631 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1030422&group_id=5470 From noreply at sourceforge.net Sat Sep 18 21:26:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 21:26:05 2004 Subject: [Patches] [ python-Patches-1030422 ] Message-ID: Patches item #1030422, was opened at 2004-09-18 12:02 Message generated for change (Settings changed) made by jeffconnelly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1030422&group_id=5470 Category: None Group: None >Status: Deleted Resolution: None Priority: 5 Submitted By: Jeff Connelly aka shellreef (jeffconnelly) Assigned to: Nobody/Anonymous (nobody) Summary: Initial Comment: Thanks loewis! This is the change I've been waiting for. Much appreciated. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-09-18 12:24 Message: Logged In: YES user_id=671362 Is this a reply to patch #908631? - WinSock 2 support on Win32 w/ MSVC++ 6 http://www.python.org/sf/908631 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1030422&group_id=5470 From noreply at sourceforge.net Sun Sep 19 03:54:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 19 03:54:48 2004 Subject: [Patches] [ python-Patches-1020845 ] Decimal performance enhancements Message-ID: Patches item #1020845, was opened at 2004-09-01 19:08 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nick Coghlan (ncoghlan) >Assigned to: Facundo Batista (facundobatista) Summary: Decimal performance enhancements Initial Comment: The attached patch implements a collection of performance enhancements for decimal.py. They are currently focused on the performance of the telco benchmark in the sandbox (i.e. they aim to speed up instantiation, addition, multiplication and quantization). The main strategy used (a subclass for NaN and infinite values) can be extended to encompass more methods in order to improve performance in other situations. There is one non-performance related change included - the '_sign' attribute is renamed to '_isneg' to better reflect the boolean nature of the property. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-18 20:54 Message: Logged In: YES user_id=80475 Checking in Nick's best version as Lib/decimal.py 1.24 Made a minor modification to the workrep __init__ code. Facunodo, feel free to checkin your own optimizations. Make sure they are clear both in concept and code. Also, make sure they show measurable speedups in both telco and the test suite. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-16 22:37 Message: Logged In: YES user_id=80475 I'll look at it in the next few day. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-09-16 20:50 Message: Logged In: YES user_id=752496 Raymond, Nick: I only reviewed the "both" version. From the patch text, the changes were pretty logical, but they were a *lot*, so I didn't want to extend the change to "_workint" version. It'll always be time. The majority of changes are because of the added attribute "_is_special", which shortcuts in an obvious manner a lot of code, and also makes possibly some interesting conceptual changes (and some other changes were not simple and implied good knowledge of the code and decimal internals). There're also a lot of changes such as executing once a function, binding its result in a name and using that name several times later (which effectively reduced the quantity of function calls). And trimmed several "getcontext()" when the only thing that was done was passing context to other function (not used there). The changed decimal was OK in the tests, showing a 14% speed up. I'm +1 to commit the "both" version. Checking the code, I saw some other optimizations, but I don't want to introduce new changes without commiting these first. Nick, congratulations, you certainly made a good work! (btw, don't upload files with spaces in the name) Raymond, do you want to commit the code or should I do it? . Facundo ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-16 07:17 Message: Logged In: YES user_id=1038590 I've separated the performance enhancements out into four different potential patches now: - "_odds_and_ends" - "_is_special" - "_both" (combination of the above two patches) - "_workint" (also incorporates "_both") A single tar.gz file is attached which contains all those in .diff and .py format, as well as a text file detailing the changes made in each patch. All diff's are directly against CVS. test_decimal.py passes cleanly with all four patches. They're listed above in order of increasing degree of change from current CVS. Hopefully I've gotten rid of any doc string changes, and non-performance related code changes (some comments have changed, usually because associated code has changed) The _workint version is the only version which regularly achieves < 20 s wall clock time on my machine for the unit tests and < 60 s for "telco_nofiles.py 10000" (that is, one hundred thousand decimal values). The _both version seems to run around 5 seconds slower on both tests (I am assuming this is due to the fact that _workint speeds up division significantly more than it speeds up addition and multiplication, thus having a much more pronounced effect on the unit tests than on the division-free telco benchmark) Here are the details on the different patches: decimal_odds_and_ends: - cache the result of repeated method calls in: __cmp__ _rescale _check_nans _fix_exponents - use sum() in __nonzero__ - call list.reverse() on preliminary result, not operands in __add__ - avoid redundant _fix_exponents call in _fix - rearrange _fix_exponents to minimise method calls on any given path - remove dead code from end of __int__ decimal_is_special: - convert to use __new__ instead of __init__ - new attribute _is_special is True if value is infinite or NaN - defer invocation of getcontext() as late as possible - make _convert_other a function instead of a method - modify all methods to take advantage of _is_special decimal_both: - combines decimal_is_special & decimal_odds_and_ends decimal_workint: - based on decimal_both - uses a numeric value for _WorkRep.int instead of a list - modifies __new__, __add__ and _divide accordingly - modifies __mul__ to use a _WorkRep (Sorry Raymond, I couldn't quite resist experimenting with borrowing int/long's C level arithmetic implementation!) I'll see about getting some wall-clock numbers for the *actual* million-value telco benchmark with all 5 versions (CVS + the four patches). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-08 18:45 Message: Logged In: YES user_id=1038590 2nd version of patch attached. It does NOT use a subclassing strategy for optimisation due to the following charming little problem I found with that approach: >>> import decimal >>> class foo(decimal.Decimal): pass >>> x = foo("NaN") >>> isinstance(x, foo) False I couldn't find any sane way to get around this, and it seemed to be a showstopper given the amount of work that has gone into making all the builtin types easily subclassable. The new patch instead relies mainly on the following techniques: - defer invocation of getcontext() as late as possible, so that we only call it if the context is going to be referenced - use issubclass(x, basestring) to identify if there are special cases that need handling, then use _is_nan and _is_infinity to determine exactly which special case applies (this slows the special cases down slightly, but speeds up the normal cases a lot) - make _convert_other a helper function instead of a method There are also some other minor changes that were present in the original patch (use sum() in __nonzero__, reduce the number of calls to list.reversed() in __add__, extract digits directly from integer inputs with divmod, rearrange _fixexponents to minimise context method calls, cache results of method calls in various operations) Facundo, two particular changes I'd like you to OK are: - _fix now indents the second call to _fixexponents to be inside the if block (in CVS, _fix_exponents could get called again directly on the result of the previous call to _fix_exponents, which didn't seem to make any sense) - _fixexponents returns immediately for NaN as well as infinite values This version of patch appears to give around a 40% speedup on direct execution of test_decimal.py, and all the tests still pass for me. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-09-07 18:47 Message: Logged In: YES user_id=752496 Nick: Submit the second version of the patch and I'll review it. Also feel free to contact me by mail anytime. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 16:59 Message: Logged In: YES user_id=80475 Glad to hear you've wrapped your head around the sign bit. FWIW, it bugged me too. But it is so closely tied to the spec that it is better to adjust our mental model than change the code. Do extend your optimizations to the other functions. Don't just optimize the benchmark -- that defeats the purpose. Can you work together with Facundo on this one? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-07 16:06 Message: Logged In: YES user_id=1038590 With the _sign/_isneg thing, I figured out the reason it was hurting my brain - I was failing to think of the value as representing a two's complement sign bit. Once I thought of it that way, it made sense with the original terminology. I suspect the lesser speedup on test_decimal.py may be due to the fact that the current version of the patch only optimises the operations used by the telco benchmark (instantiation, addition, multiplication, quantisation). As we speed up other operations, the performance on the unit tests should improve. As far as the API itself goes, the major differences I am aware of are the existence of the new subclass, and the use of __new__ instead of __init__. That will presumably be a bit more work to implement in C since another class is needed. Do we need to document somewhere that Decimal(x) may return an instance of a subclass of Decimal() rather than an instance of Decimal itself? My current plan is to produce a second version of this patch that: 1. Starts again from current CVS 2. Leaves '_sign' alone 3. Leaves existing doc strings alone (I broke a couple of them in this version of patch - I hadn't really thought about how to handle them properly) 4. For overridden methods in the _Special_Value class, duplicate the docstring from the baseclass with "f.__doc__ = Decimal.f.__doc__". This should avoid giving different answers for "help(Decimal(1).__add__)" and "help(Decimal('NaN').__add__)". 5. Optimises all operations, not just the four used by the telco benchmark (with the new strategy in place, this is mostly legwork - cutting and pasting the special-value related stuff to the new subclass, and rearranging appropriately. Unfortunately, it's legwork that I can't see a sensible way to automate, so it's a matter of taking the time to do it, and then checking that the tests all still pass). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-07 00:05 Message: Logged In: YES user_id=80475 Facundo, do you have time to look at this one? We need to: * revert the _isneg variable name change * find out why it gives a 2:1 gain on telco but only 10% on test_decimal.py * make sure the API has not changed in a way that will make it more difficult someday to convert this into C and make it a built-in. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-02 00:18 Message: Logged In: YES user_id=80475 Nice job. The timings do improve and the approach is reasonable. Please go ahead to the next step and polish it up. Also, please change _isneg back to _sign. That matches the terminology in the spec, the machine centric sign bit viewpoint of 754R, and the components of the user visible as_tuple() method. The goal is to make the patch as minimal as possible, to keep the API unchanged, and improve performance. Using the __new__ method was smart. That more closely corresponds to a potential C implementation of an immutable type. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-01 19:11 Message: Logged In: YES user_id=1038590 I forgot to add that this is NOT yet a production quality patch. The doc strings, in particular, need work. I'm mainly posting it so Raymond can have a look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020845&group_id=5470 From noreply at sourceforge.net Sun Sep 19 03:59:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 19 03:59:15 2004 Subject: [Patches] [ python-Patches-1025636 ] Check for NULL returns in compile.c:com_import_stmt Message-ID: Patches item #1025636, was opened at 2004-09-10 02:38 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1025636&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dima Dorfman (ddorfman) >Assigned to: Jeremy Hylton (jhylton) Summary: Check for NULL returns in compile.c:com_import_stmt Initial Comment: com_import_stmt doesn't check for tuple construction being successful. This hasn't been noticed before because it would only happen if we're out of memory, and compiling usually isn't done in the middle of a memory-intensive operation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1025636&group_id=5470 From noreply at sourceforge.net Mon Sep 20 00:41:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 20 00:41:59 2004 Subject: [Patches] [ python-Patches-1024670 ] Error when int sent to PyLong_AsUnsignedLong Message-ID: Patches item #1024670, was opened at 2004-09-08 14:03 Message generated for change (Comment added) made by crnixon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1024670&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Clinton R. Nixon (crnixon) Assigned to: Nobody/Anonymous (nobody) Summary: Error when int sent to PyLong_AsUnsignedLong Initial Comment: When sending a Python integer as an argument to PyLong_AsUnsignedLong, the following error occurs SystemError: Objects/longobject.c:240: bad argument to internal function This error comes from the fact that PyLong_AsUnsignedLong, unlike PyLong_AsLong, does not check to see if the number is a long or integer, but only a long. This patch checks to see if the number is an integer, and if so, calls PyInt_AsUnsignedLongMask. ---------------------------------------------------------------------- >Comment By: Clinton R. Nixon (crnixon) Date: 2004-09-19 15:41 Message: Logged In: YES user_id=350049 The reasons I submitted the patch: * There's a precedent in the PyLong_AsLong code. * The error was causing PyCDK (Python binding to the Curses Development Kit) to segfault. * Seeing as there's no data lost converting from int to long, it makes sense to go ahead and convert instead of crapping out. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-18 09:11 Message: Logged In: YES user_id=21627 Why is it desirable to accept ints in PyLong_AsUnsignedLong? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1024670&group_id=5470 From noreply at sourceforge.net Mon Sep 20 08:18:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 20 08:18:27 2004 Subject: [Patches] [ python-Patches-1024670 ] Error when int sent to PyLong_AsUnsignedLong Message-ID: Patches item #1024670, was opened at 2004-09-08 23:03 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1024670&group_id=5470 Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Clinton R. Nixon (crnixon) Assigned to: Nobody/Anonymous (nobody) Summary: Error when int sent to PyLong_AsUnsignedLong Initial Comment: When sending a Python integer as an argument to PyLong_AsUnsignedLong, the following error occurs SystemError: Objects/longobject.c:240: bad argument to internal function This error comes from the fact that PyLong_AsUnsignedLong, unlike PyLong_AsLong, does not check to see if the number is a long or integer, but only a long. This patch checks to see if the number is an integer, and if so, calls PyInt_AsUnsignedLongMask. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-09-20 08:18 Message: Logged In: YES user_id=21627 I see. The precedent of PyLong_AsLong is a good rationale. However, your patch is incorrect: It would return a value for negative integers, whereas it should raise an OverflowError in this case. I have committed a different patch as longobject.c 1.165, NEWS 1.1138, which also adds the same extension to PyLong_AsUnsignedLongMask. ---------------------------------------------------------------------- Comment By: Clinton R. Nixon (crnixon) Date: 2004-09-20 00:41 Message: Logged In: YES user_id=350049 The reasons I submitted the patch: * There's a precedent in the PyLong_AsLong code. * The error was causing PyCDK (Python binding to the Curses Development Kit) to segfault. * Seeing as there's no data lost converting from int to long, it makes sense to go ahead and convert instead of crapping out. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-18 18:11 Message: Logged In: YES user_id=21627 Why is it desirable to accept ints in PyLong_AsUnsignedLong? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1024670&group_id=5470 From noreply at sourceforge.net Mon Sep 20 15:37:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 20 15:37:33 2004 Subject: [Patches] [ python-Patches-1031213 ] Patch for bug #780725 Message-ID: Patches item #1031213, was opened at 2004-09-20 22:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031213&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for bug #780725 Initial Comment: When SyntaxError occurs and the module contains source encodings definition, current implementation prints error line in UTF8. This patch reverts the line into original encoding for printing. This patch calls some memory-allocation APIs such as PyUnicode_DecodeUTF8. I'm not sure I can (or should) call PyErr_Clear() here if error happened. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031213&group_id=5470 From noreply at sourceforge.net Mon Sep 20 16:14:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 20 16:14:23 2004 Subject: [Patches] [ python-Patches-1031233 ] Clean up discussion of new C thread idiom Message-ID: Patches item #1031233, was opened at 2004-09-20 06:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031233&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Clean up discussion of new C thread idiom Initial Comment: In init.tex, the code for the typical idiom for C threads now uses the PyGILState functions. However the preceeding discussion still refers to the need to acquire an interpreter state, etc. Attached is a patch which tries to clean this up a little. I removed the paragraph about interpreter states (which raises the possibility of creating a new interpreter state) since multiple interpreter states are, I believe, incompatible (or at least untested) with PyGILState. It's possible that more of PEP 311 should be included here, particularly the part about having to call PyEval_InitThreads on the main thread before using any of the thread APIs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031233&group_id=5470 From noreply at sourceforge.net Tue Sep 21 07:56:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 21 07:56:13 2004 Subject: [Patches] [ python-Patches-1031687 ] atexit decorator Message-ID: Patches item #1031687, was opened at 2004-09-21 00:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031687&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: atexit decorator Initial Comment: Add an obvious decorator to the atexit module: @atexit(arg1, arg2) def myexitfunc(arg1, arg2): . . . If accepted, docs and tests forthcoming. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031687&group_id=5470 From noreply at sourceforge.net Tue Sep 21 07:58:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 21 07:58:49 2004 Subject: [Patches] [ python-Patches-1025636 ] Check for NULL returns in compile.c:com_import_stmt Message-ID: Patches item #1025636, was opened at 2004-09-10 02:38 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1025636&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Dima Dorfman (ddorfman) Assigned to: Jeremy Hylton (jhylton) Summary: Check for NULL returns in compile.c:com_import_stmt Initial Comment: com_import_stmt doesn't check for tuple construction being successful. This hasn't been noticed before because it would only happen if we're out of memory, and compiling usually isn't done in the middle of a memory-intensive operation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1025636&group_id=5470 From noreply at sourceforge.net Wed Sep 22 00:07:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 00:07:36 2004 Subject: [Patches] [ python-Patches-1032206 ] Add API to logging package to allow intercooperation. Message-ID: Patches item #1032206, was opened at 2004-09-21 22:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1032206&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dave Wilson (dmw) Assigned to: Nobody/Anonymous (nobody) Summary: Add API to logging package to allow intercooperation. Initial Comment: This set of patches implements two simple ways in which the logging package could be extended to allow more than one body of code to customize the base Logger class. The first patch (and doc patch) implements a "getLoggerClass()" function symmentrical to the existing "setLoggerClass()" function. The second patch instead renames the internal "_loggerClass" variable to "loggerClass", leaving the old setLoggerClass() function for compatibility. The problem with the logging module at present is that if I wish to define extra functionality in the Logger class for use with my application or package, and another package that I make use of does the same, then one set of Logger class customisations will be lost. Using the above patches, the standard way to extend Logger would go from: class MyLogger(logging.Logger): ... to: class MyLogger(logging.getLoggerClass()): ... or alternatively for the second patch: class MyLogger(logging.loggerClass): ... Thanks, David. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1032206&group_id=5470 From noreply at sourceforge.net Wed Sep 22 15:40:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 15:40:16 2004 Subject: [Patches] [ python-Patches-1032206 ] Add API to logging package to allow intercooperation. Message-ID: Patches item #1032206, was opened at 2004-09-21 22:07 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1032206&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dave Wilson (dmw) >Assigned to: Vinay Sajip (vsajip) Summary: Add API to logging package to allow intercooperation. Initial Comment: This set of patches implements two simple ways in which the logging package could be extended to allow more than one body of code to customize the base Logger class. The first patch (and doc patch) implements a "getLoggerClass()" function symmentrical to the existing "setLoggerClass()" function. The second patch instead renames the internal "_loggerClass" variable to "loggerClass", leaving the old setLoggerClass() function for compatibility. The problem with the logging module at present is that if I wish to define extra functionality in the Logger class for use with my application or package, and another package that I make use of does the same, then one set of Logger class customisations will be lost. Using the above patches, the standard way to extend Logger would go from: class MyLogger(logging.Logger): ... to: class MyLogger(logging.getLoggerClass()): ... or alternatively for the second patch: class MyLogger(logging.loggerClass): ... Thanks, David. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2004-09-22 13:40 Message: Logged In: YES user_id=308438 getLogger() version checked into CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1032206&group_id=5470 From noreply at sourceforge.net Wed Sep 22 20:36:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 20:36:38 2004 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-09-22 20:36 Message: Logged In: YES user_id=89016 test_unpack_doctest.py looks good. Please check it in (as test_unpack.py) ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-08 17:37 Message: Logged In: YES user_id=469548 Yeah, bug #1023798 reported that and Brett fixed it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-09-07 22:34 Message: Logged In: YES user_id=89016 I'm getting the following error from the new test__locale: test test__locale failed -- Traceback (most recent call last): File "/home/walter/Achtung/Python-codec- small/dist/src/Lib/test/test__locale.py", line 37, in test_lc_numeric "%r != %r (%s); " File "/home/walter/Achtung/Python-codec- small/dist/src/Lib/locale.py", line 363, in getlocale return _parse_localename(localename) File "/home/walter/Achtung/Python-codec- small/dist/src/Lib/locale.py", line 278, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: lv_LV BTW, could someone have a look at Johannes' test_doctest and test_inspect patches? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-09-07 04:32 Message: Logged In: YES user_id=357491 OK, test__locale has been checked in. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-30 13:00 Message: Logged In: YES user_id=469548 Brett: that's just one of the drawbacks of doing data-driven testing with unittest. I don't think it's terribly important, so the test is OK to me. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-27 05:44 Message: Logged In: YES user_id=357491 Just attached a new version of test__locale. Since it is so small of a file and the change so drastic I just uploaded the whole file. Only drawback is before the test kept testing all locales when there was a failure while my implementation stops at the first failure discovered. Don't know if it is important to test all locales. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-24 18:59 Message: Logged In: YES user_id=80475 Walter, I'm afraid I don't have time for these right now. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-08-20 18:39 Message: Logged In: YES user_id=89016 Raymond, can you take a look at the patches? ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-20 17:06 Message: Logged In: YES user_id=469548 Another one: ported test_inspect to unittest and moved out the inspect fodder out into two modules instead of using the ugly imp.load_source and TESTFN. I also did a bit of rearrangement so that the TestCase classes mostly match the sections in the library docs. I used a separate module (inspect_fodder2) and class for the decorators tests. Those are kind of small now, but I'll check in http://python.org/sf/1011890 after this port and let it grow without having to update test_getfunctions(). ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-19 17:14 Message: Logged In: YES user_id=469548 Hum yes, that was me trying out how doctest fails. The expected outcome should have been True. Can you try the corrected version? Test_zipfile has been checked in as rev 1.11. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-08-18 21:29 Message: Logged In: YES user_id=89016 doctest tests should be OK. The error tests in test_unpack can be done with PyUnit too, you either use self.assertRaises(ValueError, eval, "a,b = Seq()") or try: a,b = Seq() except ValueError: pass else: self.fail("failed") test_zipfile_unittest.py looks OK, but should of course be named test_zipfile.py when you check it in. test_unpack_doctest.py gives me: ********************************************** ************************ Failure in example: a == 4 and b == 5 and c == 6 from line #14 of test.test_unpack_doctest.doctests in /home/walter/Achtung/Python- test/dist/src/Lib/test/test_unpack_doctest.pyc Expected: False Got: True ********************************************** ************************ 1 items had failures: 1 of 28 in test.test_unpack_doctest.doctests ***Test Failed*** 1 failures. Traceback (most recent call last): File "Lib/test/test_unpack_doctest.py", line 133, in ? test_main(verbose=True) File "Lib/test/test_unpack_doctest.py", line 130, in test_main test_support.run_doctest(test_unpack_doctest, verbose) File "/home/walter/Achtung/Python- test/dist/src/Lib/test/test_support.py", line 318, in run_doctest raise TestFailed("%d of %d doctests failed" % (f, t)) test.test_support.TestFailed: 1 of 28 doctests failed ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-18 15:23 Message: Logged In: YES user_id=469548 Is there any problem with porting test scripts to doctest instead of unittest? doctest is just perfect for test_unpack (doctest version attached). I've also ported test_zipfile to unittest (attached as well). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-31 18:31 Message: Logged In: YES user_id=89016 OK, checked in as: Lib/test/mapping_tests.py 1.1 Lib/test/test_os.py 1.22 Lib/test/test_shelve.py 1.7 Lib/test/test_types.py 1.60 Lib/test/test_userdict.py 1.19 Lib/test/test_weakref.py 1.39 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-29 01:02 Message: Logged In: YES user_id=80475 Looks good. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-28 22:59 Message: Logged In: YES user_id=89016 OK, I've updated the docstring for dict.update() (Object/dictobject.c 2.160) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-27 21:04 Message: Logged In: YES user_id=89016 dict_diff.txt is a patch that tries to share tests between test_dict, test_userdict, test_os, test_shelve and test_weakref. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-25 22:29 Message: Logged In: YES user_id=31435 Don't really care myself. Would be nice if the docstring for dict.update() matched the new realities, though . BTW, there is a reliable and conventional way to detect whether the 'dict' argument was passed to UserDict.update: use a unique marker object instead of the universally visible None. Like _marker = object() at module level, and ...(self, dict=_marker, ...) in the method defn. That can't be fooled without deliberate intent to deceive. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-25 22:21 Message: Logged In: YES user_id=80475 IMO, it is fine as is. I would be suprised if some code were relying on UserDict.update(None) raising an exception. This sort of thing also comes up also in places like the string and random modules whereever a function or method with an optional argument gets wrapped by another function. The only way around this is to use *args and then you break code that used the unfortunately named "dict" argument as a keyword. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-25 21:32 Message: Logged In: YES user_id=89016 Merging test_dict and test_userdict revealed a difference between dict and UserDict.UserDict: >>> import UserDict >>> d = UserDict.UserDict() >>> d.update(None) >>> d {} >>> d = {} >>> d.update(None) Traceback (most recent call last): File "", line 1, in ? TypeError: iteration over non-sequence Should we do anything about this? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-20 18:03 Message: Logged In: YES user_id=80475 test_dict is fine. Consider beefing up the tests for update(). As of Py2.4, it now takes all the same argument possibilites as dict(): d.update(a=1, b=2) d.update([('a', 1), ('b', 2)]) Also, try to link in: from test_userdict import TestMappingProtocol This was supposed to provide tests common to all mappings. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-04-03 13:06 Message: Logged In: YES user_id=89016 The attached test_dict.py moves the dict tests from test_types.py to a new PyUnit test script. Code coverage for dictobject.c is at 90.76% (up from 89.51%) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-03-15 13:17 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_binascii delete Lib/test/test_binascii.py 1.17 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-03-13 21:26 Message: Logged In: YES user_id=80475 Okay, this one is fine. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-19 00:49 Message: Logged In: YES user_id=89016 Here's the next one: test_binascii.py. Code coverage in binascii.c is at 92% (could be improved by enhancing test_binhex.py). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-13 23:46 Message: Logged In: YES user_id=33168 Looked good to me, test_future_pyunit.diff checked in as: * Lib/test/badsyntax_future3.py 1.2 * Lib/test/badsyntax_future4.py 1.2 * Lib/test/badsyntax_future5.py 1.2 * Lib/test/badsyntax_future6.py 1.2 * Lib/test/badsyntax_future7.py 1.2 * Lib/test/badsyntax_future8.py 1.1 * Lib/test/badsyntax_future9.py 1.1 * Lib/test/test_future.py 1.7 * Lib/test/test_future1.py 1.3 * Lib/test/test_future2.py 1.2 * Lib/test/output/test_future 1.4 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-13 22:47 Message: Logged In: YES user_id=33168 Walter, I didn't get a mail from SF either. After you do a cvs add, you need to use -N to cvs diff. For example, cvs diff -N new_file_added_to_cvs_but_not_committed. If you look carefully, you can see this in the patch on the diff line for each file. I'll take a look at the patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-13 21:18 Message: Logged In: YES user_id=89016 Here is a version of test_future ported to PyUnit (test_future_pyunit.diff). If this makes sense to you Neal, please check it in. (BTW, how did you convince CVS to include badsyntax_future8.py and badsyntax_future9.py in the diff? Doing a "cvs add" only results in " Lib/test/badsyntax_future8.py is a new entry, no comparison available") ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-11 13:36 Message: Logged In: YES user_id=89016 md5/weakref patch checked in as: Lib/test/test_weakref.py 1.33 Lib/test/test_md5.py 1.5 Lib/test/output/test_md5 remove ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 07:05 Message: Logged In: YES user_id=33168 Improve coverage for test_future too. I'm not sure if test future can be ported to PyUnit. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 06:52 Message: Logged In: YES user_id=33168 Attached are two tests (in one file, I'm being lazy, sorry) to improve test coverage for md5c.c and _weakref.c. test_md5 was ported to unittest, weakref, just adds two little tests to get coverage up to 100%. If you like, just go ahead and check in. You will need to remove Lib/test/output/test_md5 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-08 12:42 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/list_tests.py 1.1 Lib/test/seq_tests.py 1.1 Lib/test/test_list.py 1.1 Lib/test/test_tuple.py 1.1 Lib/test/test_types.py 1.56 Lib/test/test_userlist.py 1.11 Lib/test/output/test_types 1.3 Next will be test_binascii.py before I continue with test_types.py. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-08 00:49 Message: Logged In: YES user_id=80475 Looks good. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-11-27 20:48 Message: Logged In: YES user_id=89016 Here the first part of the test_types port: list and tuple tests have been moved to their own scripts: test_tuple.py and test_list.py. Common tests for tuple, list and UserList are shared (in seq_test.py and list_test.py) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-02 03:53 Message: Logged In: YES user_id=80475 Applied as: Lib/test/test_slice.py 1.5. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 01:52 Message: Logged In: YES user_id=80475 Looks good. I added a couple of minor tests. Revised patch attached. Okay to apply. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-31 21:49 Message: Logged In: YES user_id=89016 Thanks! Here's another one: test_slice.py ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 01:04 Message: Logged In: YES user_id=80475 Done. See: Lib/test/test_longexp.py 1.9; previous revision: 1.8 Lib/test/test_pep263.py 1.3; previous revision: 1.2 Lib/test/test_sets.py 1.27; previous revision: 1.26 Lib/test/test_structseq.py 1.5; previous revision: 1.4 Lib/test/output/test_longexp delete; previous revision: 1.3 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 19:10 Message: Logged In: YES user_id=80475 Will do! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-30 19:06 Message: Logged In: YES user_id=89016 Here's test_structse.py converted with a few additional tests. If all three scripts are OK, could you check them in Raymond, as I'll be on vacation for three weeks? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-09 17:47 Message: Logged In: YES user_id=89016 Here are two simple ones: test_pep263 and test_longexp. I can't think of any additional tests to add. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-23 15:38 Message: Logged In: YES user_id=80475 Fixed Walter's review comments and committed as Lib/test/test_compile.py 1.19 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-23 13:49 Message: Logged In: YES user_id=89016 Are you sure, that the code path is the same in the new test_argument_handling() as in the old test? I.e. is "eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"? The print statement in test_float_literals should be changed to a comment. Should the imports in test_unary_minus() be moved to the start of the script? Otherwise the test looks (and runs) OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 21:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-19 11:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 21:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-18 16:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 01:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 23:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 14:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 23:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 21:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 21:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 20:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 20:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 18:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 14:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 17:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 15:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-19 01:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 05:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 04:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 03:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 02:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 01:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply at sourceforge.net Thu Sep 23 05:45:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 23 05:45:13 2004 Subject: [Patches] [ python-Patches-896011 ] pdb enhancements and bug fixes Message-ID: Patches item #896011, was opened at 2004-02-12 12:07 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=896011&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: pdb enhancements and bug fixes Initial Comment: Bug fixes B1) Execute script in its own namespace (script was executed in pdb.py name space. E.g one could do print line_prefix in your script and one would get pdb's line_prefix variable (and I guess if was possible to accidentally stomp on pdb internals from the script)) B2) Remove pdb.py's path from sys.path. (pdb.py path was not removed from sys.path.. While normally this is not a problem, it CAN cause hard to diagnose problems. e.g. if your script needs to override some of std modules and you put them in some location and set PYTHONPATH accordingly, then everything works without pdb, but when you run under pdb (which is normally located with the rest of python std libs) your overriding suddenly breaks) This addresses CVS Bug report #751124, part 2 B3) Fix handling of breakpoints "file_name:line_no" (pdb was failing to set the breakpoint specified as "b file_name:100" when file_name did not end with ".py", and was not an absolute path.This is quite bad as many scripts commonly do not have ".py" suffix... In at least some cases, (e.g when running under emacs gud) user can't workaround this problem, as the "break" command is issued by another program..) Enhancements: E1) Now pdb gets directly to the 1st line of script (the CVS version of pdb required doing "step" twice before you get to the first line of your code: both ugly and annoying) E2) Restart the program (and preserve debugger state, such as breakpoints) if program being debugged exits (CVS version was exitting on program's exitNow debugger does not die on script's exit, taking all the settings with it) E3) Enter post-mortem debugging if the program throws an uncaught exception (CVS version was simply dying in this case This addresses CVS bug report #751124, part 1) All changes apply to the command line interface of pdb.py Ie. only when pdb.py invoked as "pdb.py script" The only exception is B3 which fixes a bug in do_break() ---------------------------------------------------------------------- >Comment By: Ilya Sandler (isandler) Date: 2004-09-22 20:45 Message: Logged In: YES user_id=971153 Another iteration of the patch 1. Allow to set bkpts while in post-mortem debuggin (which now happens in the same instance of pdb) 2. Against latest pdb.py (1.69) ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-03-05 11:28 Message: Logged In: YES user_id=971153 I am attaching a new version of the patch. Changes include: 1) the new patch is against the latest pdb.py v 1.67 2) it allows to debug code protected by if __name__== '__main__' conditional (the first version of the patch did not set __name__, so this code was not reachable).... Also, is there anything I can do to help with consideration of this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=896011&group_id=5470 From noreply at sourceforge.net Thu Sep 23 14:13:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 23 14:13:50 2004 Subject: [Patches] [ python-Patches-1031233 ] Clean up discussion of new C thread idiom Message-ID: Patches item #1031233, was opened at 2004-09-20 06:14 Message generated for change (Comment added) made by glchapman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031233&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Clean up discussion of new C thread idiom Initial Comment: In init.tex, the code for the typical idiom for C threads now uses the PyGILState functions. However the preceeding discussion still refers to the need to acquire an interpreter state, etc. Attached is a patch which tries to clean this up a little. I removed the paragraph about interpreter states (which raises the possibility of creating a new interpreter state) since multiple interpreter states are, I believe, incompatible (or at least untested) with PyGILState. It's possible that more of PEP 311 should be included here, particularly the part about having to call PyEval_InitThreads on the main thread before using any of the thread APIs. ---------------------------------------------------------------------- >Comment By: Greg Chapman (glchapman) Date: 2004-09-23 04:13 Message: Logged In: YES user_id=86307 Changed my added text to refer to Py_NewInterpreter, rather than PyInterpreterState_New. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031233&group_id=5470 From noreply at sourceforge.net Fri Sep 24 16:08:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 24 16:08:22 2004 Subject: [Patches] [ python-Patches-1034053 ] unittest.py patch: add skipped test functionality Message-ID: Patches item #1034053, was opened at 2004-09-24 16:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Remy Blank (remyblank) Assigned to: Nobody/Anonymous (nobody) Summary: unittest.py patch: add skipped test functionality Initial Comment: I added the possibility for tests using the unittest.py framework to be skipped. Basically, I added two methods to TestCase: TestCase.skip(msg): skips test unconditionally TestCase.skipIf(expr, msg): skips test if expr is true These can be called either in setUp() or in the test methods. I also added reporting of skipped tests to TestResult, _TextTestResult and TextTestRunner. If no tests are skipped, everything should be the same as before. I am using Python 2.3.3, so the changes are against the file in that version. I can generate a patch for a more recent version if desired. I attached the patch against the original (unittest_skip.patch). I can provide a complete test suite for the new functionality and a usage example program. Quick usage example: class ReadShadowTest(unittest.TestCase): """Read access to /etc/shadow""" def testReadingAsRoot(self): """Reading /etc/shadow as root""" self.skipIf(os.geteuid() != 0, "Must be root") open("/etc/shadow").close() The example program produces the following output: $ ./SkippedTestDemo.py -v Access to autoexec.bat ... SKIPPED (Only available on Windows) Access to config.sys ... SKIPPED (Only available on Windows) Reading /etc/shadow as root ... SKIPPED (Must be root) Reading /etc/shadow as non-root ... ok ------------------------------------------------------- --------------- Ran 4 tests in 0.004s OK (skipped=3) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 From noreply at sourceforge.net Fri Sep 24 18:48:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 24 18:48:48 2004 Subject: [Patches] [ python-Patches-1012468 ] Rational.py various bugfixes Message-ID: Patches item #1012468, was opened at 2004-08-19 16:20 Message generated for change (Comment added) made by russblau You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1012468&group_id=5470 Category: Demos and tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Blau (russblau) Assigned to: Nobody/Anonymous (nobody) Summary: Rational.py various bugfixes Initial Comment: Rational.py in the sandbox (python/python/nondist/sandbox/rational/Rational.py) contains a variety of minor (and not-so-minor) bugs, and some doctest errors as a result of changes introduced in recent Python versions. A corrected version (that works for me) is attached. ---------------------------------------------------------------------- >Comment By: Russell Blau (russblau) Date: 2004-09-24 12:48 Message: Logged In: YES user_id=855050 I have now uploaded a context diff. As for the doctest errors: my limited investigation suggests that the manner in which Python prints float values in "scientific" notation is platform-dependent; on Windows, the exponent will always contain 3 digits, while on Linux, leading zeros in the exponent are suppressed. If this is the case, then a doctest string containing output of this type of value will *always* fail for some users. I am not sure what to do about this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-09-18 11:32 Message: Logged In: YES user_id=21627 Please submit patches as unified or context diffs. The file you have attached fails for me as well, I get ********************************************************************** File "/tmp/Rational.py", line 115, in Rational Failed example: float(p.trim(1L<<32)-p) Expected: -7.3974359428840768e-020 Got: -7.3974359428840768e-20 ********************************************************************** File "/tmp/Rational.py", line 126, in Rational Failed example: float(p.approximate(rational(1L)>>32)-p) Expected: 1.3733999215941832e-011 Got: 1.3733999215941832e-11 ********************************************************************** I have now untabified Rational.py, please use that as a starting point for further changes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1012468&group_id=5470 From noreply at sourceforge.net Fri Sep 24 23:42:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 24 23:42:21 2004 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) >Assigned to: Nobody/Anonymous (nobody) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-24 23:42 Message: Logged In: YES user_id=469548 Checked in as rev 1.8 of test_unpack.py. Thanks for the review! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-09-22 20:36 Message: Logged In: YES user_id=89016 test_unpack_doctest.py looks good. Please check it in (as test_unpack.py) ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-09-08 17:37 Message: Logged In: YES user_id=469548 Yeah, bug #1023798 reported that and Brett fixed it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-09-07 22:34 Message: Logged In: YES user_id=89016 I'm getting the following error from the new test__locale: test test__locale failed -- Traceback (most recent call last): File "/home/walter/Achtung/Python-codec- small/dist/src/Lib/test/test__locale.py", line 37, in test_lc_numeric "%r != %r (%s); " File "/home/walter/Achtung/Python-codec- small/dist/src/Lib/locale.py", line 363, in getlocale return _parse_localename(localename) File "/home/walter/Achtung/Python-codec- small/dist/src/Lib/locale.py", line 278, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: lv_LV BTW, could someone have a look at Johannes' test_doctest and test_inspect patches? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-09-07 04:32 Message: Logged In: YES user_id=357491 OK, test__locale has been checked in. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-30 13:00 Message: Logged In: YES user_id=469548 Brett: that's just one of the drawbacks of doing data-driven testing with unittest. I don't think it's terribly important, so the test is OK to me. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-27 05:44 Message: Logged In: YES user_id=357491 Just attached a new version of test__locale. Since it is so small of a file and the change so drastic I just uploaded the whole file. Only drawback is before the test kept testing all locales when there was a failure while my implementation stops at the first failure discovered. Don't know if it is important to test all locales. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-24 18:59 Message: Logged In: YES user_id=80475 Walter, I'm afraid I don't have time for these right now. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-08-20 18:39 Message: Logged In: YES user_id=89016 Raymond, can you take a look at the patches? ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-20 17:06 Message: Logged In: YES user_id=469548 Another one: ported test_inspect to unittest and moved out the inspect fodder out into two modules instead of using the ugly imp.load_source and TESTFN. I also did a bit of rearrangement so that the TestCase classes mostly match the sections in the library docs. I used a separate module (inspect_fodder2) and class for the decorators tests. Those are kind of small now, but I'll check in http://python.org/sf/1011890 after this port and let it grow without having to update test_getfunctions(). ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-19 17:14 Message: Logged In: YES user_id=469548 Hum yes, that was me trying out how doctest fails. The expected outcome should have been True. Can you try the corrected version? Test_zipfile has been checked in as rev 1.11. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-08-18 21:29 Message: Logged In: YES user_id=89016 doctest tests should be OK. The error tests in test_unpack can be done with PyUnit too, you either use self.assertRaises(ValueError, eval, "a,b = Seq()") or try: a,b = Seq() except ValueError: pass else: self.fail("failed") test_zipfile_unittest.py looks OK, but should of course be named test_zipfile.py when you check it in. test_unpack_doctest.py gives me: ********************************************** ************************ Failure in example: a == 4 and b == 5 and c == 6 from line #14 of test.test_unpack_doctest.doctests in /home/walter/Achtung/Python- test/dist/src/Lib/test/test_unpack_doctest.pyc Expected: False Got: True ********************************************** ************************ 1 items had failures: 1 of 28 in test.test_unpack_doctest.doctests ***Test Failed*** 1 failures. Traceback (most recent call last): File "Lib/test/test_unpack_doctest.py", line 133, in ? test_main(verbose=True) File "Lib/test/test_unpack_doctest.py", line 130, in test_main test_support.run_doctest(test_unpack_doctest, verbose) File "/home/walter/Achtung/Python- test/dist/src/Lib/test/test_support.py", line 318, in run_doctest raise TestFailed("%d of %d doctests failed" % (f, t)) test.test_support.TestFailed: 1 of 28 doctests failed ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-18 15:23 Message: Logged In: YES user_id=469548 Is there any problem with porting test scripts to doctest instead of unittest? doctest is just perfect for test_unpack (doctest version attached). I've also ported test_zipfile to unittest (attached as well). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-31 18:31 Message: Logged In: YES user_id=89016 OK, checked in as: Lib/test/mapping_tests.py 1.1 Lib/test/test_os.py 1.22 Lib/test/test_shelve.py 1.7 Lib/test/test_types.py 1.60 Lib/test/test_userdict.py 1.19 Lib/test/test_weakref.py 1.39 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-29 01:02 Message: Logged In: YES user_id=80475 Looks good. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-28 22:59 Message: Logged In: YES user_id=89016 OK, I've updated the docstring for dict.update() (Object/dictobject.c 2.160) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-27 21:04 Message: Logged In: YES user_id=89016 dict_diff.txt is a patch that tries to share tests between test_dict, test_userdict, test_os, test_shelve and test_weakref. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-05-25 22:29 Message: Logged In: YES user_id=31435 Don't really care myself. Would be nice if the docstring for dict.update() matched the new realities, though . BTW, there is a reliable and conventional way to detect whether the 'dict' argument was passed to UserDict.update: use a unique marker object instead of the universally visible None. Like _marker = object() at module level, and ...(self, dict=_marker, ...) in the method defn. That can't be fooled without deliberate intent to deceive. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-25 22:21 Message: Logged In: YES user_id=80475 IMO, it is fine as is. I would be suprised if some code were relying on UserDict.update(None) raising an exception. This sort of thing also comes up also in places like the string and random modules whereever a function or method with an optional argument gets wrapped by another function. The only way around this is to use *args and then you break code that used the unfortunately named "dict" argument as a keyword. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-05-25 21:32 Message: Logged In: YES user_id=89016 Merging test_dict and test_userdict revealed a difference between dict and UserDict.UserDict: >>> import UserDict >>> d = UserDict.UserDict() >>> d.update(None) >>> d {} >>> d = {} >>> d.update(None) Traceback (most recent call last): File "", line 1, in ? TypeError: iteration over non-sequence Should we do anything about this? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-20 18:03 Message: Logged In: YES user_id=80475 test_dict is fine. Consider beefing up the tests for update(). As of Py2.4, it now takes all the same argument possibilites as dict(): d.update(a=1, b=2) d.update([('a', 1), ('b', 2)]) Also, try to link in: from test_userdict import TestMappingProtocol This was supposed to provide tests common to all mappings. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-04-03 13:06 Message: Logged In: YES user_id=89016 The attached test_dict.py moves the dict tests from test_types.py to a new PyUnit test script. Code coverage for dictobject.c is at 90.76% (up from 89.51%) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-03-15 13:17 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_binascii delete Lib/test/test_binascii.py 1.17 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-03-13 21:26 Message: Logged In: YES user_id=80475 Okay, this one is fine. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-19 00:49 Message: Logged In: YES user_id=89016 Here's the next one: test_binascii.py. Code coverage in binascii.c is at 92% (could be improved by enhancing test_binhex.py). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-13 23:46 Message: Logged In: YES user_id=33168 Looked good to me, test_future_pyunit.diff checked in as: * Lib/test/badsyntax_future3.py 1.2 * Lib/test/badsyntax_future4.py 1.2 * Lib/test/badsyntax_future5.py 1.2 * Lib/test/badsyntax_future6.py 1.2 * Lib/test/badsyntax_future7.py 1.2 * Lib/test/badsyntax_future8.py 1.1 * Lib/test/badsyntax_future9.py 1.1 * Lib/test/test_future.py 1.7 * Lib/test/test_future1.py 1.3 * Lib/test/test_future2.py 1.2 * Lib/test/output/test_future 1.4 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-13 22:47 Message: Logged In: YES user_id=33168 Walter, I didn't get a mail from SF either. After you do a cvs add, you need to use -N to cvs diff. For example, cvs diff -N new_file_added_to_cvs_but_not_committed. If you look carefully, you can see this in the patch on the diff line for each file. I'll take a look at the patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-13 21:18 Message: Logged In: YES user_id=89016 Here is a version of test_future ported to PyUnit (test_future_pyunit.diff). If this makes sense to you Neal, please check it in. (BTW, how did you convince CVS to include badsyntax_future8.py and badsyntax_future9.py in the diff? Doing a "cvs add" only results in " Lib/test/badsyntax_future8.py is a new entry, no comparison available") ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-11 13:36 Message: Logged In: YES user_id=89016 md5/weakref patch checked in as: Lib/test/test_weakref.py 1.33 Lib/test/test_md5.py 1.5 Lib/test/output/test_md5 remove ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 07:05 Message: Logged In: YES user_id=33168 Improve coverage for test_future too. I'm not sure if test future can be ported to PyUnit. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 06:52 Message: Logged In: YES user_id=33168 Attached are two tests (in one file, I'm being lazy, sorry) to improve test coverage for md5c.c and _weakref.c. test_md5 was ported to unittest, weakref, just adds two little tests to get coverage up to 100%. If you like, just go ahead and check in. You will need to remove Lib/test/output/test_md5 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-08 12:42 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/list_tests.py 1.1 Lib/test/seq_tests.py 1.1 Lib/test/test_list.py 1.1 Lib/test/test_tuple.py 1.1 Lib/test/test_types.py 1.56 Lib/test/test_userlist.py 1.11 Lib/test/output/test_types 1.3 Next will be test_binascii.py before I continue with test_types.py. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-08 00:49 Message: Logged In: YES user_id=80475 Looks good. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-11-27 20:48 Message: Logged In: YES user_id=89016 Here the first part of the test_types port: list and tuple tests have been moved to their own scripts: test_tuple.py and test_list.py. Common tests for tuple, list and UserList are shared (in seq_test.py and list_test.py) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-02 03:53 Message: Logged In: YES user_id=80475 Applied as: Lib/test/test_slice.py 1.5. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 01:52 Message: Logged In: YES user_id=80475 Looks good. I added a couple of minor tests. Revised patch attached. Okay to apply. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-31 21:49 Message: Logged In: YES user_id=89016 Thanks! Here's another one: test_slice.py ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 01:04 Message: Logged In: YES user_id=80475 Done. See: Lib/test/test_longexp.py 1.9; previous revision: 1.8 Lib/test/test_pep263.py 1.3; previous revision: 1.2 Lib/test/test_sets.py 1.27; previous revision: 1.26 Lib/test/test_structseq.py 1.5; previous revision: 1.4 Lib/test/output/test_longexp delete; previous revision: 1.3 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 19:10 Message: Logged In: YES user_id=80475 Will do! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-30 19:06 Message: Logged In: YES user_id=89016 Here's test_structse.py converted with a few additional tests. If all three scripts are OK, could you check them in Raymond, as I'll be on vacation for three weeks? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-09 17:47 Message: Logged In: YES user_id=89016 Here are two simple ones: test_pep263 and test_longexp. I can't think of any additional tests to add. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-23 15:38 Message: Logged In: YES user_id=80475 Fixed Walter's review comments and committed as Lib/test/test_compile.py 1.19 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-23 13:49 Message: Logged In: YES user_id=89016 Are you sure, that the code path is the same in the new test_argument_handling() as in the old test? I.e. is "eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"? The print statement in test_float_literals should be changed to a comment. Should the imports in test_unary_minus() be moved to the start of the script? Otherwise the test looks (and runs) OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 21:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-19 11:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 21:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-18 16:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 01:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 23:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 14:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 23:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 21:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 21:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 20:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 20:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 18:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 14:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 17:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 15:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-19 01:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 05:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 04:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 03:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 02:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 01:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply at sourceforge.net Sat Sep 25 10:18:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 25 10:18:13 2004 Subject: [Patches] [ python-Patches-1034053 ] unittest.py patch: add skipped test functionality Message-ID: Patches item #1034053, was opened at 2004-09-24 09:08 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Remy Blank (remyblank) Assigned to: Nobody/Anonymous (nobody) Summary: unittest.py patch: add skipped test functionality Initial Comment: I added the possibility for tests using the unittest.py framework to be skipped. Basically, I added two methods to TestCase: TestCase.skip(msg): skips test unconditionally TestCase.skipIf(expr, msg): skips test if expr is true These can be called either in setUp() or in the test methods. I also added reporting of skipped tests to TestResult, _TextTestResult and TextTestRunner. If no tests are skipped, everything should be the same as before. I am using Python 2.3.3, so the changes are against the file in that version. I can generate a patch for a more recent version if desired. I attached the patch against the original (unittest_skip.patch). I can provide a complete test suite for the new functionality and a usage example program. Quick usage example: class ReadShadowTest(unittest.TestCase): """Read access to /etc/shadow""" def testReadingAsRoot(self): """Reading /etc/shadow as root""" self.skipIf(os.geteuid() != 0, "Must be root") open("/etc/shadow").close() The example program produces the following output: $ ./SkippedTestDemo.py -v Access to autoexec.bat ... SKIPPED (Only available on Windows) Access to config.sys ... SKIPPED (Only available on Windows) Reading /etc/shadow as root ... SKIPPED (Must be root) Reading /etc/shadow as non-root ... ok ------------------------------------------------------- --------------- Ran 4 tests in 0.004s OK (skipped=3) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-25 03:18 Message: Logged In: YES user_id=80475 Will this muck up some the existing test runners that people have written? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 From noreply at sourceforge.net Sat Sep 25 12:51:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 25 12:51:36 2004 Subject: [Patches] [ python-Patches-1034053 ] unittest.py patch: add skipped test functionality Message-ID: Patches item #1034053, was opened at 2004-09-24 16:08 Message generated for change (Comment added) made by remyblank You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Remy Blank (remyblank) Assigned to: Nobody/Anonymous (nobody) Summary: unittest.py patch: add skipped test functionality Initial Comment: I added the possibility for tests using the unittest.py framework to be skipped. Basically, I added two methods to TestCase: TestCase.skip(msg): skips test unconditionally TestCase.skipIf(expr, msg): skips test if expr is true These can be called either in setUp() or in the test methods. I also added reporting of skipped tests to TestResult, _TextTestResult and TextTestRunner. If no tests are skipped, everything should be the same as before. I am using Python 2.3.3, so the changes are against the file in that version. I can generate a patch for a more recent version if desired. I attached the patch against the original (unittest_skip.patch). I can provide a complete test suite for the new functionality and a usage example program. Quick usage example: class ReadShadowTest(unittest.TestCase): """Read access to /etc/shadow""" def testReadingAsRoot(self): """Reading /etc/shadow as root""" self.skipIf(os.geteuid() != 0, "Must be root") open("/etc/shadow").close() The example program produces the following output: $ ./SkippedTestDemo.py -v Access to autoexec.bat ... SKIPPED (Only available on Windows) Access to config.sys ... SKIPPED (Only available on Windows) Reading /etc/shadow as root ... SKIPPED (Must be root) Reading /etc/shadow as non-root ... ok ------------------------------------------------------- --------------- Ran 4 tests in 0.004s OK (skipped=3) ---------------------------------------------------------------------- >Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:51 Message: Logged In: YES user_id=568100 I don't think so. Basically, the patch changes the following: - Adds a class SkippedException to the unittest module - Adds a skipped attribute to TestResult, containing the list of skipped tests, and an addSkipped() method to add to the list. - Catches the SkippedException in TestCase.__call__() - Adds skip() and skipIf() to TestCase - Modifies _TextTestResult and TextTestRunner to report skipped tests *only if there are any* I see two potential problems: - Test runners based on (or using the output of) TextTestRunner. I've taken care that the output is unchanged if there are no skipped tests. - Code that uses repr() of a TestResult, as I extended it to always report skipped tests. I think this would be bad practice anyway. However, to use the test-skipping functionality, custom test runners will obviously need to be extended to report skipped tests. OTOH, I don't have a big test codebase to check. I read that e.g. Zope is using unittest. Maybe I can try to run their test suite with the patched unittest.py. I'll check. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-25 10:18 Message: Logged In: YES user_id=80475 Will this muck up some the existing test runners that people have written? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 From noreply at sourceforge.net Sat Sep 25 12:53:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 25 12:53:42 2004 Subject: [Patches] [ python-Patches-1034053 ] unittest.py patch: add skipped test functionality Message-ID: Patches item #1034053, was opened at 2004-09-24 16:08 Message generated for change (Comment added) made by remyblank You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Remy Blank (remyblank) Assigned to: Nobody/Anonymous (nobody) Summary: unittest.py patch: add skipped test functionality Initial Comment: I added the possibility for tests using the unittest.py framework to be skipped. Basically, I added two methods to TestCase: TestCase.skip(msg): skips test unconditionally TestCase.skipIf(expr, msg): skips test if expr is true These can be called either in setUp() or in the test methods. I also added reporting of skipped tests to TestResult, _TextTestResult and TextTestRunner. If no tests are skipped, everything should be the same as before. I am using Python 2.3.3, so the changes are against the file in that version. I can generate a patch for a more recent version if desired. I attached the patch against the original (unittest_skip.patch). I can provide a complete test suite for the new functionality and a usage example program. Quick usage example: class ReadShadowTest(unittest.TestCase): """Read access to /etc/shadow""" def testReadingAsRoot(self): """Reading /etc/shadow as root""" self.skipIf(os.geteuid() != 0, "Must be root") open("/etc/shadow").close() The example program produces the following output: $ ./SkippedTestDemo.py -v Access to autoexec.bat ... SKIPPED (Only available on Windows) Access to config.sys ... SKIPPED (Only available on Windows) Reading /etc/shadow as root ... SKIPPED (Must be root) Reading /etc/shadow as non-root ... ok ------------------------------------------------------- --------------- Ran 4 tests in 0.004s OK (skipped=3) ---------------------------------------------------------------------- >Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:53 Message: Logged In: YES user_id=568100 The test suite for the added functionality. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:51 Message: Logged In: YES user_id=568100 I don't think so. Basically, the patch changes the following: - Adds a class SkippedException to the unittest module - Adds a skipped attribute to TestResult, containing the list of skipped tests, and an addSkipped() method to add to the list. - Catches the SkippedException in TestCase.__call__() - Adds skip() and skipIf() to TestCase - Modifies _TextTestResult and TextTestRunner to report skipped tests *only if there are any* I see two potential problems: - Test runners based on (or using the output of) TextTestRunner. I've taken care that the output is unchanged if there are no skipped tests. - Code that uses repr() of a TestResult, as I extended it to always report skipped tests. I think this would be bad practice anyway. However, to use the test-skipping functionality, custom test runners will obviously need to be extended to report skipped tests. OTOH, I don't have a big test codebase to check. I read that e.g. Zope is using unittest. Maybe I can try to run their test suite with the patched unittest.py. I'll check. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-25 10:18 Message: Logged In: YES user_id=80475 Will this muck up some the existing test runners that people have written? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 From noreply at sourceforge.net Sat Sep 25 12:54:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 25 12:54:45 2004 Subject: [Patches] [ python-Patches-1034053 ] unittest.py patch: add skipped test functionality Message-ID: Patches item #1034053, was opened at 2004-09-24 16:08 Message generated for change (Comment added) made by remyblank You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Remy Blank (remyblank) Assigned to: Nobody/Anonymous (nobody) Summary: unittest.py patch: add skipped test functionality Initial Comment: I added the possibility for tests using the unittest.py framework to be skipped. Basically, I added two methods to TestCase: TestCase.skip(msg): skips test unconditionally TestCase.skipIf(expr, msg): skips test if expr is true These can be called either in setUp() or in the test methods. I also added reporting of skipped tests to TestResult, _TextTestResult and TextTestRunner. If no tests are skipped, everything should be the same as before. I am using Python 2.3.3, so the changes are against the file in that version. I can generate a patch for a more recent version if desired. I attached the patch against the original (unittest_skip.patch). I can provide a complete test suite for the new functionality and a usage example program. Quick usage example: class ReadShadowTest(unittest.TestCase): """Read access to /etc/shadow""" def testReadingAsRoot(self): """Reading /etc/shadow as root""" self.skipIf(os.geteuid() != 0, "Must be root") open("/etc/shadow").close() The example program produces the following output: $ ./SkippedTestDemo.py -v Access to autoexec.bat ... SKIPPED (Only available on Windows) Access to config.sys ... SKIPPED (Only available on Windows) Reading /etc/shadow as root ... SKIPPED (Must be root) Reading /etc/shadow as non-root ... ok ------------------------------------------------------- --------------- Ran 4 tests in 0.004s OK (skipped=3) ---------------------------------------------------------------------- >Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:54 Message: Logged In: YES user_id=568100 Added sample code. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:53 Message: Logged In: YES user_id=568100 The test suite for the added functionality. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:51 Message: Logged In: YES user_id=568100 I don't think so. Basically, the patch changes the following: - Adds a class SkippedException to the unittest module - Adds a skipped attribute to TestResult, containing the list of skipped tests, and an addSkipped() method to add to the list. - Catches the SkippedException in TestCase.__call__() - Adds skip() and skipIf() to TestCase - Modifies _TextTestResult and TextTestRunner to report skipped tests *only if there are any* I see two potential problems: - Test runners based on (or using the output of) TextTestRunner. I've taken care that the output is unchanged if there are no skipped tests. - Code that uses repr() of a TestResult, as I extended it to always report skipped tests. I think this would be bad practice anyway. However, to use the test-skipping functionality, custom test runners will obviously need to be extended to report skipped tests. OTOH, I don't have a big test codebase to check. I read that e.g. Zope is using unittest. Maybe I can try to run their test suite with the patched unittest.py. I'll check. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-25 10:18 Message: Logged In: YES user_id=80475 Will this muck up some the existing test runners that people have written? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 From noreply at sourceforge.net Sat Sep 25 19:19:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 25 19:20:19 2004 Subject: [Patches] [ python-Patches-1034053 ] unittest.py patch: add skipped test functionality Message-ID: Patches item #1034053, was opened at 2004-09-24 09:08 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 Category: Library (Lib) >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Remy Blank (remyblank) >Assigned to: Steve Purcell (purcell) Summary: unittest.py patch: add skipped test functionality Initial Comment: I added the possibility for tests using the unittest.py framework to be skipped. Basically, I added two methods to TestCase: TestCase.skip(msg): skips test unconditionally TestCase.skipIf(expr, msg): skips test if expr is true These can be called either in setUp() or in the test methods. I also added reporting of skipped tests to TestResult, _TextTestResult and TextTestRunner. If no tests are skipped, everything should be the same as before. I am using Python 2.3.3, so the changes are against the file in that version. I can generate a patch for a more recent version if desired. I attached the patch against the original (unittest_skip.patch). I can provide a complete test suite for the new functionality and a usage example program. Quick usage example: class ReadShadowTest(unittest.TestCase): """Read access to /etc/shadow""" def testReadingAsRoot(self): """Reading /etc/shadow as root""" self.skipIf(os.geteuid() != 0, "Must be root") open("/etc/shadow").close() The example program produces the following output: $ ./SkippedTestDemo.py -v Access to autoexec.bat ... SKIPPED (Only available on Windows) Access to config.sys ... SKIPPED (Only available on Windows) Reading /etc/shadow as root ... SKIPPED (Must be root) Reading /etc/shadow as non-root ... ok ------------------------------------------------------- --------------- Ran 4 tests in 0.004s OK (skipped=3) ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 05:54 Message: Logged In: YES user_id=568100 Added sample code. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 05:53 Message: Logged In: YES user_id=568100 The test suite for the added functionality. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 05:51 Message: Logged In: YES user_id=568100 I don't think so. Basically, the patch changes the following: - Adds a class SkippedException to the unittest module - Adds a skipped attribute to TestResult, containing the list of skipped tests, and an addSkipped() method to add to the list. - Catches the SkippedException in TestCase.__call__() - Adds skip() and skipIf() to TestCase - Modifies _TextTestResult and TextTestRunner to report skipped tests *only if there are any* I see two potential problems: - Test runners based on (or using the output of) TextTestRunner. I've taken care that the output is unchanged if there are no skipped tests. - Code that uses repr() of a TestResult, as I extended it to always report skipped tests. I think this would be bad practice anyway. However, to use the test-skipping functionality, custom test runners will obviously need to be extended to report skipped tests. OTOH, I don't have a big test codebase to check. I read that e.g. Zope is using unittest. Maybe I can try to run their test suite with the patched unittest.py. I'll check. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-25 03:18 Message: Logged In: YES user_id=80475 Will this muck up some the existing test runners that people have written? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 From polux at fastermail.com Sat Sep 25 23:40:58 2004 From: polux at fastermail.com (info) Date: Sun Sep 26 04:06:16 2004 Subject: [Patches] Press release for patches@python.org Message-ID: <200409252141.i8PLf3wn018837@emerald.accessv.com> patches@python.org Canadian Subsidy Directory 4865 Hwy. 138 St-Andrews west Ontario K0C 2A0 CANADIAN SUBSIDY DIRECTORY YEAR 2004 EDITION PRESS RELEASE Legal Deposit-National Library of Canada ISBN 2-922870-05-7 The new revised edition of the Canadian Subsidy Directory 2004 is now available. The new edition is the most complete and affordable reference for anyone looking for financial support. It is deemed to be the perfect tool for new or existing businesses, individual ventures, foundations and associations. This Publication contains more than 2600 direct and indirect financial subsidies, grants and loans offered by government departments and agencies, foundations, associations and organisations. In this new 2004 edition all programs are well described. The Canadian Subsidy Directory is the most comprehensive tool to start up a business, improve existent activities, set up a business plan, or obtain assistance from experts in fields such as: Industry, transport, agriculture, communications, municipal infrastructure, education, import-export, labor, construction and renovation, the service sector, hi-tech industries, research and development, joint ventures, arts, cinema, theatre, music and recording industry, the self employed, contests, and new talents. Assistance from and for foundations and associations, guidance to prepare a business plan, market surveys, computers, and much more! The Canadian Subsidy Directory is sold $ 69.95, to obtain a copy please call: Canadian Publications toll free at: 1 - 8 6 6 - 3 2 2 - 3 3 7 6 From noreply at sourceforge.net Sun Sep 26 11:10:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 26 11:10:41 2004 Subject: [Patches] [ python-Patches-1034053 ] unittest.py patch: add skipped test functionality Message-ID: Patches item #1034053, was opened at 2004-09-24 16:08 Message generated for change (Comment added) made by calvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Remy Blank (remyblank) Assigned to: Steve Purcell (purcell) Summary: unittest.py patch: add skipped test functionality Initial Comment: I added the possibility for tests using the unittest.py framework to be skipped. Basically, I added two methods to TestCase: TestCase.skip(msg): skips test unconditionally TestCase.skipIf(expr, msg): skips test if expr is true These can be called either in setUp() or in the test methods. I also added reporting of skipped tests to TestResult, _TextTestResult and TextTestRunner. If no tests are skipped, everything should be the same as before. I am using Python 2.3.3, so the changes are against the file in that version. I can generate a patch for a more recent version if desired. I attached the patch against the original (unittest_skip.patch). I can provide a complete test suite for the new functionality and a usage example program. Quick usage example: class ReadShadowTest(unittest.TestCase): """Read access to /etc/shadow""" def testReadingAsRoot(self): """Reading /etc/shadow as root""" self.skipIf(os.geteuid() != 0, "Must be root") open("/etc/shadow").close() The example program produces the following output: $ ./SkippedTestDemo.py -v Access to autoexec.bat ... SKIPPED (Only available on Windows) Access to config.sys ... SKIPPED (Only available on Windows) Reading /etc/shadow as root ... SKIPPED (Must be root) Reading /etc/shadow as non-root ... ok ------------------------------------------------------- --------------- Ran 4 tests in 0.004s OK (skipped=3) ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2004-09-26 11:10 Message: Logged In: YES user_id=9205 This is a nice patch. I am wondering if it can be extended to support the resource idea used in the python regression tests. That is the user has a --resource option to give a list of available resources and a test only runs if its requested resources are available. Otherwise it will be skipped. Example: TestDemo.py --resource=network --resource=audio ... would supply the network and audio resource. Or does it make more sense to put this in a separate patch? ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:54 Message: Logged In: YES user_id=568100 Added sample code. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:53 Message: Logged In: YES user_id=568100 The test suite for the added functionality. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:51 Message: Logged In: YES user_id=568100 I don't think so. Basically, the patch changes the following: - Adds a class SkippedException to the unittest module - Adds a skipped attribute to TestResult, containing the list of skipped tests, and an addSkipped() method to add to the list. - Catches the SkippedException in TestCase.__call__() - Adds skip() and skipIf() to TestCase - Modifies _TextTestResult and TextTestRunner to report skipped tests *only if there are any* I see two potential problems: - Test runners based on (or using the output of) TextTestRunner. I've taken care that the output is unchanged if there are no skipped tests. - Code that uses repr() of a TestResult, as I extended it to always report skipped tests. I think this would be bad practice anyway. However, to use the test-skipping functionality, custom test runners will obviously need to be extended to report skipped tests. OTOH, I don't have a big test codebase to check. I read that e.g. Zope is using unittest. Maybe I can try to run their test suite with the patched unittest.py. I'll check. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-25 10:18 Message: Logged In: YES user_id=80475 Will this muck up some the existing test runners that people have written? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 From noreply at sourceforge.net Sun Sep 26 12:13:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 26 12:13:41 2004 Subject: [Patches] [ python-Patches-1034053 ] unittest.py patch: add skipped test functionality Message-ID: Patches item #1034053, was opened at 2004-09-24 09:08 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Remy Blank (remyblank) Assigned to: Steve Purcell (purcell) Summary: unittest.py patch: add skipped test functionality Initial Comment: I added the possibility for tests using the unittest.py framework to be skipped. Basically, I added two methods to TestCase: TestCase.skip(msg): skips test unconditionally TestCase.skipIf(expr, msg): skips test if expr is true These can be called either in setUp() or in the test methods. I also added reporting of skipped tests to TestResult, _TextTestResult and TextTestRunner. If no tests are skipped, everything should be the same as before. I am using Python 2.3.3, so the changes are against the file in that version. I can generate a patch for a more recent version if desired. I attached the patch against the original (unittest_skip.patch). I can provide a complete test suite for the new functionality and a usage example program. Quick usage example: class ReadShadowTest(unittest.TestCase): """Read access to /etc/shadow""" def testReadingAsRoot(self): """Reading /etc/shadow as root""" self.skipIf(os.geteuid() != 0, "Must be root") open("/etc/shadow").close() The example program produces the following output: $ ./SkippedTestDemo.py -v Access to autoexec.bat ... SKIPPED (Only available on Windows) Access to config.sys ... SKIPPED (Only available on Windows) Reading /etc/shadow as root ... SKIPPED (Must be root) Reading /etc/shadow as non-root ... ok ------------------------------------------------------- --------------- Ran 4 tests in 0.004s OK (skipped=3) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-26 05:13 Message: Logged In: YES user_id=80475 The skipIf() method is sufficient. From there, it is trivial to roll your own resource check. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2004-09-26 04:10 Message: Logged In: YES user_id=9205 This is a nice patch. I am wondering if it can be extended to support the resource idea used in the python regression tests. That is the user has a --resource option to give a list of available resources and a test only runs if its requested resources are available. Otherwise it will be skipped. Example: TestDemo.py --resource=network --resource=audio ... would supply the network and audio resource. Or does it make more sense to put this in a separate patch? ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 05:54 Message: Logged In: YES user_id=568100 Added sample code. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 05:53 Message: Logged In: YES user_id=568100 The test suite for the added functionality. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 05:51 Message: Logged In: YES user_id=568100 I don't think so. Basically, the patch changes the following: - Adds a class SkippedException to the unittest module - Adds a skipped attribute to TestResult, containing the list of skipped tests, and an addSkipped() method to add to the list. - Catches the SkippedException in TestCase.__call__() - Adds skip() and skipIf() to TestCase - Modifies _TextTestResult and TextTestRunner to report skipped tests *only if there are any* I see two potential problems: - Test runners based on (or using the output of) TextTestRunner. I've taken care that the output is unchanged if there are no skipped tests. - Code that uses repr() of a TestResult, as I extended it to always report skipped tests. I think this would be bad practice anyway. However, to use the test-skipping functionality, custom test runners will obviously need to be extended to report skipped tests. OTOH, I don't have a big test codebase to check. I read that e.g. Zope is using unittest. Maybe I can try to run their test suite with the patched unittest.py. I'll check. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-25 03:18 Message: Logged In: YES user_id=80475 Will this muck up some the existing test runners that people have written? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 From noreply at sourceforge.net Mon Sep 27 05:44:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 27 05:44:59 2004 Subject: [Patches] [ python-Patches-1035255 ] Remove CoreServices / CoreFoundation dependencies in core Message-ID: Patches item #1035255, was opened at 2004-09-26 23:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035255&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: Remove CoreServices / CoreFoundation dependencies in core Initial Comment: This patch trims down the Python core on Darwin by making it independent of CoreFoundation and CoreServices. It does this by: Changed linker flags in configure/configure.in Removed the unused PyMac_GetAppletScriptFile Moved the implementation of PyMac_StrError to the MacOS module Moved the implementation of PyMac_GetFullPathname to the Carbon.File module In theory this should make Python start up faster on OS X, but I haven't benchmarked it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035255&group_id=5470 From noreply at sourceforge.net Mon Sep 27 16:22:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 27 18:02:24 2004 Subject: [Patches] [ python-Patches-1035498 ] -m option to run a module as a script Message-ID: Patches item #1035498, was opened at 2004-09-28 00:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: -m option to run a module as a script Initial Comment: Implements the '-m' option recently discussed on python-dev. Runs a module 'as if' it had been invoked from the command line. E.g., for a build directory, the following two commands are equivalent: ./python -m pdb ./python Lib/pdb.py Note that neither of these does the same thing as "./python -c "import pdb". (In this latter case, any "if __name__ == "__main__" code would not be executed, whereas it will be invoked in the first two cases). Given the vagaries of sys.path, this is quite handy - if a module can be imported, it can be easily used as a script too. Not that all modules will necessarily do anything _interesting_ when used as a script. . . The current implementation makes changes to main.c (handle the new argument), pythonrun.[ch] (new flavour of PyRun_) and import.[ch] (expose a PyImport_FindModule C API) Current limitations / to-do if this is pursued: - print sensible errors for non-Python files (e.g. hotshot) - allow 'dotted' names - decide what to do with packages (e.g. run __init__.py) - check usage messages in main.c are all still under 512 characters (I assume that limit was set for a reason) - the 1K limit on absolute file paths seems rather arbitrary. - this is code written in the wee hours of the morning, so it probably has a few other lurking 'features'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 From noreply at sourceforge.net Mon Sep 27 18:33:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 27 18:33:37 2004 Subject: [Patches] [ python-Patches-1035576 ] Add New RPM-friendly record option to setup.py Message-ID: Patches item #1035576, was opened at 2004-09-28 00:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035576&group_id=5470 Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Pitman (bruthasj) Assigned to: Nobody/Anonymous (nobody) Summary: Add New RPM-friendly record option to setup.py Initial Comment: One major weakness of the current usage of INSTALLED_FILES in bdist_rpm leaves directories unlisted thereby causing an uninstall of a package to leave these behind. This patch separates out into another option --record-rpm and function that generates a list friendly for RPM consumption. It currently handles data_dirs and install_lib (everything under site-packages). In addition, languages found under the common LC_MESSAGES sub-directory is also automatically tagged with %lang(de) attribute. Documentation does not need to be handled since RPM already sets this up if the packager uses %doc. I've run a couple of tests with this patch showing good results. Before taking the concept further, I submit it here for your review. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035576&group_id=5470 From noreply at sourceforge.net Mon Sep 27 20:50:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 27 20:50:51 2004 Subject: [Patches] [ python-Patches-1020188 ] Use Py_CLEAR where necessary to avoid crashes Message-ID: Patches item #1020188, was opened at 2004-09-01 05:35 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020188&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Michael Hudson (mwh) Summary: Use Py_CLEAR where necessary to avoid crashes Initial Comment: The Py_CLEAR macro was introduced to make it less tempting to write incorrect code in the form Py_DECREF(self->field); self->field = NULL; because that can expose a half-destroyed object if deallocation can cause self->field to be read. This patch fixes mistakes like this that still exist in the core. Only cases that are potentially dangerous are fixed in this patch. If self->field can only reference a special kind of [builtin] object, then it's just a style bug because we know that the builtin object isn't evil. Likewise if the code is operating on an automatic variable. It might be nice to fix those style bugs anyway, to discourage the broken idiom. Just for kicks, here's a way to use this bug in reversed to crash the interpreter: import array, gc, weakref a = array.array('c') wr = weakref.ref(a, lambda _: gc.get_referents(rev)) rev = reversed(a) del a list(rev) For me, this crashes immediately with a debug build and after a couple tries otherwise. Also attached is clearcand.py to help find these cases. It's not comprehensive, but it's a start. Usage: $ find src -name '*.c' | python clearcand.py | fgrep -- '->' The patch requires SF #1020185 to be applied for genobject.c to compile without warnings. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-09-27 18:50 Message: Logged In: YES user_id=4771 The grep may miss other expressions, like Py_DECREF(items[index]). There is also the dreadful case of macros: Py_DECREF(x) used in a macro which is called with self->something as x. In other words I am not sure the script can replace a (really motivated) programmer's extensive review... ---------------------------------------------------------------------- Comment By: Dima Dorfman (ddorfman) Date: 2004-09-10 14:29 Message: Logged In: YES user_id=908995 Okay, I'll post a cleaned up script this weekend. About your improvements: 1. Py_CLEAR already has the same semantics as a would-be Py_XCLEAR--it doesn't do anything if its argument is null. Py_XDECREF should definitely be checked for, though. 2. Py_DECREF(x) is probably safe; this is what I meant when I talked about operating on automatic variables in the initial comment. The grep for "->" filters out matches that are safe in this manner. It should be noted that this isn't necessarily safe, just that it's almost certainly so. In particular, it's not safe in this case: PyObject *x = ...; /* self is a struct { PyObject **something; ... } */ self->something = &x; Py_DECREF(x); x = NULL; but doing that is just insane. The grep would also miss ((*self).something), but I didn't expect to see any of those. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-10 14:09 Message: Logged In: YES user_id=6656 Yeah, I've come to a similar conclusion (finally got round to thinking about this properly this morning). I think a cleaned up script would be a good idea. Two improvements (which you may well have made already): Py_XDECREF is vulnerable too (do we want Py_XCLEAR??) and Py_DECREF(x); x == NULL is ok AFAICT when x is an identifier. ---------------------------------------------------------------------- Comment By: Dima Dorfman (ddorfman) Date: 2004-09-10 13:52 Message: Logged In: YES user_id=908995 I didn't write specific tests for these since they really would be testing for one particular line of code. It's not really hard to write them, though; I think my sample using reversed can be easily adapted to iterobject and itertools. I'm not sure whether genobject can be exploited like this, and I don't think it's worth finding out just to write a test case. On the other hand, if you (anyone) think it's worth it, I'll clean up clearcand.py not to require a pipeline and it can be added to the toolbox. For that to make sense, though, we should probably fix the style bugs that it catches so it can be reasonable to expect no output. Here are the outstanding matches that dereference something using "->": src/Modules/_bsddb.c 746 'Py_DECREF(self->myenvobj);\nself->myenvobj = NULL;' src/Modules/_bsddb.c 781 'Py_DECREF(self->myenvobj);\nself->myenvobj = NULL;' src/Modules/_bsddb.c 786 'Py_DECREF(self->associateCallback); \nself->associateCallback = NULL;' src/Modules/_bsddb.c 1184 'Py_DECREF(self->associateCallback); \nself->associateCallback = NULL;' src/Modules/svmodule.c 281 'Py_DECREF(self->ob_svideo); \nself->ob_svideo = NULL;' src/Mac/Modules/carbonevt/_CarbonEvtmodule.c 1060 'Py_DECREF(_self->ob_callback);\n_self->ob_callback = NULL;' src/Objects/unicodeobject.c 161 'Py_DECREF(unicode->defenc); \nunicode->defenc = NULL;' src/Objects/unicodeobject.c 250 'Py_DECREF(unicode->defenc); \nunicode->defenc = NULL;' unicode and sv are safe, and bsddb is on my list to look at. It shouldn't be harmful to just change all of those to Py_CLEAR, though. I can cobble up a patch for that, too. Opinions? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-08 17:33 Message: Logged In: YES user_id=80475 FWIW, rather than add specific testcases (closing the barndoor after the horse has escaped), it might be a good idea to fixup the OP's search code and add it to the toolbox. Future errors of this type are better caught through code scans than by testing stuff that already works fine. Of course, if highly motivated, you can do both :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-09-01 12:32 Message: Logged In: YES user_id=6656 Test cases would be nice. If it's easy for someone whose thought about it, that would be great, if not assign to me and I'll get to it... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-01 07:06 Message: Logged In: YES user_id=80475 Accepted and applied. See: Include/object.h 2.129 Modules/itertoolsmodule.c 1.35 Objects/enumobject.c 1.18 Objects/genobject.c 1.4 Objects/iterobject.c 1.19 Thanks for the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1020188&group_id=5470 From noreply at sourceforge.net Mon Sep 27 21:28:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 27 21:28:32 2004 Subject: [Patches] [ python-Patches-1011240 ] SystemError generated by struct.pack('P', 'notanumber') Message-ID: Patches item #1011240, was opened at 2004-08-18 06:53 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011240&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Dima Dorfman (ddorfman) Assigned to: Nobody/Anonymous (nobody) Summary: SystemError generated by struct.pack('P', 'notanumber') Initial Comment: Trying to use the struct module's 'P' format with a non-numeric arguments yields a SystemError. When the P format was implemented in rev 2.28, the get_pylong helper wasn't available, so it was less obvious how do this right. Now that the helper is available, it's straight- forward to use it to ensure proper error reporting instead of rolling our own. Interestingly, the comment in np_void_p indicates that the author knew about this problem; my guess is that they intended to fix it by changing PyLong_AsVoidPtr to generate TypeError instead, but SystemError is the right thing to do because it's consistent with the rest of the C API, and get_pylong deals with this properly. References: structmodule.c 2.28 and 2.47 ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-09-27 19:28 Message: Logged In: YES user_id=4771 Seems reasonable. Checked in as: Modules/structmodule.c 2.62 Lib/test/test_struct.py 1.19 I don't think we care about it, but for 32-bit platforms converting an int to a long and then to a void* is a waste. We could special-case ints. Not sure it's worth the trouble. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1011240&group_id=5470 From noreply at sourceforge.net Mon Sep 27 21:54:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 27 21:54:59 2004 Subject: [Patches] [ python-Patches-1009075 ] (bug 952953) execve empty 2nd arg fix Message-ID: Patches item #1009075, was opened at 2004-08-14 04:48 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009075&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Dave Watson (docwatson) Assigned to: Nobody/Anonymous (nobody) Summary: (bug 952953) execve empty 2nd arg fix Initial Comment: currently os.execve will give an error for something like os.execve("/bin/ls",[],{}) while in C this is valid behavior. This patch accepts the above empty second arg. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-09-27 19:54 Message: Logged In: YES user_id=4771 Looks complete. Checked in: Modules/posixmodule.c 2.327 Doc/lib/libos.tex 1.142 ---------------------------------------------------------------------- Comment By: Dima Dorfman (ddorfman) Date: 2004-08-14 10:31 Message: Logged In: YES user_id=908995 The patch looks good to me, and allowing this is the right thing to do. Posix explicitly allows zero arguments to be passed, and the rationale says that this is to be compatible with the C Standard, which only requires that main's argc be nonnegative. ---------------------------------------------------------------------- Comment By: Dave Watson (docwatson) Date: 2004-08-14 06:15 Message: Logged In: YES user_id=1094771 An updated patch, this fixes all exec* commands to make the second arg optionally empty, and the documentation is updated to reflect the changes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009075&group_id=5470 From noreply at sourceforge.net Mon Sep 27 23:10:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 28 00:02:17 2004 Subject: [Patches] [ python-Patches-1031687 ] atexit decorator Message-ID: Patches item #1031687, was opened at 2004-09-21 00:56 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031687&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: atexit decorator Initial Comment: Add an obvious decorator to the atexit module: @atexit(arg1, arg2) def myexitfunc(arg1, arg2): . . . If accepted, docs and tests forthcoming. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-27 16:10 Message: Logged In: YES user_id=80475 Closed due to lack of interest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031687&group_id=5470 From noreply at sourceforge.net Wed Sep 29 08:36:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 29 08:36:48 2004 Subject: [Patches] [ python-Patches-1034053 ] unittest.py patch: add skipped test functionality Message-ID: Patches item #1034053, was opened at 2004-09-25 00:08 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Remy Blank (remyblank) Assigned to: Steve Purcell (purcell) Summary: unittest.py patch: add skipped test functionality Initial Comment: I added the possibility for tests using the unittest.py framework to be skipped. Basically, I added two methods to TestCase: TestCase.skip(msg): skips test unconditionally TestCase.skipIf(expr, msg): skips test if expr is true These can be called either in setUp() or in the test methods. I also added reporting of skipped tests to TestResult, _TextTestResult and TextTestRunner. If no tests are skipped, everything should be the same as before. I am using Python 2.3.3, so the changes are against the file in that version. I can generate a patch for a more recent version if desired. I attached the patch against the original (unittest_skip.patch). I can provide a complete test suite for the new functionality and a usage example program. Quick usage example: class ReadShadowTest(unittest.TestCase): """Read access to /etc/shadow""" def testReadingAsRoot(self): """Reading /etc/shadow as root""" self.skipIf(os.geteuid() != 0, "Must be root") open("/etc/shadow").close() The example program produces the following output: $ ./SkippedTestDemo.py -v Access to autoexec.bat ... SKIPPED (Only available on Windows) Access to config.sys ... SKIPPED (Only available on Windows) Reading /etc/shadow as root ... SKIPPED (Must be root) Reading /etc/shadow as non-root ... ok ------------------------------------------------------- --------------- Ran 4 tests in 0.004s OK (skipped=3) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-29 16:36 Message: Logged In: YES user_id=1038590 I'd certainly find such a feature handy - when testing different variations of an embedded firmware image, it would make it much easier to enable/disable different tests based on the capabilities of the firmware. Ditto for the original example of cross-platform testing. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-26 20:13 Message: Logged In: YES user_id=80475 The skipIf() method is sufficient. From there, it is trivial to roll your own resource check. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2004-09-26 19:10 Message: Logged In: YES user_id=9205 This is a nice patch. I am wondering if it can be extended to support the resource idea used in the python regression tests. That is the user has a --resource option to give a list of available resources and a test only runs if its requested resources are available. Otherwise it will be skipped. Example: TestDemo.py --resource=network --resource=audio ... would supply the network and audio resource. Or does it make more sense to put this in a separate patch? ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 20:54 Message: Logged In: YES user_id=568100 Added sample code. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 20:53 Message: Logged In: YES user_id=568100 The test suite for the added functionality. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 20:51 Message: Logged In: YES user_id=568100 I don't think so. Basically, the patch changes the following: - Adds a class SkippedException to the unittest module - Adds a skipped attribute to TestResult, containing the list of skipped tests, and an addSkipped() method to add to the list. - Catches the SkippedException in TestCase.__call__() - Adds skip() and skipIf() to TestCase - Modifies _TextTestResult and TextTestRunner to report skipped tests *only if there are any* I see two potential problems: - Test runners based on (or using the output of) TextTestRunner. I've taken care that the output is unchanged if there are no skipped tests. - Code that uses repr() of a TestResult, as I extended it to always report skipped tests. I think this would be bad practice anyway. However, to use the test-skipping functionality, custom test runners will obviously need to be extended to report skipped tests. OTOH, I don't have a big test codebase to check. I read that e.g. Zope is using unittest. Maybe I can try to run their test suite with the patched unittest.py. I'll check. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-25 18:18 Message: Logged In: YES user_id=80475 Will this muck up some the existing test runners that people have written? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 From noreply at sourceforge.net Thu Sep 30 07:35:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 30 07:35:45 2004 Subject: [Patches] [ python-Patches-1037516 ] ftplib PASV error bug Message-ID: Patches item #1037516, was opened at 2004-09-30 15:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1037516&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Nelson (wayland) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib PASV error bug Initial Comment: Hi. If ftplib gets an error while doing the PASV section of the ntransfercmd it dies. I've altered it so that ntransfercmd does an autodetect, if an autodetect hasn't been done yet. If there are any problems (as I'm not a python programmer :) ), please either fix them or let me know. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1037516&group_id=5470 From noreply at sourceforge.net Thu Sep 30 10:04:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 30 10:04:39 2004 Subject: [Patches] [ python-Patches-1034053 ] unittest.py patch: add skipped test functionality Message-ID: Patches item #1034053, was opened at 2004-09-24 09:08 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Remy Blank (remyblank) Assigned to: Steve Purcell (purcell) Summary: unittest.py patch: add skipped test functionality Initial Comment: I added the possibility for tests using the unittest.py framework to be skipped. Basically, I added two methods to TestCase: TestCase.skip(msg): skips test unconditionally TestCase.skipIf(expr, msg): skips test if expr is true These can be called either in setUp() or in the test methods. I also added reporting of skipped tests to TestResult, _TextTestResult and TextTestRunner. If no tests are skipped, everything should be the same as before. I am using Python 2.3.3, so the changes are against the file in that version. I can generate a patch for a more recent version if desired. I attached the patch against the original (unittest_skip.patch). I can provide a complete test suite for the new functionality and a usage example program. Quick usage example: class ReadShadowTest(unittest.TestCase): """Read access to /etc/shadow""" def testReadingAsRoot(self): """Reading /etc/shadow as root""" self.skipIf(os.geteuid() != 0, "Must be root") open("/etc/shadow").close() The example program produces the following output: $ ./SkippedTestDemo.py -v Access to autoexec.bat ... SKIPPED (Only available on Windows) Access to config.sys ... SKIPPED (Only available on Windows) Reading /etc/shadow as root ... SKIPPED (Must be root) Reading /etc/shadow as non-root ... ok ------------------------------------------------------- --------------- Ran 4 tests in 0.004s OK (skipped=3) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-30 03:04 Message: Logged In: YES user_id=80475 After more thought, I think decorators offer a cleaner, more complete solution without further complicating the unittest module. def rootonly(f): "Decorator to skip tests that require root access" if os.geteuid() == 0: return f return lambda self: 0 @rootonly def testReadingAsRoot(self): . . . Note the rootonly() decorator need only be defined once instead of writing a full self.skipIf(condition) inside every test. Also, it appears prior to the definition rather than inside. The approach is more flexible than the original proposal though it does lack a reporting mechanism. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-29 01:36 Message: Logged In: YES user_id=1038590 I'd certainly find such a feature handy - when testing different variations of an embedded firmware image, it would make it much easier to enable/disable different tests based on the capabilities of the firmware. Ditto for the original example of cross-platform testing. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-26 05:13 Message: Logged In: YES user_id=80475 The skipIf() method is sufficient. From there, it is trivial to roll your own resource check. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2004-09-26 04:10 Message: Logged In: YES user_id=9205 This is a nice patch. I am wondering if it can be extended to support the resource idea used in the python regression tests. That is the user has a --resource option to give a list of available resources and a test only runs if its requested resources are available. Otherwise it will be skipped. Example: TestDemo.py --resource=network --resource=audio ... would supply the network and audio resource. Or does it make more sense to put this in a separate patch? ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 05:54 Message: Logged In: YES user_id=568100 Added sample code. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 05:53 Message: Logged In: YES user_id=568100 The test suite for the added functionality. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 05:51 Message: Logged In: YES user_id=568100 I don't think so. Basically, the patch changes the following: - Adds a class SkippedException to the unittest module - Adds a skipped attribute to TestResult, containing the list of skipped tests, and an addSkipped() method to add to the list. - Catches the SkippedException in TestCase.__call__() - Adds skip() and skipIf() to TestCase - Modifies _TextTestResult and TextTestRunner to report skipped tests *only if there are any* I see two potential problems: - Test runners based on (or using the output of) TextTestRunner. I've taken care that the output is unchanged if there are no skipped tests. - Code that uses repr() of a TestResult, as I extended it to always report skipped tests. I think this would be bad practice anyway. However, to use the test-skipping functionality, custom test runners will obviously need to be extended to report skipped tests. OTOH, I don't have a big test codebase to check. I read that e.g. Zope is using unittest. Maybe I can try to run their test suite with the patched unittest.py. I'll check. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-25 03:18 Message: Logged In: YES user_id=80475 Will this muck up some the existing test runners that people have written? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 From noreply at sourceforge.net Thu Sep 30 11:37:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 30 11:37:50 2004 Subject: [Patches] [ python-Patches-1034053 ] unittest.py patch: add skipped test functionality Message-ID: Patches item #1034053, was opened at 2004-09-24 16:08 Message generated for change (Comment added) made by remyblank You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Remy Blank (remyblank) Assigned to: Steve Purcell (purcell) Summary: unittest.py patch: add skipped test functionality Initial Comment: I added the possibility for tests using the unittest.py framework to be skipped. Basically, I added two methods to TestCase: TestCase.skip(msg): skips test unconditionally TestCase.skipIf(expr, msg): skips test if expr is true These can be called either in setUp() or in the test methods. I also added reporting of skipped tests to TestResult, _TextTestResult and TextTestRunner. If no tests are skipped, everything should be the same as before. I am using Python 2.3.3, so the changes are against the file in that version. I can generate a patch for a more recent version if desired. I attached the patch against the original (unittest_skip.patch). I can provide a complete test suite for the new functionality and a usage example program. Quick usage example: class ReadShadowTest(unittest.TestCase): """Read access to /etc/shadow""" def testReadingAsRoot(self): """Reading /etc/shadow as root""" self.skipIf(os.geteuid() != 0, "Must be root") open("/etc/shadow").close() The example program produces the following output: $ ./SkippedTestDemo.py -v Access to autoexec.bat ... SKIPPED (Only available on Windows) Access to config.sys ... SKIPPED (Only available on Windows) Reading /etc/shadow as root ... SKIPPED (Must be root) Reading /etc/shadow as non-root ... ok ------------------------------------------------------- --------------- Ran 4 tests in 0.004s OK (skipped=3) ---------------------------------------------------------------------- >Comment By: Remy Blank (remyblank) Date: 2004-09-30 11:37 Message: Logged In: YES user_id=568100 I strongly disagree. Skipped tests should not just be transformed into passed tests, but must be recorded as skipped and reported to the user. Knowing that a test skipped is important information. The Python regression tests (although I'm not familiar with them) provide the same "skip" functionality, and I don't think people would be happy to replace it with just "pass". The decorator approach is an interesting idea, though, and could be combined with skipIf() so as to provide the other advantages you mention, namely single definition and appearance prior to definition. Something along the following: def rootOnly(f): """Decorator to skip tests that require root access""" def wrapper(self): self.skipIf(os.getuid() != 0, "Must be root") self.f() wrapper.__doc__ = f.__doc__ return wrapper class ReadShadowTest(unittest.TestCase): """Read access to /etc/shadow""" @rootOnly def testReadingAsRoot(self): """Reading /etc/shadow as root""" open("/etc/shadow").close() Note that I'm not yet familiar with decorators, so the wrapper() function might not be the correct way to do this. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-30 10:04 Message: Logged In: YES user_id=80475 After more thought, I think decorators offer a cleaner, more complete solution without further complicating the unittest module. def rootonly(f): "Decorator to skip tests that require root access" if os.geteuid() == 0: return f return lambda self: 0 @rootonly def testReadingAsRoot(self): . . . Note the rootonly() decorator need only be defined once instead of writing a full self.skipIf(condition) inside every test. Also, it appears prior to the definition rather than inside. The approach is more flexible than the original proposal though it does lack a reporting mechanism. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-29 08:36 Message: Logged In: YES user_id=1038590 I'd certainly find such a feature handy - when testing different variations of an embedded firmware image, it would make it much easier to enable/disable different tests based on the capabilities of the firmware. Ditto for the original example of cross-platform testing. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-26 12:13 Message: Logged In: YES user_id=80475 The skipIf() method is sufficient. From there, it is trivial to roll your own resource check. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2004-09-26 11:10 Message: Logged In: YES user_id=9205 This is a nice patch. I am wondering if it can be extended to support the resource idea used in the python regression tests. That is the user has a --resource option to give a list of available resources and a test only runs if its requested resources are available. Otherwise it will be skipped. Example: TestDemo.py --resource=network --resource=audio ... would supply the network and audio resource. Or does it make more sense to put this in a separate patch? ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:54 Message: Logged In: YES user_id=568100 Added sample code. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:53 Message: Logged In: YES user_id=568100 The test suite for the added functionality. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:51 Message: Logged In: YES user_id=568100 I don't think so. Basically, the patch changes the following: - Adds a class SkippedException to the unittest module - Adds a skipped attribute to TestResult, containing the list of skipped tests, and an addSkipped() method to add to the list. - Catches the SkippedException in TestCase.__call__() - Adds skip() and skipIf() to TestCase - Modifies _TextTestResult and TextTestRunner to report skipped tests *only if there are any* I see two potential problems: - Test runners based on (or using the output of) TextTestRunner. I've taken care that the output is unchanged if there are no skipped tests. - Code that uses repr() of a TestResult, as I extended it to always report skipped tests. I think this would be bad practice anyway. However, to use the test-skipping functionality, custom test runners will obviously need to be extended to report skipped tests. OTOH, I don't have a big test codebase to check. I read that e.g. Zope is using unittest. Maybe I can try to run their test suite with the patched unittest.py. I'll check. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-25 10:18 Message: Logged In: YES user_id=80475 Will this muck up some the existing test runners that people have written? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 From noreply at sourceforge.net Thu Sep 30 11:39:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 30 11:39:43 2004 Subject: [Patches] [ python-Patches-1035498 ] -m option to run a module as a script Message-ID: Patches item #1035498, was opened at 2004-09-28 00:22 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: -m option to run a module as a script Initial Comment: Implements the '-m' option recently discussed on python-dev. Runs a module 'as if' it had been invoked from the command line. E.g., for a build directory, the following two commands are equivalent: ./python -m pdb ./python Lib/pdb.py Note that neither of these does the same thing as "./python -c "import pdb". (In this latter case, any "if __name__ == "__main__" code would not be executed, whereas it will be invoked in the first two cases). Given the vagaries of sys.path, this is quite handy - if a module can be imported, it can be easily used as a script too. Not that all modules will necessarily do anything _interesting_ when used as a script. . . The current implementation makes changes to main.c (handle the new argument), pythonrun.[ch] (new flavour of PyRun_) and import.[ch] (expose a PyImport_FindModule C API) Current limitations / to-do if this is pursued: - print sensible errors for non-Python files (e.g. hotshot) - allow 'dotted' names - decide what to do with packages (e.g. run __init__.py) - check usage messages in main.c are all still under 512 characters (I assume that limit was set for a reason) - the 1K limit on absolute file paths seems rather arbitrary. - this is code written in the wee hours of the morning, so it probably has a few other lurking 'features'. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:39 Message: Logged In: YES user_id=1038590 New version of patch attached (run_module_2.diff). This version allows modules within packages to be executed. It does this *without* loading the packages first (just as if the script were specified directly on the command line). It's also a little more responsive when it comes to error message, and I've confirmed that the usage message components are now under 512 bytes each. The FindModule method is now marked as private (i.e. with leading underscore). The limit on file paths in pythonrun.c is now taken from osdefs.h (the same limit that import.c already uses) The only bug I know of is that it misbehaves if you supply a name like "a.b.module.d". You will get an ImportError saying that d was not found, and the file pointer for 'module' won't get closed properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 From noreply at sourceforge.net Thu Sep 30 11:48:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 30 11:49:02 2004 Subject: [Patches] [ python-Patches-1035498 ] -m option to run a module as a script Message-ID: Patches item #1035498, was opened at 2004-09-28 00:22 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: -m option to run a module as a script Initial Comment: Implements the '-m' option recently discussed on python-dev. Runs a module 'as if' it had been invoked from the command line. E.g., for a build directory, the following two commands are equivalent: ./python -m pdb ./python Lib/pdb.py Note that neither of these does the same thing as "./python -c "import pdb". (In this latter case, any "if __name__ == "__main__" code would not be executed, whereas it will be invoked in the first two cases). Given the vagaries of sys.path, this is quite handy - if a module can be imported, it can be easily used as a script too. Not that all modules will necessarily do anything _interesting_ when used as a script. . . The current implementation makes changes to main.c (handle the new argument), pythonrun.[ch] (new flavour of PyRun_) and import.[ch] (expose a PyImport_FindModule C API) Current limitations / to-do if this is pursued: - print sensible errors for non-Python files (e.g. hotshot) - allow 'dotted' names - decide what to do with packages (e.g. run __init__.py) - check usage messages in main.c are all still under 512 characters (I assume that limit was set for a reason) - the 1K limit on absolute file paths seems rather arbitrary. - this is code written in the wee hours of the morning, so it probably has a few other lurking 'features'. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:48 Message: Logged In: YES user_id=1038590 Barry, kicking this in your direction solely because you were one of the people to comment on it on py-dev. Feel free to say 'too busy' :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-30 19:39 Message: Logged In: YES user_id=1038590 New version of patch attached (run_module_2.diff). This version allows modules within packages to be executed. It does this *without* loading the packages first (just as if the script were specified directly on the command line). It's also a little more responsive when it comes to error message, and I've confirmed that the usage message components are now under 512 bytes each. The FindModule method is now marked as private (i.e. with leading underscore). The limit on file paths in pythonrun.c is now taken from osdefs.h (the same limit that import.c already uses) The only bug I know of is that it misbehaves if you supply a name like "a.b.module.d". You will get an ImportError saying that d was not found, and the file pointer for 'module' won't get closed properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1035498&group_id=5470 From noreply at sourceforge.net Thu Sep 30 13:31:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 30 13:31:19 2004 Subject: [Patches] [ python-Patches-1034053 ] unittest.py patch: add skipped test functionality Message-ID: Patches item #1034053, was opened at 2004-09-24 16:08 Message generated for change (Comment added) made by purcell You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Remy Blank (remyblank) Assigned to: Steve Purcell (purcell) Summary: unittest.py patch: add skipped test functionality Initial Comment: I added the possibility for tests using the unittest.py framework to be skipped. Basically, I added two methods to TestCase: TestCase.skip(msg): skips test unconditionally TestCase.skipIf(expr, msg): skips test if expr is true These can be called either in setUp() or in the test methods. I also added reporting of skipped tests to TestResult, _TextTestResult and TextTestRunner. If no tests are skipped, everything should be the same as before. I am using Python 2.3.3, so the changes are against the file in that version. I can generate a patch for a more recent version if desired. I attached the patch against the original (unittest_skip.patch). I can provide a complete test suite for the new functionality and a usage example program. Quick usage example: class ReadShadowTest(unittest.TestCase): """Read access to /etc/shadow""" def testReadingAsRoot(self): """Reading /etc/shadow as root""" self.skipIf(os.geteuid() != 0, "Must be root") open("/etc/shadow").close() The example program produces the following output: $ ./SkippedTestDemo.py -v Access to autoexec.bat ... SKIPPED (Only available on Windows) Access to config.sys ... SKIPPED (Only available on Windows) Reading /etc/shadow as root ... SKIPPED (Must be root) Reading /etc/shadow as non-root ... ok ------------------------------------------------------- --------------- Ran 4 tests in 0.004s OK (skipped=3) ---------------------------------------------------------------------- >Comment By: Steve Purcell (purcell) Date: 2004-09-30 13:31 Message: Logged In: YES user_id=21477 I've been really tied up; sorry for the delayed response, but I've been reading all the comments on this patch. Overall, I'm leaning in favour of accepting this patch, probably with some minor changes to the way skipped tests are reported. The concept of skipping is one that has been kept out of JUnit, but is found in NUnit and is well regarded there. In my XP coaching work ThoughtWorks I see an obscenely large number of JUnit tests, and a common mistake is to comment out test method bodies, leading to "false passes". Explicit support for skipping in unittest would mitigate this. I agree with Remy that the decorator example, though ingenious, has the wrong result; skipped tests will be reported as successes. In order for a test method to decide if it should be skipped, it will often need information from 'self' that was gathered during setUp() -- this makes decorators cumbersome for this. Also, a decorator solution would not allow test methods to skip if the setUp() method itself decides to skip(). Please give me a few more days on this, and I'll work on integrating and tweaking the patch. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-30 11:37 Message: Logged In: YES user_id=568100 I strongly disagree. Skipped tests should not just be transformed into passed tests, but must be recorded as skipped and reported to the user. Knowing that a test skipped is important information. The Python regression tests (although I'm not familiar with them) provide the same "skip" functionality, and I don't think people would be happy to replace it with just "pass". The decorator approach is an interesting idea, though, and could be combined with skipIf() so as to provide the other advantages you mention, namely single definition and appearance prior to definition. Something along the following: def rootOnly(f): """Decorator to skip tests that require root access""" def wrapper(self): self.skipIf(os.getuid() != 0, "Must be root") self.f() wrapper.__doc__ = f.__doc__ return wrapper class ReadShadowTest(unittest.TestCase): """Read access to /etc/shadow""" @rootOnly def testReadingAsRoot(self): """Reading /etc/shadow as root""" open("/etc/shadow").close() Note that I'm not yet familiar with decorators, so the wrapper() function might not be the correct way to do this. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-30 10:04 Message: Logged In: YES user_id=80475 After more thought, I think decorators offer a cleaner, more complete solution without further complicating the unittest module. def rootonly(f): "Decorator to skip tests that require root access" if os.geteuid() == 0: return f return lambda self: 0 @rootonly def testReadingAsRoot(self): . . . Note the rootonly() decorator need only be defined once instead of writing a full self.skipIf(condition) inside every test. Also, it appears prior to the definition rather than inside. The approach is more flexible than the original proposal though it does lack a reporting mechanism. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-29 08:36 Message: Logged In: YES user_id=1038590 I'd certainly find such a feature handy - when testing different variations of an embedded firmware image, it would make it much easier to enable/disable different tests based on the capabilities of the firmware. Ditto for the original example of cross-platform testing. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-26 12:13 Message: Logged In: YES user_id=80475 The skipIf() method is sufficient. From there, it is trivial to roll your own resource check. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2004-09-26 11:10 Message: Logged In: YES user_id=9205 This is a nice patch. I am wondering if it can be extended to support the resource idea used in the python regression tests. That is the user has a --resource option to give a list of available resources and a test only runs if its requested resources are available. Otherwise it will be skipped. Example: TestDemo.py --resource=network --resource=audio ... would supply the network and audio resource. Or does it make more sense to put this in a separate patch? ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:54 Message: Logged In: YES user_id=568100 Added sample code. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:53 Message: Logged In: YES user_id=568100 The test suite for the added functionality. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:51 Message: Logged In: YES user_id=568100 I don't think so. Basically, the patch changes the following: - Adds a class SkippedException to the unittest module - Adds a skipped attribute to TestResult, containing the list of skipped tests, and an addSkipped() method to add to the list. - Catches the SkippedException in TestCase.__call__() - Adds skip() and skipIf() to TestCase - Modifies _TextTestResult and TextTestRunner to report skipped tests *only if there are any* I see two potential problems: - Test runners based on (or using the output of) TextTestRunner. I've taken care that the output is unchanged if there are no skipped tests. - Code that uses repr() of a TestResult, as I extended it to always report skipped tests. I think this would be bad practice anyway. However, to use the test-skipping functionality, custom test runners will obviously need to be extended to report skipped tests. OTOH, I don't have a big test codebase to check. I read that e.g. Zope is using unittest. Maybe I can try to run their test suite with the patched unittest.py. I'll check. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-25 10:18 Message: Logged In: YES user_id=80475 Will this muck up some the existing test runners that people have written? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 From noreply at sourceforge.net Thu Sep 30 15:46:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 30 15:46:55 2004 Subject: [Patches] [ python-Patches-1034053 ] unittest.py patch: add skipped test functionality Message-ID: Patches item #1034053, was opened at 2004-09-24 16:08 Message generated for change (Comment added) made by remyblank You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Remy Blank (remyblank) Assigned to: Steve Purcell (purcell) Summary: unittest.py patch: add skipped test functionality Initial Comment: I added the possibility for tests using the unittest.py framework to be skipped. Basically, I added two methods to TestCase: TestCase.skip(msg): skips test unconditionally TestCase.skipIf(expr, msg): skips test if expr is true These can be called either in setUp() or in the test methods. I also added reporting of skipped tests to TestResult, _TextTestResult and TextTestRunner. If no tests are skipped, everything should be the same as before. I am using Python 2.3.3, so the changes are against the file in that version. I can generate a patch for a more recent version if desired. I attached the patch against the original (unittest_skip.patch). I can provide a complete test suite for the new functionality and a usage example program. Quick usage example: class ReadShadowTest(unittest.TestCase): """Read access to /etc/shadow""" def testReadingAsRoot(self): """Reading /etc/shadow as root""" self.skipIf(os.geteuid() != 0, "Must be root") open("/etc/shadow").close() The example program produces the following output: $ ./SkippedTestDemo.py -v Access to autoexec.bat ... SKIPPED (Only available on Windows) Access to config.sys ... SKIPPED (Only available on Windows) Reading /etc/shadow as root ... SKIPPED (Must be root) Reading /etc/shadow as non-root ... ok ------------------------------------------------------- --------------- Ran 4 tests in 0.004s OK (skipped=3) ---------------------------------------------------------------------- >Comment By: Remy Blank (remyblank) Date: 2004-09-30 15:46 Message: Logged In: YES user_id=568100 Speaking of decorators, the NUnit example is quite instructive, re. their use of attributes to mark classes as test cases, methods as test methods, grouping tests by category, and for that matter ignoring tests temporarily. I expect all of this can be done with decorators: @testMethod to mark individual tests, @category("LongRunning"), @ignore, @explicit, ... And if I'm not mistaken all of this can be added without breaking backward compatibility. Interesting times lay ahead! ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2004-09-30 13:31 Message: Logged In: YES user_id=21477 I've been really tied up; sorry for the delayed response, but I've been reading all the comments on this patch. Overall, I'm leaning in favour of accepting this patch, probably with some minor changes to the way skipped tests are reported. The concept of skipping is one that has been kept out of JUnit, but is found in NUnit and is well regarded there. In my XP coaching work ThoughtWorks I see an obscenely large number of JUnit tests, and a common mistake is to comment out test method bodies, leading to "false passes". Explicit support for skipping in unittest would mitigate this. I agree with Remy that the decorator example, though ingenious, has the wrong result; skipped tests will be reported as successes. In order for a test method to decide if it should be skipped, it will often need information from 'self' that was gathered during setUp() -- this makes decorators cumbersome for this. Also, a decorator solution would not allow test methods to skip if the setUp() method itself decides to skip(). Please give me a few more days on this, and I'll work on integrating and tweaking the patch. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-30 11:37 Message: Logged In: YES user_id=568100 I strongly disagree. Skipped tests should not just be transformed into passed tests, but must be recorded as skipped and reported to the user. Knowing that a test skipped is important information. The Python regression tests (although I'm not familiar with them) provide the same "skip" functionality, and I don't think people would be happy to replace it with just "pass". The decorator approach is an interesting idea, though, and could be combined with skipIf() so as to provide the other advantages you mention, namely single definition and appearance prior to definition. Something along the following: def rootOnly(f): """Decorator to skip tests that require root access""" def wrapper(self): self.skipIf(os.getuid() != 0, "Must be root") self.f() wrapper.__doc__ = f.__doc__ return wrapper class ReadShadowTest(unittest.TestCase): """Read access to /etc/shadow""" @rootOnly def testReadingAsRoot(self): """Reading /etc/shadow as root""" open("/etc/shadow").close() Note that I'm not yet familiar with decorators, so the wrapper() function might not be the correct way to do this. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-30 10:04 Message: Logged In: YES user_id=80475 After more thought, I think decorators offer a cleaner, more complete solution without further complicating the unittest module. def rootonly(f): "Decorator to skip tests that require root access" if os.geteuid() == 0: return f return lambda self: 0 @rootonly def testReadingAsRoot(self): . . . Note the rootonly() decorator need only be defined once instead of writing a full self.skipIf(condition) inside every test. Also, it appears prior to the definition rather than inside. The approach is more flexible than the original proposal though it does lack a reporting mechanism. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-29 08:36 Message: Logged In: YES user_id=1038590 I'd certainly find such a feature handy - when testing different variations of an embedded firmware image, it would make it much easier to enable/disable different tests based on the capabilities of the firmware. Ditto for the original example of cross-platform testing. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-26 12:13 Message: Logged In: YES user_id=80475 The skipIf() method is sufficient. From there, it is trivial to roll your own resource check. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2004-09-26 11:10 Message: Logged In: YES user_id=9205 This is a nice patch. I am wondering if it can be extended to support the resource idea used in the python regression tests. That is the user has a --resource option to give a list of available resources and a test only runs if its requested resources are available. Otherwise it will be skipped. Example: TestDemo.py --resource=network --resource=audio ... would supply the network and audio resource. Or does it make more sense to put this in a separate patch? ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:54 Message: Logged In: YES user_id=568100 Added sample code. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:53 Message: Logged In: YES user_id=568100 The test suite for the added functionality. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:51 Message: Logged In: YES user_id=568100 I don't think so. Basically, the patch changes the following: - Adds a class SkippedException to the unittest module - Adds a skipped attribute to TestResult, containing the list of skipped tests, and an addSkipped() method to add to the list. - Catches the SkippedException in TestCase.__call__() - Adds skip() and skipIf() to TestCase - Modifies _TextTestResult and TextTestRunner to report skipped tests *only if there are any* I see two potential problems: - Test runners based on (or using the output of) TextTestRunner. I've taken care that the output is unchanged if there are no skipped tests. - Code that uses repr() of a TestResult, as I extended it to always report skipped tests. I think this would be bad practice anyway. However, to use the test-skipping functionality, custom test runners will obviously need to be extended to report skipped tests. OTOH, I don't have a big test codebase to check. I read that e.g. Zope is using unittest. Maybe I can try to run their test suite with the patched unittest.py. I'll check. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-25 10:18 Message: Logged In: YES user_id=80475 Will this muck up some the existing test runners that people have written? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 From noreply at sourceforge.net Thu Sep 30 16:20:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 30 16:20:42 2004 Subject: [Patches] [ python-Patches-1034053 ] unittest.py patch: add skipped test functionality Message-ID: Patches item #1034053, was opened at 2004-09-24 16:08 Message generated for change (Comment added) made by purcell You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Remy Blank (remyblank) Assigned to: Steve Purcell (purcell) Summary: unittest.py patch: add skipped test functionality Initial Comment: I added the possibility for tests using the unittest.py framework to be skipped. Basically, I added two methods to TestCase: TestCase.skip(msg): skips test unconditionally TestCase.skipIf(expr, msg): skips test if expr is true These can be called either in setUp() or in the test methods. I also added reporting of skipped tests to TestResult, _TextTestResult and TextTestRunner. If no tests are skipped, everything should be the same as before. I am using Python 2.3.3, so the changes are against the file in that version. I can generate a patch for a more recent version if desired. I attached the patch against the original (unittest_skip.patch). I can provide a complete test suite for the new functionality and a usage example program. Quick usage example: class ReadShadowTest(unittest.TestCase): """Read access to /etc/shadow""" def testReadingAsRoot(self): """Reading /etc/shadow as root""" self.skipIf(os.geteuid() != 0, "Must be root") open("/etc/shadow").close() The example program produces the following output: $ ./SkippedTestDemo.py -v Access to autoexec.bat ... SKIPPED (Only available on Windows) Access to config.sys ... SKIPPED (Only available on Windows) Reading /etc/shadow as root ... SKIPPED (Must be root) Reading /etc/shadow as non-root ... ok ------------------------------------------------------- --------------- Ran 4 tests in 0.004s OK (skipped=3) ---------------------------------------------------------------------- >Comment By: Steve Purcell (purcell) Date: 2004-09-30 16:20 Message: Logged In: YES user_id=21477 Yes, that's right, and I would consider providing a number of such decorators at a later date. I've just spent a little time chatting to my colleage Joe Walnes (of nMock fame) about all this; he's more of an nUnit authority than I am. Categories are particularly interesting. In theory, it would be possible to get the same effect using TestSuites, but in practice tool support (including unittest.main()) discourages the use of TestSuites in favour of magic discovery of test cases; categories would be a better way of allowing tools to dynamically construct suites. @ignore could be considered equivalent to @category("ignored") in a certain sense. Skipping is not quite the same as ignoring, since it's determined at run-time, and so I think it is appropriate to add methods to explicitly support it. Interesting times indeed. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-30 15:46 Message: Logged In: YES user_id=568100 Speaking of decorators, the NUnit example is quite instructive, re. their use of attributes to mark classes as test cases, methods as test methods, grouping tests by category, and for that matter ignoring tests temporarily. I expect all of this can be done with decorators: @testMethod to mark individual tests, @category("LongRunning"), @ignore, @explicit, ... And if I'm not mistaken all of this can be added without breaking backward compatibility. Interesting times lay ahead! ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2004-09-30 13:31 Message: Logged In: YES user_id=21477 I've been really tied up; sorry for the delayed response, but I've been reading all the comments on this patch. Overall, I'm leaning in favour of accepting this patch, probably with some minor changes to the way skipped tests are reported. The concept of skipping is one that has been kept out of JUnit, but is found in NUnit and is well regarded there. In my XP coaching work ThoughtWorks I see an obscenely large number of JUnit tests, and a common mistake is to comment out test method bodies, leading to "false passes". Explicit support for skipping in unittest would mitigate this. I agree with Remy that the decorator example, though ingenious, has the wrong result; skipped tests will be reported as successes. In order for a test method to decide if it should be skipped, it will often need information from 'self' that was gathered during setUp() -- this makes decorators cumbersome for this. Also, a decorator solution would not allow test methods to skip if the setUp() method itself decides to skip(). Please give me a few more days on this, and I'll work on integrating and tweaking the patch. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-30 11:37 Message: Logged In: YES user_id=568100 I strongly disagree. Skipped tests should not just be transformed into passed tests, but must be recorded as skipped and reported to the user. Knowing that a test skipped is important information. The Python regression tests (although I'm not familiar with them) provide the same "skip" functionality, and I don't think people would be happy to replace it with just "pass". The decorator approach is an interesting idea, though, and could be combined with skipIf() so as to provide the other advantages you mention, namely single definition and appearance prior to definition. Something along the following: def rootOnly(f): """Decorator to skip tests that require root access""" def wrapper(self): self.skipIf(os.getuid() != 0, "Must be root") self.f() wrapper.__doc__ = f.__doc__ return wrapper class ReadShadowTest(unittest.TestCase): """Read access to /etc/shadow""" @rootOnly def testReadingAsRoot(self): """Reading /etc/shadow as root""" open("/etc/shadow").close() Note that I'm not yet familiar with decorators, so the wrapper() function might not be the correct way to do this. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-30 10:04 Message: Logged In: YES user_id=80475 After more thought, I think decorators offer a cleaner, more complete solution without further complicating the unittest module. def rootonly(f): "Decorator to skip tests that require root access" if os.geteuid() == 0: return f return lambda self: 0 @rootonly def testReadingAsRoot(self): . . . Note the rootonly() decorator need only be defined once instead of writing a full self.skipIf(condition) inside every test. Also, it appears prior to the definition rather than inside. The approach is more flexible than the original proposal though it does lack a reporting mechanism. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-09-29 08:36 Message: Logged In: YES user_id=1038590 I'd certainly find such a feature handy - when testing different variations of an embedded firmware image, it would make it much easier to enable/disable different tests based on the capabilities of the firmware. Ditto for the original example of cross-platform testing. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-26 12:13 Message: Logged In: YES user_id=80475 The skipIf() method is sufficient. From there, it is trivial to roll your own resource check. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2004-09-26 11:10 Message: Logged In: YES user_id=9205 This is a nice patch. I am wondering if it can be extended to support the resource idea used in the python regression tests. That is the user has a --resource option to give a list of available resources and a test only runs if its requested resources are available. Otherwise it will be skipped. Example: TestDemo.py --resource=network --resource=audio ... would supply the network and audio resource. Or does it make more sense to put this in a separate patch? ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:54 Message: Logged In: YES user_id=568100 Added sample code. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:53 Message: Logged In: YES user_id=568100 The test suite for the added functionality. ---------------------------------------------------------------------- Comment By: Remy Blank (remyblank) Date: 2004-09-25 12:51 Message: Logged In: YES user_id=568100 I don't think so. Basically, the patch changes the following: - Adds a class SkippedException to the unittest module - Adds a skipped attribute to TestResult, containing the list of skipped tests, and an addSkipped() method to add to the list. - Catches the SkippedException in TestCase.__call__() - Adds skip() and skipIf() to TestCase - Modifies _TextTestResult and TextTestRunner to report skipped tests *only if there are any* I see two potential problems: - Test runners based on (or using the output of) TextTestRunner. I've taken care that the output is unchanged if there are no skipped tests. - Code that uses repr() of a TestResult, as I extended it to always report skipped tests. I think this would be bad practice anyway. However, to use the test-skipping functionality, custom test runners will obviously need to be extended to report skipped tests. OTOH, I don't have a big test codebase to check. I read that e.g. Zope is using unittest. Maybe I can try to run their test suite with the patched unittest.py. I'll check. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-09-25 10:18 Message: Logged In: YES user_id=80475 Will this muck up some the existing test runners that people have written? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1034053&group_id=5470 From noreply at sourceforge.net Thu Sep 30 21:10:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 30 21:10:15 2004 Subject: [Patches] [ python-Patches-1037974 ] urllib2 HTTP digest authentication fix Message-ID: Patches item #1037974, was opened at 2004-09-30 13:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1037974&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mathieu Fenniak (mfenniak) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 HTTP digest authentication fix Initial Comment: Although the 'algorithm' component of the Authorization header is considered optional by RFC 2617, there are sites that do not function without providing algorithm notification. Specifically, this problem is encounted with LiveJournal RSS feeds (where HTTP digest authentication can be used to view non-public livejournal entries). This patch makes the algorithm flag always sent in the Authorization header. The following test script demonstrates the problem for a LiveJournal RSS feed (username and password must be entered): import urllib2 class PasswordMgr(object): def find_user_password(self, realm, authuri): return "someuser", "somepass" def add_password(self): pass rssURI = "http://livejournal.com/users/someuser/data/rss? auth=digest" handler = urllib2.HTTPDigestAuthHandler(PasswordMgr()) opener = urllib2.build_opener(handler) opener.open(rssURI) With the attached patch, this works successfully. Without it, it fails with an HTTP 401 error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1037974&group_id=5470 From noreply at sourceforge.net Thu Sep 30 21:13:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 30 22:02:47 2004 Subject: [Patches] [ python-Patches-1037974 ] urllib2 HTTP digest authentication fix Message-ID: Patches item #1037974, was opened at 2004-09-30 13:10 Message generated for change (Comment added) made by mfenniak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1037974&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mathieu Fenniak (mfenniak) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 HTTP digest authentication fix Initial Comment: Although the 'algorithm' component of the Authorization header is considered optional by RFC 2617, there are sites that do not function without providing algorithm notification. Specifically, this problem is encounted with LiveJournal RSS feeds (where HTTP digest authentication can be used to view non-public livejournal entries). This patch makes the algorithm flag always sent in the Authorization header. The following test script demonstrates the problem for a LiveJournal RSS feed (username and password must be entered): import urllib2 class PasswordMgr(object): def find_user_password(self, realm, authuri): return "someuser", "somepass" def add_password(self): pass rssURI = "http://livejournal.com/users/someuser/data/rss? auth=digest" handler = urllib2.HTTPDigestAuthHandler(PasswordMgr()) opener = urllib2.build_opener(handler) opener.open(rssURI) With the attached patch, this works successfully. Without it, it fails with an HTTP 401 error. ---------------------------------------------------------------------- >Comment By: Mathieu Fenniak (mfenniak) Date: 2004-09-30 13:13 Message: Logged In: YES user_id=1131071 Err, sorry, it appears I didn't attach the patch. Here it is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1037974&group_id=5470